Skip to main content

Microservice Incident Response can be Complicated

Microservice Service Catalog, or sometimes referred to as a microservice catalog, is an essential tool for support teams managing incident responses for microservice applications. 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. Imagine needing to support a microservice you know nothing about. Who do you call? Who else might be impacted?  This is the purpose of a microservice service catalog for incident response.

Microservice Incident Response Intelligence

Microservice incident response intelligence includes information such as who is using the microservice, where the microservice has been deployed, how the microservice was deployed, and most importantly who to call when something goes wrong. This data is essential for your support teams managing tickets across your cloud-native framework. Imagine taking a support call on a service you have never heard of or pushing a ticket to an application team that has no clue why their application is having issues. What is needed is a microservice service catalog that provides ownership information along with the visibility of who else is using it and where else it is running. While observability tooling is useful, relying on performance monitoring software as a first resource to track an incident can be difficult and require an expert to track down the issue. And observability is done based on a single cluster. What is needed is the ability to see what has changed across all clusters to determine the ‘usual suspect’ – the last update.

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

DeployHub Pro’s Incident Response Microservice Catalog

DeployHub Pro’s microservice incident response 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 incident response 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, critical key-value pairs, CVE, Licensing, and Swagger info.

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 incident response support team. If it broke in one cluster you will need to address all clusters.

If an anomaly occurs, the incident response 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.

Microservice Incident Response Comparison Report

Microservice Incident Response Comparison Report

DeployHub Pro’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 incident response 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.

DeployHub Key Features

Meet the Co-Founders

Get Started

Ortelius Open Source Project