Architektúra mikroslužieb – čo to je a  prečo ju používame (1. časť)

Počuli ste už o termíne architektúra mikroservisov? Je to jedna z možných alternatív ku všeobecne známej monolitickej architektúre. Dnes už existuje viacero typov architektúr a voľba, ktorú použiť, závisí hlavne od projektu. Neexistuje žiadna ideálna možnosť, nakoľko každá architektúra má svoje výhody i nevýhody. 

Aký je rozdiel v  porovnaní s  monolitickou architektúrou?

Architektúra mikroslužieb pozostáva - v  porovnaní s  monolitickou architektúrou - z  kolekcie viacerých služieb, kde má každá svoj konkrétny obchodný význam. Takúto mikroslužbu si môžeme predstaviť ako malú aplikáciu, ktorá riadi len špecifický set funkcionalít v rámci celého informačného systému. Jedna služba má na starosti napríklad správu používateľov zahŕňajúc registráciu, prihlásenie, obnovu hesla a  úpravu profilu, no iná môže mať na starosti produktový katalóg, kategorizáciu produktov a  všetko okolo nich. 

Motivácia

V projektoch, ktoré sme vyvíjali, sme videli, že sa často opakujú rovnaké funkcionality a programovať ich znova a znova nebolo efektívne. S narastajúcim dopytom po komplexných informačných systémoch sme potrebovali do nášho procesu zaviesť viac "znovupoužívania". Základný prístup k  vývoju nám už nestačil, lebo viedol k  opakovaniu rovnakej práce viackrát. Prístup s  prepoužívanými a  zdieľanými časťami, nazývanými mikroslužby, by priniesol do nášho procesu väčšiu efektivitu a  naše riešenia lepšie pripravil na plnenie požiadavok našich klientov. 

Aké benefity prináša?

Pre dosiahnutie znovupoužiteľnosti mikroslužieb ich musíme vyvíjať generické a  konfigurovateľné. Len zmenami ich konfigurácie musia byť pripravené na viaceré prípady, a  to väčšinou bez zmien ich kódu. Registrácia a  aktivačný proces používateľského účtu v  pouíivateľkom module (tzv. „User module“) je dobrým príkladom, ktorý môže fungovať ako okamžitý (bez aktivačného emailu) v  jednom projekte a v  inom zas vyžadujúci overenie aktivačným e-mailom.

V  komplexných informačných systémoch môžu niektoré časti potrebovať viac výkonu ako ostatné. To už nie je problémom, pretože jednoducho môžeme vyhradiť viac zdrojov pre konkrétnu mikroslužbu. Spracovanie veľkého množstva dát, čo je známym problémom obrovských aplikácií, pomáha riešiť škálovateľnosť vo forme viacerých inštancií jednej mikroslužby. Prirodzene tak z  tejto architektúry vyplýva aj vysoká dostupnosť služieb, keďže počas údržby alebo  aktualizácie jednej mikroslužby nie sú zasiahnuté všetky ostatné a  môžu tak pokračovať vo svojej funkčnosti. 

Aktuálizácie a  bezpečnosť

Komplexné informačné systémy často využívajú integrácie treťostranných služieb, ako napríklad daňové systémy, poskytovateľov e-mail serverov, SMS brány, platobné brány,... Keď vznikne potreba vymeniť treťostrannú službu za inú, oproti monolitickej architektúre nie je tento proces tak náročný. Nakoľko sú integrácie týchto treťostranných služieb naprogramované ako nezávislé mikroslužby, nie je problém ich vymeniť, ak dodržia stanovené rozhranie vstupov a  výstupov, ktoré poskytujú. To isté platí aj pre knižnice a  frameworky. Ohlásená bezpečnostná aktualizácia danej časti vie byť zavedená individuálne, bez ovplyvnenia celého systému. Neriskujeme pokazenie inej funkcionality a  zároveň udržiavame aplikáciu bezpečnú a  aktualizovanú. Týka sa to nielen existujúcich častí systému, ale aj nových. Každej novej službe môže byť technológia zvolená nezávisle od ostatných podľa jej potrieb. 

Závery

Teraz máte základný prehľad rozdielov medzi spomenutými architektúrami a  viete, ako architektúra mikroslužieb pomáha dodávať rýchlejšie, ušetriť peniaze klienta a  poskytovať softvér vyššej kvality. V  ďalšej časti tejto série o  architektúre mikroslužieb sa pozrieme na zmeny v  našich procesoch, ktoré sme museli spraviť a  ako sme sa im my, vývojári, prispôsobili.  

Autori: Dávid Ondruš, Richard Roštecký, Tibor Hanesz