Canary deploy
Related service Custom software · everything else
DEFINITION
A new version is rolled out to a small slice of traffic (1%, 5%, 25%) before going to 100%. SLIs (error rate, latency, business metrics) are watched; on regression, automatic rollback. Different from blue-green where two environments swap at once · canary is gradual. Without proper telemetry it is not a canary, just a 'slightly slower deploy'. Tools: Argo Rollouts, Flagger, LaunchDarkly progressive delivery.
- Docker→
We package an app with its dependencies into an image, which runs as a container - identical on your laptop and in production. "Works on my machine" stops being an excuse.
- CI/CD→
Continuous Integration / Delivery: every commit is automatically built, tested and (optionally) deployed. This pipeline lets us ship safely many times a day, without manual mistakes.
- Blue-Green Deployment→
We run two identical environments: blue is live, green is the new version. Once green is verified we flip traffic to it; on trouble we flip back instantly. Zero-downtime releases with instant rollback.
- Horizontal Scaling→
We add more machines/instances (scale out) instead of one bigger box (vertical, scale up). For stateless services this wins: cheaper, more elastic, no ceiling. State goes to a separate store.
- Load Balancer→
Distributes incoming traffic across multiple instances - the front door that gives you redundancy and smooth scaling. Health checks remove dead instances, so one failure stays invisible to users.
- Distributed Tracing→
We follow one request across every service using a trace ID (e.g. OpenTelemetry). In a microservices system this is how we pinpoint which service slowed down or failed - no guessing.