Zdá se, že vrchol humbuku kolem mikroslužeb je za námi. Už nečteme každý týden příspěvky typu „Jak jsem migroval svůj monolit na 150 služeb“. Teď slýchám rozumnější myšlenky: „Nenávidím monolit, jen mi záleží na efektivitě.“ Dokonce jsme byli svědky i několika migrací. Při migraci z jedné velké aplikace na několik menších služeb budete muset řešit několik nových výzev. Stručně je vyjmenujeme.
Instalace: Od základní chemie ke kvantové mechanice
Nastavení základní databáze a aplikace s procesem na pozadí byl poměrně přímočarý proces. Publikuji readme na Githubu a často během hodiny, maximálně několika hodin, je vše spuštěné a můžu se pustit do nového projektu. Přidávání a spouštění kódu, alespoň pro počáteční prostředí, je hotové hned první den. Pokud se ale pustíme do mikroslužeb, počáteční doba spuštění prudce stoupá. Ano, v současné době máme Docker s orchestrací a cluster strojů K8, ale pro začínajícího programátora je to všechno řádově složitější. Pro mnoho juniorních vývojářů tato zátěž skutečně představuje zbytečnou složitost.
Systém je obtížné pochopit
Zaměřme se na chvíli na náš juniorský projekt. U monolitických aplikací bylo snadné, pokud došlo k chybě, ji okamžitě vystopovat a ladit. Nyní máme službu, která komunikuje s jinou službou, která něco zařadí do fronty na sběrnici zpráv, která zpracovává jinou službu – a pak dojde k chybě. Musíme všechny tyto kousky poskládat dohromady, abychom nakonec zjistili, že služba A běží na verzi 11 a služba E již očekává verzi 12. To se velmi liší od mého standardního konsolidovaného protokolu: musím použít interaktivní terminál/ladicí program, abych proces krok za krokem procházel. Ladění a porozumění se staly ze své podstaty obtížnějšími.
Pokud je nedokážeme odladit, možná je můžeme otestovat.
Neustálá integrace a neustálý vývoj se v dnešní době stávají běžnou praxí. Většina nových aplikací, které vidím, automaticky vytváří a spouští testy s každým vydáním a vyžaduje, aby byly testy předány a zkontrolovány před jejich spuštěním. Jsou to vynikající procesy, které by se neměly opusťovat; pro mnoho společností se staly velkým posunem. Ale teď, abych službu skutečně otestoval, musím nasadit plnou produkční verzi své aplikace. Pamatujete si na toho nového inženýra s clusterem K8 se 150 službami? Teď naučíme náš systém CI, jak nasadit všechny tyto systémy, abychom ověřili, že vše skutečně funguje. To je asi příliš mnoho úsilí, takže budeme každou část testovat izolovaně: Jsem si jistý, že naše specifikace jsou správné, API je čisté a selhání služby je izolované a neovlivní ostatní.
Všechny kompromisy mají dobrý důvod, že?
Existuje mnoho důvodů pro přechod na mikroslužby. Viděl jsem to dělat kvůli větší agilitě, škálování týmu, výkonu i odolnosti. Ve skutečnosti jsme ale investovali desetiletí do nástrojů a postupů pro monolitický vývoj a ty se neustále vyvíjejí. Pracuji s profesionály z různých technologií. O škálování obvykle mluvíme, protože narážejí na limity jednoho uzlu databáze Postgres. Velká část konverzace se točí kolem... .
Ale vždycky mě zajímá, jaká je jejich architektura. V jaké fázi přechodu na mikroslužby se nacházejí. Je zajímavé sledovat, jak stále více inženýrů říká, že jsou spokojeni se svou monolitickou aplikací. Mikroslužby budou pro mnohé přínosem a výhody převáží nad překážkami v cestě migrace. Ale dejte mi mou monolitickou aplikaci místo na pláži a budu naprosto spokojený.
Zdroj: www.habr.com
