Ciao, Habr! Vi presento una traduzione originale dell'articolo .
In un'epoca in cui il mondo IT sta lentamente passando ai microservizi e strumenti come Kubernetes, un problema emerge sempre più evidente. Questo problema è delle versioni dei microservizi. Tuttavia, la comunità IT ritiene che la situazione odierna sia notevolmente migliore rispetto a delle tecnologie precedenti. Tuttavia, la gestione delle versioni dei microservizi si presenta come un compito piuttosto difficile. Una delle prove di ciò è rappresentata da articoli come .
Se leggendo questo testo non comprendete ancora il problema, permettetemi di spiegarlo. Supponiamo che il vostro prodotto sia composto da 10 microservizi. Ora supponiamo che per ognuno di questi microservizi venga rilasciata 1 nuova versione. Solo 1 versione — spero che tutti possiamo concordare che questo sia un fatto piuttosto banale e insignificante. Tuttavia, guardiamo di nuovo il nostro prodotto. Con solo una nuova versione di ciascun componente, ora abbiamo 2^10 — o 1024 permutazioni su come possiamo comporre il nostro prodotto.
Se c'è ancora qualche confusione, permettetemi di spiegare la matematica. Dunque, abbiamo 10 microservizi, ognuno con un aggiornamento. Quindi, abbiamo 2 possibili versioni per ogni microservizio (o la vecchia o la nuova). Ora, per ciascuno dei componenti del prodotto possiamo utilizzare una di queste due versioni. Matematicamente, questo è equivalente a un numero binario di 10 cifre. Ad esempio, supponiamo che 1 sia la nuova versione e 0 la vecchia versione — allora una possibile permutazione potrebbe essere rappresentata come 1001000000 — dove il primo e il quarto componente sono aggiornati, mentre tutti gli altri no. Dalla matematica sappiamo che un numero binario di 10 cifre può avere 2^10 o 1024 valori. Dunque, abbiamo confermato l'entità del numero con cui stiamo trattando.
Proseguendo nei ragionamenti — cosa succede se abbiamo 100 microservizi e ognuno con 10 possibili versioni? La situazione diventa piuttosto sgradevole — ora abbiamo 10^100 permutazioni — un numero enorme. Tuttavia, preferisco descrivere questa situazione in questo modo, perché ora non ci nascondiamo dietro parole come «kubernetes», ma affrontiamo il problema per quello che è.
Perché questa problematica mi affascina così tanto? In parte perché, avendo lavorato in precedenza nel mondo NLP e AI, abbiamo discusso a lungo del problema dell'esplosione combinatoria circa 5-6 anni fa. Solo che invece di versioni avevamo parole singole, e invece di prodotti avevamo frasi e paragrafi. E sebbene i problemi di NLP e AI rimangano in gran parte irrisolti, occorre riconoscere che negli ultimi anni è stato fatto un progresso significativo. (a mio avviso, il progresso potrebbe essere stato maggioreunse le persone nel settore avessero prestato un po' meno attenzione al machine learning e un po' di più ad altre tecniche — ma questo è un argomento a parte).
Tornando al mondo dei DevOps e dei microservizi. Ci troviamo di fronte a un grandissimo problema, camuffato da un elefante nella stanza — perché ciò che sento spesso è «basta prendere kubernetes e helm e andrà tutto bene!» Ma no, non andrà tutto bene se lasciamo le cose come stanno. Inoltre, una soluzione analitica a questo problema non appare praticabile vista la sua complessità. Come nel NLP, dobbiamo prima affrontare questo problema restringendo l'ambito di ricerca — in questo caso eliminando le permutazioni obsolete.
Una delle cose che può aiutare — ho scritto l'anno scorso . È anche importante notare che un processo CI/CD ben progettato aiuta notevolmente a ridurre le variazioni. Tuttavia, la situazione attuale con CI/CD non è sufficientemente buona per affrontare il problema delle permutazioni senza ulteriori strumenti di monitoraggio e tracciamento dei componenti.
Ciò di cui abbiamo bisogno è un sistema di esperimenti nella fase di integrazione, dove possiamo definire il fattore di rischio per ciascun componente, oltre ad avere un processo automatizzato per l'aggiornamento di vari componenti e il testing senza l'intervento dell'operatore — per vedere cosa funziona e cosa no.
Un tale sistema di esperimenti potrebbe apparire come segue:
- Gli sviluppatori scrivono test (questo è un passaggio critico — perché altrimenti non abbiamo criterio di valutazione — proprio come l'annotazione dei dati nel machine learning).
- Ogni componente (progetto) ottiene il proprio sistema CI — questo processo è oggi ben sviluppato, e la questione della creazione di un sistema CI per un singolo componente è in gran parte risolta.
- Il «Sistema Intelligente di Integrazione» raccoglie i risultati di diversi sistemi CI e assembla i progetti-componenti in un prodotto finale, avvia i test e infine calcola il percorso più breve per ottenere la funzionalità desiderata del prodotto, tenendo conto dei componenti esistenti e dei fattori di rischio. Se non è possibile effettuare l'aggiornamento, questo sistema avvisa gli sviluppatori riguardo ai componenti presenti e su quale di essi si verifica un errore. Ripeto, il sistema di test qui è di importanza critica, poiché il sistema di integrazione utilizza i test come criterio di valutazione.
- Il sistema CD, che poi riceve dati dal «Sistema Intelligente di Integrazione» e esegue direttamente l'aggiornamento. Questa fase conclude il ciclo.
In sintesi, per me una delle più grandi sfide al momento è l'assenza di un «Sistema Intelligente di Integrazione» che colleghi i vari componenti in un prodotto, permettendo così di tracciare come il prodotto sia composto nel suo insieme. Sarò interessato ai pensieri della comunità a riguardo (spoiler: sto attualmente lavorando a un progetto , che potrebbe diventare un tale sistema intelligente di integrazione).
Un'ultima cosa che voglio menzionare è che per me un monolite non è adeguato per alcun progetto di dimensioni medio-grandi. Ho grandi riserve riguardo ai tentativi di accelerare i tempi di implementazione e la qualità dello sviluppo tornando al monolite. In primo luogo, il monolite presenta 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 che gli sviluppatori spendono. La conseguenza del problema del monolite è la reale impossibilità di apportare modifiche al codice, portando a una velocità di sviluppo estremamente lenta.
I microservizi migliorano la situazione, ma poi l'architettura a 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 dei microservizi porta comunque a risultati migliori, e i team raggiungono i risultati più velocemente (probabilmente soprattutto grazie alla riduzione delle dimensioni dell'unità di sviluppo - o batch size). Tuttavia, il passaggio dal monolite ai microservizi non ha ancora portato a un miglioramento sufficiente del processo: l'esplosione combinatoria delle versioni dei microservizi rappresenta un enorme problema, e abbiamo un grande potenziale di miglioramento man mano che affrontiamo questa situazione.
Fonte: habr.com
