Tracking Microservice Ownership for Incident Response is Critical for your DevOps Teams
Microservice ownership is key for governing microservices at scale. Knowing who owns a microservice is essential for support teams managing incident response for microservice applications. When migrating from a monolithic architecture to cloud-native computing, we break up our big fat binaries into ‘bounded context’ services, which can be shared across teams and clusters.
By sharing these services, 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 business as usual is disrupted for support teams who need to maintain incident response contracts and track root cause analysis. Imagine needing to support a microservice you know nothing about. Who do you call? What is different? Who else might be impacted? Registering microservice ownership across thousands of services is the key to answering these questions.
Microservice Ownership and Incident Response
Knowing who owns a microservices means knowing who to call when a problem occurs. In a monolithic application, support teams are generally clear on who to contact when an incident is logged. This is not true in a microservice architecture. A microservice application is a collection of microservices. Some of the microservices are written by the application team themselves. Other microservices are borrowed from the pool of available ‘common’ services.
When an incident occurs, end users report a problem at the application level. The support team directs the service request to the application team. But what if the application team did not make a change? How do they know that an underlying common service may have been updated and caused the issue? Who do they call?
Such simple problems are the nature of microservices. For this reason, registering microservice ownership before a service is shared across teams is critical for maintaining incident response and keeping your end-users happy.
Microservice ownership goes beyond just who to contact in the case of a bug. Microservice ownership insights should also include who is using the microservice, where the microservice has been deployed, the version of the microservice, how the microservice was deployed, and most importantly what teams should be notified if a common service has an issue. These are the basic elements of a microservice service catalog.
Registering Your Microservice Ownership
DeployHub’s microservice 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 critical 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. But in order to have this level of data, microservices need to be registered.
While we do not like the idea of manual entry, we must have a ‘base version.’ Microservice developers must register their ‘base version’ of the service to DeployHub. Registration assigns the service to a specific ‘domain’ making it easy to find, along with the microservice ownership data. This can include:
- Contact info
- CVE
- Licensing
- Critical key-value pairs
- Deployment scripts
- Swagger info
Registering Microservice Usage
Upon registration, application teams who consume microservices can define a ‘base version’ of their application package by registering their microservice usage. With the registration of both base versions of the microservices and the ‘logical’ application package, DeployHub can begin automatically tracking changes and versioning microservices and all-consuming applications. Much like checking in your ‘base version’ of your source code, a versioning engine performs its version management.
DeployHub connects into your continuous delivery (CD) 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 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. It also exposes new versions of ‘logical’ applications based on a new version of a service.
DeployHub also connects to the continuous delivery pipeline at the ‘deployment’ step, which enables the tracking of all locations of a particular version of a service, essential data for your incident response support team. If it broke in one cluster, then all clusters need to be addressed.
Putting the Data to Use
Anomalies occur. No software is perfect. The question is can you quickly respond to incidents. If your team is registering microservice ownership and usage within a central catalog, you can act upon that data. With DeployHub, your engineering teams can view a ‘difference’ report based on the impacted application and environment to determine root cause analysis from a change management perspective.
The catalog gives the DevOps teams the needed information to notify the owner and all the consuming application teams that a problem has occurred within minutes of the first incident call. And with this level of data, difference tracking becomes quick and easy.
Using the versioning engine, DeployHub can show the differences between two microservices, applications, or clusters. Pictured below is an example of an application ‘version’ difference report. Teams can use a difference report to swiftly identify what changed, and use microservice ownership information to notify the developer.
Pictured: Microservice Incident Response Comparison Report
Conclusion: Microservice Ownership
Registering microservice ownership and usage is a critical feature of a microservice catalog tool. Knowing who owns a service and who consumes the service is key to building high-quality and secure microservice applications, at scale. Centralizing the details of your microservice ownership and usage allows teams to quickly respond when an incident occurs.
DevOps teams can quickly notify all consuming applications that a shared service needs to be updated, even before they all discover a problem exist. Having microservice ownership information is missing in most microservice implementations. The question to ask is how do they manage without a central catalog? The answer: they do not.