ความสามารถในการ deploy อย่างอิสระคือหัวใจสำคัญทั้งหมด ดังนั้นแต่ละเซอร์วิสจึงต้องมี CI/CD pipeline ของตัวเอง บวกกับ กลยุทธ์การ release ที่มีความเสี่ยงต่ำ — โดยทั่วไปคือ canary หรือ blue-green — เพื่อให้สามารถปล่อยของได้อย่างปลอดภัยหลายครั้งต่อวัน
แต่ละเซอร์วิส build, test และ deploy ตามจังหวะของตัวเอง การเปลี่ยนแปลงที่เซอร์วิสหนึ่งจะไม่ trigger การ release ทั้งระบบ
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| กลยุทธ์ | ทำอย่างไร | ข้อดี | ข้อเสีย |
|---|---|---|---|
| Rolling | แทนที่ instance ทีละน้อย | เรียบง่าย, เป็นค่าตั้งต้น | มีหลายเวอร์ชันปนกันชั่วครู่ |
| Blue-green | สอง environment, สลับ traffic | rollback ได้ทันที | ใช้ infra 2 เท่า |
| Canary | ส่ง traffic เปอร์เซ็นต์เล็ก ๆ ไปเวอร์ชันใหม่ | จำกัด blast radius | ต้องมี metrics ที่ดี |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
หากไม่มี schema ที่ backward-compatible canary/blue-green จะพังเพราะมีสองเวอร์ชันรันพร้อมกัน ควรออกแบบการเปลี่ยนแปลงให้เข้ากันได้ข้ามเวอร์ชันเสมอ
การ deploy บ่อย ๆ ที่มีความเสี่ยงต่ำคือสิ่งที่ทำให้ microservices คุ้มค่ากับความซับซ้อนที่เพิ่มขึ้น — การ release ที่ช้าและมีความเสี่ยงจะลบล้างประโยชน์ด้านความเป็นอิสระ (autonomy) ไปเสีย
Canary และ blue-green ช่วยจำกัด blast radius ของการ deploy ที่ผิดพลาด และให้ความสามารถในการ rollback ได้แทบจะทันที เปลี่ยนการ deploy จากเหตุการณ์ที่น่ากลัวให้กลายเป็นกิจวัตรประจำวันที่เป็นอัตโนมัติ