Zdravo, Habr! Predstavljam vašoj pažnji autorski prevod članka .
U vrijeme kada se IT svijet postepeno kreće ka mikroservisima i alatima poput Kubernetesa, samo jedan problem postaje sve primjetniji. Ovaj problem - mikroservisne verzije. Ipak, IT zajednica smatra da je trenutna situacija mnogo bolja nego prethodne generacije tehnologija. Međutim, verzioniranje mikroservisa je vrlo složen problem. Jedan dokaz za to mogu biti članci poput .
Ako i dalje ne razumete problem čitajući ovaj tekst, dozvolite mi da objasnim. Recimo da se vaš proizvod sastoji od 10 mikroservisa. Sada pretpostavimo da je puštena 1 nova verzija za svaki od ovih mikroservisa. Samo 1 verzija - nadam se da se svi možemo složiti da je ovo vrlo trivijalna i beznačajna činjenica. Sada, međutim, pogledajmo još jednom naš proizvod. Sa samo jednom novom verzijom svake komponente, sada imamo 2^10 - ili 1024 permutacije načina na koji se naš proizvod može sastaviti.
Ako i dalje postoji nesporazum, dozvolite mi da razbijem matematiku. Dakle, imamo 10 mikroservisa, od kojih svaka prima jedno ažuriranje. To jest, dobijamo 2 moguće verzije za svaki mikroservis (staru ili novu). Sada, za svaku od komponenti proizvoda, možemo koristiti bilo koju od ove dvije verzije. Matematički, to je isto kao da imamo binarni broj od 10 cifara. Na primjer, recimo da je 1 nova verzija, a 0 stara verzija - tada se jedna moguća permutacija može označiti kao 1001000000 - gdje su 1. i 4. komponenta ažurirane, a sve ostale nisu. Iz matematike znamo da 10-cifreni binarni broj može imati 2^10 ili 1024 vrijednosti. Odnosno, mi smo potvrdili skalu broja sa kojima imamo posla.
Nastavimo dalje naše razmišljanje - šta će se dogoditi ako imamo 100 mikroservisa i svaki ima 10 mogućih verzija? Cijela situacija postaje prilično neugodna - sada imamo 10^100 permutacija - što je ogroman broj. Ipak, radije bih ovu situaciju označio na ovaj način, jer se sada više ne skrivamo iza riječi poput „kubernetes“, već se suočavamo s problemom kakav jeste.
Zašto sam toliko fasciniran ovim problemom? Djelomično zato što smo, nakon što smo prethodno radili u svijetu NLP-a i AI-a, mnogo raspravljali o problemu kombinatorne eksplozije prije otprilike 5-6 godina. Samo umjesto verzija imali smo pojedinačne riječi, a umjesto proizvoda rečenice i pasuse. I iako problemi NLP-a i AI ostaju uglavnom neriješeni, mora se priznati da je u posljednjih nekoliko godina napravljen značajan napredak (po mom mišljenju, napredak bi se mogao postićiоBilo bi bolje kada bi ljudi u industriji posvetili malo manje pažnje mašinskom učenju, a malo više drugim tehnikama – ali ovo je već van teme).
Vratimo se u svijet DevOps-a i mikroservisa. Suočeni smo sa ogromnim problemom, maskiranjem u slona u Kunstkameri - jer ono što često čujem je "samo uzmi kubernete i kormilo, i sve će biti u redu!" Ali ne, neće sve biti u redu ako sve ostane kako jeste. Štaviše, analitičko rješenje ovog problema ne izgleda prihvatljivo zbog njegove složenosti. Kao iu NLP-u, ovom problemu prvo treba pristupiti sužavanjem opsega pretraživanja – u ovom slučaju, eliminacijom zastarjelih permutacija.
Jedna od stvari koja bi mogla pomoći je nešto što sam napisao prošle godine . Također je važno napomenuti da dobro osmišljen CI/CD proces uvelike pomaže u smanjenju varijacija. Međutim, trenutno stanje sa CI/CD nije dovoljno dobro da riješi problem permutacija bez dodatnih alata za komponente računovodstva i praćenja.
Ono što nam je potrebno je sistem eksperimentisanja u fazi integracije, gde možemo da odredimo faktor rizika za svaku komponentu, a takođe imamo automatizovan proces ažuriranja različitih komponenti i testiranja bez intervencije operatera – da vidimo šta radi, a šta ne.
Takav sistem eksperimenata bi mogao izgledati ovako:
- Programeri pišu testove (ovo je kritična faza - jer inače nemamo kriterij evaluacije - to je kao označavanje podataka u strojnom učenju).
- Svaka komponenta (projekat) dobija svoj CI sistem - ovaj proces je sada dobro razvijen, a pitanje kreiranja CI sistema za jednu komponentu je u velikoj meri rešeno
- „Sistem pametne integracije“ prikuplja rezultate različitih CI sistema i sastavlja projekte komponenti u finalni proizvod, pokreće testiranje i konačno izračunava najkraći put do dobijanja željene funkcionalnosti proizvoda na osnovu postojećih komponenti i faktora rizika. Ako ažuriranje nije moguće, ovaj sistem obavještava programere o postojećim komponentama i koja od njih uzrokuje grešku. Još jednom, sistem testiranja je ovde od kritične važnosti – pošto sistem integracije koristi testove kao kriterijum evaluacije.
- CD sistem, koji zatim prima podatke od Smart Integration System i direktno vrši ažuriranje. Ova faza završava ciklus.
Da rezimiram, za mene je jedan od najvećih problema sada nedostatak takvog “Smart Integration System” koji bi povezao različite komponente u proizvod i tako vam omogućio da pratite kako je proizvod u cjelini sastavljen. Zanimalo bi me mišljenje zajednice o ovome (spoiler - trenutno radim na projektu , koji može postati tako pametan sistem integracije).
Posljednja stvar koju želim napomenuti je da za mene monolit nije prihvatljiv ni za jedan projekat čak i srednje veličine. Za mene pokušaji da se ubrza vrijeme implementacije i kvalitet razvoja vraćanjem u monolit izazivaju veliki skepticizam. Prvo, monolit ima sličan problem upravljanja komponentama - među raznim bibliotekama od kojih se sastoji, međutim, sve to nije toliko uočljivo i manifestuje se prvenstveno u vremenu koje programeri troše. Posljedica monolitnog problema je virtualna nemogućnost izmjene koda - i izuzetno spora brzina razvoja.
Mikroservis poboljšava situaciju, ali tada se mikroservisna arhitektura suočava sa problemom kombinatorne eksplozije u fazi integracije. Da, generalno, isti problem smo prešli iz faze razvoja u fazu integracije. Međutim, po mom mišljenju, pristup mikroservisima i dalje vodi do boljih rezultata, a timovi brže postižu rezultate (vjerovatno uglavnom zbog smanjenja veličine razvojne jedinice - ili veličina serije). Međutim, prelazak s monolita na mikroservise još uvijek nije dovoljno unaprijedio proces - kombinatorna eksplozija verzija mikroservisa je ogroman problem, a mi imamo puno potencijala da poboljšamo situaciju dok je rješavamo.
izvor: www.habr.com