There are an infinite number of possibilities with cloud technology. One of the key considerations to look at is the way the applications are deployed. There are deployment strategies available that would help deploy cloud and on-premise apps. We extensively use the blue/green deployment strategy for our cloud apps, while it can also be used for on-premise.
To give you the context and the need for blue/green deployment, let us look at some of the challenges of traditional application deployment methods.
In traditional deployments, if the deployment fails, you will use the previous working version of the application for redeployment. During the redeployment, you will be using the same resources that were used for the new deployment due to cost factors, and in the case of rollback, you will overwrite the latest version with the old version of the application. This rollback cannot be done without time delays which amount to a brief period of application unavailability.
Does blue/green deployment help resolve this challenge?
Yes, it does.
With blue/green deployment strategy, you can release the new version of your app with near zero-downtime rollback capabilities.
For example, let's consider having two identical environments named blue and green. The blue environment serves the production traffic, and the green environment is a staged version of your application.
In order to make a new app release, you have to shift the traffic from blue to green. If any problems are encountered during the deployment, the traffic can be again diverted back to the blue environment. The staged green environment can be rolled back and prepared for deployment. After the green environment is fully ready, the traffic diverts from the blue environment.
It is difficult to validate your application in a production environment in traditional deployments, but in the blue/green environment, it's possible to run both applications parallelly.
With blue/green, you could send a sample amount of production traffic to validate the green environment before diverting the traffic to production. This analysis is called canary analysis. Even if you feel that the green environment is not performing as expected, you can route the traffic back to the stable environment, reducing the impact.
The impact of switching between the two environments is always limited to a very minute time difference between the impact detection and shifting traffic back to the stable environment. Also, during the testing, the impact is always limited to the small amount of traffic going to the new environment, reducing the blast radius of the deployment errors.
Besides, based on the traffic, you can scale up and down the environments after the deployment.
This is how a blue/green strategy is implemented in the cloud. You could also use this strategy when building a new application in the cloud.
Implementing a blue/green environment can be done through:
With load balancers, you can route traffic to the servers immediately without depending on DNS to switch the traffic to production.
In DNS switching, the traffic is diverted from one environment to the other by switching the servers' DNS IP address/alias names.
One of the main aspects of building a payment application is to keep deploying updates without downtime. Sometimes, there should be no downtime as the application is critical in completing the payment transactions.
Let me recount some of the learnings we had in deploying a payment application for one of the largest payment networks.
Before implementing this strategy, we faced issues during the deployment. We had to roll back the new releases, which created more downtime due to the time required for the old version to be overwritten over the latest version.
We decided to avoid this scenario, which is when we implemented the blue/green strategy for deploying a payment application for one of the largest payment networks.
We even eliminated adding the "Application is offline for maintenance" screen with this deployment. We implemented this strategy using the load balancing method where the 80/20 rule was followed. 80% of the traffic was routed to the green environment, and 20% was routed to the blue environment. We avoided using the DNS switching method as it would still take hours for DNS propagation to reflect in the browsers.
Another benefit we get with blue/ green deployment is that we don't have to find the right international deployment time, as deployment can be completed even during office hours.
