Skip to main content

Microservice Service Catalog, or sometimes referred to as a microservice catalog, is an essential tool for support teams managing incident responses in a microservice architecture. When shifting from a monolithic architecture to cloud native computing, we break up our big fat binaries into ‘bounded context’ services. These services can be shared across teams and clusters. By doing so, we can allow a single microservice to auto scale super efficiently and create a shared services architecture that leads to true business agility.

But breaking up is hard to do and it disrupts our business as usual, particularly for support teams who need to maintain incident response contracts. This is the purpose of a microservice service catalog.

Microservice Service Catalog Provides Needed Intelligence

Microservice intelligence such as usage, inventory across clusters, deployment insights and most importantly ownership information is critical for your support teams managing incidences across your cloud native framework. Imagine taking a support call on a service you know nothing about or pushing a ticket to an application team that has no insights on why their application is having issues. What is needed is a microservice service catalog that provides the information needed to identify what changed and who to call, preferably without having to monitor transactions to determine the ‘usual suspect’ – the last update.

For these reasons support teams need insights into what versions of the services are running, how they got deployed, who to call and what applications are impacted. These are the basic elements of a microservice service catalog.

DeployHub’s Microservice Service Catalog

DeployHub’s microservice service catalog tracks core details needed for your support teams to maintain fast incident responses, reducing mean time to detect (MTTD) and mean time to locate (MTTL). Most important is the insights of the ‘blast radius’ of a single service allowing support teams to proactively notify all teams who rely on a particular service before they also get a call.

Let’s take a look at how you build out your microservice service catalog in DeployHub, and how DeployHub automatically tracks the updates from your continuous delivery pipeline. DeployHub keeps track of the different versions, where they are deployed and who to call and notify if an issue occurs.

While we do not like the idea of manual entry, we must have a starting point, called a ‘base version.’ DeployHub needs your microservice developers to register their ‘base version’ of a service to DeployHub. Registration assigns the service to a specific ‘domain’ making it easy to find, along with the owners contact info, deployment scripts, and critical key value pairs.

Once registered, application teams who consume microservices can define a ‘base version’ of their application package, registering their microservice usage.  With both base versions registered, DeployHub can begin automatically tracking changes. Much like checking in your ‘base version’ of your source code, DeployHub uses a versioning engine to perform its version management.

DeployHub connects into your continuous delivery pipeline when a new container image has been updated to a container registry. DeployHub grabs the container SHA and creates a new version of the microservice in the microservice service catalog. At the same time, it creates new versions of all consuming applications. This dependency relationship is managed in the catalog showing your support team every application that relies on the microservice.

DeployHub also connects to the continuous delivery pipeline at the ‘deployment’ step. This allows DeployHub to track all locations of a particular version of a service, essential data for your support team. If it broke in one cluster you will need to address all clusters.

If an incident occurs, the support team can view a difference report based on the impacted application and environment to determine which microservice is new. Now that they know the difference, support teams have a place to go to inform the microservice owner, and all the consuming application teams that a problem has occurred within minutes of the first incident report.

Component Catalog

Microservice Comparison Report

DeployHub’s Comparison Report can be seen from the perspective of the ‘Application,’ ‘Environment,’ and ‘Component’ providing comparison details showing changes at multiple levels.

Conclusion

The use of a microservice service catalog is critical for your support teams to maintain their service level objectives and reduce MTTD and MTTL. But the data in the catalog must be relevant and up to date. DeployHub’s integration into the continuous delivery pipeline ensures that all microservice updates moving across the lifecycle stages are tracked from the time it is registered, to the time it has been deployed to the endpoints creating the full visibility needed to shorten incident response times and ensure a smooth transition to a microservice architecture.