Mikroteenused — versioonide kombinatoorne plahvatus

Tere, Habr! Esitleme teile autoriteetse tõlke artiklit Mikroteenused – kombinatoorne versioonide plahvatus.

Aegadel, mil IT-maailm üha enam mikroteenustele ja sellistele tööriistadele nagu Kubernetes üle läheb, muutub ühe probleem järjest silmatorkavamaks. See probleem on kombinatoorne plahvatus mikroteenuste versioonidest. Sellegipoolest arvab IT-kogukond, et tänane olukord on oluliselt parem kui „Sõltuvuse põrgu“ eelmistest tehnoloogiate põlvkondadest. Siiski on mikroteenuste versioonide haldamine üsna keeruline probleem. Üheks tõendiks selle kohta võivad olla artiklid nagu „Tooge mulle tagasi mu monoliit“.

Kui te ei saa selle teksti lugedes ikka veel probleemist aru, siis laske mul selgitada. Oletame, et teie toode koosneb 10 mikroteenusest. Nüüd oletame, et igaühele neist mikroteenustest tuleb 1 uus versioon. Ainult 1 versioon – loodan, et me kõik saame kokku leppida, et see on üsna triviaalne ja märkamatu fakt. Kuid vaatame nüüd meie toodet veel kord. Iga komponendi uue versiooniga on meil nüüd 2^10 – ehk 1024 permutatsiooni, kuidas meie toodet kokku panna.

Kui endiselt on arusaamatus, laske mul matemaatikat lahti seletada. Nii et meil on 10 mikroteenust, igaühel uus uuendus. See tähendab, et saame 2 võimaliku versiooni igale mikroteenusele (kas vana või uus). Nüüd saame iga toote komponenti kasutama nende kahe versiooni sõltumatu kombinatsiooni. Matemaatiliselt on see sama mis terane number 10 numbriga. Näiteks, ütleme, et 1 on uus versioon ja 0 vana versioon – siis võib üks võimalik permutatsiooni olla tähistatud kui 1001000000 – kus 1. ja 4. komponent on uuendatud, samas kui kõik teised pole. Matemaatikast teame, et terane number 10 numbriga võib omada 2^10 või 1024 väärtust. See tähendab, et me oleme kinnitanud, kui suur on number, millega tegeleme.

Jätkame mõtisklemist – mis juhtub, kui meil on 100 mikroteenust ja igal ühel 10 võimalikku versiooni? Kogu olukord muutub üsna ebameeldivaks – nüüd on meil 10^100 permutatsiooni – see on tohutu number. Sellegipoolest eelistan ma seda olukorda täpselt nii nimetada, sest nüüd ei peida me end selliste sõnade taha nagu „kubernetes“, vaid kohtume probleemiga silmitsi, nagu see on.

Miks mind see probleem nii palju paelub? Osaliselt seetõttu, et töötasin varem NLP ja AI vallas, arutasime me combinatoorse plahvatuse probleemi umbes 5-6 aastat tagasi. Ainult et versioonide asemel olid meil eraldi sõnad ja toodete asemel laused ning lõigud. Kuigi NLP ja AI probleemid jäävad suuresti lahendamata, tuleb tunnistada, et viimase paarina aasta jooksul on tehtud märkimisväärset edusammu. (minu arvates oleks edusamm olnudilotkasuurem, kui tööstuse inimesed oleksid veidi vähem tähelepanu pööranud masinõppele ja veidi rohkem teistele tehnikatele — aga see on juba off-topic).

Jõuan tagasi DevOpsi ja mikroteenuste maailma. Meie ees seisab tohutu probleem, mis peidab end nagu elevant Kunstkamera — sest mida ma sageli kuulen — "võta lihtsalt kubernetes ja helm ning kõik on korras!" Aga ei, kõik ei ole korras, kui jätta kõik nagu on. Veelgi enam, selle probleemi analüütiline lahendus ei tundu vastuvõetav selle keerukuse tõttu. Nagu NLP-s, tuleb meil kõigepealt läheneda sellele probleemile otsingu ulatuse kitsendamise kaudu — antud juhul vanade permutatsioonide välja jätmise kaudu.

Üks asi, mis võiks aidata — kirjutasin eelmisel aastal vajadusest hoida minimaalne hajusus klientidele väljastatud versioonide vahel.Samuti on oluline märkida, et hästi kujundatud CI/CD protsess aitab tõesti variatsioone vähendada. Siiski, tänane CI/CD olukord ei ole piisavalt hea permutatsioonide probleemi lahendamiseks ilma täiendava komponentide jälgimise ja arvestamise tööriistade kasutamiseta.

Mida me vajame, on eksperimentide süsteem integreerimise etapis, kus võiksime määratleda riskiteguri iga komponendi kohta ning samuti omada automatiseeritud protsessi erinevate komponentide värskendamiseks ja testimiseks ilma operaatori sekkumiseta — et näha, mis töötab ja mis mitte.

Selline eksperimentide süsteem võiks välja näha järgmine:

1. Arendajad kirjutavad teste (see on kriitiline etapp — sest muidu ei ole meil hindamiskriteeriumit — see on just nagu andmete märgistamine masinõppes).
2. Igal komponendil (projekt) on oma CI süsteem — see protsess on täna hästi välja kujundatud ja küsimus CI süsteemi loomisel ühele komponendile on suurel määral lahendatud.
3. „Nutikas integreerimissüsteem“ kogub erinevate CI süsteemide tulemusi ja koondab projekti komponente lõplikku toodet, käivitab testimise ning arvutab lõpuks välja kõige lühemad teed toote vajaliku funktsionaalsuse saavutamiseks olemasolevate komponentide ja riskifaktorite alusel. Kui uuendamine ei ole võimalik, teavitab see süsteem arendajaid olemasolevatest komponentidest ja millisel neist viga esineb. Kordan veel kord, et testimisüsteem on siin kriitilise tähtsusega — kuna integreerimissüsteem kasutab teste hindamiskriteeriumina.
4. CD süsteem, mis seejärel saadab andmed „Nutika integreerimissüsteemist“ ja viib läbi otsese uuendamise. See etapp lõpetab tsükli.

Kokkuvõttes on minu jaoks üks suurimaid probleeme praegu „Nutika integreerimissüsteemi“ puudumine, mis siduks erinevaid komponente tooteks ja võimaldaks seeläbi jälgida, kuidas toode tervikuna on koostatud. Mind huvitavad kogukonna mõtted selle kohta (spoiler — töötan praegu projekti kallal Reliza, mis võib saada selliseks nutikaks integreerimissüsteemiks).

Viimane asjaolu, mille tahaksin mainida, on see, et minu jaoks ei ole monoliit igasuguste keskmise suurusega projektide jaoks vastuvõetav. Mind paneb suur skeptitsism tagasi tulema monoliidi juurde, et kiirendada rakendamise aega ja arenduse kvaliteeti. Esiteks on monoliidil sarnane probleem komponentide haldamisega — erinevate teekide seas, millest see koosneb, kuid kogu see ei ole nii märgatav ja avaldub eelkõige arendajate kulutatud ajal. Monoliidi probleemid toovad endaga kaasa muudatuste tegemise tegeliku võimatuse — ja äärmiselt aeglase arendusprotsessi.

Mikroteenused parandavad olukorda, kuid seejärel seisab mikroteenuste arhitektuur silmitsi kombinatoorse plahvatuse probleemiga integreerimise etapis. Jah, me oleme põhimõtteliselt sama probleemi nihutanud — arendusetapilt integreerimisetapile. Siiski arvan, et mikroteenuste lähenemine viib siiski paremate tulemusteni ja meeskonnad saavutavad tulemusi kiiremini (tõenäoliselt peamiselt arenduse väiksemate üksuste tõttu — või partii suurus). Siiski, üleminek monoliidilt mikroteenustele ei ole seni andnud piisavat paranemist protsessis — mikroteenuste versioonide kombinatoorne plahvatus on tohutu probleem, ja meil on suur potentsiaal olukorra parandamiseks selle lahendamise käigus.

Allikas: habr.com