Evaluating Whether Blue-Green Deployments Are Useful
This lesson discusses the Blue-Green strategy, the concept behind it and how to use it.
We'll cover the following...
- The blue-green deployment strategy
- Blue-green strategy vs serverless deployments and the RollingUpdate strategy
- Applying a variation of the blue-green deployment
- Checking the applications running in staging
- Defining the blue and the green deployment
- Promoting the staging to production
- Inspecting the applications running in production
- Testing if the release is running
- Was that blue-green deployment?
The blue-green deployment strategy
Blue-green deployment is probably the most commonly mentioned “modern” deployment strategy. It was made known by Martin Fowler.
The idea behind blue-green deployments is to run two production releases in parallel. If, for example, the current release is called “blue”, the new one would be called “green”, and vice versa. Assuming that the load balancer (LB) is currently pointing to the blue release, all we’d need to do to start redirecting users to the new one would be to change the LB to point to green.
We can describe the process through three different stages.
- Let’s say that, right now, all the requests are forwarded to the current release. Let’s that that’s the blue release with version v2. We’ll also imagine that the release before it is running as green and that the version is v1. The green release lays dormant, mostly wasting resources.
- When we decide to deploy a new release, we do it by replacing the inactive (dormant) instances. In our case, that would be green instances that are currently running v1 and will be replaced with v3.
- When all the green instances are running the new release, all that’s left is to reconfigure the LB to forward all the requests to green instead of the blue instances. Now the blue release is dormant (unused) and will be the target of the next deployment.
If we’d like to revert the release, all we’d have to do is change the LB to point from the active to the inactive set of instances. Or, to use different terminology, we switch it from one color to another.
Blue-green deployments made a lot of sense before. If each of the replicas of our application were running in a separate VM, rolling updates would be much harder to accomplish. On top of that, rolling back (manual or automated) is indeed relatively easy with blue-green given that both releases are running in parallel. All we’d have to do is to reconfigure the LB to point to the old release.
However, we do not live in the past. We are not deploying binaries to VMs but containers to Kubernetes which schedules them inside virtual machines that constitute the cluster. Running any release is easy and fast. Rolling back containers is as easy as reconfiguring the LB.