How to Optimize Costs When Using Blue-Green Deployments

Blue-green deployments are a great way to minimize downtime and risk — however, users should remember to keep cost in mind as well when optimizing deployments.

Why You Should Use Blue-Green Deployments

One approach to continuous deployment of applications that has really taken off in popularity recently is the use of blue-green deployments.

The main idea behind this system is to have two full production deployments in existence that are running the last two versions of code, with only the latest version actively in use. For instance, if the current version of your software is running in your “blue” environment, your next deployment would take place in the “green” environment. When you’re ready to flip the switch, you start pointing users at green instead of blue.

This deployment method has a couple of great benefits. First, it helps with minimizing downtime when cutting over to newly-deployed code. Instead of upgrading your current system and having to make users wait until the upgrade is complete, the cutover downtime is minimized. Second, along the same lines, you have a fresh deployment each time instead of upgrading an existing system repeatedly. Third, you have a system that has been already working for you that you can roll back to if necessary.

How to Optimize Costs With Two Production Deployments

Of course, running two production environments means that you are paying twice the cost for your infrastructure. ParkMyCloud users have asked how they can optimize costs while using the blue-green deployment strategy. We use AWS internally for our blue-green deployments, so we’ll discuss some options in terms of AWS terminology, but you can use other clouds like Azure and Google as well.

One approach is to use AWS Auto-Scaling Groups as your deployment mechanism. With ASGs, you decide how many instances you want as a minimum, a maximum, and a desired amount for your environment. When setting up ASGs in ParkMyCloud, you can have two different settings for min/max/desired for when the ASG is “on” and “off”. This way, you can have an ASG for blue and one for green, then use ParkMyCloud to set the min/max/desired as needed, so each of these environments is only running when necessary, and not wasting money.

Another option is to use Logical Groups in ParkMyCloud. This allows you to group together instances into one entity, so you could have a database and a web server start and stop together. If you go this route, you can put all of your blue instances together in a group, then start the whole group up when you are ready to switch over. When going between blue and green, you can just update the logical group to have the newest instances as you deploy. Again, this allows you to park the inactive environment, saving its cost.

If your continuous deployment is fully automated, a third option is to utilize the ParkMyCloud API to change schedules and toggle servers as deployments are completed. Typically, you’ll want your current active deployment on an “always on” schedule, so ParkMyCloud will turn things on even if someone tries to turn them off, and the standby deployment on an “always off” schedule so you are saving money.

This idea of using ParkMyCloud with blue-green deployments is one way to start implementing Continuous Cost Control in your pipeline. This way, you can save money while delivering software quickly and automatically. Try it out with ParkMyCloud today and get the most out of your cloud!

Originally published at www.parkmycloud.com on November 16, 2017.