O mikroservisní architektuře jsem chtěl psát dlouho, ale stále mě brzdily dva momenty – čím hlouběji jsem se do tématu ponořoval, tím více mi přišlo, že to, co už vím, je zřejmé, a to, co nevím, si ještě vyžaduje další studium. Na druhou stranu si myslím, že už je o čem diskutovat i pro širší publikum. Takže alternativní názory jsou vítány.
Conwayův zákon a vztah mezi podnikáním, organizací a informačním systémem
Opět si dovolím citovat:
„Každá organizace, která navrhuje nějaký systém (v širokém smyslu), získá design, jehož struktura kopíruje strukturu týmů v této organizaci.“
— Melvyn Conway, 1967
Z mého pohledu tento zákon spíše souvisí s efektivitou organizace podnikání než přímo s informačním systémem. Vysvětlím na příkladu. Představme si, že máme dostatečně stabilní obchodní příležitost s životním cyklem tak dlouhým, že má smysl organizovat podnik (to není překlep, ale velmi se mi líbí tento termín, který jsem zmínil). Samozřejmě, že podpůrný systém tohoto podnikání bude organizačně a procesně odpovídat tomuto podnikání.
Podnikově orientované informační systémy
Vysvětlím na příkladu. Představme si obchodní příležitost na organizaci podnikání v prodeji pizzy. V první verzi (nazvěme ji předinformační) byla společnost pizzerií, pokladnou a rozvozovou službou. Tato verze byla dlouhověká za podmínek nízké změny okolního světa. Poté se objevila verze 2 — pokročilejší a schopná využívat informační systém jako základ pro podnikání s monolitickou architekturou. A právě zde, z mého pohledu, vzniká skutečně strašlivá nespravedlnost vůči monolitům — jakoby monolitická architektura neodpovídala doménovému modelu podnikání.Kdyby to tak bylo, systém by vůbec nemohl fungovat - v rozporu se stejným Conwayovým zákonem a zdravým rozumem. Ne, monolitní architektura zcela odpovídá obchodnímu modelu v této fázi vývoje podnikání — samozřejmě mám na mysli fázi, kdy je systém již vytvořen a uveden do provozu. Naprosto fascinující je, že bez ohledu na architektonický přístup, jak verze 3 se službami orientované architektury, tak mikroservisní architektura verze N, bude fungovat stejně dobře. Kde je ten háček?
Všechno teče, všechno se mění, nebo jsou mikroservisy nástrojem pro boj se složitostí?
Než budeme pokračovat, podívejme se na některé mylné představy o mikroservisní architektuře.
Zastánci mikroservisního přístupu často říkají, že rozbití monolitu na mikroservisy usnadňuje přístup k vývoji díky snížení kódové základny jednotlivých služeb. Podle mého názoru je toto tvrzení naprostý nesmysl. Opravdu, je zjevná spolupráce v rámci monolitu a homogenního kódu složitá? Kdyby to skutečně tak bylo, všechny projekty by byly od začátku konstruovány jako mikroservisy, zatímco praxe ukazuje, že migrace z monolitu na mikroservisy je mnohem běžnější. Složitost nikam nezmizí, pouze se přesune z jednotlivých modulů na rozhraní (ať už jsou to datové sběrnice, RPC, API a jiné protokoly) a orchestrující systémy. A to je složité!
Výhoda používání heterogenního stacku je také sporná. Nebudu polemizovat, že to je možné, ale v realitě se to zřídka vyskytuje (Pokud to chci předpovědět — mělo by to existovat, ale spíše jako důsledek než jako výhoda).
Životní cyklus produktu a životní cyklus služby
Podívejte se znovu na výše uvedený diagram. Ne náhodou jsem zdůraznil zkracující se životní cyklus jednotlivé verze podnikání — v současných podmínkách je právě zrychlení přechodu podnikání mezi verzemi rozhodující pro jeho úspěch. Úspěšnost produktu je určena rychlostí ověřování obchodních hypotéz v něm. A tady podle mého názoru spočívá klíčová výhoda mikroservisní architektury. Ale postupujme krok za krokem.
Přejdeme na další úroveň evoluce informačních systémů — na architekturu orientovanou na služby SOA. Takže, v nějakém okamžiku jsme ve svém produktu vyčlenili dlouhodobé služby — dlouhodobé v tom smyslu, že při přechodu mezi verzemi produktu existuje pravděpodobnost, že životní cyklus služby bude delší než životní cyklus nové verze produktu. Bylo by logické je vůbec neměnit — nám záleží na rychlosti přechodu k další verzi. Ale bohužel jsme nuceni neustále měnit služby — a zde máme vše, co lze využít, jak praktiky DevOps, tak kontejnerizaci a další — cokoli, co vás napadne. Ale to stále nejsou mikroservisy!
Mikroservisy jako prostředek boje se složitostí... správa konfigurace
A teď se konečně můžeme dostat k určující roli mikroservisů — jde o přístup, který zjednodušuje správu konfigurace produktu. Jinými slovy, funkce každého mikroservisu popisuje konkrétní obchodní funkci uvnitř produktu podle doménového modelu — a to jsou již věci, které neexistují v krátkodobé verzi, ale v dlouhodobé obchodní příležitosti. A přechod k další verzi produktu probíhá doslova nepozorovaně — měníte/přidáváte jeden mikroservis, popřípadě pouze schéma jejich interakce a najednou se ocitáte v budoucnosti, zatímco vaši plačící konkurenti stále skáčou mezi verzemi svých monolitů. Nyní si představte, že existuje dostatečně velký objem mikroservisů s předem definovanými rozhraními a obchodními příležitostmi. A vy přicházíte a stavíte strukturu vašeho produktu z hotových mikroservisů — prostě nakreslíte diagram například. Gratuluji — máte platformu — a nyní si můžete vytvořit podnikání, co potřebujete. Sny, sny.
Závěry
- Architektura systému by měla být určena životním cyklem jeho složek. Pokud komponenta žije v rámci verze produktu — nemá smysl zvyšovat složitost systému použitím mikroservisního přístupu.
- Mikroservisní architektura by měla vycházet z doménového modelu — z důvodu, že obchodní příležitost je nejvíce dlouhodobou oblastí.
- Doručovací praktiky (DevOps praktiky) a orchestraci mají pro mikroslužbovou architekturu jedno z nejdůležitějších významů — a to z důvodu, že zvýšení rychlosti změny komponentů klade vyšší nároky na rychlost a kvalitu dodávky.
Zdroj: habr.com
