Blue-green: two environments, switch traffic after deploy. Rolling: update instances one by one. Canary: send a fraction of traffic to the new version. All require load balancing and health checks. Plan rollback at each step.
Blue-green
- Setup: Two identical environments (blue and green). One serves production traffic; the other is idle or used for staging. Deploy the new version to the idle side.
- Switch: After tests, point the load balancer (or DNS) to the new environment. Traffic flips in one step. Rollback = point back to the old environment. Fast and simple but requires double the capacity during switch.
- Use when: You want a single, quick cutover and can afford two full environments. Good for apps that are not too large or stateful.
Rolling
- Setup: Multiple instances behind a load balancer. Update one instance at a time: take it out of the pool, deploy, health check, put it back. Repeat for each instance.
- Pros: No need for double capacity. Gradual rollout; if one instance fails health check, you still have others. Works well with auto-scaling groups and immutable instances (replace instead of in-place update).
- Cons: Both old and new versions run simultaneously; ensure backward compatibility (e.g. DB schema, APIs). Slower than blue-green for full rollout.
- Use when: You have many instances and want to avoid double capacity. Standard for Kubernetes (rolling update) and many PaaS.
Canary
- Setup: Send a small fraction of traffic (e.g. 5%) to the new version. Monitor errors and latency. If good, increase to 50%, then 100%. If bad, route away and roll back.
- Pros: Limits blast radius. Catch issues with real traffic before full rollout. Good for risky or high-impact changes.
- Cons: More complex (routing rules, metrics, automation). Both versions must run; need backward compatibility.
- Use when: You want to validate in production with minimal risk. Often combined with feature flags.
Common requirements
- Load balancer: Must support taking instances in/out of rotation and (for canary) routing by percentage or header.
- Health checks: LB and orchestration must health-check before sending traffic. Unhealthy instances should not receive traffic; trigger rollback if too many fail.
- Rollback plan: At each step, know how to roll back (revert LB, scale back to old version, disable canary). Test rollback in staging. Database and schema changes need extra care (forward-compatible changes, feature flags).
Summary
Blue-green: two environments, switch traffic after deploy. Rolling: update instances one by one. Canary: send a fraction of traffic to the new version. All need load balancing and health checks; plan rollback at each step.
