Even before the cloud, no one liked deployment downtime. With applications hosted in traditional data centers that restricted access for local users, many organizations scheduled deployments when users were less likely to be using the applications, like the middle of the night. With widespread adoption of cloud-based, 24x7 environments that are accessed from all time zones, every hour of the day, easy-to-find deployment windows are gone. Everyone is aiming for their applications to always be available to all potential users, all the time.

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 help keep environments up as much as possible, and speed up the deployment process. However, deploying an application or updating an environment can still cause downtime and other issues.

In this article, we will explore two common deployment techniques to virtually eliminate downtime: blue-green deployment configuration and canary deployment configuration. We will also look at some of the trade-offs, requirements, and advantages of choosing one or the other.

Deploying without downtime

The ultimate goal for most enterprises, especially those with a modern application architecture and an established CI/CD pipeline, 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 or relying on your systems for mission-critical processes.

Your application and deployment architecture plays a key role in minimizing or even eliminating 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

Additionally, 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 and not rename or reuse columns for different purposes. Adopting this non-destructive approach in your data layer enables you to rollback changes or unwind features if something does happen to go wrong.

With these requirements in mind, let us dive into 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, essentially splits your application environment into two equally-resourced sections, a blue and a green. This enables you to serve the current application on one half of your environment (the blue environment) using your load balancer to direct traffic. You can then deploy your new application to the other half of your environment (the green environment) without affecting the blue environment.

By using your load balancers to direct traffic, you keep 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 instance, 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, but the simplest 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 your 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 repeating 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 or feature flags. Feature toggles work by building and deploying your changes to an application controlled by a configuration that does not work without switching those changes on. As above, 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 achieve deployments with zero downtime? Both are effective deployment mechanisms, and both require a fairly similar architecture, but each has some 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 leverage for other concerns, you do 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 you want to achieve zero downtime. Leveraging 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.