What is Blue-Green Deployment?
Before diving deep into the working and use cases of Blue-Green Deployments let's first understand what Blue-Green Deployment Strategy is.
Blue-Green Deployment is an application release model which can reduce downtime and risk by running two identically configured production environments called Blue and Green. Only one environment is live in the production at a time which will serve all the requests in the production environment. When Blue is live Green will be idle and vice-versa. It is also sometimes called as Red-Black Deployments.
The Origin of Blue-Green Deployments
The story started in the year 2005 when two developers named Daniel North and Jez Humble ran into a problem with their e-Commerce website. Even after doing rigorous testing they still got many errors in the production.
Later after analyzing the root cause of this issue, it became clear that the errors they were getting were because of the differences between their testing and production environment. Tests were passing in their test environment but failing in the production.
Now, what they did next is generally a big no-no, they deployed and tested directly in the production environment. But the key point to notice here is that they did not overwrite their old site instead they deployed a new site parallel to their existing old site.
Now with the help of the new domain, they smoke tested the new version on production. Once the testing was complete and they were fully satisfied, they pointed the Apache Web Server to the new folder. They also had a backup plan, if in case users face any issues they had to simply run a single command and point the Apache Web Server to the old version. This came to be a very smooth transition and they were able to achieve instant rollback.
This strategy significantly improved error detection as the test and production environments were now identical.
Working of Blue-Green Deployments
There are a few prerequisites, that a company should ensure before proceeding with Blue-Green Deployments:
- Two identical environments
- Make sure that the new and old code can run together
- A router or Load Balancer is required to switch users from one version to other
Now, let's assume that V1 is the current version of the application and we want to move to the latest version V2, here V1 will be called the Blue Environment and V2 is Green Environment. The complete process can be broken down into 4 steps as follows:
1) Setting Up a Load Balancer to Route Users
As we have the two instances named Blue and Green, we want users to be able to access the Green (V2) instance instead of the Blue (V1) instance. We can achieve this using a Load Balancer instead of a DNS record exchange as DNS propagation is not spontaneous.
Load Balancers and routers help in switching users from the Blue instance to the Green instance. Changing the DNS name will not be required as the Load Balancer will reference the same DNS but routes the new traffic to the Green Environment. With this approach, we will get full control of the users which will help us to switch back to the V1 (Blue Instance) in case anything goes wrong.
2) Executing the Update
When the Green Instance is ready, we will move it to production and run it in parallel with the older version. Using Load Balance traffic can be routed from V1 to V2 seamlessly without being noticed by the users. They won't even realize that now they are accessing the new version of the application.
3) Monitoring the Environments
DevOps Engineers will get very little time to run smoke tests on the Green instance, once the traffic is switched from Blue to Green instance. They need to figure out very quickly if there are any issues in the new version before users get impacted on a large scale. They need to ensure that everything is running as expected on the new version.
4) Deployment or Rollback
Green Instance is monitored very closely as there might be some issues that users may face. For all this time Blue instance will be kept on standby.
If DevOps Engineers find any issues during the smoke test, traffic will be instantly diverted back to the Blue instance without facing any hiccups. If everything goes well after a considerable time of monitoring, the Green Instance will then become the Blue Instance for the next release.
With Cloud, Blue-Green Deployments Become More Feasible
It gets very expensive to keep two sets of instances up all the time. Fortunately, we have platforms like Terraform and Ansible to start and stop the environments on-demand basis. The release process can be simplified using Containers or Kubernetes.
With the cloud, we get flexibility and cost reduction and Blue-Green Deployment Strategy is within everyone's reach.
To conclude if Blue-Green Deployment is the right strategy for you, let's check out some of its benefits and Drawbacks.
Benefits of Using Blue-Green Deployments
Improved Customer Experience: Transition from the old version to the new version is so seamless that users don't face any downtime. They don't even realize any changes.
No specific upgrade schedule for developers: With Blue-Green Deployment Strategy, continuous deployment becomes feasible and there is no requirement of specific maintenance windows for the release.
Testing Parity: New version can be tested accurately with identical hardware and software.
Instant Rollbacks: If in case DevOps Engineers find some issues in the new version, they can quickly roll back to the previous version without getting noticed and impacting the user experience.
With the Blue-Green Deployment Strategy, developers no more have to wait for low traffic windows to deploy their changes. New releases can be pushed to production the moment developers are ready with their code.
The Downside of Using Blue-Green Deployments
High Costs: Blue Green Deployments are much more expensive as compared to any other deployment strategy. On-demand infrastructure provisioning helps to a certain extent but multiple deployments per day can lead to high costs.
Time Consuming: Blue-Green Deployment setup takes time as it is complex and needs many iterations until we get it working perfectly.
Database Migration: Database changes must be in sync as anything goes wrong it becomes very difficult to get things back to normal. The changes should be backward and forward compatible. It becomes necessary to keep one of the databases read-only or use replication.
As a database is a shared service, it can leak information between Blue and Green Instance. This one environment can impact the other one and could break isolation and impact the deployment.
Conclusion
Even if Blue-Green Deployment Strategy is costly, it is a widely used practice among many organizations. Every deployment technique has its pros and cons, therefore teams should collaborate closely to choose the right deployment technique.
As there is no fixed approach that will suit every scenario, organizations should do thorough research before settling with any particular deployment strategy.
