Sembra che il picco dell'hype sui microservizi sia ormai passato. Non leggiamo più diversi articoli a settimana su «Come ho migrato il mio monolite in 150 servizi». Ora sento più spesso opinioni sensate: «Non odio il monolite, mi interessa solo l'efficienza». Abbiamo persino osservato alcune migrazioni . Quando si passa da un'unica grande applicazione a più servizi più piccoli, ci si trova a dover affrontare diverse nuove sfide. Elenchiamole in modo conciso.
Impostazione: dalla chimica di base alla meccanica quantistica
Configurare un database di base e un'applicazione con un processo in background è stato un processo piuttosto chiaro. Publico il readme su Github e, spesso, dopo un'ora o al massimo un paio d'ore, tutto funziona e inizio un nuovo progetto. Aggiungere e avviare codice, almeno per l'ambiente iniziale, si può fare nel primo giorno stesso. Ma se ci siamo avventurati nei microservizi, il tempo di avviamento iniziale schizza alle stelle. Sì, ora abbiamo Docker con orchestrazione e un cluster di macchine K8, ma per un programmatore alle prime armi è tutto di un ordine di complessità molto maggiore. Per molti junior rappresenta un peso, che risulta essere un'eccessiva complicazione.
Il sistema non è facile da comprendere
Fermiamoci un attimo sul nostro junior. Con le applicazioni monolitiche, in caso di errore, era facile rintracciare e mettere subito a punto il problema. Ora abbiamo un servizio che comunica con un altro servizio, il quale mette qualcosa in coda su un bus di messaggi, che elabora un altro servizio — ed ecco che si presenta l'errore. Dobbiamo mettere insieme tutti questi pezzi per scoprire alla fine che il servizio A è nella versione 11, mentre il servizio E sta già aspettando la versione 12. Questo è molto diverso dal mio registro consolidato standard: devo usare un terminale interattivo/debugger per attraversare il processo passo dopo passo. Il debugging e la comprensione sono diventati sostanzialmente più complessi.
Se non possiamo eseguire il debug, forse li testeremo
L'integrazione continua e lo sviluppo continuo stanno diventando un'idea comune. La maggior parte delle nuove applicazioni che vedo crea e avvia automaticamente test con ogni nuovo rilascio e richiede che i test vengano superati e revisionati prima della registrazione. Questi sono ottimi processi, dai quali non si può rinunciare, e rappresentano un grande cambiamento per molte aziende. Ma ora, per testare davvero il servizio, devo avviare una versione completamente funzionante della mia applicazione. Ricordi quel nuovo ingegnere con il cluster K8 di 150 servizi? Bene, ora insegneremo al nostro sistema CI come avviare tutti questi sistemi per verificare che tutto funzioni davvero. Probabilmente è troppa fatica, quindi testeremo semplicemente ogni parte in isolamento: sono sicuro che le nostre specifiche sono abbastanza buone, le API sono pulite e l'interruzione del servizio è isolata e non influenzerà gli altri.
Ogni compromesso ha una buona ragione. Giusto?
Ci sono molte ragioni per passare ai microservizi. Ho visto che questa transizione avviene per maggiore flessibilità, per scalare i team, per migliorarne le prestazioni e per garantire una maggiore resilienza operativa. Ma in realtà, abbiamo investito decenni in strumenti e pratiche di sviluppo monolitiche che continuano a evolversi. Lavoro con professionisti in diverse tecnologie. Di solito parliamo di scalabilità, perché si trovano di fronte ai limiti di un singolo nodo database Postgres. La maggior parte delle conversazioni riguarda .
Ma sono sempre curioso di conoscere la loro architettura. A che punto si trovano nel passaggio ai microservizi? È interessante vedere come sempre più ingegneri affermano di essere soddisfatti della propria applicazione monolitica. A molti microservizi porteranno vantaggi, e i benefici supereranno gli ostacoli nel processo di migrazione. Ma personalmente, per favore, datemi la mia applicazione monolitica, un posto sulla spiaggia, e sarò assolutamente felice.
Fonte: habr.com
