Onafhankelijke deployability is het hele punt, dus elke service heeft zijn eigen CI/CD pipeline plus een risicoarme release-strategie nodig — meestal canary of blue-green — om veilig meerdere keren per dag uit te rollen.
Elke service bouwt, test en implementeert op zijn eigen tempo. Een wijziging in één service triggert nooit een volledige systeemrelease.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategie | Hoe | Voordeel | Nadeel |
|---|---|---|---|
| Rolling | Instances geleidelijk vervangen | Eenvoudig, standaard | Kortstondig gemengde versies |
| Blue-green | Twee omgevingen, verkeersomschakeling | Instant rollback | 2x infrastructuur |
| Canary | Klein percentage naar nieuwe versie | Beperkt blastgebied | Vereist goede metreken |
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
Zonder backward-compatible schema's breken canary/blue-green omdat twee versies gelijktijdig draaien. Ontwerp wijzigingen altijd zodat ze compatibel zijn over versies.
Frequente, risicoarme implementaties zijn wat microservices de complexiteit waard maakt — trage, risicovolle releases zouden het autonomievoordeel opheffen.
Canary en blue-green beperken het blastgebied van een slechte implementatie en bieden bijna-instant rollback, wat implementatie verandert van een eng gebeuren in een routine, geautomatiseerde, dagelijkse activiteit.