You ship 100 deploys a week. Each one risks breaking production. The naive "stop the old version, start the new version" gives you 30 seconds of total outage and a rollback that takes longer than the original deploy. Deployment strategies — blue-green, canary, rolling — let you ship continuously with zero downtime and instant rollback. Pairs with feature flags for the application-layer release dimension.
| Strategy | How it works | Rollback | Cost |
|---|---|---|---|
| Recreate | Stop old, start new. Downtime during deploy. | Re-run with old image | Free; bad UX |
| Rolling | Replace instances N at a time. Old + new run side by side briefly. | Roll back the same way (slow) | Cheap; default in K8s |
| Blue-green | Two full environments. Switch traffic atomically. | Switch traffic back instantly | 2× infra during deploy |
| Canary | Deploy to a small slice (1%). Watch metrics. Promote or revert. | Revert before promotion | Minimal extra infra |
You run two environments behind a router (LB, DNS, service mesh):
Cut over: flip the router from blue → green. All new requests go to green. Done.
Rollback = flip back. Instant. Old environment was running, just not serving.
Cost: 2× infrastructure during the deploy window (often hours-long for safety). Trade money for instant rollback. Used for high-stakes critical services where rollback speed matters most.
Deploy the new version to a small subset of instances (typically 1-5%). Other instances stay on the old version. The router (LB, mesh) splits traffic by percentage.
Watch metrics on the canary instances:
If healthy after a hold period (15 min - 1 hour), promote: bump canary to 10%, watch, then 25%, then 50%, then 100%. Each step is a checkpoint with automated guardrails. Spinnaker, Argo Rollouts, Flagger automate the whole ladder.
Blue-green is binary — all or none. Canary lets you discover problems with 1% blast radius instead of 100%. The bug that only shows up under real production load? Canary catches it before it bites everyone.
Modern canary platforms (Flagger, Argo Rollouts) do automated promotion + rollback based on SLO compliance. The pattern:
Operator never touches the deploy after pushing. SLO-violating changes self-revert before anyone is paged. Confidence in deploys goes from "fingers crossed" to "trust the system." Netflix and Lyft both run this pattern.
The catch: requires good SLO definitions (see SLIs/SLOs) and metric instrumentation. Garbage-in metrics = false confidence in your canary analysis.
All these strategies have one painful invariant: old + new must coexist briefly. So new versions must be backwards-compatible with old versions of:
Common pattern: expand-then-contract migrations. Add a new column / endpoint / message field. Old code ignores it. Deploy new code that uses it. Once 100% on new, remove the old. Two deploys instead of one, but always backwards-compatible during transition.
Deploy to AWS + GCE simultaneously with canary analysis. Open-source; battle-tested at Netflix scale.
CRDs that turn standard deployments into canary or blue-green with automated promotion. The new default in K8s shops.
Native canary support for Lambda (10% then 100%) and ECS services. Native to the AWS deploy story.
Mesh handles the percentage routing. Canary is just a YAML change. Combine with feature flags for full progressive delivery.
News feed deploys ranker changes via canary with auto-promotion. E-commerce uses blue-green for checkout — instant rollback critical near peak shopping. Payment gateway is canary-only (small slice for hours, monitor everything). Notification system uses rolling for back-end workers, canary for client-facing APIs.
