Canary Deployment
Canary deployment is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure.
1. The Concept
The term comes from the "canary in a coal mine" practice. Miners would carry a canary into mine tunnels. If dangerous gases collected, the canary would die first, giving the miners a warning to escape.
In software, the "canary" is the small percentage of users who receive the new update. If the update is buggy, only a few users are affected, and you can rollback quickly.
2. How it Works
- Stage 1: Deploy the new version (v2) to a small percentage of your infrastructure (e.g., 5% of servers) or route 5% of traffic to it.
- Stage 2: Monitor key metrics (error rates, latency, CPU usage) specifically for the v2 instances.
- Stage 3: If metrics are healthy, gradually increase the traffic (10%, 25%, 50%).
- Stage 4: Once 100% of traffic is on v2, decommission the old version (v1).
3. Canary vs. Blue-Green Deployment
- Blue-Green: You have two identical environments (Blue and Green). You switch 100% of traffic from Blue to Green instantly.
- Pros: Fast rollback, no version mixing.
- Cons: Requires double the infrastructure (costly).
- Canary: You gradually replace old instances with new ones.
- Pros: Cheaper (no need to double resources), limits blast radius of bugs.
- Cons: Slow rollout, you have two versions running simultaneously (version compatibility issues).
4. Implementation Strategies
- Load Balancer: Configure the load balancer (e.g., NGINX, HAProxy, AWS ALB) to split traffic based on weight.
- Feature Flags: Use feature flags to enable the new functionality for specific users (e.g., internal employees or beta testers) regardless of the server they hit.
- Kubernetes: Tools like Istio or Flagger can automate canary rollouts based on metrics.
programming/continuous-deployment programming/ci-cd-pipelines programming/software-testing-basics