Ahoj, Habr! Predstavujem vám autorský preklad článku .
V čase, keď sa svet IT postupne prenáša na mikroslužby a nástroje ako Kubernetes, stáva sa čoraz zjavnejším len jeden problém. Tento problém je verzií mikroslužieb. Napriek tomu IT komunita považuje súčasnú situáciu za podstatne lepšiu než predchádzajúcej generácie technológií. Napriek tomu je správa verzií mikroslužieb veľmi zložitým problémom. Jedným z dôkazov môžu byť články ako .
Ak zatiaľ nerozumiete problému, dovoľte mi vysvetliť. Predpokladajme, že váš produkt pozostáva z 10 mikroslužieb. Teraz predpokladajme, že pre každú z týchto mikroslužieb vyjde 1 nová verzia. Iba 1 verzia — dúfam, že sa všetci môžeme zhodnúť, že je to veľmi triviálny a nepodstatný fakt. Teraz sa však pozrime ešte raz na náš produkt. S jednou novou verziou každého komponentu máme teraz 2^10 — alebo 1024 permutácií toho, ako môže byť náš produkt zložený.
Ak ešte stále zostáva nepochopenie, dovoľte mi rozložiť matematiku. Takže máme 10 mikroslužieb, každá dostáva jedno aktualizáciu. To znamená, že dostaneme 2 možné verzie pre každú mikroslužbu (buď starú, alebo novú). Teraz, pre každý z komponentov produktu môžeme použiť ktorúkoľvek z týchto dvoch verzií. Matematicky, to je rovnaké, ako keby sme mali dvojkové číslo z 10 znakov. Povedzme, že 1 — to je nová verzia, a 0 — stará verzia — potom jedna možná permutácia môže byť označená ako 1001000000 — kde 1. a 4. komponent sa aktualizovali, a všetky ostatné nie. Z matematiky vieme, že dvojkové číslo z 10 znakov môže mať 2^10 alebo 1024 hodnôt. Teda potvrdili sme rozsah čísla, s ktorým sa zaoberáme.
Pokračujme v úvahe ďalej — čo sa stane, ak budeme mať 100 mikroslužieb a každá 10 možných verzií? Celá situácia sa stáva veľmi nepríjemnou — teraz máme 10^100 permutácií — a to je obrovské číslo. Napriek tomu preferujem nazvať túto situáciu týmto spôsobom, pretože teraz sa neskrývame za slová ako „kubernetes“, ale čelíme problému tak, ako je.
Prečo ma táto problematika tak fascinuje? Čiastočne preto, že keď som nakoniec pracoval vo svete NLP a AI, veľa sme diskutovali o probléme kombinatorickej explózie niekde pred 5-6 rokmi. Len namiesto verzií sme mali jednotlivé slová, a namiesto produktov sme mali vety a odstavce. A hoci problémy v NLP a AI zostávajú do značnej miery nevyriešené, treba uznať, že za posledných niekoľko rokov sa dosiahol výrazný pokrok. (podľa môjho názoru by pokrok mohol byťoväčší, keby sa ľudia v odvetví trocha menej sústredili na strojové učenie a trocha viac na iné techniky – ale to už je off-topic).
Vrátim sa do sveta DevOps a mikroslužieb. Pred nami stojí obrovský problém, maskujúci sa ako slon v Kunstkammer — veď čo často počujem — „len vezmi Kubernetes a Helm, a všetko bude v poriadku!“ Ale nie, všetko nebude v poriadku, ak to všetko necháme tak. Navyše, analytické riešenie tohto problému sa nezdá byť prijateľné z dôvodu jeho zložitosti. Rovnako ako v NLP, mali by sme sa najprv prístupovať k tejto probléme zúžením vyhľadávacej oblasti — v tomto prípade vylúčením zastaraných permutácií.
Jedna z vecí, ktorá môže pomôcť — minulý rok som písal . Rovnako je dôležité poznamenať, že dobre navrhnutý proces CI/CD veľmi pomáha pri znižovaní variácií. Avšak, súčasný stav v CI/CD nie je dostatočne dobrý na riešenie problému permutácií bez dodatočných nástrojov na sledovanie a evidenciu komponentov.
Čo potrebujeme — je systém experimentov v štádiu integrácie, kde by sme mohli určiť faktor rizika pre každý komponent, a tiež mať 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ť nasledovne:
- Vývojári píšu testy (to je kritický krok — pretože inak nemáme hodnotiaci kriterium — to je ako označovanie dát v strojovom učení).
- Každý komponent (projekt) dostane svoju vlastnú CI systém — tento proces je v súčasnosti dobre prepracovaný, a otázka vytvorenia CI systému pre jediný komponent je vo veľkej miere vyriešená.
- „Inteligentný integračný systém“ zhromažďuje výsledky rôznych CI systémov a spája komponenty projektov do konečného produktu, spúšťa testovanie a nakoniec vypočíta najkratšiu cestu k dosiahnutiu požadovanej funkčnosti produktu na základe existujúcich komponentov a rizikových faktorov. Ak nie je možné vykonať aktualizáciu, tento systém upozorňuje vývojárov na existujúce komponenty a na tom, na ktorom z nich dochádza k chybe. Ešte raz pripomínam, že testovací systém tu má kritickú dôležitosť — pretože integračný systém používa testy ako kritérium hodnotenia.
- CD systém, ktorý potom prijíma dáta z „Inteligentného integračného systému“ a vykonáva samotnú aktualizáciu. Táto fáza uzatvára cyklus.
Zhrnujúci povedané, pre mňa je jednou z najväčších problémov teraz absencia takej „Inteligentnej integračnej“ systému, ktorý by spojil rôzne komponenty do produktu a tým umožnil sledovať, akým spôsobom je produkt v celku zložený. Zaujímajú ma názory komunity na túto tému (spoiler — momentálne pracujem na projekte , ktorý by mohol byť takým inteligentným integračným systémom).
Jedna posledná vec, ktorú chcem spomenúť, — pre mňa nie je monolit prijateľný pre ktorýkoľvek projekt aspoň strednej veľkosti. Mám veľké pochybnosti o pokusoch urýchliť čas realizácie a kvalitu vývoja tým, že sa vrátime k monolitu. Po prvé, monolit má podobný problém riadenia komponentov — medzi rôznymi knižnicami, z ktorých sa skladá, avšak všetko toto nie je tak zjavné a prejavuje sa predovšetkým v čase, ktorý vývojári strácajú. Dôsledkom problému monolitu je faktická nemožnosť vykonávať zmeny v kóde — a extrémne pomalá rýchlosť vývoja.
Mikroslužby zlepšujú situáciu, avšak potom sa mikroslužbová architektúra stretáva s problémom kombinatorického výbuchu v fáze integrácie. Áno, vo všeobecnosti sme presunuli rovnaký problém — z fázy vývoja na fázu integrácie. Avšak, podľa môjho názoru, prístup mikroslužieb stále vedie k lepším výsledkom a tímy dosahujú výsledky rýchlejšie (pravdepodobne najmä kvôli zmenšovaniu veľkosti jednotky vývoja — alebo batch size). Avšak prechod od monolitu k mikroslužbám zatiaľ neposkytol dostatočné zlepšenie procesu — kombinatorický výbuch verzií mikroslužieb je obrovský problém a máme veľký potenciál na zlepšenie situácie, keď sa to začne riešiť.
Zdroj: habr.com
