What Is Blue-Green Software Delivery Deployment?

A blue-green deployment model is a software delivery release strategy based on maintaining two separate application environments. The existing production environment running the current production release of the software is called the blue environment, whereas the new version of the software is deployed to the green environment. As part of testing and validation of the new version of the software, application traffic is gradually re-routed to the green environment. If no issues are found, then the green environment becomes the new blue environment. The former blue environment can be taken down, and a new green environment can be established for the next release.

Why Is Blue-Green Deployment Useful?

The primary benefits of implementing a blue-green strategy are 1) minimal or zero application downtime and 2) no negative impact on end-users when switching users to a new software release or when rolling back a release in the event of unforeseen issues with the new release or deployment.  

The concepts and components required to implement blue-green deployments include but are not limited to, load balancers, routing rules, and container orchestration platforms like Kubernetes.

How Blue-Green Deployment Works

As shown in the image, let’s assume that version 1 is the current version of the application, and we want to move to the new update, version 1.1. Version 1 will be called the blue environment, and version 1.1 will be called the green environment. 

The Process of Switching Traffic Between the Two Environments

Now that we have two instances of the application, named blue and green, we want users to access the new green (v 1.1) instance rather than the older blue instance. For this to happen, we normally use a load balancer instead of a DNS record exchange because DNS propagation is not instantaneous.

By using load balancers and routers, there is no need to change DNS records because the load balancer references the same DNS record but routes new traffic to the green environment. This gives administrators full control of user access, which is important because it enables quickly switching users back to version 1 (the blue instance) in the event of a failure in the green instance. Because of the speed of the switchover, most users won’t notice that they are now accessing a newer version of the service or application — or that they have been rolled back to a previous version.

Monitoring

Traffic can be switched from the blue to the green environment gradually or all at once. As the traffic flows to the green instance, the DevOps engineers get a small window of time to run smoke tests on the green instance. This is crucial, as they need to ensure that all aspects of the new version are running as they should before users are impacted on a wide scale. 

The Benefits of Implementing Blue-Green Deployments

• Improved user experience — As noted above, users don’t experience any downtime, and the new environment can be rolled back instantly to the previous best state if necessary.
• Disaster recovery — The Blue-Green strategy is also a best practice for simulating and running disaster recovery scenarios because of the inherent equivalence of the blue and green instances and the ability to instantly failover to the (back-up) green instance in case of an issue with the (production) blue instance.
• Simulating actual production scenarios — With a Canary deployment, the testing environment is often not identical to the final production environment. Instead, we use a small portion of the production environment and move a small amount of traffic to the new system. (Read more about Canary Analysis here.) By contrast, in a Blue-Green deployment, the new green instance can simulate the entire production environment running in the blue instance.
• Increasing developer productivity — Gone are the days when DevOps engineers had to wait for low-traffic windows to deploy updates. The Blue-Green strategy eliminates the need for maintaining downtime schedules, and developers can quickly move their updates into production as soon as they are ready with their code.

Best Practices and Challenges To Keep In Mind When Implementing a Blue-Green Deployment

Choose Load Balancing Over DNS Switching

Do not use multiple domains to switch between servers. This is a very old way of diverting traffic. DNS propagation takes from hours to days, and it can take browsers a long time to get the new IP address. Some of your users may still be served by the old environment.

Instead, use load balancing. Load balancers enable you to set your new servers immediately without depending on the DNS. This way, you can ensure that all traffic is served to the new production environment.

Keep Databases in Sync

One of the biggest challenges of blue-green deployments is keeping databases in sync. Depending on your design, you may be able to feed transactions to both instances to keep the blue instance as a backup when the green instance goes live. Or you may be able to put the application in read-only mode before cut-over, run it for a while in read-only mode, and then switch it to read-write mode. That may be enough to flush out many outstanding issues.

Backward compatibility is business critical. Any new users added to the new version must still have access in the event of a rollback. Otherwise, the business could, for instance, lose new customers. In addition, any new data added to the new version must also be passed to the old database in the event of a rollback.

Execute a Rolling Update

The container architecture has enabled the use of a rolling, or seamless, blue-green update. Containers enable DevOps engineers to perform a blue-green update only on the required pod. This decentralized architecture ensures that other parts of the application do not get affected.

Challenges To Consider While Implementing Blue-Green Deployments

Errors When Changing User Routing

Blue-green is the best choice of deployment strategy in many cases, but it comes with some challenges. One issue is that during the initial switch to the new (green) environment, some sessions may fail, or users may be forced to log back into the application. Similarly, when rolling back to the blue environment in case of an error, users logged in to the green instance may face service issues.

With more advanced load balancers, these issues can be overcome by slowing the moving of new traffic from one instance to another. The load balancer can either be programmed to wait for a fixed duration before users become inactive or force-close sessions for the users still connected to the blue instance after the specified time limit. This might slow down the deployment process and result in some failed or stuck transactions for a small fraction of users, but it will provide a far more seamless and uninterrupted service quality than having routers force the exit of all users and divert traffic.

Seamless Blue-Green Deployment

Instantaneous Blue-Green Deployment

High Infrastructure Costs

The elephant in the room with blue-green deployments is infrastructure cost. Organizations that adopt a blue-green strategy need to maintain an infrastructure that doubles the size required by their application. If you utilize elastic infrastructure, the cost can be absorbed more easily. Similarly, blue-green deployments can be a good choice for applications that are less hardware intensive.

Code Compatibility

Lastly, the blue and green instances live in the production environment, so developers need to ensure that each new update is compatible with the previous environment. For example, if a software update requires changes to a database (e.g., adding a new field or column), the blue-green strategy is difficult to implement because, at times, traffic is switched back and forth between the blue and green instances. It should be a mandate to use a database that is compatible across all software updates, as some NoSQL databases are.

Conclusion

The blue-green software deployment strategy can involve significant costs, but it is one of the most widely used advanced deployment strategies. Blue-green is particularly helpful when you expect environments to remain consistent between releases and you require reliability in user sessions across new releases.