Deploying a newer version of the software application to the production environment is always a challenging task. When an application transfers to the production environment from the development environment, some anomalies in software can be expected. But the competitive nature of industry forces software firms to deliver frequent updates to fulfill the rapidly changing market requirements.
In traditional deployment processes, the software application needs to be taken offline to deploy the newer version. It takes a short period to copy new updates and restart the application. This leads to a system downtime that stops even the customers’ business operations. Sometimes it may cause a financial impact on their businesses too. The reason behind downtime is that in traditional models, generally, one production environment uses for deployment.
Automaton is a practical approach to eliminate the challenges in traditional software deployment. For instance, the Continuous Integration and Continuous Deployment (CI/CD) approach ensure faster release cycles by automating the software development stages. Likewise, blue-green deployment has been introduced to improve the deployment process further.
What is Blue-Green Deployment?
Blue-green deployment is a software release model that aims to achieve zero downtime. This method uses two identical production environments known as blue and green for application deployment. Each environment contains resources, including servers, virtual machines, services, databases, etc. A router or load balancer directs the user traffics to the production environments.
Let’s say, live version runs on the green environment and the newer or updated version deploys on the blue environment. In the beginning, the router will be configured to send user traffics to the green environment. While the green environment actively handling user traffics, the updated version can be deployed on the blue environment and do tests to ensure that software works as expected. Final testing before pushing the application to production is done in this environment. Once the updated version ready to go live, the router switches user traffics to the blue environment. In such a way, end users never experience any system downtime. Now the green environment sets to non-active and maintains it as a backup. At any given time, only one production environment manages the user traffics. In case of an issue, user traffics can be rerouted to the older version without causing any interruption to the users’ activities. After ensuring that the newer version is error-free, stable, and no roll-backs will be required, the older version can be removed from the system. Because of this uninterrupted and zero downtime deployment practice, blue-green deployment is a well-suited method for continuous software deployment. It also ideal for systems with continuous uptime requirements that ensure high system availability.
In 2005, two developers, Daniel Terhorst-North and Jez Humble, first came up with this method as a solution to a problem they have encountered. They had figured out that there were a lot of differences between the test and production environments. To minimize these differences, they deployed the application for testing into a new space identical to the production environment. Initially, they named these side-by-side environments as A and B. But, because of the hierarchical nature of those names (some people might think that A is better than B), later, they had changed it to blue and green environments.
The pros and cons of Blue-Green Deployment
Pros:
Before the blue-green deployment, developers had to use a single production environment for system updates. Therefore, downtime expects when replacing the software with a newer version. Developers have to pre-plan the downtime for the entire process, and sometimes they have to wait until non-peak hours to initiate the process. But, the blue-green deployment eliminates the downtime problem by using two identical production environments.
If the customer owns a global scale business, it’s nearly impossible to find non-peak hours for system updates. Because their systems need to be up around the clock, since blue-green deployment achieves zero downtime, the development team can deploy the new version at any time of the day. As the user traffics switch to the new version without any downtime, they don’t experience any disruption, and every user could access the new version at the same time.
Instant rollback is possible with blue-green deployment. All the runtime errors cannot be detected in test environments, no matter how thorough the testing is done. These errors can be reached in the production environment and caused some unexpected system crashes. In that case, blue-green deployment makes it possible to instantly re-route user traffics to the previous version. In this approach, developers get enough time to fix the errors and re-deploy the error-free version.
Cons:
Compared to the single production environment approach, blue-green deployment is a complex and expensive method. Because it always has to maintain two identical production environments. Cost can be further increased when working with microservices architecture.
In blue-green deployment, production environments switch between the old and new versions, and as a result, database schemas might require change. It could cause consistency issues in shared databases, and during a rollback, sometimes it leads to a data loss.
When the live version instantly changes from green to blue, some user operations might disrupt. Suppose a user engages in an online transaction during the cut-over. Data related to that transaction might not save properly to the database.
Blue-Green Deployment on Amazon Web Services
AWS provides a number of tools and services that enable the blue-green deployment, including Amazon Route 53, Elastic Load Balancing, AWS Elastic Beanstalk, AWS OpsWorks, Auto Scaling, AWS CloudFormation, and Amazon CloudWatch. In AWS, there are three basic methods to do the blue-green deployment.
The first method uses the DNS swap. Here, it uses Route 53 and updates the main DNS point with the CNAME, either blue or green, to do the swap. The downside of this method is time to live in DNS timeout values around the internet. This can takes anywhere from 5 to 15 minutes to affect the change.
Source: Blue Green Deployments on Amazon Web Services
The second method uses the load balancer swap. It swaps auto-scaling groups behind the load balancer. Here, it has the existing auto-scaling group for blue that drains out and then brings up the auto-scaling group in green and provisioning instances with the new codebase. Once that drain and provisioning complete, the swap happens in the load balancer level, and nothing changes on DNS. It’s a much faster way to do things.
Source: Blue Green Deployments on Amazon Web Services
The third method updates the launch configuration within a single auto-scaling group. It has the blue launch configuration and creates a new launch configuration for the green with the new image and new application. Then it slowly drains out the blue configuration and brings up the green configuration.
Source: Blue Green Deployments on Amazon Web Services
I hope this post is helpful.
