Mikroslužby v agenturním vývoji?
Jak víte z našich předešlých příspěvků na sítích, naším primárním jazykem pro psaní “backendů” je Node.js. Jedním z důvodů, proč jsme se rozhodli pro tuto technologii, byl i fakt, že klasické monolitické aplikace, kde veškerá logika, renderování, zpracování requestů, atp. je v jedné codebase, začaly být značně limitující. A to jak technicky, tak z pohledu lidských zdrojů. I v našich “koncích” s PHP jsme rozdělovali finální zobrazovací vrstvu do samostatného tenkého klienta napsaného v Reactu. Chtěli jsme však jít ještě dál, rozdělit backend na několik menších a hlavně samostatných částí.
To, že koncept, kterému se říká microservices (mikroslužby), funguje, jsme věděli. Tou dobou ho již úspěšně používaly firmy jako Netflix nebo Spotify. Ale my nefungujeme ani jako jedna z těchto společností, netvoříme jeden velký produkt, takže bylo otázkou, zda jsme schopni tento koncept správně uchopit v našem agenturním procesu.
První projekt, na kterém jsme tento přístup vyzkoušeli, bylo Tapito. A výsledek byl naprosto skvělý, jak se můžete dočíst v naší case study. Od té doby jsme ušli dlouhou cestu a přístup jsme pilovali, ladili a nyní používáme tento koncept snad v každé zakázce.
Minimální struktura, kterou používáme, se skládá ze 3 částí
Gateway
Jedná se o jedinou část, která je viditelná z internetu. Stará se o rozdělování příchozích požadavků na jednotlivé služby a zajišťuje překlad bezpečnostních tokenů na informace o uživatelích, tak, aby se každá služba uvnitř clusteru mohla rozhodnout, zda požadavek obslouží nebo ne.
User Service
Tato služba je jednoduchá, ale velice důležitá. Uchovává informace o uživatelích a řeší autentizaci a uživatelské role napříč celým systémem.
Core
Pod tímto názvem se skrývá 1-N služeb, které obsahují kompletní business logiku aplikace, obsluhování požadavků, komunikují se službami 3. stran nebo vykonávají periodické úkony. Tyto služby mezi sebou komunikují napřímo. Jejich počet a množství se liší aplikaci od aplikace. Důležité však je, aby služba vždy sloužila k jednomu účelu a pomalu se z ní nestal starý známý monolitický moloch. Naopak, přílišné dělení na “nano služby” může způsobit chaos ještě větší. K dobrému návrhu je zajisté potřeba dobrý úsudek a dostatek zkušeností.
Co se Mikroslužbám vyčítá?
Mikroslužby bývají často kritizované za složitou správu při nasazování a údržbě. Věřím, že toto může být problém, nicméně s naší infrastrukturou postavenou na CI, Docker a Google cloud si tento přístup nemůžeme vynachválit. Samozřejmě, testování více služeb najednou při lokálním vývoji může být občas pracnější. Další výtkou bývá psaní stejného kódu několikrát stále dokola. Ano, logicky, více menších aplikací vyžaduje více kódu, aby byly všechny schopné obsluhovat požadavky, načítání konfigurací, atd. Pro tyto účely jsme vytvořili naší modulární šablonu, která nám tuto činnost značně usnadňuje. Mimochodem, tuto šablonu plánujeme v blízké době vystavit na náš Github.
Co jsme získali?
Podařilo se nám zlepšit přehlednost našich aplikací, menší codebase je snazší udržovat. Další výhodou je, že 2 vývojáři teď mohou pracovat na 2 nezávislých modulech současně, bez potřeby spolu koordinovat, což zrychlí nejen samotný vývoj, ale i zapojení nových členů do projektu.
Získali jsme přehlednější a bezpečnější architekturu, která není nikterak komplikovaná, ale zároveň je dostatečně robustní, škálovatelná a nezávislá. Zároveň jsme se zbavili “Single Point of Failure”. Pád jedné konkrétní služby nemusí znamenat nefunkčnost celého systému, služby jsou na sobě nezávislé, a tak přetížení jedné služby neznamená zastavení jiné kritické služby. Dobrá je i znovupoužitelnost některých částí napříč různými projekty. Tento přístup tedy rozhodně měnit nehodláme, protože nám přináší větší klid a radost při vývoji a našim klientům kvalitnější software. :)
Takže závěrem mohu jen potvrdit: mikroslužby určitě nejsou pouze výsadou velkých produktových firem, skvěle se dají uplatnit i v agenturním vývoji.
