A Perspective from Security

Blue Green deployment (or Red/Black, A/B) is a methodology to eliminate downtime from your workloads by bringing up a parallel production environment and implementing required changes before moving the traffic from one group to another. It is an effective technique to minimize risk in application changes ensuring you have appropriate time to test while your users are unaffected and being handled as normal. There are also security events which can be handled similarly.

Let’s take a closer look at some specifics and scenarios.

In this figure, we have a set of Azure VM’s running behind an Azure Load Balancer in production and labeled as Blue. These workloads could be running a number of different services including but not limited to LAMP stack or application logic.

Next, we’ll bring up a parallel architecture that mirrors the blue workloads.   These instances could be in a separate subnet or network security group. You might even place them in the exact same location with an enumerated version in their names. Your next goal will be to apply the change on the green side while blue is still handing production. This change could be new application logic or patch, an operating system hotfix, anything that could cause an outage to your customers that would require testing.

After the change has been made, it’s important to test all aspects of the AzureVM to ensure proper functionality. Since these are about to go into production and the whole purpose of this technique is to eliminate downtime, testing is the most critical stage.

Finally, when you complete your testing, you will promote the green side to production.  You could also just instantiate new instances into the blue side and delete the VM’s running the older code.

As you move back and forth with this code deployment and application development, you can minimize the impact to your users to hopefully zero.

From a security perspective, this also allows you to buy yourself time during a breach or attack. By bringing up a parallel environment, you can test new firewall or intrusion prevention rules, pull in a new security hotfix, or even just remove an attackers footing in the existing instances causing them to start their attack over.  You could also use techniques like quarantining instances into a locked down security group to run forensic analysis on or switching over the deployments automatically in the case of a malware or other alert from your security tool.

The ability to swap back and forth between parallel production environments allows you to deal with many situations since it effectively makes compute disposable. If you can move your workloads seamlessly without loss of user connectivity, it gives your environment resiliency and flexibility to respond to any situation (hopefully automatically).