Modulárny monolit vs mikroslužby. Ako si vybrať architektúru

Fakturácia a sklad sa menia v tom istom vydaní, hoci ich vyvíjajú rôzne tímy. Rozhodnutie o mikroslužbách má začať týmto obmedzením a cenou jeho odstránenia. Samostatná služba umožní nezávislé nasadenie, ale pridá sieťové volania a ďalšiu prevádzku.

Modulárny monolit beží ako jedna aplikácia, rozdelená vnútri podľa obchodných oblastí. Fakturácia si od skladu pýta rezerváciu cez rozhranie a nesiahne mu do tabuliek. Rovnako sú na tom objednávky. Mikroslužby berú tú istú hranicu a postavia ju medzi dva procesy, zvyčajne aj medzi dve databázy. Prevádzková cena tej hranice je to, čo sa mení, a rátať sa má skôr, než tím otvorí druhý repozitár a zistí, že jednoduchý formulár teraz potrebuje dve nasadenia.

1. 01

   Modulárny monolit

   Jeden proces a deploy. Moduly komunikujú cez vnútorné kontrakty.

2. 02

   Mikroslužby

   Samostatné procesy a deploye. Každá hranica prináša sieť a prevádzku.

Začnite doménou, nie infraštruktúrou

Ak sa doména nedá rozumne rozdeliť v jednom procese, sieť tú hranicu nenájde za nás. Nejasný rez sa po rozdelení prejaví ako časté vzdialené volania nad zdieľanými tabuľkami a ako nasadzovanie, ktoré si musia dva tímy dohodnúť na tej istej hodine. Systém vyzerá distribuovane. Meniť sa však stále musí ako jeden celok.

Modul v monolite potrebuje verejný kontrakt. Kód fakturácie nemá čítať interné tabuľky skladu, má si rezerváciu vypýtať cez rozhranie, ktoré sklad vlastní. Takéto pravidlo ustrážia testy architektúry a kontrola závislostí, ak má každý balík vlastníka. A keď hranica drží lokálne, presun za sieťové API prestáva byť skokom do neznáma a stáva sa z neho bežná úloha, ktorú vie tím odhadnúť bez toho, aby hádal.

Dobré moduly kopírujú schopnosti firmy. Priečinky s názvami controllers a repositories pomenúvajú vrstvy, nie schopnosti. Zmena cenotvorby potom zostane v cenotvorbe a neprekvapí nikoho v preprave o dva týždne neskôr, keď sa už nikto nepamätá, čo presne sa v tom vydaní menilo. Rovnaké uvažovanie používame pri návrhových vzoroch v praxi, len o poschodie nižšie.

Čo si mikroslužba kupuje

Samostatná služba má vlastný rytmus nasadenia. Tím opraví vyhľadávanie a vydá ho ešte v ten istý deň, kým zvyšok produktu beží ďalej v poslednej schválenej verzii, pričom kompatibilitu medzi službami treba naďalej overovať. Výpočtovo náročnú časť sa oplatí škálovať oddelene. Citlivý modul môže dostať prísnejší bezpečnostný režim než zvyšok aplikácie.

Nezávislosť má cenu len tam, kde ju firma vie naozaj použiť.

Účet príde hneď, lebo lokálne volanie sa mení na sieťové. Odpoveď môže meškať alebo doraziť dvakrát. Občas nedorazí. Odvtedy treba timeouty, opakovanie bezpečné voči duplikátom a trasovanie cez viac služieb, a hlavne treba vopred vedieť, čo systém urobí, keď z reťazca volaní zlyhá jedno. Jedna databázová transakcia už celý obchodný krok nedrží pokope.

Testovanie sa tým mení tiež. Zelený unit test nedokazuje, že sa dve nasadené služby stále dohodnú na tom, ako vyzerá objednávka. Kontrakty medzi nimi potrebujú vlastnú kontrolu pri každom vydaní. Bez tejto disciplíny rastie čas diagnostiky rýchlejšie než počet služieb, a to je presne ten účet, ktorý si nikto nedal do rozpočtu a ktorý napokon platí ten, kto má práve pohotovosť.

Dáta určujú skutočnú hranicu

Služba, ktorá vlastní kód, ale číta cudzie tabuľky, nie je nezávislá. Rozbije ju zmena schémy v inom tíme, ktorej sa jej vlastný repozitár ani nedotkol, takže o vlastníctve dát sa rozhoduje už vtedy, keď niekto na tabuli kreslí prvú hranicu. Nie neskôr pri výbere úložiska.

Samostatné úložiská znamenajú, že niektoré pohľady budú chvíľu neaktuálne. Objednávka sa potvrdí a fakturácia sa o tom dozvie o okamih neskôr. Tím musí pomenovať, kde je takéto oneskorenie prípustné. Analytický prehľad ho znesie. Účtovný zostatok alebo rezervácia posledného kusu na sklade potrebujú iný návrh, lebo tam sa z okamihu nepresnosti stáva telefonát od zákazníka, ktorému systém tovar už sľúbil.

Rozdelená transakcia sa nemá maskovať reťazou krehkých synchrónnych volaní.

Pomáhajú udalosti s idempotentným konzumentom. Pomáha aj proces, ktorý vie po výpadku pokračovať tam, kde skončil. Je to však ďalšia prevádzková vrstva. Treba ju pozorovať aj skúšať. Ak produkt zatiaľ nezávislé vlastníctvo dát nepotrebuje, vyjde lacnejšie jedna databáza za dobre chránenými modulmi, ktorú nikto nemusí po výpadku zmierovať s druhou kópiou tých istých čísel.

Tímová štruktúra nie je poznámka pod čiarou

Mikroslužby dávajú najväčší zmysel tam, kde existuje tím, ktorý službu vlastní od prvého návrhu cez nasadenie až po incident o druhej v noci, a nie tím, ktorý ju len zdedil. Samostatný repozitár bez jasného vlastníka zodpovednosť nesústredí, iba ju rozptýli. Zmena potom čaká na cudzích ľudí.

Menší produktový tím zvyčajne získa viac z jedného nasadenia a z jedného vývojového prostredia, v ktorom sa dá refaktorovať naprieč modulmi bez čakania na cudzí merge. Monolit preto nemusí byť neporiadok. Distribúcia je len drahý spôsob, ako si disciplínu vynútiť zvonku.

Obráti sa to, keď dva tímy pravidelne blokujú to isté vydanie a keď je hranica medzi nimi stabilná, pričom každá z nich potrebuje iný rytmus nasadzovania. Vtedy oddelenie koordinačnú cenu zníži. Dôkaz prichádza z práce, ktorá už prebieha.

1. 01

   Samostatný rytmus zmien

   Jeden modul blokuje vydania ostatných.

2. 02

   Odlišné škálovanie

   Záťaž je izolovaná a opakovane zmeraná.

3. 03

   Jasný vlastník

   Tím vie prevziať vývoj aj prevádzku.

4. 04

   Stabilný kontrakt

   Hranica domény sa už nemení každý sprint.

Signály, že modul dozrel na oddelenie

Prvým signálom je nezávislý dôvod na zmenu. Modul má vlastný produktový plán a väčšina jeho úprav sa nikde inde v systéme neprejaví, takže tím okolo neho nemusí čakať na nikoho. Druhý signál je prevádzkový. Modul potrebuje iné škálovanie alebo inú dostupnosť než zvyšok aplikácie, niekedy aj technológiu, ktorú by si do systému nikto iný dobrovoľne nepridal, lebo by ju musel prevádzkovať.

Tretí signál je stabilný kontrakt. Tím vie bez hádania pomenovať vstupy aj výstupy, vie povedať, kto vlastní ktoré dáta, a vie opísať, čo presne služba urobí, keď jej volanie zlyhá uprostred kroku. Ak sa kontrakt mení každý sprint, samostatné nasadenie nestabilitu neodstráni. Presunie ju do verziovania API.

Praktický postup je hranicu najprv upevniť v monolite. Zastavia sa priame databázové skratky. Pridajú sa kontraktové testy a začne sa merať, koľko volaní medzi modulmi prechádza a ako často padnú pri skutočnej záťaži, nie v starostlivo pripravenom demo prostredí. Až potom má zmysel porovnať prínos oddelenia s cenou distribúcie. Mikroslužba je záver, ku ktorému tím dôjde s číslami v ruke.

Rozhodnutie, ktoré sa dá neskôr zmeniť

Pre nový firemný systém býva modulárny monolit rozumný začiatok, kým produkt aj hranice ešte dozrievajú. Jedno nasadenie drží spätnú väzbu rýchlu. Silné moduly pritom nechávajú otvorené dvere pre časť, ktorá si nezávislosť neskôr naozaj zaslúži, a môžu obmedziť rozsah neskoršieho oddelenia.

Mikroslužby sú správna voľba vtedy, keď firma za spoločné vydania alebo za nejasné vlastníctvo už platí merateľnú cenu, a keď to isté platí o spoločnom škálovaní. Rozpočet potom musí obsahovať platformu a pozorovateľnosť, k tomu pohotovosť. Rozdelenie kódu nevytvorí ani jedno.

Pri vývoji softvéru na mieru tieto predpoklady zapisujeme do rozhodnutia, ku ktorému sa dá o rok vrátiť a spýtať sa, či platilo to, čo sme vtedy predpokladali. Ak už systém brzdí zmeny, ďalší diel vysvetľuje modernizáciu legacy systému bez veľkého prepisu. Výsledkom má byť nižšia cena bezpečnej zmeny.

Pred oddelením modulu treba pripraviť aj cestu späť. Treba vopred povedať, čo bude meranie úspechu, a potom sledovať frekvenciu zmien, záťaž, chybovosť aj to, koľko koordinácie stojí jedno vydanie v porovnaní s tým, čo stálo predtým. Ak po presune každá úprava stále vyžaduje súčasnú prácu viacerých tímov, hranica bola zvolená zle. Opraviť ju je lacnejšie než brániť názov architektúry.