Microservice Incident Response can be Complicated
Microservice Service Catalog also referred to as a microservice catalog, is an important 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. When shared, we can allow a single microservice to auto-scale super efficiently and create a shared services architecture that leads to business agility.
But breaking up is hard to do and it disrupts our business as usual. This is particularly true for support teams who need to maintain incident response contracts. Imagine needing to support a microservice that you know nothing about. Who would you call? Who may be impacted? This is the purpose of a microservice 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 support teams to maintain fast incident responses. This reduces both 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 CD pipeline. DeployHub keeps track of the different versions, where they are deployed, and who to call and notify if an issue occurs.
While manual entry is not a good idea, we must have a starting point, also called a ‘base version.’ With DeployHub, microservice developers need to register their ‘base version’ of a service. Registration assigns the service to a specific ‘domain’ making it easy to find, along with the microservice ownership 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, you 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. What this does is it 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.
In the case that 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.
A comparison Report can be seen from the perspective of the ‘Application,’ ‘Environment,’ and ‘Component’ providing comparison details showing changes at multiple levels.
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 ensuring a smooth transition to a microservice architecture.
DeployHub Key Features
- Microservice Supply Chain
- Domain-Driven Design Catalog to Tame Microservice Sprawl
- Simplifying Microservice Applications
- Ship Microservices Safely – Know Your Blast Radius
- Microservice Version Management
- Microservice Configuration Management
- Database Updates Pushed Across Your CD Pipeline
- Building Microservice Pipeline
- Microservices Continuous Integration
- DeployHub Microservice Dashboard