Skip to main content

What is a Microservice Catalog?

A microservice catalog simplifies cloud-native architecture by displaying all services in one place. The use of a microservice catalog simplifies a cloud-native implementation by providing a central location to find and share thousands of services consistently across all clusters and teams. A microservice catalog facilitates collaboration across organizational siloes, saves money by encouraging reuse, and tames the difficulty common to a shared service architecture.

“Software systems have become so complex that it’s getting too difficult for humans to reason about the systems they design. The complexity spans the team (even small projects with 20 dependencies have a broader committer graph of 10K engineers), the tooling, the architecture, and the users. Service Governance will be the creation of service catalogues, metadata stores about *how* the software was created, and intelligence systems that inform stakeholders on insights for the system.”

Tyler Jewel, The Developer Led Landscape 2022


Microservices and Their Unique Attributes

Every microservice is different and each has its own unique attributes. These attributes change over time, impacting consuming applications and other dependent services. Microservice attributes include ownership details, consuming applications, transitive microservice dependencies, versions, and inventory across all clusters.

The catalog tracks and manages these attributes showing changes over time, minimizing the time for root cause analysis, and provides a ‘predictive’ platform for taming microservices even before deployment. 

microservice attributes 

Evaluating Microservice Catalogs

While all microservice catalogs centralize data on microservices, they all approach the problem differently. The difference between microservice catalogs often depends on who they are serving. For example, some catalogs track mainly production information and are focused on helping the support teams maintain SLOs.

Others cater to the microservice developer and automate the onboarding of services. Some focus on tracking intelligence and managing the service supply chain across siloed teams. These catalogs provide SBOM and dependency data critical for knowing where your security vulnerabilities lie.

Features of Microservice Catalogs

Below is a list of standard features of microservice catalogs:

  • Project Templating
  • Microservice Organization
  • Microservice Ownership
  • Service to Service Dependencies
  • Logical Application Supply Chain with SBOM
  • Supply Chain Versioning
  • Vulnerability and License Reporting
  • Microservice Inventory by Cluster
  • Deployment Metadata
  • SLO tracking

Categories of Microservice Catalogs

There are three basic categories of microservice catalogs:

  • For Developers
  • For Operations
  • For DevOps

Catalogs for Developers

The design of these catalogs helps developers start creating microservices. They focus on project templating and tracking developers’ tools to develop and test services.

Catalogs for Operations

These catalogs focus on monitoring production systems and tracking service level objectives (SLOs). Their primary goal is to help support teams and SREs maintain their incident response times.

Catalogs for DevOps

The design of these catalogs tracks the software supply chain with versions. They service all individuals in the DevOps pipeline focusing on microservice intelligence and governance.

    Microservice Catalog Explored Whitepaper:

    Who uses a Microservice Catalog?

    A microservice architecture disrupts the way we develop software. The loss of the monolithic application changes the way we manage the creation and delivery of software to end-users. This modern shared microservice architecture has created new challenges across the DevOps pipeline. Choosing the correct catalog type requires a close look at your microservice usage and journey.

    As you mature in your microservice journey, the need to manage microservices from a central location will become clear. Part of the complexity of a microservice implementation is understanding who uses them, where they are running, and their impact. The core purpose of a microservice catalog is to provide everyone, from the API developers to the production support teams, essential information needed to succeed in a shared services architecture.

    Catalog Users

    The users of a microservice catalog include:

    • Producers
    • Consumers
    • DevOps Teams
    • SREs and Support Teams
    • CISO and Application Security

    Producers – The API or Microservice Developer

    Familiar with microservices is a domain-driven approach where ‘Domain’ teams develop small functions to address bounded context problem spaces. These teams are the ‘producers’ of microservices who deliver functions to ‘application’ or ‘project’ teams.

    Consumers – Application or Project Teams

    Application developers are the consumers of microservices. They create software solutions by writing their unique services and reusing available ones. A collection of microservices is a ‘logical’ application. Application teams use a microservice catalog to find and reuse available services and package their logical applications.

    DevOps Teams

    We have all gotten very good at using a continuous delivery process to push monolithic changes across the dev to prod lifecycle. DevOps teams are responsible for keeping a lifecycle process automated even in a microservices architecture. The job of the DevOps Team is to manage changes, report differences, and understand the impact of a single update. Microservices make their job particularly difficult. DevOps Teams use a microservice catalog to track the impact of services and the applications that use them.

    SREs and Support Teams

    Imagine trying to support a microservice you know nothing about. This puzzle is the job of the Site Reliability Engineers and Support Teams. Maintaining SLOs in a microservice architecture is their challenge. These individuals use a microservice catalog to determine who to contact when a service fails.

    CISO and Application Security

    Governance of the microservice supply chain is essential, however difficult. Tracking what microservices are being consumed by a particular application, and creating a full Software Bill of Material (SBOM) for that application is near impossible in a decoupled microservice architecture. The microservice catalog is used by Security Professionals to govern the supply chain of microservices and create application-level Software Bill of Material reports.


    The DevOps process will need a central microservice catalog to support a cloud-native architecture. Part of the complexity of a microservice implementation is understanding who uses them, where they are running, and their impact.

    Critical in this new architecture is to have a clear view of your microservice supply chain. This view includes knowing what microservices are available, what is missing, what versions are running, and their changes over time. The core purpose of a microservice catalog is to provide everyone, from the API developers to the production support teams, essential information needed to succeed in a shared services architecture. 

    Learn More and Catalog Comparison

    For more information and a Microservice Catalog comparison, download the ‘Exploring Microservice Catalog Whitepaper.

    Download Here