Kemampuan penyebaran independen adalah inti masalahnya, jadi setiap layanan membutuhkan pipeline CI/CD sendiri ditambah strategi rilis berisiko rendah — biasanya canary atau blue-green — untuk mengirimkan dengan aman berkali-kali sehari.
Setiap layanan dibangun, diuji, dan dikerahkan sesuai kecepatannya sendiri. Perubahan pada satu layanan tidak pernah memicu rilis seluruh sistem.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategy | How | Pro | Con |
|---|---|---|---|
| Rolling | Replace instances gradually | Simple, default | Mixed versions briefly |
| Blue-green | Two envs, switch traffic | Instant rollback | 2x infra |
| Canary | Send small % to new version | Limits blast radius | Needs good 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
Tanpa skema yang kompatibel ke belakang, canary/blue-green rusak karena dua versi berjalan secara bersamaan. Selalu desain perubahan agar kompatibel di seluruh versi.
Penyebaran sering dan berisiko rendah adalah apa yang membuat microservices layak digunakan meskipun kompleks — rilis yang lambat dan berisiko akan menghilangkan keuntungan otonomi.
Canary dan blue-green membatasi jari-jari ledak dari penyebaran yang buruk dan memberikan rollback hampir instan, mengubah penyebaran dari peristiwa menakutkan menjadi aktivitas rutin, otomatis, dan harian.