Deploy xong mà service down vài giây thôi cũng đủ để user complain và on-call bị gọi dậy lúc nửa đêm 😩. Dưới đây là 3 chiến lược phổ biến nhất để release mà không ai nhận ra có chuyện gì vừa xảy ra.

🔵 Rolling Update⌗

Thay dần từng pod/instance cũ bằng bản mới, theo từng batch nhỏ.

  • ✅ Không cần thêm hạ tầng, tiết kiệm chi phí
  • ✅ Default strategy của Kubernetes Deployment
  • ⚠️ Trong lúc rollout, cả 2 version cùng chạy song song → cẩn thận breaking change ở API/schema
  • ⚠️ Rollback không tức thời, phải rolling ngược lại

Phù hợp: hầu hết workload nội bộ, ít rủi ro về schema.

🟢 Blue/Green⌗

Dựng song song 2 môi trường (Blue = đang chạy, Green = bản mới), test kỹ Green rồi chuyển toàn bộ traffic sang trong một phát.

  • ✅ Rollback tức thì: trỏ traffic ngược lại Blue
  • ✅ Không có trạng thái “nửa cũ nửa mới”
  • ⚠️ Tốn gấp đôi tài nguyên trong lúc chuyển đổi
  • ⚠️ Cần layer routing/load balancer switch được nhanh (DNS, ALB, Service selector…)

Phù hợp: hệ thống critical, cần rollback nhanh và chắc chắn.

🟠 Canary⌗

Đẩy bản mới cho một nhóm nhỏ traffic (1% → 10% → 50% → 100%), theo dõi metrics/error rate trước khi tăng dần.

  • ✅ Giảm blast radius nếu bản mới có bug
  • ✅ Kết hợp tốt với observability (Prometheus, Datadog…) để auto rollback theo threshold
  • ⚠️ Cần service mesh hoặc ingress hỗ trợ traffic splitting (Istio, Argo Rollouts, Flagger)
  • ⚠️ Phức tạp hơn để setup và debug

Phù hợp: hệ thống lớn, thay đổi rủi ro cao, có sẵn observability tốt.

Chọn cái nào?⌗

Tiêu chí Rolling Blue/Green Canary
Chi phí hạ tầng Thấp Cao (tạm thời) Trung bình
Tốc độ rollback Chậm Tức thì Nhanh (giảm % traffic)
Độ phức tạp Thấp Trung bình Cao
Rủi ro khi lỗi Trung bình Thấp Rất thấp

Không có strategy nào “đúng nhất” — chọn theo mức độ chấp nhận rủi ro và hạ tầng hiện có. Nhiều team production thực ra kết hợp cả 3: Rolling cho service phụ, Blue/Green cho service critical, Canary cho những thay đổi lớn ở core service 🚀.