Mikroslužby nebo modulární monolit?

Při navrhování nového e-shopu, systému pro správu objednávek nebo výrobní integrační platformy není otázka "mikroslužby nebo modulární monolit" jen technologickou debatou. Volba ovlivní rychlost vydání, sledovatelnost chyb, provozní zátěž, spolehlivost integrace a to, jak dobře systém zapadá do skutečného fungování společnosti. Špatně načasované rozhodnutí o architektuře nemusí způsobit okamžité problémy, ale může se roky promítat do nákladů na vývoj a provoz.

Hranice systému jsou důležitější než technologická nálepka

Obě přístupy jsou často zjednodušovány. Monolity jsou popisovány jako zastaralé, obtížně modifikovatelné systémy, zatímco mikroslužby jsou považovány za automaticky škálovatelné, moderní cílové stavy. To je zavádějící. Dobře navržený modulární monolit může být dlouhodobě přehledným, testovatelným a udržitelným obchodním systémem. Podobně zbytečně roztříštěné prostředí mikroslužeb může představovat trvalá rizika sítěmi chyb, synchronizací dat a mnoha samostatnými nasazovacími jednotkami.

Skutečná otázka je, kde leží přirozené hranice obchodních procesů. Například zpracování objednávek může zahrnovat rezervaci zásob, stanovení cen, přenos fakturačních dat, logistickou organizaci a komunikaci se zákazníky. Pokud tyto kroky tvoří úzkou obchodní transakci, může předčasné oddělení výrazně zvýšit složitost. Pokud se však mění různou rychlostí, spravují je různé týmy nebo mají odlišné požadavky na dostupnost a zátěž, může mít oddělení obchodní důvod.

Architektura by měla sloužit prokazatelnou funkčností, nikoli organizačním módním trendům. Cílem není mít co nejvíce komponent, ale rychle zjistit, co se stalo, kde se to stalo a jak lze proces kontrolovaným způsobem obnovit v případě chyby objednávky, pozdních dodavatelských dat nebo výpadku připojení ERP.

Kdy je vhodné začít s modulárním monolitem?

Modulární monolit je jedna nasaditelná aplikace, kde jsou funkce jasně odděleny do obchodních modulů. Příklady zahrnují katalog produktů, správu objednávek, skladové procesy, integrace s partnery nebo správu přístupu. Aplikace běží jako celek, ale moduly mají vlastní odpovědnost, pravidla pro správu dat a dobře definovaná vnitřní rozhraní.

To je obzvláště dobrý výchozí bod pro středně velké podnikové systémy, kde je třeba sjednotit více interních a externích procesů, ale vývojová a provozní organizace ještě neospravedlňuje existenci desítek nezávislých služeb. Například u platformy pro správu objednávek a logistiky je konzistence dat, sledovatelnost procesů a rychlá obchodní přizpůsobivost často důležitější než provozování každé funkce v samostatném kontejneru.

Výhodou modulárního monolitu je, že transakční zpracování je jednodušší, prochází méně systémů pro ladění chyb a nasazovací řetězec je snadněji přehledný. Interakce obchodních pravidel mohou být spravovány v jedné verzované verzi. To neznamená, že systém může být neuspořádanou hromadou kódu se společnými databázovými tabulkami. Naopak, hranice modulů musí být od prvního dne disciplinovaně spravovány.

Omezení přístupu se projeví, když funkční oblast dostává velmi odlišné zátěže, vyvíjí se v různých životních cyklech nebo koordinace vydání se stává neúměrně pomalou. V takových případech není třeba přepisovat celý systém; spíše je třeba zjistit, které moduly jsou zralé na oddělení.

Kdy jsou mikroslužby oprávněné?

Architektura mikroslužeb přináší skutečné výhody, když jsou nezávislé služby obchodně a provozně autonomní. Služba má jasnou odpovědnost, vlastní rozhraní, pokud možno vlastní správu dat a samostatný proces nasazení. Nejde jen o to, že části stávající aplikace jsou umístěny do samostatných procesů nebo kontejnerů.

Může být oprávněné oddělit například službu s vysokým provozem produktových a cenových informací, pokud ji různými způsoby používají e-shopy, B2B portály, trhy a interní prodejní systémy. Podobně vrstva integrace dodavatelů komunikující s více poskytovateli, která vyžaduje vlastní pravidla pro opakování, protokolování a zpracování, může být nezávislou oblastí. V těchto případech může oddělené škálování, nezávislé vydání a cílené řešení chyb přinést hmatatelnou obchodní hodnotu.

Nicméně náklady jsou značné. Síťová komunikace mezi službami může selhat nebo se zpozdit. Co bylo dříve jednoduchou databázovou transakcí, se stává zpracováním zpráv, událostí, opakovaným zpracováním a někdy dočasně odlišnými stavy dat. Identifikace služby, řízení přístupu, centrální protokolování, sběr metrik, upozornění, správa konfigurace, zálohování a kompatibilita verzí jsou úkoly, které je třeba řešit. Nejsou to doplňkové úkoly, ale součást architektury.

Mikroslužby nebo modulární monolit: jaké důkazy by měly řídit naše rozhodnutí?

Rozhodnutí by mělo vycházet ze skutečného provozu, nikoli z předpokládané budoucí velikosti. Skutečnost, že společnost chce růst, sama o sobě neospravedlňuje mikroslužby. Růst často nejprve vyžaduje čistá kmenová data, spolehlivé integrace, konzistentní přístupové modely a měřitelné procesy.

Nejprve je třeba určit, které obchodní oblasti se často a nezávisle mění. Pokud každá změna v logice skladu vyžaduje úplné vydání pro zákaznický portál, fakturaci a stanovení cen, hranice jsou pravděpodobně příliš těsné. Pokud se však funkce obvykle mění jako součást obchodního procesu, může samostatné nasazení přinést více koordinace než výhod.

Za druhé, je třeba zkoumat vlastnictví dat. Mnoho architektur se stává obtížně spravovatelnými, protože více služeb přímo mění stejná data objednávek, zákazníků nebo zásob. V mikroslužbách musí mít každý kritický datový objekt jasného vlastníka. Ostatní systémy mohou žádat o data nebo iniciovat procesy prostřednictvím rozhraní nebo událostí. To vyžaduje větší disciplínu, ale činí odpovědnost předvídatelnější.

Za třetí, provozní zralost je třeba realisticky zhodnotit. Existuje jednotné protokolování a monitorování? Lze sledovat obchodní transakci napříč více systémy? Jsou tajemství a přístupy bezpečně spravovány? Jsou testovací a vydávací procesy automatizovány s možnostmi vrácení? Pokud tyto ještě nejsou zavedeny, je vhodné posílit základy před zavedením mikroslužeb.

Postupné oddělení obvykle nese menší riziko

Architektura není jednorázové, konečné rozhodnutí. Disciplinovaný modulární monolit je vhodný pro pozdější cílené oddělení funkcí, kde se prokážou potřeby nezávislosti. V postupném přístupu se nejprve vytvářejí stabilní vnitřní hranice modulů, dokumentovaná rozhraní a oddělené odpovědnosti. Poté se konkrétní, vysoce hodnotná oblast—jako je přenos dat partnerů nebo zpracování oznámení—může stát nezávislou službou.

Oddělení by mělo být spojeno s měřitelnými problémy. Mohou to být trvale odlišné zátěžové profily, časté a nezávislé obchodní změny, specifické technologické požadavky nebo izolace chyb v externí integraci. "Jednou to bude dobře škálovat" není dostatečný důvod, pokud se mezitím zhoršuje denní provozní přehlednost.

V mnoha případech je nejlepší hybridní řešení. Centrální obchodní procesy zůstávají v modulárním monolitu, zatímco asynchronní, objemné nebo intenzivní oblasti komunikace s externími systémy fungují jako samostatné služby. To je obzvláště relevantní pro ERP, e-shop, skladové a dodavatelské systémové integrace, kde spolehlivost externích spojení a řízení opakovaného zpracování vyžadují nezávislou pozornost.

Provozuschopnost jako požadavek na návrh

Bez ohledu na zvolený model by měly být provozní požadavky stanoveny ve fázi návrhu. Obchodně kritický systém musí zvládat chybné nebo chybějící zprávy, opakované zpracování, protokolování přístupu, zálohování, monitorování kapacity a kontrolovaná vydání. Nejsou to jen úkoly infrastruktury; přímo ovlivňují plnění objednávek, přesnost dat o zásobách a přesnost finančních procesů.

V přístupu CGAT začíná výběr architektury hodnocením obchodních procesů, identifikací integračních hranic a vyjasněním provozních požadavků. Hodnota systému není určena tím, kolik služeb obsahuje, ale tím, jak slouží společnosti kontrolovatelným, udržitelným způsobem, který je v souladu s každodenním provozem, i uprostřed změn.

Před dalším rozhodnutím o vývoji je vhodné se ptát ne na to, která architektura zní moderněji, ale která struktura činí kritické obchodní procesy srozumitelnějšími, modifikovatelnějšími a provozuschopnějšími za rok.