Tere, Habr! Esitan teie tähelepanu artikli autori tõlge .
Ajal, mil IT-maailm liigub tasapisi mikroteenuste ja Kubernetesi sarnaste tööriistade poole, on üha enam märgata vaid üks probleem. See probleem - mikroteenuste versioonid. Siiski usub IT-ringkond, et praegune olukord on palju parem kui eelmise põlvkonna tehnoloogia. Mikroteenuste versioonide loomine on aga väga keeruline probleem. Selle üheks tõestuseks võivad olla sellised artiklid nagu .
Kui te ikka seda teksti lugedes probleemist aru ei saa, lubage mul selgitada. Oletame, et teie toode koosneb 10 mikroteenusest. Oletame nüüd, et iga sellise mikroteenuse jaoks on välja antud 1 uus versioon. Ainult 1 versioon – ma loodan, et me kõik nõustume, et see on väga tühine ja tähtsusetu fakt. Nüüd aga vaatame veelkord meie toodet. Iga komponendi ühe uue versiooniga on meil nüüd 2^10 või 1024 permutatsiooni selle kohta, kuidas meie toodet saab koostada.
Kui on ikka arusaamatus, lubage mul matemaatika lahti kirjutada. Seega on meil 10 mikroteenust, millest igaüks saab ühe värskenduse. See tähendab, et iga mikroteenuse (kas vana või uus) jaoks saame 2 võimalikku versiooni. Nüüd saame iga tootekomponendi jaoks kasutada üht neist kahest versioonist. Matemaatiliselt on see sama, kui meil oleks 10-kohaline kahendnumber. Näiteks oletame, et 1 on uus versioon ja 0 on vana versioon – siis võib ühe võimaliku permutatsiooni tähistada kui 1001000000 – kus 1. ja 4. komponenti uuendatakse, kõiki teisi aga mitte. Matemaatikast teame, et 10-kohalisel kahendarvul võib olla 2^10 või 1024 väärtust. See tähendab, et oleme kinnitanud selle numbri ulatuse, millega tegeleme.
Jätkame oma mõttekäiku edasi – mis saab siis, kui meil on 100 mikroteenust ja igal neist on 10 võimalikku versiooni? Kogu olukord muutub üsna ebameeldivaks – meil on nüüd 10^100 permutatsiooni – mis on tohutu arv. Eelistan seda olukorda siiski niimoodi sildistada, sest nüüd ei peitu me enam sõnade taha nagu “kubernetes”, vaid vaatame probleemile vastu sellisena, nagu see on.
Miks ma olen sellest probleemist nii lummatud? Osaliselt seetõttu, et olles varem NLP ja AI maailmas töötanud, arutasime umbes 5-6 aastat tagasi palju kombinatoorse plahvatuse probleemi. Ainult versioonide asemel olid meil üksikud sõnad ning toodete asemel laused ja lõigud. Ja kuigi NLP ja AI probleemid on suures osas lahendamata, tuleb tunnistada, et viimastel aastatel on tehtud märkimisväärseid edusamme. (minu arvates võiks edusamme tehaоParem oleks, kui tööstuse inimesed pööraksid natuke vähem tähelepanu masinõppele ja natuke rohkem teistele tehnikatele – aga see on juba teemaväline).
Tuleme tagasi DevOpsi ja mikroteenuste maailma. Me seisame silmitsi tohutu probleemiga, maskeerume Kunstkameras elevandiks - sest sageli kuulen, et "võta lihtsalt kubernetes ja tüür ja kõik saab korda!" Aga ei, kõik ei lähe hästi, kui kõik jääb nii nagu on. Pealegi ei tundu selle probleemi analüütiline lahendus selle keerukuse tõttu vastuvõetav. Nagu NLP puhul, peaksime esmalt sellele probleemile lähenema otsingu ulatuse kitsendamisega – antud juhul aegunud permutatsioonide kõrvaldamisega.
Üks asi, mis võib aidata, on see, mida ma eelmisel aastal kirjutasin . Samuti on oluline märkida, et hästi läbimõeldud CI/CD protsess aitab oluliselt vähendada variatsioone. CI/CD praegune olukord ei ole aga piisavalt hea, et lahendada permutatsioonide probleemi ilma täiendavate arvestus- ja jälgimiskomponentide tööriistadeta.
Vajame integreerimisetapis katsetamissüsteemi, kus saame määrata iga komponendi riskiteguri, samuti on olemas automatiseeritud protsess erinevate komponentide värskendamiseks ja testimiseks ilma operaatori sekkumiseta – et näha, mis töötab ja mis mitte.
Selline katsete süsteem võiks välja näha järgmine:
- Arendajad kirjutavad teste (see on kriitiline etapp – sest muidu pole meil hindamiskriteeriumit – see on nagu andmete märgistamine masinõppes).
- Iga komponent (projekt) saab oma CI-süsteemi - see protsess on nüüd hästi arenenud ja ühe komponendi jaoks CI-süsteemi loomise küsimus on suures osas lahendatud
- “Nutikas integratsioonisüsteem” kogub kokku erinevate CI-süsteemide tulemused ja komplekteerib komponendiprojektid lõpptooteks, viib läbi testimise ja lõpuks arvutab olemasolevate komponentide ja riskitegurite põhjal välja lühima tee soovitud toote funktsionaalsuse saavutamiseks. Kui värskendamine pole võimalik, teavitab see süsteem arendajaid olemasolevatest komponentidest ja sellest, millised neist vea põhjustavad. Siin on taaskord kriitilise tähtsusega testisüsteem – kuna integratsioonisüsteem kasutab hindamiskriteeriumina teste.
- CD-süsteem, mis võtab seejärel Smart Integration Systemilt andmeid ja teostab värskenduse otse. See etapp lõpetab tsükli.
Kokkuvõtteks võib öelda, et minu jaoks on praegu üheks suurimaks probleemiks sellise “Targa integratsioonisüsteemi” puudumine, mis seoks erinevad komponendid tooteks ja võimaldaks seeläbi jälgida, kuidas toode tervikuna kokku pannakse. Mind huvitavad kogukonna mõtted selle kohta (spoiler – töötan praegu projekti kallal , millest võib saada nii nutikas integratsioonisüsteem).
Viimane asi, mida tahan mainida, on see, et minu jaoks ei ole monoliit vastuvõetav ühegi isegi keskmise suurusega projekti jaoks. Minus tekitavad suurt skeptitsismi katsed kiirendada teostusaega ja arenduskvaliteeti monoliidi juurde naasmisega. Esiteks on monoliidil sarnane komponentide haldamise probleem - erinevate teekide hulgas, millest see koosneb, pole see kõik aga nii märgatav ja avaldub peamiselt arendajate ajakulus. Monoliidi probleemi tagajärjeks on virtuaalne võimatus koodis muudatusi teha – ja äärmiselt aeglane arenduskiirus.
Mikroteenused parandavad olukorda, kuid siis seisab mikroteenuste arhitektuur integreerimisetapis silmitsi kombinatoorse plahvatuse probleemiga. Jah, üldiselt oleme viinud sama probleemi arendusetapist integratsioonifaasi. Kuid minu hinnangul viib mikroteenuste lähenemine siiski paremate tulemusteni ning meeskonnad saavutavad tulemusi kiiremini (ilmselt peamiselt tänu arendusüksuse suuruse vähenemisele - või partii suurus). Üleminek monoliidilt mikroteenustele ei ole aga protsessi veel piisavalt paranenud – mikroteenuste versioonide kombinatoorne plahvatus on suur probleem ja meil on palju potentsiaali selle lahendamise käigus olukorda parandada.
Allikas: www.habr.com