Zero-Downtime Deployments in AWS

A brief overview and concepts using Rolling and Blue-Green Deployments.

AWS CodeDeploy

There are many ways to achieve zero downtime deployments, but I'm going to show you the two deployments within Amazon's CodeDeploy. This service allows you to do automated deployments, and maximize application availability. CodeDeploy grabs your code from CodeCommit or any repository you have setup, and deploys it onto your EC2 instances that you've setup. For those that are familiar, this is just like Heroku and Capistrano.

Concept

We start with a basic application which has three parts; revision, a deployment group and a deployment configuration. Revision is a specific version of your application code, which can be tagged and stored in CodeCommit. A deployment group is a set of instances that are associated with the application that you target for deployment. You can add instances to a deployment through an auto scaling group or by creating tags. Deployment configuration is how the deployment progresses in the the deployment group. To define how the deployment progresses, we include a specific YAML file. This will define what files go to what destinations, and which scripts to run in the life-cycle.

version: 1.0
os: linux
files:
  - source: /index.html
    destination: /var/www/html/index.html
hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
  ApplicationInstall: 
    - location: deploy/apache_install.sh
    - location: deploy/mysql_install.sh
  ConigureScripts:
    - location: deploy/app_configure.sh
      timeout: 30
      runas: root

Usage and Types of Deployments

Rolling Deployment

Using an ELB which has three instances attached, we stop the first EC2 instance and deploy new code to the instance in standby. We then will start server back up and add it back to the ELB. Immediately, the second instance is removed and the deployment process begins. Now, here is where we have two different versions available to the customer depending on the instance that gets served. After it finishes the second, the third gets deployed to and ELB serves up the newest version. Depending on time, a small window of two different versions will be in the production environment. This can be one of the main issues when using the rolling deployment process. To solve this, you would use blue-green deployments.

Blue-Green Deployments

Instead of taking out one instance at a time, we take out half of the instances. Taking half from the ELB, we put them into Standby, which designates them into a 'blue' state. Once they finish, started and added back, the other instances are immediately taken out to be patched. From a customer perspective, they will now see the new version. The second batch of instances then come back into service and you'll have the full capacity for the customer load. One disadvantage of the blue-green is the impact to capacity while losing half of the instances during deployment.

Cost

Great news! When deploying with CodeDeploy for EC2/Lambda there is no additional charge for code deployments. Now, if you do have an on-premise CodeDeploy, this will cost 2 cents per instance. Any deployment skipped will not be charged.

See my last article about moving from Developer to DevOps here!