Mikroslužby - kombinatorická explózia verzií

Ahoj Habr! dávam do pozornosti autorský preklad článku Mikroslužby – kombinačná explózia verzií.
Mikroslužby - kombinatorická explózia verzií
V čase, keď sa IT svet postupne posúva smerom k mikroslužbám a nástrojom ako Kubernetes, je čoraz zreteľnejší len jeden problém. Tento problém - kombinatorický výbuch mikroservisné verzie. Napriek tomu je IT komunita presvedčená, že súčasná situácia je oveľa lepšia ako "Peklo závislosti" predchádzajúca generácia technológií. Verzia mikroslužieb je však veľmi zložitý problém. Jedným z dôkazov toho môžu byť články ako napr "Vráť mi môj monolit".

Ak stále nerozumiete problému pri čítaní tohto textu, dovoľte mi vysvetliť. Povedzme, že váš produkt pozostáva z 10 mikroslužieb. Teraz predpokladajme, že pre každú z týchto mikroslužieb je vydaná 1 nová verzia. Len 1 verzia - dúfam, že sa všetci zhodneme, že ide o veľmi triviálny a nepodstatný fakt. Teraz sa však pozrime ešte raz na náš produkt. Len s jednou novou verziou každého komponentu máme teraz 2^10 – alebo 1024 permutácií toho, ako možno náš produkt zložiť.

Ak ešte dôjde k nejakému nedorozumeniu, dovoľte mi rozobrať matematiku. Máme teda 10 mikroslužieb, z ktorých každá dostáva jednu aktualizáciu. To znamená, že pre každú mikroslužbu (starú alebo novú) dostaneme 2 možné verzie. Teraz môžeme pre každý komponent produktu použiť ktorúkoľvek z týchto dvoch verzií. Matematicky je to rovnaké, ako keby sme mali binárne číslo 10 číslic. Povedzme napríklad, že 1 je nová verzia a 0 je stará verzia – potom môže byť jedna možná permutácia označená ako 1001000000 – kde 1. a 4. komponent sú aktualizované a všetky ostatné nie. Z matematiky vieme, že 10-miestne binárne číslo môže mať 2^10 alebo 1024 hodnôt. To znamená, že sme potvrdili rozsah čísla, s ktorým máme do činenia.

Pokračujme v úvahách ďalej – čo sa stane, ak budeme mať 100 mikroslužieb a každá bude mať 10 možných verzií? Celá situácia sa stáva dosť nepríjemnou – teraz máme 10^100 permutácií – čo je obrovské číslo. Radšej však takto označujem túto situáciu, pretože teraz sa už neschovávame za slová ako „kubernetes“, ale čelíme problému tak, ako je.

Prečo ma tento problém tak fascinuje? Čiastočne preto, že keď sme predtým pracovali vo svete NLP a AI, pred 5-6 rokmi sme veľa diskutovali o probléme kombinatorickej explózie. Len namiesto verzií sme mali jednotlivé slová a namiesto produktov sme mali vety a odseky. A hoci problémy NLP a AI zostávajú do značnej miery nevyriešené, treba priznať, že za posledných pár rokov sa dosiahol významný pokrok. (podľa mňa by sa dalo pokročiťоBolo by lepšie, keby ľudia z brandže venovali trochu menej pozornosti strojovému učeniu a trochu viac iným technikám – ale to už je mimo témy).

Vráťme sa do sveta DevOps a mikroslužieb. Čelíme obrovskému problému, vydávame sa za slona v Kunstkamere - pretože často počujem: „Vezmi kubernetes a kormidlo a všetko bude v poriadku! Ale nie, všetko nebude v poriadku, ak všetko zostane tak, ako je. Okrem toho sa analytické riešenie tohto problému nezdá prijateľné pre jeho zložitosť. Rovnako ako v NLP by sme mali najprv pristupovať k tomuto problému zúžením rozsahu vyhľadávania - v tomto prípade odstránením zastaraných permutácií.

Jedna z vecí, ktorá by mohla pomôcť, je niečo, čo som napísal minulý rok o potrebe zachovať minimálny rozdiel medzi verziami zverejnenými pre klientov. Je tiež dôležité poznamenať, že dobre navrhnutý proces CI/CD výrazne pomáha pri znižovaní variácií. Súčasný stav vecí s CI/CD však nie je dosť dobrý na to, aby vyriešil problém permutácií bez ďalších nástrojov na účtovanie a sledovanie komponentov.

Potrebujeme systém experimentovania vo fáze integrácie, kde dokážeme určiť rizikový faktor pre každý komponent a tiež máme automatizovaný proces aktualizácie rôznych komponentov a testovania bez zásahu operátora – aby sme videli, čo funguje a čo nie.

Takýto systém experimentov by mohol vyzerať takto:

  1. Vývojári píšu testy (toto je kritická fáza – pretože inak nemáme žiadne hodnotiace kritérium – je to ako označovanie údajov v strojovom učení).
  2. Každý komponent (projekt) dostáva svoj vlastný CI systém – tento proces je teraz dobre vyvinutý a otázka vytvorenia CI systému pre jeden komponent je do značnej miery vyriešená
  3. „Inteligentný integračný systém“ zhromažďuje výsledky rôznych systémov CI a zostavuje projekty komponentov do konečného produktu, spúšťa testovanie a nakoniec vypočítava najkratšiu cestu k získaniu požadovanej funkčnosti produktu na základe existujúcich komponentov a rizikových faktorov. Ak aktualizácia nie je možná, tento systém upozorní vývojárov na existujúce komponenty a na to, ktoré z nich spôsobujú chybu. Opäť je tu rozhodujúci testovací systém, pretože integračný systém používa testy ako hodnotiace kritérium.
  4. CD systém, ktorý následne prijíma dáta zo Smart Integration System a priamo vykoná aktualizáciu. Táto fáza ukončí cyklus.

Aby som to zhrnul, jedným z najväčších problémov v súčasnosti je pre mňa nedostatok takého „inteligentného integračného systému“, ktorý by spájal rôzne komponenty do produktu a umožňoval tak sledovať, ako je produkt ako celok zostavený. Bude ma zaujímať názor komunity na toto (spoiler - momentálne pracujem na projekte Reliza, ktorý sa môže stať takýmto inteligentným integračným systémom).

Posledná vec, ktorú by som chcel spomenúť, je, že pre mňa nie je monolit prijateľný pre akýkoľvek projekt dokonca strednej veľkosti. U mňa pokusy o urýchlenie času implementácie a kvality vývoja návratom k monolitu vyvolávajú veľkú skepsu. Po prvé, monolit má podobný problém so správou komponentov - medzi rôznymi knižnicami, z ktorých pozostáva, však toto všetko nie je také nápadné a prejavuje sa predovšetkým v čase strávenom vývojármi. Dôsledkom problému monolitu je virtuálna nemožnosť vykonávať zmeny v kóde - a extrémne nízka rýchlosť vývoja.

Mikroslužby zlepšujú situáciu, ale potom architektúra mikroslužieb čelí problému kombinatorickej explózie vo fáze integrácie. Áno, vo všeobecnosti sme ten istý problém presunuli z fázy vývoja do fázy integrácie. Prístup mikroslužieb však podľa mňa stále vedie k lepším výsledkom a tímy dosahujú výsledky rýchlejšie (zrejme najmä vďaka zmenšeniu veľkosti vývojovej jednotky – resp. veľkosť dávky). Prechod od monolitu k mikroslužbám však ešte proces dostatočne nezlepšil – kombinatorická explózia verzií mikroslužieb je obrovský problém a máme veľký potenciál na zlepšenie situácie, keď ju vyriešime.

Zdroj: hab.com

Pridať komentár