Kľúčom k vyhodnoteniu užitočnosti IT architekúry microservices (MS) je dobre poznať kontext zákazníka, jeho biznis, jeho procesy (prevádzka, IT, životný cyklus jeho produktov a systémov atď.), už existujúce technológie a jeho očakávania (dlhodobá stabilita vs. vysoká dynamika, pružnosť vs. dlhodobé plánovanie atď.).

Nasleduje zhrnutie na základe úspešnej realizácie takéhoto projektu (resp. viacerých súvisiacich projektov), kde zohrala hlavnú úlohu pripravenosť a odhodlanie zákazníka, správny výber kľúčových hráčov a pružnosť, s ktorou sa musí počítať v každej fáze realizácie.

Čo sú to tie microservices?

IT architektúra sa dá budovať rôznymi stratégiami a rôznym prístupom. Závisí samozrejme od kontextu – komu, načo, ako dlho má slúžiť, aký je predpokladaný životný cyklus budovaných systémov a pod..

Jedným z architektonických štýlov sú aj microservices. Sú založené na myšlienke, že systémy staviame z malých (naozaj dosť malých) komponentov, ktoré sú autonómne (čo najmenej závislé na ostatných systémoch a komponentoch). Typická mikroslužba sa má dať naprogramovať za pár dní, maximálne týždňov, má vlastnú databázu a komunikuje s ostatnými službami (ak je to nutné resp. žiadúce) čo „najľahším“ spôsobom – napr. HTTP REST. Takýchto služieb – keďže sú malé – vznikne veľa, a preto je vhodné ich automatické nasadzovanie a management.

Za to – a to je hlavná motivácia pre využitie tohto prístupu – získavame značné výhody:

• čistá architektúra – „silné hranice“ jednotlivých komponentov, explicitné a jasné rozhrania a kompetencie
• nezávislé nasadenie – ak (pre)nasadím iba malú zmenu, mám menšie riziko, že pokazím niečo iné
• nižšia závislosť od technológií a viazanosť na dodávateľa – takéto služby sú nezávislé a je možné ich realizovať rôznymi technológiami a rôznymi dodávateľmi
• škálovateľnosť – možnosť škálovať do šírky práve a iba tie komponetny, ktoré sú úzkym miestom a nič iné

Na druhej strane, IT architekt si musí uvedomiť aj riziká a nevýhody takéhoto prístupu:

• distribuovanosť – viac nezávislých služieb = vyššia miera distribuovanosti = zložitejšie na naprogramovanie
• eventuálna konzistencia – viac databáz = vyššie riziko že v danej chvíli (ešte alebo už) dáta nie sú konzistentné medzi sebou (hoci len nakrátko)
• zložitejšie prevádzkové činnosti – prevádzke nedodávam „systém“, ale sadu „komponentov“, ktoré musí prevádzka prevziať, nasadiť a držať v chode; je to ako švédsky nábytok – dodávam komponenty, ktoré si môže – ale aj musí – odberateľ poskladať do celku, ktorý potrebuje
• výkon – komunikácia medzi microservices je zvyčajne „drahšia“ ako vnútorné volania v rámci monolitu; riziko sa prejaví najmä vtedy, ak je nevhodne zvolená granularita (veľkosť) microservices resp. hranica medzi nimi nebola zvolená správne

Tak či onak, kritériá pre využitie tohto architektonického prístupu sú jasné – použijem ho vtedy, keď benefity prevyšujú riziká, čo by skúsený IT architekt, so znalosťou kontextu zákazníka, mal vedieť odhadnúť a spočítať.

Čo potreboval zákazník vyriešiť?

Nedávno sme úspešne pomohli zákazníkovi prekonať technologický a štrukturálny problém v jeho predajných a zákazníckych systémoch práve postupným a plynulým prechodom od monolitu k microservices.

Jeho agendou bol predaj služieb a tovaru v pobočkách po celom Slovensku, eshop, elektronické služby koncovým používateľom a všetko čo patrí k starostlivosti o zákazníka (selfcare, call centrum a pod).

Všetky systémy však končili (či vlastne začínali) vo veľkom a pomerne zložitom (a preto aj drahom) systéme, ktorý síce fungoval spoľahlivo, ale bol už na hranici svojich možností – drahé a rizikové zmeny, obavy o výkon, predražovanie prevádzky a rozvoja atď.

Na počiatku bola teda typická motivácia – máme starý, drahý a pomalý systém typu „monolit“. Drahé licencie. Zvyšovanie výkonu škálovaním do šírky bolo už prakticky nemožné. Výkonnejší hardware už výkon nezlepšoval. Zmena architektúry riešenia znamenala urobiť to odznova.

Zákazník si uvedomoval, že náprava je možná iba výmenou prístupu k riešeniu, nie iba výmenou jednej škatule za inú.

Analytici a dizajnéri správne vyhodnotili, že jednotlivé časti systému majú rôznu životnosť, rôznu dynamiku zmien, rôzne nároky na výkon, rôzne správanie sa vzhľadom na škálovanie.

A že svet IT sa za posledné roky zmenil tak, že vývojári a ďalší špecialisti už majú iné očakávania na poli technológií aj metodiky svojej práce – vŕtanie sa v monolite, ktorý už nikde inde nestretnú, nepridáva na pocite zmysluplnosti.

Takže padlo rozhodnutie, že monolit sa postupne odbúra, bude nahradený viacerými nezávislými aplikáciami, ktoré budú organizované v rámci servisne orientovanej architektúry. Zostala iba otázka, aká presne bude ich granularita – niekoľko hlavných aplikácií, alebo veľa malých autonómnych služieb.

Nakoniec prevážil názor, že „niečo tak a niečo tak“, podľa toho, aký užitočný výkon nám ponúknu jednotlivé domény, tiež aký rozpad nám umožnia jej dáta – pretože rozloženie monilitných dát (databázy) je skúšobným kameňom každého pokusu o silne distribuovanú architektúru (čoho sú MS extrémnym prípadom).

Prečo sme zákazníkovi odporučili microservices?

Treba si hneď z kraja uvedomiť, že v rámci zákazníka existuje viacero skupín, ktoré majú rôzne požiadavky a očakávania od systému. Prevádzka, biznis, operátori a asistenti, call-centrum či marketing a samozrejme aj zákazníci v eshope a predajniach – každý z nich prichádza do styku so systémom inak, inokedy a za iným účelom. Uspokojiť (a upokojiť) prevádzku nie je menej dôležité ako naplniť očakávania marketingu.

Preto sme zvážili všetky dopady novo navrhovaného prístupu (architektúry) – od vývoja a rozvoja systému, cez jeho nasadenie do testu, prevádzky, až po jeho vyradenie, prípadne postupné nahrádzanie. Tiež je jasné, že žiadna požiadavka nie je konečná, že o pár mesiacov a rokov môže byť všetko inak, že systém sa bude musieť prispôsobovať – rôzne jeho časti rôzne rýchlo a vo viacerých rozmeroch – funkčne, výkonovo, používateľsky.

Preto sme za hlavné výhody navrhovanej microservisovej architektúry (pre väčšinu systému) deklarovali:

• postupnosť a priebežnosť = systém sa bude dodávať postupne, po častiach, za behu, t.j. popri „business-as-usual“. Žiadny BigBang nikto riskovať nebude. Scope a rýchlosť dodávok vieme regulovať priebežne, podľa kapacity vývoja a podľa priorít zákazníka.
• škálovateľnosť = malé autonómne služby sú na škálovanie ideálne, tomuto aspektu sa iné architektúrne prístupy len ťažko vyrovnajú
• nezávislosť = flexibilita. Žiadny vendor lock ani technologický lock. Každú microslužbu resp. mikroaplikáciu je možné nahradiť (naimplementovať nanovo) za niekoľko týždňov (rádovo jednotky týždňov) a bez ohľadu na technológiu, framework, dodávateľa, keďže MS sú autonómne. Jedinou podmienkou je dodržať integračné rozhrania.
• stabilita = prípadná chyba, výpadok alebo iný nedostatok v jednej časti systému (jednej microslužbe) ovplyvňuje celok v oveľa menšej miere, ako to má monolit (ten buď beží alebo stojí), ale aj ako „vrstvená“ servisne orientovaná architektúra (v tej sa môžu šíriť problémy v rámci jednej vrstvy cez viaceré domény)
• výhodná cena malej aj strednej zmeny = je ľahké pochopiť, ako fungujú jednotlivé microservices a urobiť zmenu/opravu bez rizika, že poškodím niečo, o čom ani neviem, že existuje. Je to priamy dopad nezávislosti – nemusím sa zaoberať priamo nesúvisiacimi časťami systému, pretože všetky prípadné väzby a súvislosti sú explicitné (cez rozhrania).

Koľko trvala implementácia?

Merítkom úspešného projektu je, okrem iného, aj trvanie implementácie, kedže čas sú peniaze a predlžovanie projektu sa rovná jeho predražovaniu. Ale zdanlivo jednoduchá metrika – koľko projekt trvá vs. ako boli nastavené míľniky – má svoje úskalia. V tomto prípade boli práce na transformácii z monolitického systému na MS architektúru odhadované na 3 roky. Bolo však jasné, že za ten čas bude musieť realizačný tím absorbovať aj netriviálne množstvo zmien a prác, ktoré v pláne neboli:

• zmeny z marketingu a biznisu (svet sa mení a biznis to musí reflektovať, lebo predaj sa nesmie zastaviť)
• legal-must – zmena legislatívy nie je signalizovaná dopredu a nedá sa odložiť. Zažili sme GDPR, eKasa a sadu ďalších zmien, ktoré bolo treba zapracovať v rámci transformácie bez toho, aby sme to odložili, zrušili alebo posunuli.
• licenčné a technické obmedzenia – počas projektu sa menili obchodné a licenčné podmienky, verzie používaných nástrojov a frameworkov, podpora existujúcich aj plánovaných komponentov, nové bezpečnostné hrozby a zmena odporúčaní pre ich elimináciu. Toto sú ale riziká každého nie úplne krátkeho projektu.

Napriek týmto vplyvom sa ale projekt podarilo dostať do konečnej podoby načas (odchýlka bola v desiatkach dní).

Prečo sa microservices firmám oplatí?

Firma, ktorá si vybuduje (alebo nechá postaviť) systém pre svoj core biznis, zvyčajne má celkom konkrétne očakávania v oblastiach jeho funkčnosti a spoľahlivosti, aj ceny za jeho získanie.

Ale celkové náklady na to, že ten systém vlastní, používa, udržiava, a postupne alebo nárazovo vymieňa, alebo upravuje – tam sú odhady veľmi nepresné (a sú na to aj objektívne dôvody). Rozhodnutie pre nový systém alebo väčšiu zmenu starého si totiž vyžaduje predpovedať, ako sa bude firma, jej zákazníci a jej biznis vyvíjať do budúcnosti. Monolitické systémy zvyčajne indukujú rozhodnutia na dlhú dobu – ak do toho idem, bude to na dlho a zmena rozhodnutia bude drahá. Budovanie systému po menších – ale spolupracujúcich – častiach má svoje riziká (musím sa rozhodovať priebežne a vyhodnocovať, čo ďalej), ale každé rozhodnutie viem relatívne lacno a rýchlo zmeniť alebo opraviť. Čím vyššiu mieru neistoty potrebujem do plánov zahrnúť, tým viac sa mi oplatí investovať do škálovateľnej, tvárnej architektúry mojich systémov.

Vysoko dynamické odvetvia, ako je Telco, energie, média a čokoľvek na internete dnes už neriskujú, a volia prístup, kde sa dá všetko zmeniť a vymeniť do nasledujúceho zdaňovacieho obdobia.

Microservices – je to budúcnosť?

Dnešný svet – otočený okolo technológií – je veľmi rýchly. Nápady sa recyklujú, ale ich používanie sa zrýchlilo a zlacnilo natoľko, že to zmenilo základné princípy budovania biznisu – nielen v technologickej resp. IT doméne.

Realita tlačí na to, že zmenu treba urobiť už dnes, vyskúšať a zajtra to poopraviť alebo zahodiť, zmeniť = čakať nie je na čo. MS ako architektúrny prístup je ústretový tejto filozofii – spraviť niečo rýchlo, hoci jednoducho, a zakrátko to zmeniť (aj úplne prerobiť), ak to nejde dobre. A naopak – ak to stačí, tak sa toho nijako nechytať (nerobiť si prácu navyše = nestrácať čas).

Všetky hore popísané výhody MS smerujú presne k tomuto – maximálna flexibilita, ľahká škálovateľnost, prenositeľnosť (=nezávislosť) – firme umožňujú robiť tieto zmeny rýchlo, málo rizikovo a reagovať na zmenu vonkajších podmienok (trh, technológie, dodávatelia), ale aj vnútorných potrieb a očakávaní (prejdeme do cloudu, alebo rádovo znásobíme zdroje, či zmeníme škálu svojho biznisu atď.).

Takže áno, microservices sú budúcnosť a už aj prítomnosť 🙂 .

Ak máte otázky alebo zvažujete použiť aj vo vašej firme microservices, neváhajte nas kontaktovať.

Rastislav Senderák, Architekt