Microservices: The Key to Successful Blue/Green Deployments

In my role, I often help customers create CI/CD solutions to deploy to AWS. I've noticed a common pattern among customers who struggle with blue/green deployments. These customers often haven't fully embraced the concept of microservices, and as a result, they face challenges when trying to orchestrate multiple blue/green deployments. In this blog post, I will explore the relationship between microservices and blue/green deployments, and why misunderstanding the former can lead to difficulties with the latter.

Before I start, I want to define a few terms.

Microservices: Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams. Microservice architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

Blue/Green Deployments: A blue/green deployment is a deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new application version. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails.

The core concept of microservices is that each service should be independent and loosely coupled from other services. However, I frequently see customers trying to orchestrate intricate blue/green deployments across multiple services simultaneously. I have observed two reasons for this.

First, the services are not independent. For example, two or more services might have a common library used for object serialization. When the services communicate, they use this library to format the messages they send to one another. As a result, you must update the library in both services at the same time, or they cannot communicate.

Second, the customer is performing manual testing. As a result, the test is long running and expensive. Even if they could deploy a service independently, they prefer to batch up many changes and deploy them together. The Quality Assurance (QA) team will then perform manual testing of the green environment, while the blue environment continues to serve traffic.

The Blue/Green Deployments on AWS whitepaper addresses these scenarios in the section title when blue/green deployments are not recommended. The whitepaper identifies scenarios where “schema changes are too complex to decouple” or there are “workarounds or additional moving parts in the deployment process.” These correspond to my two observations. You can read the whitepaper for additional information. Next, I will briefly discuss how to succeed with blue/green deployments.

The solution to these struggles is to embrace a microservice architecture. Each service should be developed, deployed, and scaled independently. This means that blue/green deployments should be performed on a per-service basis, rather than trying to deploy multiple services at once.

By adopting microservices, you can enjoy the benefits of blue/green deployments without the added complexity. Each service can be deployed independently, with its own blue/green deployment strategy. This approach allows for faster deployment times, increased scalability, and reduced risk of failure.

When I first learned about microservices, I read Building Microservice by Sam Newman. According to Sam, “If your shared code ever leaks outside your service boundary, you have introduced a potential form of coupling.” I suggest that you read chapter four of his book, which describes strategies for decoupling microservices. This includes strategies for versioning so that you can continue to serve clients of the old version of the API, while making new features available on a new version of the API. This allows you to update the services independently.

Decoupling your services will allow you to deploy them independently. However, you also need to reduce, or better yet eliminate, manual testing. Otherwise, it is cost prohibitive to perform many small deployments. This will incent you to deploy services together, even when the architecture no longer requires it. You can read more about configuring automated testing in the Deployment and Test on Amazon Web Service whitepaper.

By adopting microservices and automating tests, you can begin to deploy services independently. This will greatly reduce the complexity of your deployments. I am confident this will reduce, or even eliminate, the struggles you have had with blue/green deployments.

Blue/green deployments are a powerful tool for delivering applications in a continuous delivery pipeline. However, when customers struggle with these deployments, it's often a sign that they haven't fully embraced the concept of microservices. By breaking down large, monolithic applications into smaller, independent services, customers can adopt blue/green deployments for each service, reducing complexity, and increasing scalability and resilience. You can watch Application modernization, microservices & the strangler fig pattern for more information.Top of Form