Bună, Habr! Vă prezint atenției traducerea articolului de către autor .
Într-un moment în care lumea IT se îndreaptă treptat către microservicii și instrumente precum Kubernetes, o singură problemă devine din ce în ce mai vizibilă. Această problemă - versiuni de microservicii. Totuși, comunitatea IT consideră că situația actuală este mult mai bună decât generația anterioară de tehnologii. Cu toate acestea, versiunea microserviciilor este o problemă foarte complexă. O dovadă în acest sens pot fi articole precum .
Dacă tot nu înțelegeți problema citind acest text, permiteți-mi să vă explic. Să presupunem că produsul dvs. este format din 10 microservicii. Acum să presupunem că este lansată o versiune nouă pentru fiecare dintre aceste microservicii. Doar 1 versiune - sper că putem fi cu toții de acord că acesta este un fapt foarte banal și nesemnificativ. Acum, însă, să aruncăm o altă privire asupra produsului nostru. Cu o singură versiune nouă a fiecărei componente, avem acum 1^2 - sau 10 permutări ale modului în care poate fi compus produsul nostru.
Dacă există încă vreo neînțelegere, permiteți-mă să descompun matematica. Deci avem 10 microservicii, fiecare primind o actualizare. Adică obținem 2 versiuni posibile pentru fiecare microserviciu (fie vechi, fie nou). Acum, pentru fiecare dintre componentele produsului, putem folosi oricare dintre aceste două versiuni. Din punct de vedere matematic, este la fel ca și cum am avea un număr binar de 10 cifre. De exemplu, să presupunem că 1 este versiunea nouă, iar 0 este versiunea veche - atunci o posibilă permutare poate fi notată ca 1001000000 - unde componentele 1 și 4 sunt actualizate, iar toate celelalte nu. Din matematică știm că un număr binar de 10 cifre poate avea 2^10 sau 1024 de valori. Adică am confirmat amploarea numărului cu care avem de-a face.
Să continuăm raționamentul – ce se va întâmpla dacă avem 100 de microservicii și fiecare are 10 versiuni posibile? Întreaga situație devine destul de neplăcută - acum avem 10^100 de permutări - care este un număr uriaș. Cu toate acestea, prefer să etichetez această situație astfel, pentru că acum nu ne mai ascundem în spatele unor cuvinte precum „kubernetes”, ci mai degrabă ne confruntăm cu problema așa cum este.
De ce sunt atât de fascinat de această problemă? Parțial pentru că, după ce am lucrat anterior în lumea NLP și AI, am discutat mult problema exploziei combinatorii în urmă cu aproximativ 5-6 ani. Doar în loc de versiuni aveam cuvinte individuale, iar în loc de produse aveam propoziții și paragrafe. Și, deși problemele NLP și AI rămân în mare parte nerezolvate, trebuie să admitem că s-au înregistrat progrese semnificative în ultimii ani. (După părerea mea, s-ar putea face progreseоAr fi mai bine dacă oamenii din industrie ar acorda puțin mai puțină atenție învățării automate și puțin mai mult altor tehnici - dar acest lucru este deja în afara subiectului).
Să revenim în lumea DevOps și a microserviciilor. Ne confruntăm cu o problemă uriașă, mascarându-ne ca un elefant în Kunstkamera - pentru că ceea ce aud adesea este „doar luați kubernetes și cârma, și totul va fi bine!” Dar nu, totul nu va fi bine dacă totul este lăsat așa cum este. Mai mult, o soluție analitică a acestei probleme nu pare acceptabilă din cauza complexității sale. Ca și în NLP, ar trebui mai întâi să abordăm această problemă prin restrângerea domeniului de căutare - în acest caz, prin eliminarea permutărilor învechite.
Unul dintre lucrurile care ar putea ajuta este ceva ce am scris anul trecut . De asemenea, este important să rețineți că un proces CI/CD bine conceput ajută foarte mult la reducerea variațiilor. Cu toate acestea, starea actuală a lucrurilor cu CI/CD nu este suficient de bună pentru a rezolva problema permutărilor fără instrumente suplimentare pentru componente de contabilitate și urmărire.
Ceea ce avem nevoie este un sistem de experimentare în etapa de integrare, în care să putem determina factorul de risc pentru fiecare componentă și, de asemenea, să avem un proces automat de actualizare a diverselor componente și testare fără intervenția operatorului - pentru a vedea ce funcționează și ce nu.
Un astfel de sistem de experimente ar putea arăta astfel:
- Dezvoltatorii scriu teste (aceasta este o etapă critică - pentru că altfel nu avem un criteriu de evaluare - este ca și etichetarea datelor în învățarea automată).
- Fiecare componentă (proiect) primește propriul său sistem CI - acest proces este acum bine dezvoltat, iar problema creării unui sistem CI pentru o singură componentă a fost în mare măsură rezolvată
- „Sistemul de integrare inteligent” colectează rezultatele diferitelor sisteme CI și asamblează proiecte de componente în produsul final, execută testarea și în final calculează calea cea mai scurtă pentru obținerea funcționalității produsului dorit pe baza componentelor existente și a factorilor de risc. Dacă o actualizare nu este posibilă, acest sistem informează dezvoltatorii despre componentele existente și care dintre ele cauzează eroarea. Încă o dată, sistemul de testare este de o importanță critică aici - deoarece sistemul de integrare folosește testele ca criteriu de evaluare.
- Sistem CD, care apoi primește date de la Smart Integration System și realizează direct actualizarea. Această etapă încheie ciclul.
Pentru a rezuma, pentru mine, una dintre cele mai mari probleme de acum este lipsa unui astfel de „Sistem de integrare inteligent” care să lege diferitele componente într-un produs și, astfel, să vă permită să urmăriți modul în care produsul în ansamblu este asamblat. Voi fi interesat de părerile comunității despre acest lucru (spoiler - în prezent lucrez la un proiect , care poate deveni un sistem de integrare atât de inteligent).
Un ultim lucru pe care vreau să-l menționez este că, pentru mine, un monolit nu este acceptabil pentru niciun proiect nici măcar de dimensiuni medii. Pentru mine, încercările de a accelera timpul de implementare și calitatea dezvoltării prin revenirea la un monolit provoacă un mare scepticism. În primul rând, un monolit are o problemă similară de gestionare a componentelor - printre diferitele biblioteci din care constă, totuși, toate acestea nu sunt atât de vizibile și se manifestă în primul rând în timpul petrecut de dezvoltatori. Consecința problemei monolitului este imposibilitatea virtuală de a face modificări la cod - și viteza de dezvoltare extrem de lentă.
Microservicii îmbunătățesc situația, dar apoi arhitectura microserviciilor se confruntă cu problema exploziei combinatorii în etapa de integrare. Da, în general, am mutat aceeași problemă din etapa de dezvoltare în etapa de integrare. Cu toate acestea, în opinia mea, abordarea cu microservicii duce în continuare la rezultate mai bune, iar echipele obțin rezultate mai rapid (probabil în principal din cauza reducerii dimensiunii unității de dezvoltare - sau dimensiunea lotului). Cu toate acestea, trecerea de la monolit la microservicii nu a îmbunătățit încă suficient procesul - explozia combinatorie a versiunilor de microservicii este o problemă uriașă și avem mult potențial de a îmbunătăți situația pe măsură ce o rezolvăm.
Sursa: www.habr.com