Blue-Green Deployment DevOps

Even with the benefits of cloud-based DevOps run by a specialist provider, rushing can lead to mistakes being made if it’s not implemented properly. This has led to many advances being made in the DevOps space, like methods to manage risk and fix code problems in new releases before they reach the end user. One such method is the Blue-Green deployment approach.

What Is Blue-Green Deployment?

The Blue-Green deployment strategy works with the DevOps model to control the quality of product rollouts by deploying to an environment that is identical to the live site, but not publicly accessible, until the launch is 100% validated and bug-free.

Blue-Green deployment means you temporarily maintain two almost identical versions of your site. One is known as the Blue environment and the other one is the Green environment. When you have a new product to launch, you roll out the release to a new Blue environment and keep the old Green environment to handle the existing site traffic.

If the deployment is confirmed as working properly after the testing period, your Blue-Green deployers divert public traffic to the Blue site, which has the perfectly coded and tested, brand new product or service. If all goes well, the Green site is deleted and you’re ready to start the process over again and launch the next product, at which point you will make a new duplicate (Blue) site.

On the other hand, if the product doesn’t work as expected and it needs some code tweaks or debugging before it can be released, you can just switch your live site over to the Green environment. This will roll back the deployment as if it never happened, giving you time and space to do more work to improve the product before relaunching.

Blue-Green deployment is like writing in pencil because if something goes wrong, you can always go back and erase it, and have your original, high-quality manuscript back again. But it lets you test the product in a live environment for more reliable and realistic results. The other advantage of Blue-Green is that there is little to no downtime when running instances of the new application.

To be efficient, Blue-Green relies on automation, so it can only be used with cloud-native, virtual and container services like Kubernetes and Dockers offered by Amazon Elastic Container Service (ECS) and Microsoft Azure Containers.

What Is the Difference between Blue-Green and Other Deployment Strategies?

The Blue-Green deployment pattern is by no means the only type of safe deployment model. The most common new techniques for automated deployment processes are Canary deployments and Rolling reployments. Each one has their own use cases for different types of organisations, budgets and products.

Note that releases, where the user opts in to test a beta version of the new product, is not the same as a deployment, where the new application is launched on the users or a subsection of users without their consent. This discussion focuses on deployments.

Blue-Green Deployment vs Canary Deployment

Canary deployment is a deployment pattern that focuses on releasing to a subset of users or servers at first to be able to test it in a small, controlled environment before releasing it more widely. This Canary method reduces the number of users affected by the deployment in the testing phase so that any bugs or problems that may exist will have the minimum effect on the least number of people possible.

It is named after the practice of miners of taking a live canary down into the mineshaft with them as a way to detect carbon monoxide, in the same way that the Canary deployment is a means of preventing greater catastrophes.

While Blue-Green deployments involve releasing to the new testing environment in its entirety all at once, Canary deployment happens incrementally. Blue-Green is better for releasing small iterations, whereas Canary is better for larger updates. Blue-Green is faster than Canary because the deployment doesn’t happen in stages, but you have to be more sure that the update is thoroughly debugged and smoke tested before deploying. That’s why it’s better to Blue-Green deploy small changes that have less that can go wrong. They both involve negligible to non-existent downtime, with the switch to the new server or testing environment being made in a matter of milliseconds.

Blue-Green Deployment vs Rolling Deployment

Rolling deployment is another way of reducing or removing downtime altogether when releasing new applications. If Canary is similar to Blue-Green in the sense that both have multiple (at least two) deployment environments, Rolling is different in that it only has one. However, this deployment environment is effectively split across a number of different cloud sites.

The new development is uploaded progressively first to one node, then when it’s confirmed to work, to the next, and then the next, until it is active on all nodes. While the upload is taking place, each node will be disabled and user traffic redirected to another, live hosting site, normally by way of a load balancer. If an error arises at any point in the Rolling deployment, all traffic can be redirected to an environment that is still unaffected by the new application code.

Rolling deployment is better than Blue-Green deployment for applications that only introduce small upgrades, like web apps that need small improvements to UI, and for companies with a production infrastructure that consists of enough servers so that if several have to be down due to errors in the deployed version, the others can carry the weight of all traffic with no performance degradation. It is more cost-effective than Blue-Green deployment because it doesn’t need the same large-scale testing resources, but it is less powerful at testing for the same reason. Also, Rolling deployment will mean users are operating different versions of the application at one and the same time, leading to mismatching and disruption, while with Blue-Green everyone uses the same version.

Blue-Green Deployment vs Red-Black Deployment

Red-Black deployment is the same thing as Blue-Green. Red-Black is the name more commonly used by Netflix and its Spinnaker platform to refer to Blue-Green testing, as red and black are their brand colours. There is no difference in the ability to bypass the router to one of the two live production sites because there is never a time, either in Blue-Green or in Red-Black, when the two hosting environments are live at the same time.

Blue-Green Deployment vs A/B Testing

Contrary to popular belief, A/B testing has nothing to do with Blue-Green deployments, or Canary, or any other kind of deployment model. Blue-Green and A/B testing are sometimes confused and conflated because they both involve the use of testing and are both binary systems with two environments, but they happen for two very different reasons and in different ways.

The purpose of Blue-Green is to lower risks when releasing new products by being able to rollback safely, but A/B testing is used to ascertain which feature of a product users respond to better, normally for usability or design optimisation. Blue-Green uses only one environment at a time, whereas A/B testing uses both for a short time, until a winner is found. If that’s still not clear enough for you… one uses colours and the other one uses letters! They’re not the same!

Blue-Green Deployment vs Linear Deployment

Linear Deployment is not an alternative safe deployment method, exactly, but rather a variation of Blue-Green and Canary deployments that is available on Amazon Web Service (AWS) CodeDeploy. It simply involves adding an extra layer of security to the process by staggering how quickly the traffic is shifted over to the test environment(s).

With linear deployment on AWS ECS, Lambda and Fargate, 10% of traffic, or another customisable amount, is shifted over to the new hosting environment each 10 minutes, or any length of time you choose. This lets you slow down launches to minimise the number of users who could be affected by potential errors in the application code.

Blue-Green Deployment Pros and Cons

There is no single correct answer as to what is the best cloud deployment strategy. Frustrating as it is when we get the answer “it depends”, it depends. Blue-Green requires more infrastructure investment than some other deployment models but that’s because it offers the fastest rollback to a complete, last known working, version and mitigates risk particularly well.

Blue-Green is especially good for high-availability websites like eCommerce sites and government gateways. For a brochure site or new software engineering projects for other types of sites, it’s probably best to consider another deployment pattern.

One of the biggest challenges of Blue-Green deployment is accidental changes in the database schema between the two environments. While the testing is going on, unforeseen inconsistencies can arise in the schema that means that deleting the Green site to switch definitively to the Blue will cause certain functions to be irretrievably lost.

For this reason, it’s advisable to rely on a dedicated DevOps provider to ensure that all development and operations teams within the company are working with the same tools and datasets, towards the same outcome, and communicating properly about all changes, including code fixes and managing database migrations so that Blue-Green deployments work perfectly and remove all the problems and risks inherent in new product launches.

Specializing in the optimization of usability, reliability and sales strategies for eCommerce stores and other commercial websites, SmartOSC offers a variety of customizable solutions for DevOps as a Service (DaaS) and 24/7 Managed IT Support Services. To benefit from our expertise, or just to say hello, get in touch today.

Drop here!