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.
Get hands-on with 1400+ tech skills courses.