Orchestrating Zero-Down Time Blue-Green Deployments for Production Workloads in Kubernetes

This article is mainly concerned about the most trending word in the cloud-native world that is blue-green deployment.

Blue-green deployment is a technique that reduces downtime and risk by running two similar production environments called Blue and Green and among those two, only one of the environments is active and it is serving all production traffic. For example, if Green is active then blue is idle.

When you are updating the application or releasing the new version of the software, then deployment and the final stage of testing takes place in the idle environment. Once you have deployed and fully tested the software in the idle environment, you switch the router, so that now all incoming requests go to idle instead of active. Idle is now active, and active environment is idle.

This technique can eliminate downtime due to app deployment and also it reduces risk. If something unexpected happens with your new version on an active environment, you can immediately roll back to last version by switching back to the idle environment. The actual procedure of blue-green deployment is schematically explained in the below figure.

 

Blue-green deployment provides you to achieve the following goals by eliminating risks that are witnessed in the deployment. 

Possibility of errors is less:

When we are doing online bank transactions, sometimes we will be surprised with the error message saying “bank server is under maintenance” or similar. But with blue-green deployment, you never have to worry about this maintenance screen. Up-gradation is fast and the application can be deployed with the next click on the updation of the software. It would provide near-zero downtime and would present easy rollback capabilities. 

Testing the production environment:

With the blue-green deployment, it is easy to ensure the pre-production environment is as close to the production environment and which is not only important but essential too. The user can test any application while it is disconnected from the main traffic. The team has the eligibility to even load the test if they desire too.

Helps to maintain consistent traffic:

In any e-commerce enterprise, banking sector or any major enterprise where the traffic is high and maintaining the consistent traffic is essential. Blue-green deployment assures that your traffic never stops. Also makes sure that customers can place their order just fine without disruption, which means that the employees overseas continue to do their job without any interruption. The fundamental idea behind blue-green deployment is to shift traffic between two identical environments that running differently in different applications.

Easy recovery:

You might witness times where you would get introduced to bugs and viruses. We can either spend a lot of money on its recovery or we can inevitably find them and recover them. The blue-green deployment helps us to have our older and more stable version of our applications to come back online at a moment’s notice by evading the pain to roll back a deployment.

Example of Blue-Green deployment:

Here, in this example, the Nginx image version 1.10 is updated to 1.11. Let the Nginx image with version 1.10 is in a blue environment, and it is active. The service.yaml file of the application is shown below:

The service pods of the Nginx image with 1.10 are active and are running

 

The green environment is idle and the Nginx image is upgraded to 1.11 version. Once the up-gradation is complete, make the green environment as active and blue as idle. The service.yaml file for the application is updated with the new version. The service pods of the 1.11 version are active and running.

Summary:

Deployments are one of the most important parts of the software development life cycle, therefore all the activities involved should thoroughly be researched and tested to ensure that they are a perfect fit for your system architecture and business. Blue-green deployments need two identical sets of hardware, and that hardware carries added costs and overhead without actually adding capacity or improving utilization. Blue-green deployments are usually utilized for consumer-facing applications and the applications which have critical uptime requirements. The new code is delivered to the inactive environment, where it is completely tested.

For more details about cloud-native microservices & cloud-native stack transformation, please refer Yobitel Communications. www.yobitel.com/cloud-native-services.