Blue Green Deployments vs Rolling Deployments?

Question

What's the difference between a blue/green deployment and a rolling deployment? I always thought that a blue/green deployment was a sudden switch of traffic from the old version to the new version immediately.

This talk about Blue/Green deployment on AWS shows various different strategies to implement a blue/green deployment, but they also seem to match the definition of a rolling deployment.

Is a blue/green deployment a subset of rolling deployments?

Solution 1

I have written an essay on this topic here: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

In my opinion the difference is whether the new version is applied by replacing instances in the existing setup (in the case of rolling upgrade), or a completely isolated setup is created for the new version (in the case of Blue/Green). In my opinion Blue/Green is the safest strategy and is better in most cases for production deployments. Read the post for a detailed comparison.

Solution 2

In Blue Green Deployment, you have TWO complete environments.

One is Blue environment which is running and the Green environment to which you want to upgrade. Once you swap the environment from blue to green, the traffic is directed to your new green environment. You can delete or save your old blue environment for backup until the green environment is stable.

In Rolling Deployment, you have only ONE complete environment.

Once you start upgrading your environment. The code is deployed in the subset of instances of the same environment and moves to another subset after completion.

So both are different in various factors and you need to choose the deployment model based on the scenario. Blue/green deployment is not a subset of rolling deployments.

Comments

[overexchange]

For production deployments, blue green is better? I think docker based production environments are more approachable for rolling upgrade

[itaysk]

This answer is quite old but I would still say the b/g is safer if it works for you. You can do blue/green with docker: if you had two containers serving traffic and you created a new couple of containers to serve the new version, and then swapped the traffic so not the new couple is active, that's b/g. But if you had two containers and you upgraded one at a time, then this is rolling.

[overexchange]

It is not just the number of containers, we run containers in AWS vpc. B/G will create call those resources (subnets/security groups etc...) Which is unnecessary... Isn't it?

[itaysk]

if you meant to say that there will be redundancy - then yes this is how b/g works. for the duration of the migration you will need to run (and pay for) both versions of the application. However, what is the granularity of "the application" is up to you to decide, and this is also discussed in the blog post. it doesn't have to be the entire network environment. if you prefer, it could be at the scope of "a service", which may be just a couple of containers and a virtual load balancer. upgrading a single service in isolation may be easy or hard depending on how well your system is designed.