Blue-Green deployment

We have many types of deployments like Canary, Blue-Green, big bang etc. Each deployment have its own pros and cons. In this article, I have described about what is Blue-Green deployment, how it works, why Blue-Green deployment and comparison of blue-green deployment with big bang deployment and some limitations of this deployment strategy.

In Blue-Green deployment, We are keeping two identical environments. When we say identical, it could be possible that in same server we have multiple VMs or it could be separate server or separate hardware itself. So all user's requests will always be routed to the any one environment and other will be ideal one.

Lets take an example that, current prod environment is Blue and Green is staging one. When we have new release, First we will test it in Green environment as its our staging environment. We will perform and run all end to end tests, simulation etc. Once, we are good with testing, we will just switch the router from blue to green environment. So now, green becomes the prod and blue becomes the staging environment.

If any failures or unexpected things happen with green environment, we have Blue environment with us in ideal stage. We can again switch back all requests to the Blue.

Again, whenever we will have new release, once our testing will be done on Blue and once confirmed, Blue become prod and Green become ideal.

Why Blue-Green deployment?

1. Its easy and quick to switch back to the older version in case of any problem we face in newer version of software whereas its difficult to rollback in big bang deployment. We may face downtime also while rollback.
2. Our Staging and Production environment are identical so whatever testing we perform on staging environment, that would be suffice. However in big bang deployment, our test or staging environments might be different than the prod one may be some server configuration, hardware etc. Due to that, we may miss many testing scenarios.
3. In the event of disaster, Blue green deployment strategy really helps. If both environments are in different data centers / regions, then you can directly switch to the other environment without facing any downtime. Only challenge here is that if we are not frequently releasing our software than older environment may have software version which has older feature. In big bang, you may face downtime.
4. Literally, there is no downtime involve in blue-green deployment as you need to switch your router only. Where as in big bang, you may face downtime as you may need to run some prod script, flush out, other deployment etc.

Challenges

1. If we are keeping database shared between both the environments, then challenge is that newer version might have some schema related changes. In the case of rollback, database will have those changes however older version of software won't have those changes. Two thing can be done here. A) We need to rollback our database B) before releasing database schema changes, we may need to make code change in both environments, test them and release them. So in case of rollback, older version should also work.
2. As we have two identical environments, we may need more hardware or same compute resources in both environments like server, memory etc. which eventually increase the overall capex cost.
3. To keep both environments identical, takes times and efforts. The overall process is complex.
4. With Blue-green approach, we need to maintain two identical environments. Maintenance could be related to compute resources, hardware, certificates, updates and security patches etc. E.g. Certificates renewal process has to be taken care in both the environments.