Ciao, Habr! Mi presento alla tua attenzione la traduzione dell'autore dell'articolo .
In un’epoca in cui il mondo IT si sta gradualmente spostando verso microservizi e strumenti come Kubernetes, un solo problema diventa sempre più evidente. Questo problema - versioni di microservizi. Tuttavia, la comunità IT ritiene che la situazione attuale sia molto migliore rispetto a quella attuale precedente generazione di tecnologie. Tuttavia, il controllo delle versioni dei microservizi è un problema molto complesso. Una prova di ciò possono essere articoli come .
Se ancora non capisci il problema leggendo questo testo, lasciami spiegare. Supponiamo che il tuo prodotto sia composto da 10 microservizi. Supponiamo ora che venga rilasciata 1 nuova versione per ciascuno di questi microservizi. Solo 1 versione - Spero che possiamo essere tutti d'accordo sul fatto che si tratta di un fatto molto banale e insignificante. Ora, però, diamo un'altra occhiata al nostro prodotto. Con una sola nuova versione di ciascun componente, ora abbiamo 2^10 o 1024 permutazioni di come può essere composto il nostro prodotto.
Se c'è ancora qualche malinteso, lasciatemi analizzare i conti. Quindi abbiamo 10 microservizi, ciascuno dei quali riceve un aggiornamento. Otteniamo cioè 2 possibili versioni per ciascun microservizio (vecchio o nuovo). Ora, per ciascuno dei componenti del prodotto, possiamo utilizzare una di queste due versioni. Matematicamente è come se avessimo un numero binario di 10 cifre. Ad esempio, supponiamo che 1 sia la nuova versione e 0 sia la vecchia versione, quindi una possibile permutazione può essere indicata come 1001000000, dove il primo e il quarto componente vengono aggiornati e tutti gli altri no. Dalla matematica sappiamo che un numero binario di 1 cifre può avere 4^10 o 2 valori. Cioè, abbiamo confermato l’entità del numero con cui abbiamo a che fare.
Continuiamo ulteriormente il nostro ragionamento: cosa accadrebbe se avessimo 100 microservizi e ognuno avesse 10 possibili versioni? L'intera situazione diventa piuttosto spiacevole: ora abbiamo 10^100 permutazioni, che è un numero enorme. Preferisco però etichettare la situazione in questo modo, perché ormai non ci nascondiamo più dietro parole come “kubernetes”, ma affrontiamo il problema così com’è.
Perché sono così affascinato da questo problema? Anche perché, avendo precedentemente lavorato nel mondo della PNL e dell’AI, abbiamo discusso molto del problema dell’esplosione combinatoria circa 5-6 anni fa. Solo che invece delle versioni avevamo singole parole e invece dei prodotti avevamo frasi e paragrafi. E sebbene i problemi della PNL e dell’AI rimangano in gran parte irrisolti, bisogna ammettere che negli ultimi anni sono stati compiuti progressi significativi (secondo me si potrebbero fare dei progressiоSarebbe meglio se gli operatori del settore prestassero un po' meno attenzione al machine learning e un po' di più ad altre tecniche (ma questo è già fuori tema).
Torniamo al mondo di DevOps e dei microservizi. Ci troviamo di fronte a un problema enorme, mascherato da elefante nella Kunstkamera, perché quello che sento spesso è "basta prendere Kubernetes e timone e tutto andrà bene!" Ma no, non andrà tutto bene se tutto resta com’è. Inoltre, una soluzione analitica a questo problema non sembra accettabile a causa della sua complessità. Come nella PNL, dovremmo prima affrontare questo problema restringendo l’ambito della ricerca, in questo caso eliminando le permutazioni obsolete.
Una delle cose che potrebbe aiutare è qualcosa che ho scritto l’anno scorso . È anche importante notare che un processo CI/CD ben progettato aiuta notevolmente a ridurre la variazione. Tuttavia, la situazione attuale con CI/CD non è sufficiente per risolvere il problema delle permutazioni senza strumenti aggiuntivi per la contabilità e il monitoraggio dei componenti.
Ciò di cui abbiamo bisogno è un sistema di sperimentazione nella fase di integrazione, in cui possiamo determinare il fattore di rischio per ciascun componente, e disporre anche di un processo automatizzato per aggiornare i vari componenti e testarli senza l'intervento dell'operatore, per vedere cosa funziona e cosa no.
Un tale sistema di esperimenti potrebbe assomigliare a questo:
- Gli sviluppatori scrivono i test (questa è una fase critica, perché altrimenti non abbiamo alcun criterio di valutazione, è come etichettare i dati nel machine learning).
- Ogni componente (progetto) riceve il proprio sistema CI: questo processo è ora ben sviluppato e il problema della creazione di un sistema CI per un singolo componente è stato in gran parte risolto
- Il “sistema di integrazione intelligente” raccoglie i risultati di vari sistemi CI e assembla i progetti dei componenti nel prodotto finale, esegue i test e infine calcola il percorso più breve per ottenere la funzionalità del prodotto desiderata in base ai componenti esistenti e ai fattori di rischio. Se un aggiornamento non è possibile, questo sistema avvisa gli sviluppatori sui componenti esistenti e quale di essi causa l'errore. Anche in questo caso il sistema di test è di fondamentale importanza, poiché il sistema di integrazione utilizza i test come criterio di valutazione.
- Sistema CD, che poi riceve i dati dallo Smart Integration System ed esegue direttamente l'aggiornamento. Questa fase conclude il ciclo.
Per riassumere, per me uno dei maggiori problemi ora è la mancanza di un tale “sistema di integrazione intelligente” che colleghi i vari componenti in un prodotto e quindi consenta di monitorare come viene assemblato il prodotto nel suo insieme. Sarò interessato alle opinioni della community al riguardo (spoiler: attualmente sto lavorando a un progetto , che può diventare un sistema di integrazione così intelligente).
Un'ultima cosa che voglio menzionare è che, per me, un monolite non è accettabile per nessun progetto, anche di medie dimensioni. Per me, i tentativi di accelerare i tempi di implementazione e la qualità dello sviluppo tornando a un monolite causano grande scetticismo. In primo luogo, il monolite ha un problema simile nella gestione dei componenti: tra le varie librerie di cui è composto, tuttavia, tutto ciò non è così evidente e si manifesta principalmente nel tempo impiegato dagli sviluppatori. La conseguenza del problema del monolite è l'impossibilità virtuale di apportare modifiche al codice e una velocità di sviluppo estremamente lenta.
I microservizi migliorano la situazione, ma poi l’architettura dei microservizi affronta il problema dell’esplosione combinatoria nella fase di integrazione. Sì, in generale abbiamo spostato lo stesso problema dalla fase di sviluppo a quella di integrazione. Tuttavia, a mio avviso, l’approccio basato sui microservizi porta comunque a risultati migliori e i team ottengono risultati più velocemente (probabilmente principalmente a causa della riduzione delle dimensioni dell’unità di sviluppo – o dimensione del lotto). Tuttavia, il passaggio dal monolite ai microservizi non ha ancora migliorato sufficientemente il processo: l’esplosione combinatoria delle versioni dei microservizi è un problema enorme e abbiamo molte potenzialità per migliorare la situazione una volta risolta.
Fonte: habr.com