Článok na tému architektúry mikroservisov som chcel napísať už dlho, no dve veci ma brzdili – čím ďalej som sa do témy ponáral, tým viac sa mi zdalo, že to, čo viem, je samozrejmé, a čo neviem. neviem, treba študovať a študovať. Na druhej strane si myslím, že už teraz je o čom diskutovať medzi širokým publikom. Takže alternatívne názory sú vítané.
Conwayov zákon a vzťah medzi podnikom, organizáciou a informačným systémom
Ešte raz si dovolím citovať:
„Každá organizácia, ktorá navrhuje systém (v širšom zmysle), dostane návrh, ktorého štruktúra kopíruje štruktúru tímov v danej organizácii.
— Melvyn Conway, 1967
Podľa môjho názoru sa tento zákon týka skôr realizovateľnosti organizácie podnikania ako priamo informačného systému. Vysvetlím to na príklade. Povedzme, že máme pomerne stabilnú obchodnú príležitosť so životným cyklom takej dĺžky, že má zmysel organizovať podnik (toto nie je preklep, ale veľmi sa mi páči tento termín, ktorý som si ukradol). Samozrejme, podporný systém tohto podnikania bude organizačne a procesne zodpovedať tomuto obchodu .
Obchodná orientácia informačných systémov
Vysvetlím to na príklade. Povedzme, že existuje obchodná príležitosť zorganizovať firmu na predaj pizze. Vo verzii V1 (nazvime to predinformácia) bola podnikom pizzéria, pokladňa, donášková služba. Táto verzia mala dlhú životnosť v podmienkach nízkej variability prostredia. Potom ho nahradila verzia 2 – pokročilejšia a schopná využiť vo svojom jadre informačný systém na podnikanie s monolitickou architektúrou. A tu je podľa môjho názoru jednoducho hrozná nespravodlivosť vo vzťahu k monolitom - údajne monolitická architektúra nezodpovedá doménovému obchodnému modelu. Áno, ak by to tak bolo, systém by vôbec nemohol fungovať – v rozpore s rovnakým Conwayovým zákonom a zdravým rozumom. Nie, monolitická architektúra je plne v súlade s obchodným modelom v tejto fáze rozvoja podnikania – myslím tým, samozrejme, štádium, keď je systém už vytvorený a uvedený do prevádzky. Je úplne úžasný fakt, že bez ohľadu na architektonický prístup bude rovnako dobre fungovať architektúra orientovaná na služby verzia 3 aj architektúra mikroslužieb verzia N. v čom je háčik?
Všetko plynie, všetko sa mení, alebo sú mikroslužby prostriedkom na boj so zložitosťou?
Než budeme pokračovať, pozrime sa na niektoré mylné predstavy o architektúre mikroslužieb.
Zástancovia používania mikroservisného prístupu často argumentujú, že rozdelenie monolitu na mikroslužby zjednodušuje vývojový prístup znížením kódovej základne jednotlivých služieb. Toto tvrdenie je podľa mňa úplný nezmysel. Vážne, zdá sa očividná interakcia v rámci monolitu a homogénneho kódu komplikovaná? Ak by to tak naozaj bolo, všetky projekty by boli spočiatku postavené ako mikroslužby, pričom prax ukazuje, že migrácia z monolitu na mikroslužby je oveľa bežnejšia. Zložitosť nezmizne, jednoducho sa presunie od jednotlivých modulov k rozhraniam (či už ide o dátové zbernice, RPC, API a iné protokoly) a organizačné systémy. A toto je ťažké!
Otázna je aj výhoda použitia heterogénneho zásobníka. Nebudem tvrdiť, že aj to je možné, ale v skutočnosti sa to stáva málokedy (Pohľad dopredu - to by sa malo stať - ale skôr ako dôsledok ako výhoda).
Životný cyklus produktu a životný cyklus služby
Pozrite sa ešte raz na vyššie uvedený diagram. Nie náhodou som zaznamenal klesajúci životný cyklus samostatnej verzie podniku – v moderných podmienkach je pre úspech rozhodujúce práve zrýchlenie prechodu podniku medzi verziami. O úspechu produktu rozhoduje rýchlosť testovania obchodných hypotéz v ňom. A tu sa podľa mňa skrýva kľúčová výhoda architektúry mikroslužieb. Ale poďme pekne po poriadku.
Prejdime k ďalšej fáze evolúcie informačných systémov – k architektúre SOA orientovanej na služby. Takže v určitom bode sme v našom produkte zdôraznili služby s dlhou životnosťou - dlhodobá v tom zmysle, že pri prechode medzi verziami produktu existuje šanca, že životný cyklus služby bude dlhší ako životný cyklus ďalšej verzie produktu. Bolo by logické ich vôbec nemeniť – my Dôležitá je rýchlosť prechodu na ďalšiu verziu. Ale bohužiaľ, sme nútení neustále meniť služby – a tu nám všetko funguje, postupy DevOps, kontajnerizácia atď. – všetko, čo nás napadne. Ale stále to nie sú mikroslužby!
Mikroslužby ako prostriedok na boj so zložitosťou... riadenie konfigurácie
A tu môžeme konečne prejsť k definujúcej úlohe mikroslužieb – ide o prístup, ktorý zjednodušuje správu konfigurácie produktu. Podrobnejšie funkcia každej mikroslužby presne popisuje obchodnú funkciu vo vnútri produktu podľa doménového modelu – a to sú veci, ktoré žijú nie v krátkodobej verzii, ale v dlhotrvajúcej obchodnej príležitosti. A prechod na ďalšiu verziu produktu sa deje doslova bez povšimnutia – zmeníte/pridáte jednu mikroslužbu a možno len schému ich interakcie a zrazu sa ocitnete v budúcnosti a zanecháte za sebou plačúcich konkurentov, ktorí naďalej preskakujú medzi verziami ich monolity. Teraz si predstavte, že existuje pomerne veľký objem mikroslužieb s preddefinovanými rozhraniami a obchodnými možnosťami. A vy prídete a postavíte štruktúru svojho produktu z hotových mikroslužieb – jednoducho napríklad nakreslením diagramu. Gratulujeme - máte platformu - a teraz môžete prilákať podnikanie pre seba. Sny Sny.
Závery
- Architektúra systému by mala byť určená životným cyklom jeho komponentov. Ak komponent žije vo verzii produktu, nemá zmysel zvyšovať zložitosť systému pomocou mikroservisného prístupu.
- Architektúra mikroservisov by mala byť založená na doménovom modeli – pretože obchodná príležitosť je doménou s najdlhšou životnosťou
- Doručovacie praktiky (DevOps praktiky) a orchestrácia sú jedny z najdôležitejších pre architektúru mikroslužieb – z toho dôvodu, že nárast rýchlosti zmien komponentov kladie zvýšené nároky na rýchlosť a kvalitu dodania.
Zdroj: hab.com