Pozdrav, Habr! Predstavljam vašoj pozornosti autorski prijevod članka .
U vrijeme kada se IT svijet postupno kreće prema mikroservisima i alatima poput Kubernetesa, samo jedan problem postaje sve uočljiviji. Ovaj problem - verzije mikroservisa. Ipak, IT zajednica smatra da je trenutno stanje puno bolje od prethodne generacije tehnologija. Međutim, verzioniranje mikroservisa vrlo je složen problem. Jedan od dokaza za to mogu biti članci poput .
Ako čitajući ovaj tekst i dalje ne razumijete problem, dopustite mi da objasnim. Recimo da se vaš proizvod sastoji od 10 mikroservisa. Sada pretpostavimo da je izdana 1 nova verzija za svaku od ovih mikrousluga. 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. Uz samo jednu novu verziju svake komponente, sada imamo 2^10 - ili 1024 permutacije kako se naš proizvod može sastaviti.
Ako još uvijek postoji bilo kakav nesporazum, dopustite mi da pojasnim matematiku. Dakle, imamo 10 mikroservisa, svaki prima jedno ažuriranje. Odnosno, dobivamo 2 moguće verzije za svaku mikroservis (ili 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 znamenki. 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-znamenkasti binarni broj može imati 2^10 ili 1024 vrijednosti. Odnosno, potvrdili smo razmjere broja s kojim se radi.
Nastavimo s razmišljanjem dalje – što ć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”, nego se suočavamo s problemom kakav jest.
Zašto sam toliko fasciniran ovim problemom? Djelomično zato što smo, budući da smo prethodno radili u svijetu NLP-a i umjetne inteligencije, puno raspravljali o problemu kombinatorne eksplozije prije otprilike 5-6 godina. Samo što smo umjesto verzija imali pojedinačne riječi, a umjesto proizvoda rečenice i odlomke. I premda problemi NLP-a i umjetne inteligencije ostaju uglavnom neriješeni, mora se priznati da je u posljednjih nekoliko godina postignut značajan napredak (po mom mišljenju, napredak bi se mogao napravitiоBilo bi bolje kada bi ljudi u industriji malo manje pažnje obraćali na strojno učenje, a malo više na druge tehnike – ali to je već off-topic).
Vratimo se u svijet DevOpsa i mikroservisa. Suočeni smo s velikim problemom maskiranja u slona u Kunstkameri - jer ono što često čujem je “samo uzmi kubernetes i kormilo, i sve će biti u redu!” Ali ne, neće sve biti u redu ako sve ostane kako jest. Štoviše, analitičko rješenje ovog problema ne čini se prihvatljivim zbog njegove složenosti. Kao i u NLP-u, prvo bismo trebali pristupiti ovom problemu sužavanjem opsega pretraživanja - u ovom slučaju, uklanjanjem 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 stvari s CI/CD nije dovoljno dobro za rješavanje problema permutacija bez dodatnih alata za računovodstvo i praćenje komponenti.
Ono što nam treba je sustav eksperimentiranja u fazi integracije, gdje možemo odrediti faktor rizika za svaku komponentu, a također imamo automatizirani proces ažuriranja različitih komponenti i testiranja bez intervencije operatera – da vidimo što radi, a što ne.
Takav sustav eksperimenata mogao bi izgledati ovako:
- Programeri pišu testove (ovo je kritična faza - jer inače nemamo kriterij ocjenjivanja - to je kao označavanje podataka u strojnom učenju).
- Svaka komponenta (projekt) dobiva svoj vlastiti CI sustav - ovaj proces je sada dobro razvijen, a problem kreiranja CI sustava za pojedinačnu komponentu uvelike je riješen
- “Pametni integracijski sustav” prikuplja rezultate različitih CI sustava i sastavlja projekte komponenti u konačni proizvod, provodi testiranje i na kraju izračunava najkraći put do dobivanja željene funkcionalnosti proizvoda na temelju postojećih komponenti i faktora rizika. Ako ažuriranje nije moguće, ovaj sustav obavještava programere o postojećim komponentama i koja od njih uzrokuje pogrešku. Još jednom, testni sustav je ovdje od ključne važnosti - budući da integracijski sustav koristi testove kao kriterij ocjenjivanja.
- CD sustav, koji zatim prima podatke od Smart Integration System i izravno vrši ažuriranje. Ova faza završava ciklus.
Ukratko, za mene je sada jedan od najvećih problema nedostatak takvog "Smart Integration System" koji bi povezivao različite komponente u proizvod i tako vam omogućio praćenje kako je proizvod u cjelini sastavljen. Zanimat će me mišljenja zajednice o ovome (spojler - trenutno radim na projektu , koji može postati tako pametan integracijski sustav).
Posljednja stvar koju želim spomenuti je da za mene monolit nije prihvatljiv ni za jedan projekt čak ni srednje veličine. Kod mene veliki skepticizam izazivaju pokušaji da se ubrza vrijeme implementacije i kvaliteta razvoja povratkom na monolit. Prvo, monolit ima sličan problem upravljanja komponentama - među raznim bibliotekama od kojih se sastoji, međutim, sve to nije toliko vidljivo i očituje se prvenstveno u vremenu koje programeri provode. Posljedica problema monolita je virtualna nemogućnost unošenja izmjena u kod - i izuzetno spora brzina razvoja.
Mikroservisi poboljšavaju situaciju, ali tada se arhitektura mikroservisa suočava s problemom kombinatorne eksplozije u fazi integracije. Da, općenito, premjestili smo isti problem iz faze razvoja u fazu integracije. Međutim, po mom mišljenju, pristup mikroservisima još uvijek dovodi do boljih rezultata, a timovi brže postižu rezultate (vjerojatno uglavnom zbog smanjenja veličine razvojne jedinice - ili veličina serije). Međutim, prelazak s monolita na mikroservise još nije dovoljno unaprijedio proces - kombinatorna eksplozija verzija mikroservisa veliki je problem, a mi imamo mnogo potencijala da poboljšamo situaciju dok je rješavamo.
Izvor: www.habr.com