Everything about Blue Green Deployment Strategy!

Back in 2005, two developers named - Daniel Terhorst-North and Jez Humble were tackling issues with their Ecommerce Website. They were disappointed with the fact that even with a good testing system, the errors are still being detected at much later stages of production. Following this, they performed a detailed root cause analysis, the results of which showed a significant difference in the conditions of testing and production environment, and these differences resulted in frequent failures.

Very unconventional for their time, yet they created a new environment running parallel to the existing production environment. That means instead of over-writing on their older version, they had a similar new production environment to deploy new codes and further experiments. The plan was to route the traffic to the new environment where new codes are deployed, to gain accurate real-world end-user insights on their updates. Thereby putting an end to the failures that slipped due to the differences between testing and production environments.

Following the subsequent success, they coined this strategy as the “Blue-Green Deployment Strategy.”

Requirements before executing Blue-Green Deployment Strategy

1. Two identical environments must be available
2. It is to be made certain that the new code can be run alongside the existing code, as they will be running at the same time in the production environment.
3. A load balancer to route the traffic.

Two identical platforms are created - Blue environment and Green environment. The blue environment holds the existing version and the green environment holds the newer update (or as per your convenience, there is no rule as such, this is just for naming convention).

Steps Involved in Blue-Green Deployment Strategy

The Blue-Green Deployment Strategy can be broken down into four steps:

Step 1: Setting up a Load Balancer 

Now when we have two environments, we want to direct the traffic to the green environment, where we have deployed our new update. For that to happen we need a load balancer, though it can be done through a DNS record exchange, but it’s not much preferred as DNS propagation is not instantaneous. 

If a load balancer and router are used, for switching traffic between two instances, there will be absolutely no requirement to change the DNS records, the load balancer will point to the same DNS records, but the traffic is now routed to the green environment. 

With the use of a load balancer, we have full control over the users’ channel, which implies that we can switch them back to the older/existing version, i.e., in our case we have placed it in the blue instance instantaneously, in case of any failure in the green instance.

Step 2: To Execute the Update

After our green instance is ready, we move it to production and run it simultaneously with the existing code. The load balancer effectively drives the traffic, from blue to green. This complete transaction is very unnoticeable to the users. 

Step 3: To Monitor the Environment

As the traffic is routed to the new green instance, the DevOps engineers get a narrow frame of time to conduct a smoke test on the new instance. This is to ensure that all aspects of the new instance are working fine. This is a crucial step, in order to figure out any present errors, before it is experienced on a wide scale.

Step 4: Deployment or Rollback

This is the time when any error is found during the smoke test, the users are redirected to the older version or blue instance immediately. In some cases, errors are identified only after the application is live for some time, therefore, even after a successful smoke test, the devops engineers monitor the entire transaction to understand and find the bugs or any other issues.

If all is well with the new green instance, it becomes our blue instance for our next update. 

Benefits of Blue-Green Deployment Strategy

Pleasant Customer Experience

This is quite possible when we have a load balancer to securely reroute the traffic to the older/existing version without committing any change to the DNS records (in the case where the new instance shows errors). The routing action is so swift that it doesn’t show any downtime to the customers/users.

Instantaneous Rollbacks

It’s as simple as pressing undo, without any adverse consequences. When the routing action swiftly diverts users in no time, it’s easier to roll out new updates for experimentation and also immediate roll back in case of any error or failure.

No more waiting for Maintenance Windows

Earlier DevOps engineers had to wait and keep a track of days when the traffic was down, to conduct the scheduled downtimes, in order to deploy certain updates. These scheduled downtime events incurred a significant amount of loss.

Testing Parity

Results are accurate when the conditions provided are real, or the environment where the newer updates are deployed experiences the same kind of stress as a production environment. The inherent equivalence between the two instances - blue & green, makes it the perfect choice to perform disaster recovery practices.

As compared to Canary Deployment, a small piece of the production environment is used, and a tiny amount of traffic is routed to test the update. Though it’s a profitable approach, with limited conditions impacted on the new update, we cannot establish the complete picture of the update when it’s finally deployed and made accessible to everyone. 

Challenges of Blue-Green Deployment Strategy

Failed User Transaction

During the initial switch to the green instance or the newly deployed instance, some users would be forced to log out of the application, or in some cases, the services can go down. If the new update is not working, and a switch back to the older environment is required, then the users logged into the green environment might face sudden blocking in services. 

These issues can be counteracted with the use of advanced load balancers, which usually work by slowing down the incoming traffic instead of force diverting all the users out of their current sessions or waiting for the users to become inactive. 

A Rise in Infrastructure Costs

Enterprises require to maintain an infrastructure that is double the size of their application to perform the Blue-Green Deployment Strategy. Making this strategy a good choice, only if our application is not so hardware intensive. An ideal solution, in this case, would be the use of an elastic infrastructure that can help in absorbing the costs.

Compatibility of Codes

When both the existing code and the new updated code are supposed to work parallelly in the production environment, it is of utmost importance to ensure that both of them are consistent in every aspect. For example, if the new software requires some change in the database like adding a new field or column, which is different from the existing code, will make it difficult for us to switch the traffic between the two instances, as it will make the entire process incompatible. 

Conclusion

Although the Blue-Green deployment strategy involves cost, it is one of the most reliable approaches when it comes to checking the status of an application. This is ideal when our environments are consistent between releases and have our user sessions reliable across multiple new releases. 

What’s helpful to notice is that the ever-growing need of adopting complex models like the Blue-Green deployment strategy has created a new space for sophisticated services like Managed DevSecOps (like BuildPiper, GitLab, Aqua Security, DataDog, etc). They ensure the end-to-end execution of a faster-to-market model by

• cost optimization
• better uniformity between the new codes and existing codes
• comprehensive observability of end-to-end traffic flow
• security of the production environment,
  and much more that is involved in these processes. 

The changing demands result in changing trends and being part of it, is what keeps any business afloat. The only way to sustain this dynamic market is to create our very own space, which is created as a result of a satisfied customer base.            

This article was first published here