What is blue green deployment?
Blue green deployment is an application release model that gradually transfers user traffic from a previous version of an app or microservice to a nearly identical new release—both of which are running in production.
The old version can be called the blue environment while the new version can be known as the green environment. Once production traffic is fully transferred from blue to green, blue can standy in case of rollback or pulled from production and updated to become the template upon which the next update is made.
There are downsides to this continuous deployment model. Not all environments have the same uptime requirements or the resources to properly perform CI/CD processes like blue green. But many apps evolve to support such continuous delivery as the enterprises supporting them digitally transform.
CI/CD is 1 of the 6 steps of digital transformation
How does blue green deployment work?
Think about it like this. You’ve developed a simple cloud-native app—a mobile game where users earn points tapping multicolored balloons that fly across the screen. The game’s back end is supported by multiple container-based microservices that handle game achievements, scoring, mechanics, communication, and player identification.
Hundreds of users start playing the game after its initial release. They’re logging thousands of transactions every minute. Your DevOps team has encouraged you to release early and often, which is why you’re about to release a minor update to the mechanics microservice that increases the size and speed of the red balloon.
Instead of waiting until midnight to push the update to the production environment (when the least amount of users are active), you’re using a blue green deployment model to update the app during peak use. And you’re going to do it with zero downtime.
You’re able to do this because you took the mechanics microservice in the production environment (blue) and copied it to an identical—but separate—container (green). After you increased the size and speed of the red balloons in the green environment, it passed through Q/A and staging (which were perhaps automated by an open source stress test project like Jenkins) before it’s pushed to the production environment alongside the active blue environment.
The ops team can use a load balancer to redirect each user’s next transaction from blue to green, and—once all production traffic is filtered through the green environment—the blue environment is brought offline. Blue can either standby as a disaster recovery option, or it can become the container for the next update.
Blue green deployment and Kubernetes
Kubernetes is a natural fit with all the elements associated with the blue green deployment process, including cloud-native apps, microservices, containers, continuous integration, continuous delivery, continuous deployment, SRE, and DevOps. As an open source platform that automates Linux® container operations, Kubernetes not only helps orchestrate the containers that package cloud-native apps’ microservices, but Kubernetes is also supported by a collection of architectural patterns that developers can reuse instead of creating application architectures from scratch.
One of those Kubernetes patterns is known as the Declarative Deployment pattern. Since microservices are inherently small, they can multiply in number very quickly. The Declarative Deployment pattern reduces the manual effort needed to deploy new pods—the smallest and simplest unit in the Kubernetes architecture.