V praxi to znamená především efektivnější vývoj, ale i lepší uživatelskou zkušenost.
Monolitická architektura funguje jako nedělitelná jednotka spravovaná centrálně a zahrnuje stranu serveru, klienta i databáze.
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.
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.
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).
Monolitická architektura (vlevo) se skládá ze 3 částí - UI (uživatelské rozhraní), „business logic“ někdy také service layer (logika řídicí 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).
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 několika týmů - například při změnách rozhraní (API).
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.
Blíže jsme o nich psali v článku Docker, Kubernetes a kontejnery.
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.
Č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.
U architektury založené na mikroslužbách záleží na tom, jak je navržena.
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í.
Skorobylo by se 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.
Chyby se mohou objevovat i jinde, než kde reálně vznikají.
Jako každé řešení mají i mikroslužby svá pro a proti.
Je tedy jasné, že nejsou vhodné pro každého.
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í.
1. 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ě nastavené rozhraní (API), které stanovuje vzorce chování pro každou z nich.
2. 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í.
3. 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í.
4. Navzdory veškeré nezávislosti tvoří mikroslužby stále jednu aplikaci.
5. 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ákladné 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í.
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 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á.
