Mikroslužby (microservices) představují specifický způsob vývoje software, který slibuje lepší škálovatelnost, možnost nasazení v různých prostředích a dobře provázané inteligentní endpointy schopné samostatně vyhodnocovat příchozí požadavky a vzájemně komunikovat prostřednictvím jednoduchých mechanismů.

V praxi to znamená především efektivnější vývoj, ale i lepší uživatelskou zkušenost. Dobře postavená architektura mikroslužeb díky segmentaci na jednotlivé části totiž eliminuje počet případů, kdy selhání na straně aplikace ovlivní jejího uživatele a znemožní mu například dokončit objednávku.

Tradiční způsob vývoje a nasazování aplikací představuje monolitická architektura. Funguje jako nedělitelná jednotka spravovaná centrálně a zahrnuje stranu serveru, klienta i databáze. Veškeré změny prováděné v rámci monolitické architektury se propisují plošně do jednoho kódu, který se vlivem rozšiřování aplikace stává komplexním, složitým a může tedy i prodlužovat samotný vývoj.

V řadě případů monolit stále dobře funguje. Na největší problémy ale naráží v cloudu. Kvůli své provázanosti se musí při každé aktualizaci provést přestavba a znovunasazení celé architektury. Zajistit, aby změna ovlivnila vždy jen konkrétní část aplikace není jednoduché, a může proto dojít k narušení modulární struktury. Problematické je i škálování, které nelze přizpůsobit jednotlivým částem aplikace, ale rozšiřuje ji celou nezávisle na množství požadovaných zdrojů.

V čem jsou mikroslužby lepší než monolitická architektura?

Přesně v těchto situacích může architektura postavená na mikroslužbách pomoci. Na rozdíl od monolitu architektura mikroslužeb rozděluje aplikaci do několika logicky souvisejících procesů (služeb či mikroslužeb), které fungují jako nezávislé jednotky, samostatně škálovatelné, nahraditelné a jasně oddělené od ostatních. Každá taková mikroslužba má svou vlastní úlohu.

Aby byly jednotlivé mikroslužby provázány, musí spolu komunikovat, a to buď přímo nebo nepřímo (synchronně/asynchronně). Volání funkcí nebo metod zajišťuje, jak už je zmíněno výše, jeden ze standardních protokolů, a to buď HTTP a API, STOMP (Simple Text Oriented Message Protocol) nebo protokol MQTT (MQ Telemetry Transport). V tomto ohledu vychází architektura mikroslužeb z konceptu léty prověřených unixových systémů.

Monolitická architektura (vlevo) se skládá ze 3 částí – UI (uživatelské rozhraní), „business logic“ někdy také service layer (logika řídící komunikaci mezi uživatelským rozhraním a databází) a „data acces layer“ (umožňuje přístup k datům uloženým v databázi). Architektura mikroslužeb vpravo rozděluje procesy do jednotlivých mikroslužeb, na jejichž úrovni se zpracovávají požadavky a zpravidla každá z nich pracuje i se svou vlastní databází.

Rychlejší vývoj nových verzí a variabilita jazyků

Izolovanost mikroslužeb zajišťuje mimo jiné jedny z nejčastěji zmiňovaných výhod tohoto typu softwarové architektury – vývoj a nasazování nových verzí jednotlivých mikroslužeb nezávislými týmy, které často programují i ve zcela odlišných jazycích.

Výsledkem je minimální ovlivnění vývoje ostatních mikroslužeb a narušení celého systému i rychlejší schvalování změn ze strany managementu. Neplatí to sice paušálně, protože některé změny jsou rozsáhlejší a mohou ovlivnit i jinou mikroslužbu, což vyžaduje spolupráci jiného týmu – například při změnách rozhraní (API). Obecně ale tento design vývoje směřuje k eliminaci těsného propojení mikroslužeb a podporuje rychlejší souběžný vývoj, automatické nasazování a testování.

Nasazení a provoz mikroslužeb jde ruku v ruce s kontejnerizací. Umožňují ji nástroje vytvořené speciálně k těmto účelům. Mezi ty nejznámější patří třeba Docker nebo Kubernetes.

Volba adekvátních nástrojů

Přestože lze mikroslužby orchestrovat z jednoho nástroje, např. Kubernetes, mají decentralizovanou povahu a díky tomu lze pro každou jednu mikroslužbu a procesy, jež zahrnuje, použít odpovídající technologie. V rámci monolitu jsou takové postupy jen těžko realizovatelné, případně omezené.

Mikroslužby otevírají každému týmu širokou škálu technologií a po­stu­pů, které jsou pro danou mikroslužbu ideální a které by v monoliti­cké architektuře byly pevně svázány komplexním designem aplikace.

Častým problémem mezi aplikacemi, ale i v rámci jedné aplikace u monolitu je i různá interpretace atributů, která se liší podle toho, zda se na daný proces nahlíží například po obchodní nebo technické stránce. I tomu lze konkrétní mikroslužbu přizpůsobit. Pro každou mikroslužbu jde navíc vytvořit i vlastní instanci databázové technologie, případně použít úplně jiný databázový systém.

Flexibilita architektury sahá ještě dále a kromě různých variant řeše­ní umožňuje i unifikaci a sdílení knihoven pro ty nejběžnější problémy.

Lepší kontrola nad změnami a více možností využití kódu

U architektury založené na mikroslužbách záleží na tom, jak je navržena. Tedy na způsobu, jakým jsou rozděleny jednotlivé procesy, jestli a jak spolu souvisí, z čehož logicky vyplývá i to, zda případné změny v jednom procesu ovlivní druhý apod.

Pořádek v jednotlivých procesech je klíčový a poskytuje vývojářům dokonalý přehled o tom, které funkcionality mohou, případně musí, být updatovány společně a které naopak daná změna vůbec neovlivní. Riziko, že aktualizace jedné mikroslužby bude mít negativní dopad na funkčnost jiné části aplikace, je na rozdíl od monolitické architektury minimální.

Jako bonus mohou části kódu každé mikroslužby posloužit jako základ pro vývoj nových funkcionalit a usnadnit tak vývojářům práci.

Mikroslužby neodpouští chyby v designu

Skoro by se mohlo zdát, že nic lepšího než mikroslužby neexistuje. Je tedy s podivem, že je pro své aplikace nevyužívá každý. Je to nejspíš i proto, že tradiční monolitická architektura je shovívavější k určitým mezerám v návrhu, zatímco pro dobře fungující mikroslužby je perfektní návrh nezbytný. To samozřejmě vyžaduje i vyšší investice. Jaké další nevýhody pramení z architektury mikroslužeb?

• Mikroslužby vyžadují širší záběr znalostí, užší specializaci a více kapacit.
• Pro komunikaci mezi mikroslužbami je nezbytný mechanismus vzdáleného volání, který se neobejde bez API s hrubší granularitou.
• Hrubší granularita API zesložiťuje případné přerozdělování odpovědností za procesy mezi mikroslužbami.
• Vysoká závislost na síti může být v reálném provozu problematická a způsobovat selhání aplikace.
• Architekturu je potřeba dobře navrhnout, aby při vícenásob­ném volání nedošlo k ovlivnění uživatelské zkušenosti aplikace.
• Architektura mikroslužeb vyžaduje pravidelné automatizované testování reálného provozu se zaměřením na hromadná volání, která by mohla ovlivnit stabilitu aplikace.
• Nezbytný je pokročilý monitoring, který upozorní na problémy s latencí nebo propustností sítě v reálném čase.
• Problematické bývá sdílení knihoven a databází mezi mikroslužbami v případě, že je mezi sebou příliš úzce prováže a naruší tak jejich nezávislost.
• Chyby se mohou objevovat i jinde, než kde reálně vznikají. Mikroslužby vyžadují komplexní přístup ke sběru logů a trasování aplikace.

Kdo ocení aplikační architekturu založenou na mikroslužbách?

Jako každé řešení mají i mikroslužby svá pro a proti. Je tedy jasné, že nejsou vhodné pro každého. Ve firmách s menšími týmy vývojářů by komplexnost architektury působila příliš velkou zátěž a nasazování nových verzí spíše zpomalila.

Naopak aplikacím, které plánují časté updaty, implementaci nových funkcí a vlastností a které mají ambici většího růstu, se vyplatí do architektury mikroslužeb investovat. Mikroslužby navíc usnadňují škálování. V takovém případě je zásadní mít k dispozici několik vývojářských týmů, které se mohou soustředit na vývoj jednotlivých mikroslužeb.

5 tipů, jak začít s mikroslužbami

Správné rozdělení procesů

Zvláště u aplikací, které se překlápí z monolitické architektury do mikroslužeb, je klíčové koncept návrhu kompletně přepracovat. Mikroslužby vyžadují naprosto odlišné uvažování nad strukturou. Neexistuje v nich žádná centrální správa ani logika, pouze jednotlivé procesy. Pokud mají mikroslužby fungovat dobře, musí mít mezi sebou jasně nastevené rozhraní (API), které stanovuje vzorce chování pro každou z nich. Následná implementace pak musí toto rozhraní respektovat.

Dobrá organizace vývojových týmů

Výhoda nezávislého vývoje jednotlivých částí aplikace se z pohledu managementu stává oříškem. K vývoji každé mikroslužby se v ideálním případě přistupuje jako k samostatnému produktu. Každý tým musí mít veškeré kompetence, aby mohl nejen připravovat nové verze, ale rovnou je i implementovat bez ohledu na to, v jaké fázi vývoje jsou zrovna ostatní. Vývojáři pak lépe pochopí dopad změn na produkční prostředí a sníží i pravděpodobnost, že se případné problémy dostanou k uživateli aplikace.

Udržení snadné komunikace mezi mikroslužbami

Vzdálená volání mohou některé procesy prodloužit. Komunikace mezi mikroslužbami musí proto vždy zůstat co nejjednodušší, aby byl potenciál architektury mikroslužeb naplněn. Základním konceptem této architektury je co nejmenší provázanost mikroslužeb. Při komunikaci jde o prostý přenos informace, nikoli o jeho zpracování. To se děje až v koncových bodech, tedy jednotlivých mikroslužbách.

Komplexní pohled na systém

Navzdory veškeré nezávislosti tvoří mikroslužby stále jednu aplikaci. Pohled na celý balík procesů, na to, jak jsou provázány a co selhání jednoho z nich znamená pro druhý, jsou aspekty, s nimiž se musí počítat, aby se už v rámci návrhu omezil počet možných selhání, či zpomalení vlivem horší propustnosti sítě na minimum.

Nepřetržitý monitoring

Prioritou každé aplikace je zajistit, aby ani menší problém neovlivnil zákazníka. Testování různých případů selhání je u mikroslužeb ná­klad­né a často ani není reálné všem rizikům předejít. Klíčový je proto monitoring, který včas upozorní na problémy a poskytne dostatečný prostor na ně reagovat. Ať už jde o výpadky některých částí služeb nebo jejich neočekávané chování. Správně postavené mikroslužby by totiž uživatelé měli být schopni bez omezení plně využívat ve chvíli, kdy vývojáři pracují na obnově některého z procesů.

Pokud se chystáte pustit do vývoje sami a s koncepcí architektury zatím nemáte moc zkušeností, bude lepší začít s monolitickou architekturou a všechny procesy si nejdřív osahat. V současné době se už nových aplikací vyplatí začít rovnou s mikroslužbami, což ušetří případné náklady na budoucí migraci.

V případě, že už monolit máte a zvažujete přechod do mikroslužeb a kontejnerizaci aplikace, nepodceňte přípravu pro přesun na nový typ architektury. Bez ní může být investice do nového konceptu zcela zbytečná.

Veronika Jakubová Autorka článku je PR specialistka společnosti MasterDC.