Skip to main content

Do You Know Your Microservice’s Blast Radius?

In hundreds of conversations we have had with developers, cloud architects, and SREs, they all expressed the feeling of ‘flying blind’ and having a lack of confidence when moving microservice updates to clusters. It was not too surprising when we began hearing the term ‘microservice blast radius,’ describing the impact a microservice update may have on their end-users.

The truth is, microservices are intended to be reused across multiple teams, but the implementation of a microservice architecture requires a shift in the way we organize and release microservices across all clusters. More than anything else, it requires a commitment to facilitating and leveraging the reuse factor across teams and environments.

Understanding who consumes a microservice, and when they want to start using it, is key to a successful reuse strategy. The only way to implement a successful reuse strategy is to track who is using a service, and communicate updates keeping everyone informed. In other words, we must rethink the organization, tracking, and visualization of services in order to simplify the use of microservices, fully recognize their core benefits, and facilitate reuse across teams.

Article Content

  1. Microservice Supply Chain
  2. Microservice Sprawl
  3. Concepts in a Shared Microservice Architecture
  4. DeployHub and Your Microservice Blast Radius
  5. Conclusion

Microservice Supply Chain

At its core, not knowing your microservice blast radius is a supply chain management issue. A microservice supply chain includes many concepts, including microservice version management, inventory tracking, and maintaining SBOMs for each version of the service and all applications that consume the service. The questions to ponder is  ‘how do we create an SBOM in a microservices application without a monolithic build?’ The answer is to aggregate microservice usage up to the ‘logical’ application level.

By tracking the ‘logical’ application package, we associate all the services the application consumes. Creating one big Helm chart is one way of creating an microservice application package. But in reality, that puts us right back into our old monolithic habits.

Microservice Sprawl

A lack of visibility into the usage of a single microservice across all of your clusters is a dangerous condition. When you don’t know your microservice blast radius and want to avoid an adverse impact on end-users, you are left with some undesirable options.

One option is to run back to monolithic practices even in a cloud-native environment. One way this is done is the practice of using Kubernetes namespaces to silo ‘application’ configurations. Another scenario is to give each application (product team) their own cluster. Both of these methods are monolithic practices that lead to both cluster sprawl and service sprawl. In either case, you will most certainly experience drift of your services across the clusters and namespaces.

In the example below, we see cluster sprawl and microservice sprawl with drift.  In this example configuration, we are managing 3 clusters, 3 Namespaces, and 12 Pods, and that is for just 1 environment (dev, test or prod.) If you have a dev, test, prod pipeline, you can multiply this number by 3. So we go from 12 to 36 services very quickly.

Notice in this example, the ‘shipping’ service drifts at the Clothing Store Cluster. This will occur if the shipping service’s blast radius is unknown. This level of detail is obfuscated in the complex software systems that we now build. If this does occur, it should be on purpose. Maybe the Clothing Store application developers held back on the new release of the service, but were notified of the need to upgrade.

service drift

Concepts in Shared Microservice Architecture

To successfully implement reuse in a microservice architecture we need to understand what teams are using which services. This requires knowing your blast radius and communicating updates prior to a release.

If you have a method of tracking which teams are using shared services, you can confidently build out a shared microservice architecture that includes notifications to all teams when a new release is on its way.

Tracking use and ownership of microservices builds trust in a microservice implementation, improving reuse across teams.  Most importantly, a well managed microservice architecture can ensure that critical updates of the shared services are being consumed by all teams. A single release fixes the problem for all teams, even before they are aware that a problem exists.

In the example below, all 3 stores, Candy, Toy, and Clothing, receive the Shipping update at the same time. We are now building out a true shared microservice architecture where business agility can be achieved.

shared services

But in order to gain this level of coordination, there must be a method for automating the application’s service usage. Tracking relationships manually is an option for smaller organizations with relatively few shared microservices. But as your shared services grow, and you have more application teams consuming those services, automating this level of control is required. Re-imagining how to address microservice configuration management will be key when microservices are implemented at scale.

DeployHub and Your Microservice Blast Radius

DeployHub’s catalog tracks a microservices blast radius based on the applications that consume it. DeployHub can predict a microservices usage, impact, and dependencies before it is deployed.  This is one of the core benefits of DeployHub’s microservice catalog tool.

By publishing your shared services to the DeployHub Domain catalog, application teams can then package their application base version by identifying the shared services they use. As shared services are updated, DeployHub automatically builds an Impact Analysis map that clearly shows the blast radius for that service, listing all dependent applications even before you deploy.  With this information, you can automatically push testing steps of all impacted applications and determine if the new service is ready for prime time. In addition, you can automate the notifications of all impacted teams so they are aware that a new service is on its way.

blast radius

Regardless of which method your organization chooses, siloed clusters or a shared service strategy, the need for understanding the blast radius remains. However, if you understand microservice impact you can confidently move to a shared service architecture and finally retire a monolithic practice.

Conclusion

Building a shared microservice architecture has always been a challenge. In a Kubernetes microservice environment we have an opportunity to realize this goal – but not without some re-imagining. Our habit will be to return to our old ways of thinking and rely on siloed environments reinforcing old ideas of ownership that create inflexible architectures, even in a cloud-native environment.

To maximize on sharing services and facilitating reuse visibility around application dependencies and microservice usage becomes critical.  DeployHub is designed to perform automated dependency management, tracking application to service relationships, including the blast radius. DeployHub removes much of the complexity around managing microservices in a shared service environment.

DeployHub Key Features