🥇Mikroteenused — versioonide kombinatoorne plahvatus

Tere, Habr! Esitleme teile autori tõlgitud artiklit Mikroteenused – kombinatoorne versioonide plahvatus.

Aegadel, mil IT maailm üha enam mikroteenustele ja sellistele tööriistadele nagu Kubernetes üle läheb, muutub üha silmatorkavamaks üks probleem. See probleem on kombinatoorne plahvatus mikroteenuste versioonides. Siiski usub IT kogukond, et tänane olukord on oluliselt parem kui «Sõltuvuse põrgu» eelmistest tehnoloogiate põlvkondadest. Siiski on mikroteenuste versioonide haldamine keeruline probleem. Ühe tõendina selle kohta võivad teenida artiklid, nagu «Tooge mulle tagasi mu monoliit».

Kui te lugedes seda teksti ei mõista probleemi, lubage mul seda selgitada. Oletame, et teie toode koosneb 10 mikroteenusest. Nüüd oletame, et igaühele neist mikroteenustest tuleb välja 1 uus versioon. Ainult 1 versioon – loodan, et me kõik saame kokku leppida, et see on vägagi triviaalne ja ebaoluline fakt. Nüüd vaatame aga uuesti meie toodet. Üheainsa uue versiooniga iga komponendi jaoks oleme nüüd omandanud 2^10 – ehk 1024 permutatsiooni, kuidas meie toodet kokku panna.

Kui teie arusaam pole ikka veel selge, lubage mul matemaatika lahti harutada. Nii et meil on 10 mikroteenust, igaüks saab ühe uuenduse. See tähendab, et iga mikroteenuse kohta on meil 2 võimalikku versiooni (kas vana või uus). Nüüd, iga komponendi puhul saame kasutada kas ühte neist kahest versioonist. Matemaatiliselt on see sama, kui meil oleks 10-kohaline binaarnumber. Näiteks oletame, et 1 on uus versioon ja 0 on vana versioon – siis võib ühte permutatsiooni tähistada kui 1001000000 – kus 1. ja 4. komponent on uuendatud, ja kõik teised mitte. Matemaatikast teame, et 10-kohaline binaarnumber võib omada 2^10 ehk 1024 erinevat väärtust. See tähendab, et oleme kinnitanud, millega tegeleda.

Jätkame arutlemist edasi – mis juhtub, kui meil on 100 mikroteenust ja igal neist 10 võimalikku versiooni? Kogu olukord muutub väga ebameeldivaks – nüüd on meil 10^100 permutatsiooni – ja see on tohutu number. Siiski eelistan ma selle olukorra nii nimetada, sest nüüd me ei peida end selliste sõnade nagu «kubernetes» taha, vaid kohtume probleemiga otse.

Miks see probleem mind nii paelub? Osaliselt seetõttu, et töötades varem NLP ja AI maailmas, arutasime me palju kombinatoorse plahvatuse probleemi umbes 5–6 aastat tagasi. Ainult et versioonide asemel olid meil eraldi sõnad ja toodete asemel lõigud ja paragrahvid. Ja kuigi NLP ja AI probleemid jäävad suures osas lahendamata, tuleb tunnistada, et viimase paari aasta jooksul on saavutatud märkimisväärne edusamm (minu arvates oleks edusamm võinud olla suurem, kui valdkonna inimesed oleksid natuke vähem tähelepanu pööranud masinõppele ja natuke rohkem teistele tehnikatele – aga see on juba off-topic).oTagasi DevOps ja mikroteenuste maailma. Meie ees seisab tohutu probleem, mis varjab end nagu elevant Kunstkambris – sest sageli kuuleme: «võta lihtsalt kubernetes ja helm, ja kõik läheb hästi!» Aga ei, kõik ei lähe hästi, kui me kõik jätame endise olukorra. Veelgi enam, selle probleemi analüütiline lahendus ei tundu olevat aktsepteeritav keerukuse tõttu. Nii nagu NLP-s, peaksime ka me enne selle probleemi lahendamist lähenema otsinguala kitsendamisega – sel korral ajalooliste permutatsioonide välistamise kaudu.

Üks asi, mis võib aidata – kirjutasin mullu

vaja hoida minimaalset kõikumist klientide jaoks avaldatud versioonide vahel . Oluline on märkida, et hästi läbi mõeldud CI/CD protsess aitab samuti variatsioone vähendada. Siiski ei ole tänane CI/CD olukord piisavalt hea, et lahendada permutatsioonide probleem ilma täiendava komponentide jälgimise ja arvestamise tööriistadeta.Mida me vajame – on katsetuste süsteem integreerimise etapis, kus saaksime määrata riskifaktori iga komponendi kohta, samuti omada automatiseeritud erinevate komponentide uuendamise ja testimise protsessi ilma operaatori sekkumiseta – et näha, mis töötab ja mis mitte.

Selline katsetuste süsteem võiks välja näha nii:

Arendajad kirjutavad teste (see on kriitiline etapp – sest vastasel korral pole meil hindamisnäitajat – see on just nagu andmete märgistus masinõppes).

Igal komponendil (projekt) on oma CI süsteem – see protsess on tänapäeval hästi arenenud ja küsimus CI süsteemi loomise kohta üheainsa komponendi jaoks on suures osas lahendatud.
Iga komponent (projekt) saab oma isikliku CI-süsteemi - see protsess on täna hästi välja töötatud ja küsimus CI-süsteemi loomise kohta üheainsa komponendi jaoks on suures osas lahendatud.
«Tarkussüsteem» kogub kokku erinevate CI-süsteemide tulemused ja koostab komponentprojektid lõplikuks tooteks, käivitab testimise ja arvutab lõpuks välja lühima tee vajaliku toote funktsionaalsuse saavutamiseks, lähtudes olemasolevatest komponentidest ja riskiteguritest. Kui uuendust ei saa teostada, teavitab see süsteem arendajaid olemasolevatest komponentidest ja milles tekib viga. Kordan veel kord, et testide süsteem on siin kriitilise tähtsusega — kuna integreerimissüsteem kasutab teste hindamiskriteeriumina.
CD-süsteem, mis seejärel saab andmeid «Tarkussüsteemist» ja teostab otse uuenduse. See etapp lõpetab tsükli.

Kokkuvõtteks, üks suurimaid probleeme minu jaoks praegu on sellise «Tarkussüsteemi» puudumine, mis ühendaks erinevad komponendid tooteks ja seega võimaldaks jälgida, kuidas toode üldiselt kokku on pandud. Mind huvitavad kogukonna mõtted selle kohta (spooiler — praegu töötan projekti Reliza, mis võib saada selliseks tarkussüsteemiks).

Viimane asi, mida tahan mainida, on see, et minu jaoks ei ole monoliit mis tahes keskmise suurusega projekti jaoks vastuvõetav. Olen suur skeptik katsetes kiirendada tegevusaega ja arenduse kvaliteeti, naastes monoliidi juurde. Esiteks, monoliidil on sarnane probleem komponentide haldamise osas — erinevate raamatukogude seas, millest see koosneb, kuid kõik see ei ole nii märgatav ja avaldub eelkõige ajas, mille arendajad kulutavad. Monoliidi probleemide tagajärg on tegelik koodimuudatuste võimatus — ja äärmiselt aeglane arenduskiirus.

Mikroteenuseid ühendavad probleemid, kuid seejärel seisab mikroteenuste arhitektuur silmitsi kombinatoorse plahvatuse probleemiga integreerimise etapis. Jah, oleme põhimõtteliselt viinud sama probleemi arenduselt integreerimise etapile. Kuid minu arvates toob mikroteenuste lähenemine siiski paremaid tulemusi ning meeskonnad saavutavad tulemusi kiiremini (tõenäoliselt peamiselt seetõttu, et arenduse yksuse suurus on vähenenud — või batch size). Siiski ei ole üleminek monoliidilt mikroteenustele veel tooteprotsessi piisavalt parandanud — mikroteenuste versioonide kombinatoorne plahvatus on tohutu probleem ning meil on suur potentsiaal olukorra parendamiseks selle lahendamisel.

Allikas: habr.com