Už dlouho jsem chtěl napsat článek na téma mikroservisní architektura, ale stále mě brzdily dvě věci - čím víc jsem se do tématu nořil, tím víc se mi zdálo, že to, co vím, je samozřejmé a co neumím. to vědět je třeba studovat a studovat. Na druhou stranu si myslím, že už teď je o čem diskutovat mezi širokým publikem. Alternativní názory jsou tedy vítány.
Conwayův zákon a vztah mezi obchodem, organizací a informačním systémem
Ještě jednou si dovolím citovat:
"Každá organizace, která navrhuje systém (v širším smyslu), obdrží návrh, jehož struktura kopíruje strukturu týmů v této organizaci."
— Melvyn Conway, 1967
Podle mého názoru se tento zákon týká spíše proveditelnosti organizace podnikání než přímo informačního systému. Dovolte mi to vysvětlit na příkladu. Řekněme, že máme poměrně stabilní obchodní příležitost s tak dlouhým životním cyklem, že má smysl organizovat podnik (nejedná se o překlep, ale tento termín, který jsem si ukradl, se mi velmi líbí). bude organizačně a procesně odpovídat tomuto obchodu .
Obchodní orientace informačních systémů
Dovolte mi to vysvětlit na příkladu. Řekněme, že existuje obchodní příležitost zorganizovat firmu prodávající pizzu. Ve verzi V1 (říkejme tomu předinformace) byla firma pizzerie, pokladna, rozvoz. Tato verze měla dlouhou životnost v podmínkách nízké variability prostředí. Pak jej nahradila verze 2 – pokročilejší a schopná využívat ve svém jádru informační systém pro podnikání s monolitickou architekturou. A tady je podle mého názoru ve vztahu k monolitům prostě hrozná nespravedlnost - údajně monolitická architektura neodpovídá doménovému obchodnímu modelu. Ano, pokud by tomu tak bylo, systém by vůbec nemohl fungovat – v rozporu se stejným Conwayovým zákonem a zdravým rozumem. Ne, monolitická architektura je v této fázi rozvoje podnikání plně v souladu s obchodním modelem – mám samozřejmě na mysli fázi, kdy je systém již vytvořen a uveden do provozu. Je naprosto úžasný fakt, že bez ohledu na architektonický přístup budou stejně dobře fungovat jak architektura orientovaná na služby verze 3, tak architektura mikroslužeb verze N. V čem je háček?
Všechno plyne, všechno se mění, nebo jsou mikroslužby prostředkem pro boj se složitostí?
Než budeme pokračovat, podívejme se na některé mylné představy o architektuře mikroslužeb.
Zastánci používání přístupu mikroslužeb často tvrdí, že rozdělení monolitu na mikroslužby zjednodušuje vývojový přístup tím, že snižuje kódovou základnu jednotlivých služeb. Podle mého názoru je toto tvrzení úplný nesmysl. Vážně, zdá se zřejmá interakce v rámci monolitu a homogenního kódu komplikovaná? Pokud by tomu tak skutečně bylo, byly by všechny projekty zpočátku stavěny jako mikroslužby, přičemž praxe ukazuje, že migrace z monolitu na mikroslužby je mnohem častější. Složitost nezmizí, pouze se přesune od jednotlivých modulů k rozhraním (ať už jde o datové sběrnice, RPC, API a další protokoly) a orchestrační systémy. A to je těžké!
Otázna je také výhoda použití heterogenního zásobníku. Nebudu tvrdit, že je to také možné, ale ve skutečnosti k tomu dochází jen zřídka (Pohled dopředu - to by se mělo stát - ale spíše jako důsledek než výhoda).
Životní cyklus produktu a cyklus životnosti
Podívejte se ještě jednou na výše uvedený diagram. Nikoli náhodou jsem zaznamenal klesající životní cyklus samostatné verze podniku – v moderních podmínkách je pro úspěch rozhodující právě zrychlení přechodu podniku mezi verzemi. Úspěch produktu je dán rychlostí testování obchodních hypotéz v něm. A zde se podle mého názoru skrývá klíčová výhoda architektury mikroslužeb. Ale pojďme popořadě.
Přejděme k další fázi vývoje informačních systémů – k architektuře SOA orientované na služby. Takže v určitém okamžiku jsme v našem produktu zdůraznili služby s dlouhou životností - dlouhověká v tom smyslu, že při přechodu mezi verzemi produktu existuje šance, že životní cyklus služby bude delší než životní cyklus další verze produktu. Bylo by logické je vůbec neměnit – my Důležitá je rychlost přechodu na další verzi. Ale bohužel jsme nuceni neustále měnit služby – a tady nám vše funguje, postupy DevOps, kontejnerizace a tak dále – vše, co nás napadne. Pořád to ale nejsou mikroslužby!
Mikroslužby jako prostředek pro boj se složitostí... správa konfigurace
A zde můžeme konečně přejít k definující roli mikroslužeb – to je přístup, který zjednodušuje správu konfigurace produktu. Podrobněji funkce každé mikroslužby přesně popisuje obchodní funkci uvnitř produktu podle doménového modelu – a to jsou věci, které žijí nikoli v krátkodobé verzi, ale v dlouhodobé obchodní příležitosti. A přechod na další verzi produktu se děje doslova nepozorovaně – změníte/přidáte jednu mikroslužbu a třeba jen schéma jejich interakce a najednou se ocitnete v budoucnosti a zanecháte za sebou plačící konkurenty, kteří dál přeskakují mezi verzemi jejich monolity. Nyní si představte, že existuje poměrně velký objem mikroslužeb s předdefinovanými rozhraními a obchodními schopnostmi. A vy přijdete a postavíte strukturu svého produktu z hotových mikroslužeb – jednoduše například nakreslením diagramu. Gratulujeme - máte platformu - a nyní můžete přilákat podnikání pro sebe. Sny Sny.
Závěry
- Architektura systému by měla být určena životním cyklem jeho součástí. Pokud komponenta žije ve verzi produktu, nemá smysl zvyšovat složitost systému pomocí přístupu mikroslužeb.
- Architektura mikroslužeb by měla být založena na doménovém modelu – protože obchodní příležitost je doménou s nejdelší životností
- Doručovací praktiky (DevOps practices) a orchestrace jsou jedny z nejdůležitějších pro architekturu mikroslužeb – z toho důvodu, že nárůst rychlosti změn komponent klade zvýšené nároky na rychlost a kvalitu dodání.
Zdroj: www.habr.com