Zero Downtime using Blue Green Deployments
This article explains briefly some concepts required to achieve zero downtime using blue green deployments.
Blue Green Deployments in a Nutshell
Let's assume that you have an application in AWS. This application has the following architecture: The traffic makes DNS requests to yourdomain.com, then it access to the load balancer (elastic load balancer for AWS). This load balancer is configured with an autoscale group, which creates new
instances that connects to the database (
for Amazon Web Services). The current application is the version 1.0.
The following steps must be completed to deploy the version 2.0 using blue green deployments:
1 - Create a Brand New Production Ready Infrastructure
The new infrastructure won't be active yet. This process should be completely automated and it should take just a few minutes. The new infrastructure connects to the existing database.
2 - Test the new infrastructure
Make sure that it is working properly. You can automate this step, which will be discussed in another post. If the new infrastructure does not work you can destroy it, fix the problem, and create another system from scratch. All this process is completely transparent to your users.
3 - Activate the new infrastructure
Depending on how things are organised you can, for example, activate it by replacing the servers in the load balancer or by updating a DNS entry. This example uses DNS, but you should evaluate what option is best for you.
4 - Destroy the old infrastructure
Once there is no more traffic active in the old infrastructure, there are no more tasks pending (e.g the workers has finished the queues) and we are confident that the new infrastructure is working fine, the old infrastructure is destroyed.
Blue Green Deployments are easier when the system is designed using Immutable Infrastructure Architecture Pattern.
Immutable Architecture Pattern in a Nutshell
1 - The immutable infrastructures pattern divides the infrastructure into two areas: data and everything else. The "everything else" components are replaced at every deployment, rather than being updated in-place.
In our previous example we had several infrastructure elements in place. EC2 and the load balancer does not have state, which means that are the same in time. RDS, the database, has state as it is storing the application information.
2 - You should never change any part of the production once it is deployed. If you need a new change, deploy a new system.
3 - It is best to automate everything at the lowest level possible.