Sembra che l’apice dell’entusiasmo per i microservizi sia ormai alle nostre spalle. Non leggiamo più più volte alla settimana i post “Come ho spostato il mio monolite su 150 servizi”. Ora sento pensieri più basati sul buon senso: “Non odio il monolite, mi interessa solo l’efficienza”. Abbiamo anche osservato diverse migrazioni . Quando si passa da un'applicazione di grandi dimensioni a più servizi più piccoli, sarà necessario risolvere diversi nuovi problemi. Li elenchiamo il più brevemente possibile.
Ambito: dalla chimica di base alla meccanica quantistica
La configurazione di un database di base e di un'applicazione con un processo in background è stata un processo abbastanza semplice. Pubblico il file readme su Github - e spesso dopo un'ora, un paio d'ore al massimo, tutto funziona e inizio un nuovo progetto. L'aggiunta e l'esecuzione del codice, almeno per l'ambiente iniziale, vengono eseguite il primo giorno. Ma se ci avventuriamo nei microservizi, il tempo di lancio iniziale sale alle stelle. Sì, ora abbiamo Docker con orchestrazione e un cluster di macchine K8, ma per un programmatore alle prime armi tutto questo è molto più complicato. Per molti ragazzi, questo è un peso che rappresenta davvero una complicazione inutile.
Il sistema non è facile da capire
Concentriamoci un attimo sui nostri junior. Con le applicazioni monolitiche, se si verificava un errore, era facile rintracciarlo e passare immediatamente al debug. Ora abbiamo un servizio che comunica con un altro servizio che accoda qualcosa su un bus di messaggi che sta elaborando un altro servizio e quindi si verifica un errore. Dobbiamo mettere insieme tutti questi pezzi per scoprire alla fine che il servizio A esegue la versione 11 e il servizio E sta già aspettando la versione 12. Questo è molto diverso dal mio registro consolidato standard: dover utilizzare un terminale/debugger interattivo per camminare attraverso il processo passo dopo passo. Il debug e la comprensione sono diventati intrinsecamente più difficili.
Se non è possibile eseguire il debug, forse li testeremo
L'integrazione continua e lo sviluppo continuo stanno ormai diventando un luogo comune. La maggior parte delle nuove app che vedo creano ed eseguono automaticamente test con ogni nuova versione e richiedono che i test vengano eseguiti e rivisti prima della registrazione. Si tratta di processi importanti che non dovrebbero essere abbandonati e che hanno rappresentato un grande cambiamento per molte aziende. Ma ora, per testare davvero il servizio, devo scaricare 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 attivare tutti questi sistemi per verificare che tutto funzioni davvero. Probabilmente si tratta di uno sforzo eccessivo, quindi testeremo ogni parte isolatamente: sono sicuro che le nostre specifiche siano abbastanza buone, le API siano pulite e un errore del servizio sia isolato e non influisca sugli altri.
Tutti i compromessi hanno una buona ragione. Giusto?
Esistono molti motivi per passare ai microservizi. L'ho visto fare per una maggiore flessibilità, per ridimensionare i team, per prestazioni, per fornire una migliore sostenibilità. Ma in realtà abbiamo investito decenni in strumenti e pratiche per sviluppare monoliti che continuano ad evolversi. Collaboro con professionisti di diverse tecnologie. Di solito parliamo di ridimensionamento perché rientrano nei limiti di un singolo nodo del database Postgres. La maggior parte delle conversazioni riguarda .
Ma sono sempre interessato a conoscere la loro architettura. A che punto della transizione verso i microservizi si trovano? È interessante vedere sempre più ingegneri affermare di essere soddisfatti della loro applicazione monolitica. Molte persone trarranno vantaggio dai microservizi e i vantaggi supereranno gli ostacoli nel percorso di migrazione. Ma personalmente, per favore, dammi la mia applicazione monolitica, un posto sulla spiaggia - e sono completamente felice.
Fonte: habr.com