Salutami, Habr! Prestu à a vostra attenzione traduzzione di l'autore di l'articulu .
In un momentu chì u mondu IT si move gradualmente versu i microservizi è arnesi cum'è Kubernetes, solu un prublema hè diventatu più è più notu. Stu prublema - versioni di microserviziu. Eppuru, a cumunità IT crede chì a situazione attuale hè assai megliu cà generazione precedente di tecnulugia. Tuttavia, a versione di i microservizi hè un prublema assai cumplessu. Una prova di questu pò esse articuli cum'è .
Sè vo ùn capisci ancora u prublema da leghje stu testu, lasciami spiegà. Diciamu chì u vostru pruduttu hè custituitu da 10 microservizii. Avà assumemu chì 1 nova versione hè liberata per ognunu di sti microservizi. Solu a versione 1 - Spergu chì pudemu tutti d'accordu chì questu hè un fattu assai triviale è insignificante. Avà, però, fighjemu un altru sguardu à u nostru pruduttu. Cù una sola versione nova di ogni cumpunente, avemu avà 2 ^ 10 - o 1024 permutazioni di cumu u nostru pruduttu pò esse cumpostu.
S'ellu ci hè sempre un malintesi, lasciami sfondà a matematica. Allora avemu 10 microservizi, ognunu riceve una aghjurnazione. Vale à dì, avemu 2 versioni pussibuli per ogni microserviziu (o vechju o novu). Avà, per ognunu di i cumpunenti di u produttu, pudemu usà una di queste duie versioni. Matematicamente, hè listessa cum'è s'ellu avemu avutu un numeru binariu di 10 cifre. Per esempiu, dicemu chì 1 hè a nova versione, è 0 hè a versione vechja - allora una permutazione pussibule pò esse indicata cum'è 1001000000 - induve i cumpunenti 1 è 4 sò aghjurnati, è tutti l'altri ùn sò micca. Da a matematica sapemu chì un numeru binariu di 10 cifre pò avè 2^10 o 1024 valori. Questu hè, avemu cunfirmatu a scala di u numeru chì avemu trattatu.
Cuntinuemu u nostru ragiunamentu più luntanu - chì succede se avemu 100 microservizi è ognunu hà 10 versioni pussibuli? A situazione sana diventa abbastanza dispiacevule - avemu avà 10 ^ 100 permutazioni - chì hè un gran numaru. In ogni casu, preferimu chjappà sta situazione in questu modu, perchè avà ùn simu più ammucciati daretu à e parolle cum'è "kubernetes", ma piuttostu affruntà u prublema cum'è hè.
Perchè sò cusì affascinatu da stu prublema? In parte perchè, avè travagliatu prima in u mondu di NLP è AI, avemu discututu u prublema di l'esplosione cumminatoria assai circa 5-6 anni fà. Solu invece di versioni avemu avutu parolle individuali, è invece di prudutti avemu avutu frasi è paragrafi. E ancu s'è i prublemi di NLP è AI restanu largamente senza risolve, deve esse ammessi chì un prugressu significativu hè statu fattu in l'ultimi anni. (in u mo parè, u prugressu puderia esse fattuоSaria megliu se a ghjente in l'industria hà pagatu un pocu menu attenzione à l'apprendimentu automaticu è un pocu più à altre tecniche - ma questu hè digià off-topic).
Riturnemu à u mondu di DevOps è microservizi. Avemu affruntatu un prublema enormu, mascheratu cum'è un elefante in a Kunstkamera - perchè ciò chì spessu sente hè "pigliate solu kubernetes è timone, è tuttu sarà bè!" Ma no, tuttu ùn sarà micca bè se tuttu hè lasciatu cum'è. Inoltre, una suluzione analitica à stu prublema ùn pare micca accettabile per via di a so cumplessità. Cum'è in NLP, duvemu prima avvicinà stu prublema ristringendu u scopu di ricerca - in questu casu, eliminendu permutazioni obsolete.
Una di e cose chì puderia aiutà hè qualcosa chì aghju scrittu l'annu passatu . Hè impurtante ancu di nutà chì un prucessu CI / CD ben cuncepitu aiuta assai à riduce a variazione. In ogni casu, u statu attuale di l'affari cù CI / CD ùn hè micca abbastanza bè per risolve u prublema di permutazioni senza strumenti supplementari per i cumpunenti di cuntabilità è seguimentu.
Ciò chì avemu bisognu hè un sistema di sperimentazione in a fase di integrazione, induve pudemu determinà u fattore di risicu per ogni cumpunente, è ancu avè un prucessu automatizatu per aghjurnà diversi cumpunenti è teste senza intervenzione di l'operatore - per vede ciò chì funziona è ciò chì ùn hè micca.
Un tali sistema di esperimenti puderia vede cusì:
- I sviluppatori scrivenu testi (questu hè un stadiu criticu - perchè altrimenti ùn avemu micca un criteriu di valutazione - hè cum'è l'etichettatura di dati in l'apprendimentu machine).
- Ogni cumpunente (prughjettu) riceve u so propiu sistema CI - stu prucessu hè avà bè sviluppatu, è u prublema di creà un sistema CI per un solu cumpunente hè stata largamente risolta.
- U "sistema d'integrazione intelligente" raccoglie i risultati di diversi sistemi CI è assemble i prughjetti di cumpunenti in u pruduttu finali, esegue teste è infine calculate u percorsu più curtu per ottene a funziunalità di u produttu desiderata basatu annantu à i cumpunenti esistenti è i fatturi di risichi. Se un aghjurnamentu ùn hè micca pussibule, stu sistema avvisa i sviluppatori nantu à i cumpunenti esistenti è quale di elli hè causatu l'errore. Una volta, u sistema di teste hè d'impurtanza critica quì - postu chì u sistema di integrazione usa e teste cum'è un criteriu di valutazione.
- sistema CD, chì poi riceve dati da u Sistema di Integrazione Smart è eseguisce l'aghjurnamentu direttamente. Sta tappa finisci u ciclu.
Per riassuntu, per mè unu di i prublemi più grande avà hè a mancanza di un tali "Smart Integration System" chì ligà i diversi cumpunenti in un pruduttu è cusì vi permette di seguità cumu u pruduttu in tuttu hè misu. Seraghju interessatu à i pinsamenti di a cumunità nantu à questu (spoiler - Sò attualmente travagliendu in un prughjettu , chì pò diventà un sistema di integrazione cusì intelligente).
Un'ultima cosa chì vogliu mencionà hè chì, per mè, un monolitu ùn hè micca accettatu per qualsiasi prughjettu ancu di una dimensione mediana. Per mè, i tentativi di accelerà u tempu di implementazione è a qualità di u sviluppu tornanu à un monolitu causanu un grande scetticismu. Prima, un monolitu hà un prublema simili di gestione di cumpunenti - trà e diverse biblioteche chì hè custituitu, però, tuttu questu ùn hè micca cusì notevuli è si manifesta principalmente in u tempu passatu da i sviluppatori. A cunsiquenza di u prublema di u monolitu hè l'impossibilità virtuale di fà cambiamenti à u codice - è a velocità di sviluppu estremamente lenta.
I microservices migliurà a situazione, ma allora l'architettura di microservice face u prublema di l'esplosione cumminatoria in u stadiu di integrazione. Iè, in generale, avemu spustatu u listessu prublema da u stadiu di sviluppu à u stadiu di integrazione. In ogni casu, in u mo parè, l'approcciu di i microservizii porta sempre à risultati megliu, è e squadre ghjunghjenu risultati più rapidamente (probabilmente principalmente per via di a riduzione di a dimensione di l'unità di sviluppu - o dimensione di batch). Tuttavia, u muvimentu da u monolitu à i microservizi ùn hà ancu migliuratu u prucessu abbastanza - l'esplosione cumminatoria di versioni di microservizi hè un prublema enormu, è avemu assai putenziali per migliurà a situazione mentre risolvemu.
Source: www.habr.com