Blue Green Deployment

We have seen many types of deployments, such as Canary, Blue-Green, Big Bang, etc. Each deployment has its own pros and cons. In this article, I have described Blue-Green deployment, how it works, and a comparison of Blue-Green deployment with Big Bang deployment, and some limitations of this deployment strategy.

Introduction 

 

We have many types of deployments like Canary, Blue-Green, Big Bang, etc. Each deployment has its own pros and cons. In this article, I have described Blue-Green deployment, how it works, why Blue-Green deployment, and a comparison of Blue-Green deployment with Big Bang deployment and some limitations of this deployment strategy.

 

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

 

Lets take an example, say the current prod environment is Blue and Green is the staging one. When we have new release, first we will test it in the Green environment, as it's 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 the blue to the 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 its ideal stage. We can again switch back all requests to the Blue.

 

 

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

 

Why Blue-Green deployment?

1. It's easy and quick to switch back to the older version in case of any problem we face in the newer version of the software, whereas it's difficult to rollback in Big Bang deployment. We may face downtime also during 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, maybe server configuration, hardware, etc. Due to this, we may miss many testing scenarios.
3. In the event of a 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. The only challenge here is if we are not frequently releasing our software, then the older environment may have a software version that has older features. In Big Bang, you may face downtime.
4. Literally, there is no downtime involve in blue-green deployment, as you only need to switch your router. 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 a shared database between both the environments, then the 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 time and effort. The overall process is complex.
4. With the 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 of in both environments.