Mikroslužby alebo modulárny monolit?

Keď navrhujeme nový e-shop, systém na správu objednávok alebo výrobný integračný systém, otázka "mikroslužby alebo modulárny monolit" zriedka zostáva len technologickou diskusiou. Výber ovplyvní rýchlosť vydávania, sledovateľnosť chýb, prevádzkovú záťaž, spoľahlivosť integrácie a to, ako dobre systém zapadá do skutočného fungovania spoločnosti. Zle načasované architektonické rozhodnutie nemusí spôsobiť okamžité problémy, ale môže sa roky premietať do nákladov na vývoj a prevádzku.

Hranice systému sú dôležitejšie ako technologická nálepka

Oba prístupy sú často zjednodušované. Monolity sú popisované ako zastarané, ťažko modifikovateľné systémy, zatiaľ čo mikroslužby sú považované za automaticky škálovateľné, moderné cieľové stavy. To je zavádzajúce. Dobre postavený modulárny monolit môže byť dlhodobo prehľadným, testovateľným a udržateľným obchodným systémom. Podobne, zbytočne roztrieštené prostredie mikroslužieb môže predstavovať trvalé riziká s chybami siete, synchronizáciou dát a mnohými samostatnými nasadzovacími jednotkami.

Skutočná otázka je, kde sa nachádzajú prirodzené hranice obchodných procesov. Napríklad spracovanie objednávok môže zahŕňať rezerváciu zásob, cenotvorbu, prenos fakturačných údajov, logistickú organizáciu a komunikáciu so zákazníkmi. Ak tieto kroky tvoria úzku obchodnú transakciu, skoré oddelenie môže výrazne zvýšiť zložitosť. Avšak ak sa menia rôznou rýchlosťou, spravujú ich rôzne tímy alebo majú odlišné požiadavky na dostupnosť a záťaž, oddelenie môže mať obchodný dôvod.

Architektúra by mala slúžiť preukázateľnej funkčnosti, nie organizačnej móde. Cieľom nie je mať čo najviac komponentov, ale rýchlo zistiť, čo sa stalo, kde sa to stalo a ako možno proces kontrolovane obnoviť v prípade chyby objednávky, oneskorených dodávateľských údajov alebo výpadku ERP spojenia.

Kedy je vhodné začať s modulárnym monolitom?

Modulárny monolit je jedna nasaditeľná aplikácia, kde sú funkcie jasne oddelené do obchodných modulov. Príklady zahŕňajú produktový katalóg, správu objednávok, skladové procesy, integrácie s partnermi alebo správu prístupu. Aplikácia beží ako jednotka, ale moduly majú vlastnú zodpovednosť, pravidlá správy dát a dobre definované vnútorné rozhrania.

Toto je obzvlášť dobrý východiskový bod pre stredne veľké podnikové systémy, kde je potrebné zjednotiť viacero vnútorných a vonkajších procesov, ale vývojová a prevádzková organizácia ešte neodôvodňuje existenciu desiatok nezávislých služieb. Napríklad v prípade platformy na správu objednávok a logistiky je často dôležitejšia konzistencia údajov, sledovateľnosť procesov a rýchla obchodná prispôsobivosť než spúšťanie každej funkcie v samostatnom kontajneri.

Výhodou modulárneho monolitu je, že správa transakcií je jednoduchšia, na odstraňovanie chýb je potrebné prejsť menej systémov a nasadzovací reťazec je ľahšie prehľadný. Interakcie obchodných pravidiel môžu byť spravované v jednej verzovanej verzii. To neznamená, že systém môže byť neusporiadanou masou kódu so spoločnými tabuľkami databázy. Naopak, hranice modulov musia byť od prvého dňa disciplinovane spravované.

Obmedzenia prístupu sa prejavia, keď jedna funkčná oblasť dostáva veľmi odlišné záťaže, vyvíja sa v rôznych životných cykloch alebo koordinácia vydaní sa stáva neúmerne pomalou. V takýchto prípadoch nie je potrebné prepisovať celý systém; skôr je potrebné preskúmať, ktoré moduly sú zrelé na oddelenie.

Kedy sú mikroslužby opodstatnené?

Architektúra mikroslužieb poskytuje skutočné výhody, keď sú nezávislé služby obchodne a prevádzkovo autonómne. Služba má jasnú zodpovednosť, vlastné rozhranie, najlepšie vlastné vlastníctvo správy dát a samostatný nasadzovací proces. Nejde len o to, aby sa existujúce časti aplikácie umiestnili do samostatných procesov alebo kontajnerov.

Môže byť opodstatnené napríklad oddelenie služby s vysokou návštevnosťou produktových a cenových informácií, ak ju rôzne využívajú e-shopy, B2B portály, trhoviská a vnútorné predajné systémy. Podobne, vrstva integrácie dodávateľov komunikujúca s viacerými poskytovateľmi, ktorá vyžaduje vlastné pravidlá opätovného pokusu, logovania a spracovania, môže byť nezávislou oblasťou. V týchto prípadoch môže oddelené škálovanie, nezávislé vydania a cielené riešenie chýb priniesť hmatateľnú obchodnú hodnotu.

Náklady sú však značné. Sieťová komunikácia medzi službami môže zlyhať alebo sa oneskoriť. To, čo bolo predtým jednoduchou databázovou transakciou, sa stáva správou správ, spracovaním udalostí, opakovaným spracovaním a niekedy dočasne odlišnými stavmi dát. Identifikácia služby, regulácia prístupu, centrálne logovanie, zber metrik, upozornenia, správa konfigurácie, zálohovanie a kompatibilita verzií sú úlohy, ktoré je potrebné riešiť. Tieto nie sú doplnkovými úlohami, ale súčasťou architektúry.

Mikroslužby alebo modulárny monolit: aké dôkazy by mali riadiť naše rozhodnutie?

Rozhodnutie by malo byť odvodené z reálnej prevádzky, nie z predpokladanej budúcej veľkosti. Skutočnosť, že spoločnosť chce rásť, sama o sebe neodôvodňuje mikroslužby. Rastu často predchádza potreba čistých kmeňových dát, spoľahlivých integrácií, konzistentných modelov prístupu a merateľných procesov.

Najprv je potrebné určiť, ktoré obchodné oblasti sa často a nezávisle menia. Ak každá zmena v logike skladu vyžaduje úplné vydanie pre zákaznícky portál, fakturáciu a cenotvorbu, hranice sú pravdepodobne príliš úzke. Avšak ak sa funkcie zvyčajne menia ako súčasť obchodného procesu, samostatné nasadenie môže priniesť viac koordinácie než výhod.

Po druhé, je potrebné preskúmať vlastníctvo dát. Mnoho architektúr sa stáva ťažko spravovateľnými, pretože viacero služieb priamo modifikuje rovnaké objednávkové, zákaznícke alebo skladové dáta. V mikroslužbách by mal mať každý kritický dátový objekt jasného vlastníka. Iné systémy môžu žiadať dáta alebo iniciovať procesy prostredníctvom rozhraní alebo udalostí. To vyžaduje väčšiu disciplínu, ale robí zodpovednosť predvídateľnejšou.

Po tretie, je potrebné realisticky zhodnotiť prevádzkovú zrelosť. Existuje jednotné logovanie a monitorovanie? Je možné sledovať obchodnú transakciu cez viacero systémov? Sú tajomstvá a prístupy bezpečne spravované? Sú testovacie a vydávacie procesy automatizované s možnosťami návratu? Ak tieto ešte nie sú zavedené, je vhodné posilniť základy pred zavedením mikroslužieb.

Postupné oddelenie zvyčajne nesie menšie riziko

Architektúra nie je jednorazové, konečné rozhodnutie. Disciplinovaný modulárny monolit je vhodný na neskoršie cielené oddelenie funkcií, kde sa preukážu potreby nezávislosti. V postupnom prístupe sa najprv vytvoria stabilné vnútorné hranice modulov, dokumentované rozhrania a oddelené zodpovednosti. Potom sa konkrétna, vysoko hodnotná oblasť—ako napríklad prenos údajov o partneroch alebo spracovanie oznámení—môže stať nezávislou službou.

Oddelenie by malo byť viazané na merateľné problémy. Môžu to byť trvalo odlišné záťažové profily, časté a nezávislé obchodné zmeny, špeciálne technologické požiadavky alebo izolácia chýb v externej integrácii. "Jedného dňa sa to dobre škáluje" nie je dostatočný dôvod, ak sa medzitým zhoršuje každodenná prevádzková prehľadnosť.

V mnohých prípadoch je najlepším riešením hybridné riešenie. Centrálne obchodné procesy zostávajú v modulárnom monolite, zatiaľ čo asynchrónne, vysoko objemové alebo intenzívne oblasti komunikácie s externými systémami fungujú ako samostatné služby. To je obzvlášť relevantné pre ERP, e-shop, skladové a dodávateľské systémové integrácie, kde spoľahlivosť externých spojení a správa opätovného spracovania vyžadujú nezávislú pozornosť.

Prevádzkovateľnosť ako návrhová požiadavka

Bez ohľadu na zvolený model, prevádzkové požiadavky by mali byť definované vo fáze návrhu. Kritický obchodný systém musí zvládať chybné alebo chýbajúce správy, opakované spracovanie, logovanie prístupu, zálohovanie, monitorovanie kapacity a kontrolované vydania. Tieto nie sú len úlohy infraštruktúry; priamo ovplyvňujú plnenie objednávok, presnosť skladových údajov a presnosť finančných procesov.

V prístupe CGAT začína výber architektúry hodnotením obchodných procesov, identifikáciou integračných hraníc a objasnením prevádzkových požiadaviek. Hodnotu systému neurčuje počet služieb, ale to, ako slúži spoločnosti kontrolovateľným, udržateľným spôsobom, ktorý je v súlade s každodennou prevádzkou, aj uprostred zmien.

Pred ďalším rozhodnutím o vývoji je vhodné sa opýtať, nie ktorá architektúra znie modernejšie, ale ktorá štruktúra robí kritické obchodné procesy zrozumiteľnejšími, modifikovateľnejšími a prevádzkyschopnejšími o rok.