How open source service catalogs changed in 2025

Editor's note: This post was updated 24 January 2025 to include more service catalog options and provide a more comprehensive overview of how the industry has changed since this article was originally published.

Introduction

The emergence of cloud-native DevOps practices, GitOps, Kubernetes containerization, and more, has resulted in a lot of complexity. As a DevOps or platform engineer, you now have to be familiar with many different tooling interfaces to be able to efficiently and effectively deploy code across your software development pipeline.

Service catalogs originate from IT departments, where the catalog offered a list of services the IT team could perform or offer the rest of their company or clients. As microservices architectures become the norm, service catalogs have evolved to display the microservices that exist within the engineering organization, how they are connected to each other, the APIs they use and rely on, and where they are deployed. 

In this post, we’ll discuss how service catalogs have changed to address modern concerns and cover the top open source and commercial options available. 

How open source catalogs emerged

Before open source service catalogs emerged, engineers used myriad manual solutions to organize their teams:

• Spreadsheets
• CMDBs, or configuration management databases, which are similar to manual service catalogs
• ServiceNow catalogs
• A built-in service catalog that’s part of their cloud service provider, developer tooling, or incident management platform
• An API catalog, which may not be able to cover non-API services

The issue with most or all of these options was that they relied on manual updates, which puts an additional burden on developers to update docs each time they make changes to their software environment. 

As your DevOps responsibilities have increased, and microservices architecture became popular, developers gained more responsibility and ownership over their specific services. This meant they also became responsible for more moving parts — from coding to shipping and running software. This means everyone has more to manage and more complexity to resolve. If one dev has to manage 10 microservices, their dependencies, resources, and associated developer tooling — this gets difficult. Imagine doing the same for hundreds or thousands of microservices! 

These increased responsibilities between developers and DevOps engineers compound, led to commercial software catalog offerings, which build on top of modern service catalogs and extend them. 

What is a modern service catalog?

In short, a modern service catalog — also known as a software catalog — represents the entire list of services within your software development pipeline. If you have a microservices architecture, your catalog would typically include:

• Each microservice in production, development, and staging
• Its dependencies, such as other services that each microservice interacts with
• A link to the GitHub repository for the service
• The microservice’s domain
• Which team owns each service

Depending on what your specific software stack includes, you may have additional information about each service in your catalog, like the language a specific service is written in or its related on-call engineer.

Modern service catalogs solve three resulting problems with developer experience:

• Discoverability: Software catalogs create a central metadata repository for your entire software development lifecycle, including microservices, their dependencies, packages, APIs, and anything else. This organizes information and encourages both your developers and other DevOps engineers to maintain accurate services. It also eliminates the need for manual documentation maintenance — no spreadsheets needed!
• High cognitive load and mindless toil: You save a lot of time with a service catalog by eliminating manual updates — you no longer need to update AppSec documentation and standards compliance docs, feature flags, and other pertinent data about microservices.
• Inconsistent experiences: Without service catalogs, developers need to access each different interface, understand and interact with its different (and often confusing) data about microservices, and navigate each service’s associated infra and tools.

A software catalog that integrates directly with your internal developer platform or software stack also offers the benefit of real-time updates, which means you’ll always know what’s going on with each service as it changes. 

From open source service catalogs to internal developer portals

Open source service catalogs were just the first step in helping developers shift left. But the increasing complexity of software environments — coupled with the need for improved visibility, real-time updates, and a reliable way to integrate with the entire SDLC — led to the creation of internal developer portals. 

Internal developer portals offer more in terms of implementing an effective service catalog and an excellent developer experience. The idea behind them is simple: with an organized service catalog that can enable discovery, you can also let developers self-serve common actions like provisioning new services, while ensuring that devs are following standards and golden paths. 

Top commercial and open source service catalogs

Several different commercial and open source portals have emerged recently as the concept of platform engineering gains popularity. Especially as complexity increases, commercial offerings that further abstract away the difficulty of mapping and visualizing services have become more appealing. 

In this section, we’ll list seven internal developer portals, service catalogs, and adjacent tools that may help you organize your software stack and make engineering more efficient. We’ll include both open source and commercial offerings.

Backstage

Backstage is a popular open-source catalog that serves two benefits: discoverability and organization. Originally developed at Spotify, Backstage is now open source and maintained by the Cloud Native Computing Foundation (CNCF).

{{port-for-backstage}}

Backstage ingests data from your integrated services and uses a fixed data model to organize and standardize information, providing a central metadata repository for everything in the SDLC.

The software catalog is one of Backstage’s core features, which means it is an essential part of the tool that is available out of the box. But to visualize the data your Backstage software catalog ingests, you need to involve front-end engineers familiar with the React framework, which may be cost-ineffective for teams with less React experience or smaller engineering departments. 

Port

Port is an open internal developer portal that takes software catalogs to the next level. Rather than affix and enforce an opinionated data model on your services, Port integrates with your stack as it is designed. 

This results in less configuration and simpler data modeling — giving your platform engineers more time to design better patterns and maintain better control over complex architectures.

Port maps all of your services, their dependencies, and their domains in one place using a visual model called a blueprint. These blueprints offer a full visualization of every part of your software development pipeline — whether you want to understand your Kubernetes clusters, your packages, or your virtual machines, you can see how they interact with each other via blueprints. 

You can also click into each of the blueprints to inspect individual services:

This view can show you the health status, sync status, and other related properties for each service, as well as any automations associated with the service. Essentially, this view gives you full context for each service and how it acts within its environment, whether that is production, development, or staging. 

{{cta-demo}}

Meshery

Another open source service catalog is meshery. Meshery is a platform made to standardize and routinize Kubernetes patterns, and is another project donated to the CNCF. Meshery is more focused on orchestrating infrastructure needs, which can be helpful when you need to produce a catalog that makes sense to developers outside of platform or DevOps engineering. 

Meshery Catalog is an offering more similar to a cloud marketplace than a traditional software catalog: it allows you to discover and deploy Kubernetes-based infrastructure and tools, which abstracts away some of the complexity associated with dealing with Kubernetes. Your DevOps engineers can use the catalog to share configurations, best practices, feedback, and other experiences with developers — and using the Meshery Server, you can both share these experiences with other community members or download templates to your own environment.

Cortex

Cortex is another commercial internal developer portal that offers an integrated software catalog as a core feature. Cortex offers four types of catalogs out of the box:

• Services
• Infrastructure
• Domains
• Teams

These catalogs do interact, but how they interact is up to you — it is also possible to customize the Cortex catalogs based on your specific needs and architecture. 

Once your catalog is set up, you can then search across entities and build individual catalogs for everyone on your team. These can then be managed by platform engineers, who can add or remove entities, track catalog changes, and configure displays.

OpenMetadata

OpenMetadata is an open source unified data platform that creates a central metadata repository for observability, governance, and data discovery. This platform offers a bit more than the standard service catalog, making it more similar to an internal developer portal than a spreadsheet. 

OpenMetadata offers five system components:

1. A UI, which is used by the developer 
2. A search engine, which can provide both service information and analytics information about your software development pipeline
3. An API catalog, which automatically integrates with your APIs and the APIs you rely on, and provides metadata to power the search engine
4. An entity store that collects information about service relationships and dependencies
5. An ingestion framework that supports the connection between your services and OpenMetadata

Below is a diagram of the system architecture:

OpenMetadata relies on the standardized JSON format to consume information about entities in your pipeline, making it a flexible solution that supports multiple other languages and makes it easy to routinely and consistently define your entities.

Incident.io

Though Incident.io is primarily known for their incident management workflows, these are powered by their Catalog offering. The catalog platform integrates with your entire tech stack, including any system you’ve already set up, and presents the data in an easily searchable format. With AI-enabled service discovery, you can automatically integrate and create new catalog types, which reduces the amount of time you spend on building. 

‍

The Incident.io catalog serves as the glue between all of your services, making it possible to navigate deeply through your services to understand their health, dependencies, and standards compliance. 

Datadog

Datadog’s Service Catalog is another commercial offering that provides all of your microservice, ownership, dependency, security posture, and other key information in one place. Like OpenMetadata, Datadog’s Service Catalog architecture is JSON-based and flexible, allowing you to consolidate data from across microservices into one place. 

As part of a larger system monitoring, real-user monitoring, and software delivery platform, Datadog’s service catalog offering is a sophisticated platform that can combine more than what some open source frameworks can offer out of the box, making it closer to an internal developer portal than a service catalog. However, this may require additional setup and configuration to provide its full benefit. 

Wrapping up

As service catalogs and internal developer portals continue to evolve, what’s clear is that they share several goals for improving developer experience. From making it easier to understand service health to visualizing dependencies, both catalogs and internal developer portals offer streamlined, real-time methods of managing software catalog information and making it discoverable.  

Engineering teams stand to gain not only speed and efficiency as service catalogs and internal developer portals mature, but an unmatched level of clarity and autonomy to work across their software development environments.