You've mastered CI — code is built, tested, and ready. Now the hard question: how does it get to users? This lesson covers the deployment strategies you'll choose between as an architect.

The Deployment Problem

You have v1 running in production. v2 is ready. How do you switch without:

  • ❌ Downtime (users see errors)
  • ❌ Corruption (half-old, half-new state)
  • ❌ No way back (if v2 is broken, you're stuck)

Different strategies make different tradeoffs. As an architect, you'll pick the right one per service.

Strategy 1: Recreate (Replace)

v1.0 Running ⚠️ DOWN Stop → Deploy → Start v2.0 Running ✅ Simple | ❌ Downtime | ❌ Risky rollback Use for: dev environments, batch jobs, non-critical internal tools

Strategy 2: Rolling Update

Time → Pod 1 Pod 2 Pod 3 v1 🔄 v2 v1 🔄 v2 v1 🔄 v2 ✅ Zero downtime | ✅ Gradual | ⚠️ Both versions run briefly Use for: stateless APIs, microservices (Kubernetes default!)
Pods are replaced one at a time. At any moment, at least 2/3 pods serve traffic. You already know this from K8s!

Strategy 3: Blue-Green

Load Balancer 🔵 Blue (v1 — LIVE) Pod 1 | Pod 2 | Pod 3 ← All traffic goes here 🟢 Green (v2 — IDLE) Pod 1 | Pod 2 | Pod 3 Deploy here, test, then switch switch! ✅ Instant rollback (switch back) | ✅ Zero downtime | ❌ Double infrastructure Use for: critical services where rollback speed matters most
Both versions exist simultaneously. Traffic switches atomically. Rollback = switch back.

Strategy 4: Canary

Phase 1 Phase 2 Phase 3 v1 ← 95% traffic v2 ← 5% 🐤 Monitor error rate... v1 50% v2 50% Still healthy? Promote... v2 ← 100% 🎉 Full promotion complete ✅ Lowest risk | ✅ Real traffic validation | ❌ Complex | ❌ Needs observability Use for: high-traffic user-facing services where a bad deploy = revenue loss
Gradually shift traffic. If metrics degrade at any phase, auto-rollback to v1. This is what ArgoCD Rollouts does.

Decision Framework: Which Strategy When?

Can you tolerate downtime? Yes → Recreate No Need instant rollback? Yes, cost OK → Blue-Green No High traffic? Need validation? Yes → Canary No → Rolling Update
Start from the top question and follow the path. Most K8s services end up with Rolling or Canary.
StrategyDowntimeRollbackCostComplexity
Recreate⚠️ YesSlow (redeploy v1)1×Low
Rolling✅ NoneModerate (rollout undo)1×Low
Blue-Green✅ NoneInstant (switch back)2×Medium
Canary✅ NoneInstant (shift to 0%)1.1×High

How These Map to Our Tools

StrategyAzure App ServiceKubernetes (AKS)GitOps (ArgoCD)
RecreateDefault deploystrategy: RecreateDefault sync
Rolling—strategy: RollingUpdateDefault sync
Blue-GreenDeployment slotsTwo Deployments + Service switchArgo Rollouts
CanaryTraffic splittingArgo Rollouts + AnalysisTemplateArgo Rollouts
Since you already know Kubernetes: Rolling Update is the default K8s strategy (what happens with kubectl apply). Blue-Green and Canary require additional tooling — we'll use Argo Rollouts for these when we reach the GitOps modules.

🧠 Recall Check

  1. Which strategy has downtime? Which has zero downtime?
  2. What's the key difference between Blue-Green and Canary?
  3. Which strategy is the Kubernetes default?
  4. For a high-traffic payment service, which strategy would you recommend and why?
Reveal answers
  1. Recreate has downtime. Rolling, Blue-Green, and Canary all have zero downtime.
  2. Blue-Green switches 100% of traffic at once (all or nothing). Canary shifts traffic gradually (5% → 25% → 50% → 100%), validating at each step.
  3. Rolling Update — strategy.type: RollingUpdate in Deployment spec.
  4. Canary. High traffic means a bad deploy affects many users. Canary limits blast radius (only 5% of users see v2 initially) and automated analysis can detect issues before full rollout. The cost of getting it wrong (payment failures) justifies the complexity.

Next lesson: Azure OIDC Authentication — connecting your pipeline to Azure without storing any credentials.