Ciao, Habr! Vi presento la traduzione di un articolo .
In un'epoca in cui il mondo IT si sta lentamente spostando verso i microservizi e strumenti come Kubernetes, emerge sempre più evidente un solo problema. Questo problema è delle versioni dei microservizi. Tuttavia, la comunità IT ritiene che la situazione attuale sia notevolmente migliore rispetto a della generazione precedente di tecnologie. Tuttavia, la gestione delle versioni dei microservizi è un problema molto complesso. Una delle prove di ciò può essere trovata in articoli come .
Se leggendo questo testo non comprendete ancora il problema, permettetemi di spiegare. Supponiamo che il vostro prodotto sia composto da 10 microservizi. Ora supponiamo che per ciascuno di questi microservizi venga rilasciata una nuova versione. Solo una versione — spero che possiamo tutti concordare che questo è un fatto piuttosto triviale e insignificante. Ora, però, diamo un'altra occhiata al nostro prodotto. Con solo una nuova versione per ciascun componente, abbiamo ora 2^10 — ovvero 1024 permutazioni di come possiamo configurare il nostro prodotto.
Se c'è ancora confusione, permettetemi di spiegare la matematica. Dunque, abbiamo 10 microservizi, ciascuno con un aggiornamento. Questo significa che abbiamo 2 possibili versioni per ogni microservizio (o la vecchia o la nuova). Ora, per ciascuno dei componenti del prodotto, possiamo utilizzare qualcuna di queste due versioni. Matematicamente, questo è lo stesso che avere un numero binario di 10 cifre. Ad esempio, diciamo che 1 è la nuova versione, e 0 è la vecchia versione — allora una possibile permutazione può essere rappresentata come 1001000000 — dove il 1° e il 4° 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 le dimensioni del numero con cui stiamo trattando.
Proseguiamo ulteriormente il ragionamento — cosa succederebbe se avessimo 100 microservizi e ciascuno di essi avesse 10 versioni possibili? 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 così com'è.
Perché questa problematica mi affascina così tanto? In parte perché, lavorando in passato nel mondo dell'NLP e dell'AI, abbiamo discusso molto 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 le problematiche di NLP e AI rimangano in larga misura irrisolte, bisogna riconoscere che negli ultimi anni è stato fatto un progresso significativo. (a mio avviso, il progresso potrebbe essere statounmaggiore, se le persone nel settore prestassero un po' meno attenzione al machine learning e un po' più ad altre tecniche — ma questo è già off-topic).
Tornando al mondo del DevOps e dei microservizi. Ci troviamo di fronte a un enorme problema, mascherato come un elefante in una stanza — infatti, ciò che sento spesso è: «basta prendere Kubernetes e Helm, e andrà tutto bene!» Ma no, non andrà tutto bene se tutto rimane così com'è. Inoltre, una soluzione analitica a questo problema non sembra accettabile vista la sua complessità. Come nell'NLP, dobbiamo prima avvicinarci a questo problema restringendo l'ambito di ricerca — in questo caso, escludendo le permutazioni obsolete.
Una delle cose che potrebbero aiutare — ho scritto l'anno scorso È anche importante notare che un processo CI/CD ben sviluppato aiuta notevolmente a ridurre le variazioni. Tuttavia, la situazione attuale con CI/CD non è sufficientemente buona per risolvere il problema delle permutazioni senza strumenti aggiuntivi per la registrazione e il tracciamento dei componenti.
Ciò di cui abbiamo bisogno è un sistema di esperimenti nella fase di integrazione, dove possiamo determinare il fattore di rischio per ciascun componente e avere anche un processo automatizzato per l'aggiornamento e il testing dei vari componenti senza intervento da parte dell'operatore — per capire cosa funziona e cosa no.
Un tale sistema di esperimenti potrebbe apparire nel seguente modo:
- Gli sviluppatori scrivono test (questo è un passaggio critico — perché altrimenti non abbiamo criteri di valutazione — è come l'annotazione dei dati nel machine learning).
- Ogni componente (progetto) riceve il proprio sistema CI — questo processo è attualmente ben consolidato e la creazione di un sistema CI per un singolo componente è in gran parte risolta.
- Il «Sistema di integrazione intelligente» raccoglie i risultati di diversi sistemi CI e compone i progetti-componenti nel prodotto finale, avvia i test e infine calcola il percorso più breve per ottenere la funzionalità desiderata del prodotto sulla base dei componenti esistenti e dei fattori di rischio. Se un aggiornamento non è possibile, questo sistema avverte gli sviluppatori riguardo ai componenti disponibili e su quale di essi si verifica l'errore. Ripeto che il sistema di test qui è di importanza cruciale, poiché il sistema di integrazione utilizza i test come criterio di valutazione.
- Il sistema CD che poi riceve dati dal «Sistema di integrazione intelligente» e produce direttamente l'aggiornamento. Questa fase conclude il ciclo.
In sintesi, per me uno dei problemi principali al momento è l'assenza di un «Sistema di integrazione intelligente» che colleghi i diversi componenti nel prodotto, permettendo così di tracciare come sia composto il prodotto nel suo insieme. Sarei interessato ai pensieri della comunità al riguardo (spoiler: sto attualmente lavorando a un progetto , che potrebbe diventare un tale sistema di integrazione intelligente).
Un'ultima cosa che voglio menzionare è che per me il monolite non è accettabile per nessun progetto di medio livello. Ho grande scetticismo riguardo ai tentativi di accelerare i tempi di implementazione e la qualità dello sviluppo tornando al monolite. In primo luogo, il monolite ha un problema simile nella gestione dei componenti, tra le varie librerie di cui è composto, ma tutto ciò non è così evidente e si manifesta prima di tutto nel tempo speso dagli sviluppatori. La conseguenza del problema del monolite è l'effettiva impossibilità di apportare modifiche al codice e una velocità di sviluppo estremamente lenta.
I microservizi migliorano la situazione, tuttavia poi l'architettura a microservizi si confronta con il problema dell'esplosione combinatoria nella fase di integrazione. Sì, in generale, abbiamo spostato lo stesso problema dalla fase di sviluppo alla fase di integrazione. Tuttavia, a mio avviso, l'approccio dei microservizi porta comunque a risultati migliori, e i team ottengono risultati più rapidamente (probabilmente principalmente a causa della riduzione delle dimensioni dell'unità di sviluppo — o batch size). Tuttavia, il passaggio da monoliti a microservizi non ha ancora portato a un miglioramento significativo del processo: l'esplosione combinatoria delle versioni dei microservizi rappresenta un enorme problema, e abbiamo un grande potenziale per migliorare la situazione man mano che la affrontiamo.
Fonte: habr.com
