Mikroslužby a rizika s nimi spojená

Mikroslužby (microservices) jsou většinou menší, zpravidla jednoúčelové aplikace komunikující spolu prostřednictvím výměny zpráv.

Vycházejí z filozofie Linuxu, a to dělat jen jednu věc, ale zato pořádně. Snáze se vyvíjí, testují, spravují a mění.

Je však otázka, jak velká by ona mikroslužba měla vlastně být, rozuměj, co všechno by měla dělat. Někdy se mluví i o tom, jak velký by měl být SecDevOps tým, který bude onu mikroslužbu vyvíjet, protože náklady generuje i samotný tým. A s větším počtem mikroslužeb a větším počtem těchto týmů by se pak snadno mohlo stát, že se očekáváné úspory se vzhledem k vysokým režijním nákladům vůbec nedostaví.

Jestli nemáte jasně definovaná pravidla, na základě čeho se budou mikroservisy a o jaké velikosti vytvářet, tak máte problém, který představuje riziko, které budete muset nějakým způsobem zvládat.

Zapomenout také nesmíme na to, že v okamžiku, kdy vznikne více týmů, např. v rámci agilního vývoje, tak každý tým bude prosazovat svoje technologie, frameworky, nástroje apod. což povede k vysoké heterogenitě celé organizace a možnému růstu nákladů. Někdo bude muset ty autonomní týmy uřídit a definovat a zavést odpovídající standardy, aby byla možná tzv. continous Integration a delivery. Jestli toto nemáte vyřešeno, opět se jedná o riziko.

V souvislosti s mikroslužbami je třeba upozornit na skutečnost, že rostoucí komplexita takto vytvářených systémů představuje i určité riziko. (Komplexita systému vychází z počtu jednotlivých mikroslužeb, ze kterých je daný systém složen a z počtu komunikačních toků, které tyto mikroslužby mezi sebou navazují.)

S počtem těchto mikroslužeb dále roste riziko selhání a klesá celková dostupnost. (Dostupnost systému se počítá jako součin dostupnosti jednotlivých mikroslužeb.) Je otázka, jak řešit dostupnost. Budou všechny služby zdvojeny nebo poběží v clusteru, budou to řešit sami anebo budou spoléhat na OS? Něco lze jistě vyřešit za použití vritualizace a kontejnerizace, ale ta samo o sobě přináší další rizika. (Ostatně na tahle rizika jsme upozorňovali již před více jak deseti lety, vizte odkazované články.)

Vzhledem k použitému protokolu (často se jedná o ne zrovna úsporný HTTP) vzrůstá počet volání, a tím i meziserverová komunikace a roste i objem přenášených dat, což ve výsledku může vést ke zvýšeným nárokům na systémové zdroje nutné k odbavení těchto zpravidla asynchronních volání, jejichž režie rovněž spotřebovává cenné systémové prostředky, vizte chatty a chunky rozhraní. Kvalita sítě bude v tomto směru klíčová a může si vyžádat další investice.

Vývoj a unitní testování bude sice mnohem jednodušší, ale integrace a integrační testování zase mnohem složitější. Mnohem náročnější také bude zajistit konzistenci a integritu dat. Logicky, když budeme mít více těch mikroslužeb. Toto riziko lze ošetřit zavedením automatizovaných nástrojů na provádění testů apod. Ale i zde stále narážíme na problémy, např. s takovým load testem, který málokdo umí udělat správně.

A jestliže vaše IT mělo doposud problém s dokumentací monolitických systémů (monolith nebo také macroservice) budovaných jako klasická vícevrstvá HW a SW architektura a popsání datových toků, je otázka, zda se tento problém ještě neprohloubí.

Nehledě na to přílišná specializace povede i ke ztrátě představy, jak celý systém vlastně funguje. Každý bude znát jen tu svoji část. Veškeré datové toky a formáty přenášených zpráv budou muset být popsány, protože dokumentace všeho bude důležitější více než kdy dříve.

Z výše uvedeného logicky vyplývá, že provozování silně orientovaného mikroservis systému bude klást větší nároky na zdroje, dokumentaci, logování, monitoring, řízení změn, a tedy i vyzrálost odpovídajících procesů, a nástrojů umožňujících tuto automatizaci, a je otázka, zda se díky lepší možnosti škálování podaří skutečně dosáhnout očekávaných úspor.

Rovněž je otázka, zda by každá organizace měla provádět dekompozici svých monolitických systémů a snažit se je převádět na mikroslužby.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.