TL;DR: Developer Portals reduce the complexity of platform engineering by providing a common interface. Software Catalogs provide visibility into software, ownership, dependencies, and technical relationships.
Still remember Backstage?
Backstage is a good example of a Developer Portal that includes a Software Catalog and other platform engineering capabilities.
However, using Backstage as the example can make these concepts appear more tightly coupled than they actually are. Before continuing, we should clarify what a Developer Portal is and what a Service Catalog is.
Developer Portals
We will focus on Internal Developer Portals (IDPs) first.
An Internal Developer Portal (IDP) is a centralized interface that allows software engineers to interact with an organization’s platform engineering ecosystem. It brings together capabilities such as software catalogs, infrastructure, CI/CD pipelines, security policies, documentation, and observability into a common developer experience.
An IDP can provide several core functions:
1. Software Catalog A central inventory of software components, services, APIs, systems, teams, and their relationships. This is what we will focus on in this post.
2. Developer Self-Service A way for developers to request or provision standardized resources and capabilities. We will discuss this further in Golden Paths.
3. Documentation as Code (DaC) A centralized place to discover and access technical documentation associated with software and platform components.
4. Scorecards & Engineering Governance A way to expose engineering standards, ownership, maturity, and operational information. We will discuss the measurement side of this later in DORA Metrics.
What IDPs Solve?
High Cognitive Load: Engineers must learn and switch contexts between dozens of distinct tools such as Kubernetes, AWS/GCP, Terraform, Argo CD, GitHub, PagerDuty, Datadog, and Vault.
Platform Bottlenecks: DevOps and Infrastructure teams become bottlenecked by manual ticket requests for routine provisioning tasks, such as creating a microservice, spinning up a database, or requesting cloud permissions.
Orphaned Software & Fragmentation: Lack of visibility can lead to unknown service ownership, missing documentation, abandoned cloud resources, and unmonitored security risks.
Service Catalogs
A Service Catalog is a structured inventory of services that an organization provides, operates, or makes available to developers and other internal users.
What exactly is being catalogued?
A Software Catalog can act as a System of Record for software metadata and ownership. It indexes technical assets across the organization—microservices, monoliths, APIs, libraries, databases, serverless functions, and infrastructure—and maps the relationships between them.
The catalog can collect metadata from different systems, including source repositories, deployment environments, CI/CD pipelines, cloud platforms, and observability tools. This gives developers a common view of what exists, who owns it, where it runs, and how it relates to other components.
For example, a service entry may identify its source repository, deployment environment, framework, current version, dependencies, responsible engineering team, documentation, communication channel, and on-call information.
By mapping these relationships, the Software Catalog can also help engineers understand upstream and downstream dependencies and estimate the potential blast radius of a failure or change.
The important point is that the catalog brings information from different systems together into a common model that developers can discover and navigate.
Back to Certified Cloud Native Platform Engineering Associate Preparation