Day 80: Blue-green and canary deployments
Deploying with a safety net
Blue-green: run two identical environments (blue = current, green = new version); once green passes checks, switch all traffic to it atomically. Rollback is just switching traffic back — instant, since blue never stopped running. Cost: you need double the infrastructure, at least briefly.
Canary: route a small percentage of real traffic (e.g. 5%) to the new version, watch its error rate/latency, and gradually increase the percentage if it looks healthy — or roll back instantly if it doesn't. Cost: more operational complexity (you need real metrics and a mechanism to split traffic by percentage), but you catch problems on a small blast radius instead of all users at once.
Both exist because Kubernetes's default RollingUpdate isn't always enough
RollingUpdate (Phase 8, Day 56) replaces Pods gradually but doesn't control *traffic percentage* precisely, and mixes both versions serving simultaneously without a controlled ramp. Canary and blue-green are strategies for controlling risk explicitly — this is exactly what a service mesh (Phase 22) or dedicated tooling (Argo Rollouts) automates.
Key terms
- Blue-green deployment
- Two full environments, with traffic switched atomically between them.
- Canary deployment
- Gradually shifting a small, increasing percentage of traffic to a new version while monitoring health.
Why might a team choose canary deployment over blue-green for a high-traffic service?
