Sembra che il picco dell'hype sui microservizi sia ormai alle spalle. Non leggiamo più ogni settimana articoli su "Come ho trasformato il mio monolite in 150 servizi". Ora sento più spesso riflessioni sensate: "Non odio il monolite, mi preoccupo semplicemente dell'efficienza". Abbiamo persino osservato alcune migrazioni . Quando si passa da un'unica grande applicazione a diversi servizi più piccoli, ci si trova ad affrontare diverse nuove problematiche. Elenchiamo le principali in modo conciso.
Installazione: dalla chimica di base alla meccanica quantistica
La configurazione del database di base e dell'applicazione con processo in background è stata piuttosto chiara. Pubblico un readme su Github — e spesso dopo un'ora, al massimo un paio d'ore, tutto funziona, e inizio un nuovo progetto. L'aggiunta e l'esecuzione del codice, almeno per l'ambiente iniziale, vengono fatte il primo giorno stesso. Ma se ci avventuriamo nei microservizi, il tempo di avvio iniziale schizza alle stelle. Sì, ora abbiamo Docker con orchestrazione e un cluster di macchine K8, ma per un programmatore alle prime armi tutto ciò è di gran lunga più complesso. Per molti junior è un fardello che risulta davvero una complessità superflua.
Il sistema non è facile da comprendere
Fermiamoci un attimo sul nostro junior. Con le applicazioni monolitiche, in caso di errore era facile tracciarlo e passare immediatamente al debug. Ora abbiamo un servizio che comunica con un altro servizio, che mette qualcosa in coda su un bus di messaggi, che gestisce un altro servizio — e qui si verifica un errore. Dobbiamo unire tutti questi pezzi per scoprire infine che il servizio A è alla versione 11, mentre il servizio E sta già aspettando la versione 12. Questo è molto diverso dal mio normale registro consolidato: devo usare un terminale interattivo/debugger per passare attraverso il processo passo dopo passo. Il debug e la comprensione sono diventati sostanzialmente più complessi.
Se non può essere debugged, forse lo testeremo.
L'integrazione continua e lo sviluppo continuo stanno diventando la norma. La maggior parte delle nuove applicazioni che vedo crea automaticamente e esegue test con ogni nuova versione, richiedendo che i test vengano superati e revisionati prima del rilascio. Questi sono ottimi processi, da cui non si può prescindere, e rappresentano un grande cambiamento per molte aziende. Ma ora, per testare davvero il servizio, devo attivare una versione completa della mia applicazione. Ricordi quell'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 è troppo impegnativo, quindi testeremo semplicemente ogni parte in isolamento: sono sicuro che le nostre specifiche siano abbastanza buone, che le API siano pulite e che il guasto del servizio sia isolato e non influisca sugli altri.
Ogni compromesso ha una ragione valida. Giusto?
Ci sono molte ragioni per passare ai microservizi. Ho visto che lo fanno per avere maggiore flessibilità, per scalare i team, per le prestazioni e per garantire una migliore resilienza operativa. Ma in realtà abbiamo investito decenni in strumenti e pratiche di sviluppo di monoliti, che continuano ad evolversi. Lavoro con professionisti in diverse tecnologie. Di solito parliamo di scalabilità, perché si trovano ad affrontare i limiti di un singolo nodo di database Postgres. Gran parte delle conversazioni è dedicata a .
Ma sono sempre curioso di conoscere la loro architettura. A che punto si trovano nel passaggio ai microservizi? È interessante osservare come sempre più ingegneri affermino di essere soddisfatti della loro applicazione monolitica. Molti trarranno beneficio dai microservizi e i vantaggi supereranno gli ostacoli lungo il percorso di migrazione. Ma a me, per favore, date la mia applicazione monolitica, un posto sulla spiaggia - e sarò completamente felice.
Fonte: habr.com
