In the past, many development teams scheduled deployments when users were least likely to be using the applications, like the middle of the night. Now that users expect cloud-based, 24x7 environments to be available in all time zones, easy-to-find deployment windows are gone. Fortunately, there are two common deployment techniques that can virtually eliminate downtime: blue-green deployment configuration and canary deployment configuration. In blue-green deployment you serve the current app on one half of your environment (Blue) and deploy your new application to the other (Green) without affecting the blue environment. In canary deployment you cut over just a small subset of servers or nodes first, before finishing the others.

In this article we will look at some of the trade-offs, requirements, and advantages of choosing one deployment configuration or the other.

Deploying without downtime

Historically, developers brought applications offline when deploying changes and updates, resulting in downtime. Now, continuous integration and continuous deployment (CI/CD) pipelines that automate application build, test, and deployment. CI/CD piplines keep environments up as much as possible, and speed up the deployment process. Deploying an application or updating an environment can still cause downtime and other issues.

For most enterprises, especially those with an up-to-date application architecture and an established CI/CD pipeline, the goal is to deploy applications and features at any time with no noticeable effect on the end user. This requires deploying changes into production environments, rapidly and safely, without:

  • Interrupting users who may be performing critical tasks
  • Relying on your systems for mission-critical processes

Your application and deployment architecture plays a key role in reducing deployment downtime. Generally, your environment should meet the following requirements for both the canary and blue-green deployment methods:

  • A deployment pipeline that can build, test, and deploy to specific environments
  • Multiple application nodes or containers distributed behind a load balancer
  • An application that is stateless, allowing any nodes in the cluster to serve requests at any time

When you make changes to your application, they should be non-destructive to your data layer. This means you should make columns in your datasets optional or nullable. Don’t rename or reuse columns for different purposes. Adopting this non-destructive approach in your data layer enables you to roll back changes or unwind features if something goes wrong.

With these requirements in mind, let’s explore the first zero downtime deployment option: the blue-green deploy.

What is blue-green deployment?

Blue-green deployment, the more common of the two options we are considering, splits your application environment into two equally-resourced sections, Blue and Green. You serve the current application on one half of your environment (Blue) using your load balancer to direct traffic. You can then deploy your new application to the other half of your environment (Green) without affecting the blue environment.

Using your load balancers to direct traffic keeps your blue environment running seamlessly for production users while you test and deploy to your green environment. When your deployment and testing are successful, you can switch your load balancer to target your green environment with no perceptible change for your users.

There are many other benefits to setting up your application environment this way. For example, the green environment can also act as an instant hot standby if your application is under heavy load, or even as part of a disaster recovery activity.

What is canary deployment?

Canary deployment works similarly to blue-green deployment, but uses a slightly different method. Instead of another full environment waiting to be switched over once deployment is finished, canary deployments cut over just a small subset of servers or nodes first, before finishing the others.

There are many ways to configure your environment for canary deployments. The simplest way is to set up your environment behind your load balancer as normal, but keep an additional node or server or two (depending on the size of your application) as an unused spare. This spare node or server group is the deployment target for your CI/CD pipeline. Once you build, deploy, and test this node, you add it back into your load balancer for a limited time for a limited group of people. This allows you to make sure changes are successful before you repeat the process with the other nodes in your cluster.

The other option for configuring a canary deployment is to use a development pattern called feature toggles. Feature toggles (sometimes called feature flags) work by building and deploying your changes to an application controlled by a configuration that switches those changes on. You take a node out of your cluster, deploy, and add it back in — but without needing to test or control anything through the load balancer. Then, when all the nodes are updated, you toggle the feature on for a number of users before rolling the feature out to everyone.

The downside to this method, however, is the development time and cost of modifying your application to support feature toggles. Depending on the age and size of your application, developing this feature could be fairly complex or nearly impossible.

Blue-green deploy versus canary deploy

So which method, blue-green or canary, is the best way to deploy with zero downtime? Both are effective strategies, and both require a fairly similar architecture, but there are distinguishing features.

If you have the capacity for two complete application hosting environments, and your application rarely changes in a way that is not backwards compatible, blue-green offers the most secondary benefits with minimal application changes. It enables a zero downtime environment that you can also leverage when performance issues occur, or during a disaster recovery situation.

If, however, you are limited in how many extra resources you can provision, or your application is modular and configuration-driven, you can use the canary deployment option instead. While you lack an extra environment to use for other concerns, you minimize the amount spent operating and maintaining your environment. Canary deployment also provides an easier way to enable and disable features at any point or based on any set of criteria.

Both methods, however, require some pre-planning and thought about the architecture of your applications and environments.

Wrap up

Both the blue-green and canary deployment methods help deploy your application without any downtime or interruptions for users. Achieving this goal requires that specific capabilities are enabled in your environments and applications, particularly load balancing and stateless architectures.

Deployment automation and consistency also matter when updating and changing your environments, if your goal is zero downtime. Using your CI/CD pipeline to handle the automated deployment, testing, and cutover of application environments helps immensely.

Now that you have more information about canary and blue-green deployment strategies, you can choose the one that works best for your enterprise and, hopefully, deploy your applications with zero downtime. You can get started right away, by signing up for your CircleCI free trial today.