Blue-Green vs. Canary vs. Rolling Deployments

What they are and the pros/cons to each

In a world that revolves around applications providing every type of service or product you could imagine, it is only natural that companies want to give their customers the best possible experience so that they return time and time again. A massive part of this experience comes down to how users are able to interact with and utilize your applications.

Picture this, you see a product on Shark Tank that looks pretty neat so you decide to check it out. You go to their website only to see that it takes a long time to load, and after clicking around on a few links to get some more information the site eventually times out. I don’t know about you but personally I wouldn’t have the patience to keep trying to figure out their page and how to subsequently order something. My attention span is probably to short to deal with that and I could just go get something similar elsewhere.

This leads us to our main point, it is extremely important to have your sites and applications be deployed in such a way that minimizes downtime, latency, and gives the end user the best possible experience. Ever had a problem ordering something on Amazon? I doubt it.

In the world of DevOps there are a multitude of different strategies you can use to seamlessly deploy and update your applications without end users even being aware of what is happening. However we are going to focus on just 3 of the more popular ones: Canary, Blue-Green, and Rolling deployments. The goal of these deployment strategies is to have a live “testing” environment with minimal downtime and service interruptions where you can push out changes to your application to see how it holds up in regards to its performance, security, durability, etc.

Canary Deployments

Canary deployments involve pushing out a set of changes to a small portion of your active user base by deploying them to a few of your servers that the target users will be routed to. If the users in phase 1 for example start working with a new feature you push out and have no issues, you can go to phase 2 and roll it out to a few more users. If there are issues, it is relatively easy to roll back your changes since they were not pushed out to your entire architecture.

Pros:

• Allows real end users to test your new features in a production environment
• No downtime while releasing new features
• Cheaper strategy as you do not need additional servers for a separate environment
• Easy to rollback changes if issues arise

Cons:

• Deployment mechanism and load balancing to appropriately distribute changes can be complex
• May take time for end users to actually test your new features out directly
• Separate monitoring/logging should be implemented for your new Canary environment(s)

Blue-Green deployments

Blue-Green deployments require two identical production environments, with one being a staging environment (blue in this example) and the other being a live production environment (green). Once your staging environment is in its ideal state running a new version of your application, and has been tested internally, you gradually route traffic from the green to the blue.

Then, you apply the same new version to your green environment, so that now your green and blue deployments are identical again. Finally, you route traffic back to your green environment and you can then repeat the process.

Pros:

• Very easy rollback as you have a completely separate environment
• Deployment is faster and relatively simple than other strategies
• Internal testing means you have a higher chance to catch bugs/defects before end users do

Cons:

• More expensive since you have additional infrastructure
• Effort required to maintain and update multiple environments is higher
• Delivery pipeline is more complex as you have two separate environments to manage

Rolling Deployment

A Rolling deployment is very similar to a Canary deployment, but the key difference is that you are rolling out changes incrementally to new servers, as opposed to targeting users.

Pros:

• Rollback is easy since you push changes out in small increments
• Deployment is easier since you push it to servers instead of specific users
• Very cost-effective

Cons:

• Depending on how many servers you have it could take longer to fully roll out your new application to all servers
• If deployed to a server with a larger number of users and bugs are then discovered, a larger number of users could be affected

At the end of the day, the debate will continue to rage on about which deployment strategy is “the best”. There really is no right or wrong answer, only pros and cons to each that may work better in some situations more than others.

But some general guidelines to remember are that a Canary deployment is best for mission-critical applications, Blue-Green is best for a user base that has slightly less business impact, and Rolling deployments are best for an architecture that have a smaller number of nodes.

Hopefully this was helpful for you to understand how modern day companies can seamlessly push out new versions of their applications with minimal downtime and the best possible user experience.