In the companion piece to this blog post—A 5-Step Guide to Good Continuous Delivery—we looked at the best practices high-performing IT teams should be employing to achieve Continuous Delivery (CD) with Docker. CD is achievable using numerous deployment methods and Docker is just one tool to help realize the necessary customizable “workflow-based” integration/build process.

Continuous Delivery Deployment Types

Now, we’re going to examine the four major deployment types and outline each of their advantages and disadvantages. These are:

Minimum In-Service deployment

Rolling application updates

Blue/Green deployment

A/B testing

These four deployment types fall into two sub-categories: application and infrastructure deployment.

Minimum In-Service Deployments

With this method, we specify the minimum number of instances in our applications that stay in-service while updating the remaining percentage—therefore, deploying to as large a number of targets as possible. This process is repeated until all servers have been updated with the new release.

Example: If we have 5 containers each running our current application A, then we set our policy to keep a minimum in-service number of 2. We take 3 servers offline to update them to our new version B. Once these are completed and back online, we can update the remaining 2.

Disadvantages

The process happens in multiple stages, so support is necessary in the form of orchestration and health checks outside of Swarm

Does not work well for infrastructure changes

Changes are being run on live servers—recovery time may be necessary if one fails

Advantages

There are few moving parts, which means increased testing capability; make application and code changes within the process

No downtime and no additional infrastructure cost

The process is often quicker than a rolling deployment (see below)

Rolling Deployments

Consider rolling deployments as an extension of minimum in-service. However, rather than define the number of containers that should remain online, we specify the maximum number of containers to update in tandem.

Example: We have the same 5 containers as before, but this time we initialize rolling updates by specifying the number of containers that may be updated simultaneously, e.g. 2. The process moves updates through 2 containers at a time until all the servers in the series are updated.

Note: Docker Swarm supports rolling updates out the box; the default is to update one container at a time. To modify this use the –update-parallelism setting

Disadvantages

Docker rolling updates deal with failure in two ways:

By pausing, allowing someone to jump in and rollback to fix

Or continuing regardless, meaning you may not discover a problem while the container is running

More complex than minimum in-service

Can be the least efficient in terms of deployment time; based on the time taken to update per stage

Again, we recommend orchestration and health checks outside of Swarm

Advantages

Blue/Green Deployments

When following the Blue/Green (a.k.a. Red/Black) method, we replicate our “entire” infrastructure for a short time. The replicated infrastructure hosts the new application, while the old infrastructure continues to run until testing is complete and the new stack is adopted. The capabilities to achieve this have been around for a long time, but before the Cloud, it was an incredibly costly deployment method. Now, we can deploy stacks to a whole new environment—allowing for isolated evaluation—and thanks to the Cloud, at minimal costs. Once testing is complete, we switch our application over to the new version and shut down the legacy stack.

As the image depicts, Blue represents your current environment version, while the new variant you want to deploy is Green. Typically, this happens in the form of a DNS change, though you can deploy Blue/Green by modifying Auto Scaling Groups too.

Disadvantages

Requires advanced orchestration tooling

Some risk as the same database is necessary

Incurs some additional cost, though for a short time only

Unnatural user traffic will flood your servers—which is not the point for everything to break

Advantages

Reduced risk profile since infrastructure becomes immutable

Offers near zero-downtime

The switch is clean and controlled when using a DNS change

Process is fully automated and provides a larger validation window

It’s possible to test the entire environment’s health and performance before the switch

A/B Testing

A/B deployments are virtually identical to Blue/Green, but in this method, we send a small percentage of traffic to our new green environment. This method is capable of switching environments and changing infrastructure, but in a far more precise way than with Blue/Green deployment.

Disadvantages

In comparison to the aforementioned deployment methods, there are a lot of moving parts

Much more complex

Requires full automation of everything

Advantages

All the benefits of Blue/Green deployments, plus:

We can predictably scale capacity and pre-warm production

Use to test new features and make gradual assessments on performance, stability, and health

Selecting your method of deployment comes down to what best suits your business and technical needs. If it makes sense for your application and user base, we highly recommend leveraging A/B testing where possible.

If you’re keen to automate this entire process, then we’d like to invite you to check out Caylent, our SaaS platform that makes it easy to deploy apps, such as WordPress, inside your own cloud. Our DevOps Container Management System automates the entire process covered here and a whole lot more.