Tému mikroslužieb som chcel napísať už dávno, no stále ma brzdili dva faktory – čím hlbšie som sa do tejto témy ponáral, tým viac mi pripadalo, že to, čo viem, je očividné, a to, čo neviem, je potrebné ešte skúmať a skúmať. Na druhej strane sa domnievam, že už je o čom diskutovať aj medzi širokým publikom. Takže alternatívne názory sú vítané.
Conwayov zákon a vzťah medzi podnikaním, organizáciou a informačným systémom
Opäť si dovolím citovať:
„Každá organizácia, ktorá navrhuje akýkoľvek systém (v širokom zmysle), dostane dizajn, ktorého štruktúra kopíruje štruktúru tímov v tejto organizácii.“
— Melvyn Conway, 1967
Podľa môjho názoru tento zákon skôr súvisí s efektívnosťou organizácie podnikania než priamo s informačným systémom. Vysvetlím to na príklade. Predpokladajme, že máme dostatočne stabilnú podnikateľskú príležitosť s takým dlhou životnosťou, aby malo zmysel zorganizovať podnik (nie je to preklep, ale veľmi sa mi páči tento termín, ktorý som si požičal). Samozrejme, že zabezpečujúci systém tohto podnikania bude organizačne a procesne zodpovedať tomuto podnikaniu.
Podnikateľská orientácia informačných systémov
Vysvetlím to na príklade. Predpokladajme existenciu podnikateľskej príležitosti na organizáciu podnikania v oblasti predaja pizze. Vo verzii V1 (nazvime ju neinformatívna) spoločnosť predstavovala pizzeriu, pokladňu a doručovaciu službu. Táto verzia mala dlhú životnosť v podmienkach nízkej volatility okolia. Potom prišla verzia 2 — pokročilejšia a schopná využívať informačný systém ako základ pre podnikanie s monolitickou architektúrou. A tu, podľa môjho názoru, vzniká proste hrozná nespravodlivosť voči monolitom — akoby monolitická architektúra nezodpovedala doménovému modelu podnikania. Ak by to tak bolo, systém by vôbec nemohol fungovať - v rozpore s tým istým Conwayovým zákonom a zdravým rozumom. Nie, monolitná architektúra plne zodpovedá obchodnému modelu v tejto fáze vývoja podnikania - samozrejme mám na mysli fázu, keď je systém už vytvorený a uvedený do prevádzky. Úžasný fakt je, že bez ohľadu na architektonický prístup, ako je verzia 3 so službami orientovanými na služby a mikroslužby verzie N, budú fungovať rovnako dobre. Kde je háčik?
Všetko tečie, všetko sa mení alebo mikroslužby sú prostriedkom boja proti zložitosti?
Predtým, ako pokračujeme, pozrime sa na niektoré mýty o mikroslužbovej architektúre.
Zástancovia mikroslužbového prístupu často tvrdia, že rozdelenie monolitu na mikroslužby zjednodušuje prístup k vývoju prostredníctvom zníženia kódovej základne jednotlivých služieb. Podľa môjho názoru je toto tvrdenie úplný nezmysel. Naozaj, zdá sa, že zrejmé interakcie v rámci monolitu a homogénneho kódu sú zložité? Keby to skutočne tak bolo, všetky projekty by sa od začiatku budovali ako mikroslužby, zatiaľ čo prax ukazuje, že migrácia z monolitu na mikroslužby je oveľa bežnejšia. Zložitosť nikam nezmizne, jednoducho prechádza z jednotlivých modulov do rozhraní (či už ide o dátové zbernice, RPC, API a iné protokoly) a orchestrujúce systémy. A to je - zložité!
Výhoda používania heterogénneho stacku je tiež sporná. Nebudem oponovať, že to je tiež možné, ale v skutočnosti sa to zriedka stretáva (Ak sa ponáhľam dopredu - to by malo mať miesto - ale skôr ako následok, než výhodu).
Životný cyklus produktu a životný cyklus služby
Pozrite sa ešte raz na diagram vyššie. Neoznačil som náhodou zmenšujúci sa životný cyklus jednotlivých verzií podniku - v súčasných podmienkach je presne zrýchlenie prechodu podniku medzi verziami rozhodujúce pre jeho úspech. Úspešnosť produktu je určená rýchlosťou overovania obchodných hypotéz v ňom. A práve tu podľa môjho názoru leží kľúčová výhoda mikroslužbovej architektúry. Ale poďme na to postupne.
Prejdeme na ďalšiu úroveň evolúcie informačných systémov — na architektúru orientovanú na služby SOA. Takže v určitom momente sme vyčlenili vo svojom produkte dlhoveké služby — dlhoveké v tom zmysle, že pri prechode medzi verziami produktu existuje šanca, že životný cyklus služby bude dlhší ako životný cyklus nasledujúcej verzie produktu. Bolo by logické ich vôbec nemeniť — pre nás je dôležitá práve rýchlosť prechodu na ďalšiu verziu. Ale žiaľ, musíme neustále vykonávať zmeny v službách — a tu nám vyhovuje všetko, od DevOps praktík, cez kontajnerizáciu, a tak ďalej — všetko, čo napadne. Ale to stále nie sú mikroslužby!
Mikroslužby ako prostriedok boja so zložitosti… správa konfigurácií
A tu sa konečne môžeme preorientovať na určujúcu úlohu mikroslužieb — je to prístup, ktorý zjednodušuje správu konfigurácie produktu. Presnejšie povedané, funkcia každej mikroslužby opisuje presne obchodnú funkciu v rámci produktu podľa doménového modelu — a to už sú veci, ktoré nežijú v krátkodobých verziách, ale v dlhodobých obchodných možnostiach. A prechod na ďalšiu verziu produktu sa deje doslova bez povšimnutia — meníte/pridávate jednu mikroslužbu, možno len schému ich interakcie a zrazu ste už v budúcnosti, pričom nechávate za sebou plačúcich konkurentov, ktorí naďalej skáču medzi verziami svojich monolitov. Teraz si predstavte, že existuje dostatočne veľký objem mikroslužieb s vopred definovanými rozhraniami a obchodnými možnosťami. A prídete a staviate štruktúru svojho produktu z hotových mikroslužieb — jednoducho nakreslíte diagram napríklad. Blahoželám — máte platformu — a teraz si môžete naklikať obchod. Sny, sny.
Zhrnutie
- Architektúra systému by mala byť definovaná životným cyklom komponentov, ktoré sú do nej zahrnuté. Ak komponent žije v rámci verzie produktu — nemá zmysel zvyšovať zložitosti systému, ak použijeme mikroslužbový prístup.
- Mikroslužbová architektúra by mala byť založená na doménovom modeli — z dôvodu, že obchodná príležitosť je najdlhšie trvajúca oblasť
- Praktiky doručovania (DevOps praktiky) a orchestrace majú pre mikroslužbovú architektúru jedno z najdôležitejších významov — pretože zvýšenie rýchlosti zmien komponentov kladie vyššie požiadavky na rýchlosť a kvalitu doručovania.
Zdroj: habr.com
