Itsenäinen käyttöönottokelpoisuus on koko pointti, joten jokainen palvelu tarvitsee oman CI/CD-putkilinjan sekä matalariskisen julkaisustrategian — tyypillisesti canary tai blue-green — jotta voidaan julkaista turvallisesti monta kertaa päivässä.
Jokainen palvelu rakentaa, testaa ja ottaa käyttöön omaan tahtiinsa. Muutos yhteen palveluun ei koskaan käynnistä koko järjestelmän julkaisua.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategia | Miten | Etu | Haittapuoli |
|---|---|---|---|
| Rolling | Korvaa instanssit asteittain | Yksinkertainen, oletusarvo | Sekalaiset versiot hetkellisesti |
| Blue-green | Kaksi ympäristöä, liikenneksi vaihto | Välitön palautus | 2x infrastruktuuri |
| Canary | Lähetä pieni % uuteen versioon | Rajoittaa vaikutusaluetta | Tarvitsee hyviä mittareita |
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
Ilman taaksepäin yhteensopivia scheemoja canary/blue-green hajoavat, koska kaksi versiota toimii samanaikaisesti. Suunnittele muutokset aina siten, että ne ovat yhteensopivia eri versioiden välillä.
Usein tehdyt, matalariskiset käyttöönodot ovat se, mikä tekee mikropalivelisista vaivan arvoisen monimutkaisuuden — hitaat, riskilliset julkaisut poistaisivat autonomiahyödyn.
Canary ja blue-green rajoittavat huonon käyttöönodoton vaikutusaluetta ja tarjoavat lähes välittömän palautuksen, muuttaen käyttöönodosta pelottavasta tapahtumasta rutiininomaiseksi, automaattiseksi, päivittäiseksi toiminnaksi.