Uavhengig distribuerbarhet er hele poenget, så hver tjeneste trenger sin egen CI/CD-pipeline pluss en lavrisiko-releasestrategi — vanligvis canary eller blue-green — for å kunne levere sikkert mange ganger per dag.
Hver tjeneste bygger, tester og distribuerer i sitt eget tempo. En endring i én tjeneste utløser aldri en fullstendig systemutgivelse.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategi | Hvordan | Fordel | Ulempe |
|---|---|---|---|
| Rolling | Bytt instanser gradvis | Enkelt, standard | Blandet versjon kort tid |
| Blue-green | To miljøer, bytt trafikk | Øyeblikkelig rollback | 2x infrastruktur |
| Canary | Send liten % til ny versjon | Begrenser skadesradius | Trenger god metrikker |
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
Uten bakoverkompatible skjemaer brytes canary/blue-green fordi to versjoner kjører samtidig. Design alltid endringer for å være kompatible på tvers av versjoner.
Hyppige, lavrisikoinstallasjoner er det som gjør mikrotjenester verdt kompleksiteten — sakte, risikofylte utgivelser ville utslettet autonomifordelen.
Canary og blue-green begrenser skadesradiusen fra en dårlig distribusjon og gir nesten øyeblikkelig rollback, noe som gjør distribusjon fra en skremmende begivenhet til en rutin, automatisert, daglig aktivitet.