A canary deployment is an application rollout strategy that involves keeping some users on the current production version of an application, while shifting a progressively-larger portion of user traffic to a new version. Also called a "phased rollout," a canary deployment strategy helps organizations test new features or underlying technologies before bringing them to everyone. It's an effective, safer way to gather user feedback while measuring the impacts of future changes.
How do canary deployments work?
Let's say we have a video streaming application with a sizable user base. First, we'll assume that 100% of users are running the sole production version (Version A). As a developer, we may want to experiment with new playback controls, new transmission protocols, or a number of factors that directly impact user experiences—such as variable video quality.
If we want to pursue a canary deployment, we need to complete the following steps:
Assessing our user base. Will this be tested externally or internally? Which group(s) will receive the new application (Version B) and which will remain on Version A?
Accounting for capacity issues and other resource needs
Determining the number of stages necessary and the increments in which we'll shift traffic (such as 25%)
Designing a new architecture and associated environment to go with it
Setting up monitoring and metrics gathering
Gathering feedback and assessing overall confidence in Version B. How are performance, reliability, security, and satisfaction?
Rolling out to greater numbers of users until all have transitioned
There's no set amount of time that a canary deployment should take from start to finish. Each organization has different goals and infrastructure setups. The overall breadth of changes introduced is also a major determining factor in rollout time. Plus, every organization has a unique process for both gathering and triaging feedback.
What makes canary deployments useful?
It can be tricky (and often risky) to simultaneously move all application users from one live application version to another. Like we mentioned previously, the primary purpose of canary deployments are to allow staged rollouts of new application versions. However, there are many benefits to the canary approach:
Gradual rollout in settable increments, depending on your cloud platform or load balancer
Rollout automation and customized deployment
Real-world reliability testing
User satisfaction and readiness testing for new features, design languages, etc.
Easier rollback and issue remediation
Because canary deployments are good for gathering feedback, it's also possible to shorten the software feedback loop by spotting issues faster. And in cases where breaking issues aren't found, these deployments give teams the confidence to complete a successful launch.
However, canary deployments do come with some important drawbacks. First, you have to maintain separate application environments and code bases. Second, establishing reliable and efficient traffic routing splits can be challenging—and time consuming. Finally, there's never a guarantee that a wider rollout will be trouble-free (but this can be said for all software). Canary deployments are associated with improved software quality, but this isn't always the case. Teams should keep this in mind while testing.
Does HAProxy support canary deployments?
Yes! HAProxy, HAProxy Enterprise, HAProxy ALOHA, and our comprehensive Kubernetes solutions support traffic splitting between applications, letting you selectively route groups of users to different backends. Within your backend configuration, you can even designate as many server pools as you'd like. No matter which product you're using, it's easy to set up incremental traffic splitting between staging and production environments.
