Zdá se, že vrcholový pobídky kolem mikroslužeb je za námi. Už nečteme několikrát týdně příspěvky „Jak jsem převedl svůj monolit na 150 služeb“. Častěji slyším rozumné myšlenky: „Monolit nenávidím, jen se starám o efektivitu“. Dokonce jsme byli svědky několika migrací . Při přechodu z jedné velké aplikace na několik menších služeb budete muset řešit několik nových problémů. Vyjmenujme je co nejstručněji.
Instalace: od základní chemie k kvantové mechanice
Nastavení základní databáze a aplikace s pozadím bylo docela jasným procesem. Publikuji readme na GitHubu – a často už za hodinu, maximálně za dvě, všechno funguje a já začínám nový projekt. Přidání a spuštění kódu, alespoň pro počáteční prostředí, se realizuje během prvního dne. Ale pokud jsme se odhodlali k mikroslužbám, čas potřebný pro počáteční spuštění raketově vzrůstá. Ano, nyní máme Docker s orchestrace a cluster strojů K8, ale pro začínajícího programátora je to vše o řád složitější. Pro mnohé juniory je to zátěž, která je opravdu zbytečnou složitostí.
Systém není snadné pochopit
Na chvíli se zastavme u našeho juniora. U monolitických aplikací bylo snadné sledovat chybu a okamžitě přejít k ladění. Nyní máme službu, která komunikuje s jinou službou, která posílá něco do fronty na zprávové sběrnici, která zpracovává další službu – a tam se objeví chyba. Musíme spojit všechny tyto části, abychom nakonec zjistili, že služba A běží ve verzi 11, zatímco služba E již očekává verzi 12. To je výrazně odlišné od mého standardního konsolidovaného záznamu: musím použít interaktivní terminál/ladič, abych prošel procesem krok za krokem. Ladění a porozumění se v zásadě stalo složitějším.
Pokud nemůžeme ladit, možná je otestujeme
Nepřetržitá integrace a nepřetržitý vývoj se nyní stávají běžnou praxí. Většina nových aplikací, které vidím, automaticky vytváří a spouští testy s každým novým vydáním a požaduje, aby testy byly úspěšně splněny a přezkoumány před registrací. To jsou skvělé procesy, kterých se nelze vzdát, staly se velkým posunem pro mnoho společností. Ale nyní, abych skutečně otestoval službu, musím mít plně funkční verzi své aplikace. Pamatujete na toho nového inženýra s K8 clusterem o 150 službách? No, teď naučíme náš CI systém, jak spustit všechny tyto systémy pro testování, že vše opravdu funguje. Pravděpodobně je to příliš mnoho práce, proto jen izolovaně otestujeme každou část: jsem si jistý, že naše specifikace jsou dostatečně dobré, API jsou čistá a výpadek služby je izolovaný a neovlivní ostatní.
Všechny kompromisy mají své opodstatnění. Je to tak?
Existuje mnoho důvodů pro přechod na mikroservisy. Viděl jsem, že to lidé dělají pro větší flexibilitu, pro škálování týmů, pro výkon, aby zajistili lepší odolnost. Ale ve skutečnosti jsme investovali desetiletí do nástrojů a praktik vývoje monolitů, které se neustále vyvíjejí. Pracuji s odborníky na různé technologie. Obvykle mluvíme o škálování, protože se potýkají s limity jednoho uzlu databáze Postgres. Velká část diskuzí se věnuje .
Ale vždy mě zajímá jejich architektura. V jaké fázi přechodu na mikroservisy se nacházejí. Je zajímavé pozorovat, jak čím dál více inženýrů říká, že jsou spokojeni se svým monolitním aplikacím. Mnohým mikroservisy přinesou prospěch a výhody převažují nad překážkami na migrační cestě. Ale mně osobně dejte, prosím, mou monolitní aplikaci, místo na pláži — a jsem naprosto šťastný.
Zdroj: habr.com
