Canary vs blue-green deployment to reduce downtime

In the past, developers released updates late at night — when users were not active — to minimize disruptions. Updating during slow times ensured users didn’t have problems and weren’t inconvenienced. Today, users want cloud services available 24/7 in all time zones, which makes finding convenient deployment times challenging.

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 discuss the pros and cons of choosing one deployment setup over another.

Deploying without downtime

Historically, developers brought applications offline when deploying changes and updates, resulting in downtime. Now, continuous integration and delivery (CI/CD) allows teams to automate application build, test, and deployment processes. CI/CD pipelines keep environments available as much as possible, while speeding up the deployment process. But deploying an application or updating an environment can still cause downtime and other issues.

Most businesses want to release applications and features without affecting the user. This is especially true for those with a modern application setup and a CI/CD pipeline in place. 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 reducing deployment downtime. Generally, your environment should meet the following requirements for both the canary and blue-green deployment methods:

1. A deployment pipeline that can build, test, and deploy to specific environments

2. Multiple application nodes or containers distributed behind a load balancer

3. 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. Using a non-destructive method in your data layer lets you reverse changes or delete features if there are problems.

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 splits your runtime environment into two identical sections: Blue and Green. This ensures that resources are distributed equally and eliminates the possibility of conflicts or misconfiguration issues. Here’s how the strategy works:

1. You serve the current application on one half of your environment (Blue), using a load balancer to direct traffic. The Green environment remains idle.

2. When it’s time to release a new version of the application, the update is deployed to the Green environment, which is not currently serving any production traffic.

3. The engineering team tests and monitors the application in the Green environment, ensuring it meets all performance and security requirements.

4. Once the new version on the Green environment is fully vetted and deemed stable, the traffic is switched from the Blue environment to the Green environment.

5. The Green environment is now the production environment, and the Blue environment becomes idle.

Load balancers help maintain smooth operation of your production environment for users. This is especially important when you are making changes and updates to your testing environment. After testing, you can switch the load balancer to the green environment without disrupting users.

Setting up your application environment this way has other benefits. You can use the idle environment as a backup when your app is under heavy load or during disaster recovery.

What is canary deployment?

Canary deployment works similarly to blue-green deployment, but uses a slightly different method. Canary deployments switch a small part of servers or nodes first, instead of waiting for the whole environment to be ready.

You can configure your environment for canary deployments in a variety of ways. The first method involves using a load balancer:

1. Your production environment is set up behind a load balancer, with a few extra nodes or servers being reserved as backups.

2. The spare node or server group is the deployment target for the new version of your app. When an update is ready for release, you deploy it to your unused nodes. These “canary” servers are the first to run the new version in the live environment.

3. Using the load balancer, you gradually direct a small percentage of traffic to the canary servers. This allows you to test the update on a small number of users first, monitoring for errors or user feedback to help identify and address any issues.

4. If the new version performs well and no significant issues are detected, you gradually increase the percentage of traffic it receives. This incremental process continues until the new version is handling all traffic.

The other option for configuring a canary deployment is to use a development pattern called feature flags. These tools let you control changes in an application with a configuration switch. They enable you to easily turn features on or off without changing the code. This can be useful for testing new features, rolling out changes gradually, or fixing bugs quickly.

Here’s how you execute a canary deployment using feature flags:

1. When developing new features or making significant changes to existing ones, wrap the changes in feature flags. This practice ensures that the new functionality can be enabled or disabled through configuration changes rather than code deployments.

2. Deploy your application with the new features or changes disabled by default. This means the new code is present in your production environment but inactive.

3. Identify a small group of users to act as your canary group. This could be a percentage of your total user base, specific user IDs, or users who meet certain criteria. Enable the feature flags only for this canary group.

4. Closely monitor application performance, user feedback, and any other relevant metrics for issues related to your changes.

5. If the canary phase is successful and the new features are stable, begin gradually increasing the percentage of users with the feature flag enabled. Continue the incremental rollout, monitoring for issues as the number of users increases.

6. Once you’re confident in the stability and performance of the new features, enable the feature flags for all users, completing the rollout. If significant issues are encountered during the canary or rollout phases, use the feature flags to disable the new features.

Canary deployments with feature flags can be challenging to set up, but there are tools that simplify the process, including Flagger and Argo Rollouts. You can incorporate these tools into your CI/CD pipeline, giving you end-to-end visibility into your continuous delivery process and the ability to swiftly roll back changes when issues arise.

Blue-green vs canary deployment: Which should you choose?

Blue-green deployment leverages two mirrored environments for safe, instant updates, while canary deployment employs staged rollouts to minimize impact on the user experience. Which method 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 resources to set up two hosting environments and your app rarely changes in a way that is not backwards compatible, blue-green deployment may be best for you. It offers many benefits and requires few changes to your app. It allows for continuous operation without interruptions, which can be helpful during performance problems or disaster recovery.

If you have a modular, configuration-driven application and want to limit the number of idle resources you provision, consider using canary deployments. This approach allows you to test the changes on a smaller scale before rolling them out to the entire application, and to easily enable or disable features as needed. It can help minimize the impact of any potential issues.

While blue-green is ideal for straightforward, low-risk updates, canary deployments offer a more nuanced approach, allowing for detailed feedback and adjustments. Both methods are invaluable in modern software development, ensuring high availability and user satisfaction. Deciding which one is best for you will 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. To reach this goal, you must activate certain features in your setups and programs, like load balancing and stateless designs.

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. You can learn more about automating and safeguarding your deployment processes in What is continuous delivery (CD)?

Now that you understand canary and blue-green deployment strategies, you can choose the most suitable approach for your business. This will allow you to deploy your apps smoothly without experiencing any downtime. Start right away by signing up for your free CircleCI account and exploring release management capabilities for faster, more reliable deployments.