Microservizi: MonolithFirst?

Ho studiato architetture di microservizi cercando di ottenere una panoramica di alto livello di tutti i pro e i contro, perché e perché, molte informazioni che sto leggendo / guardando provengono da ThoughtWorks (Martin Fowler, Neal Ford, et al).

La maggior parte del lavoro di Martin Fowler sull'argomento ha pochi anni, quando Microservices (come nome familiare nella programmazione, se non in medicina generale) era ancora giovane, quindi ne prendo gran parte con un granello di sale.

Una cosa in particolare è questa:

Mentre ascolto storie di team che usano un'architettura di microservizi, ho notato uno schema comune.

• Quasi tutte le storie di successo del microservizio sono iniziate con un monolite che è diventato troppo grande e rotto
• Quasi tutti i casi in cui ho sentito parlare di un sistema che è stato costruito da zero come un sistema di microservizi, è finito in guai seri.

Questo schema ha portato molti dei miei colleghi a sostenere che non dovresti iniziare un nuovo progetto con microservizi, anche se sei sicuro che la tua applicazione sarà abbastanza grande da renderlo utile. .

(rif: https://martinfowler.com/bliki/MonolithFirst.html - enfatizza la loro)

Ora, 3 anni dopo e con i microservizi un termine più onnipresente, è generalmente piacevole che un nuovo sistema sia in genere meglio servito da blocchi di servizio più grandi (-hanno microservizio-ma-più piccolo del monolito) per iniziare e fare loro più granulari come parte di una misura evolutiva?

Oppure, c'è una norma per iniziare un progetto da zero con un'architettura granulare a microservizi, in contrasto con le affermazioni sopra?

Sembra un approccio generale sano, ma curioso dei pensieri della comunità.

Se la tua azienda ha fatto microservizi per un po ', alcuni pezzi potrebbero già essere stati costruiti e devi semplicemente incorporarli. Probabili esempi potrebbero essere l'autenticazione come servizio o l'archiviazione di dati BLOB. In tal caso, hai già definito i limiti e stai riutilizzando il codice in una nuova applicazione. È una buona cosa.

Per il nuovo codice in cui non si è sicuri di dove debba essere il confine, crearlo in un servizio. Se lo mantieni modulare, puoi dividere i microservizi da esso, se necessario. Soprattutto quando trovi parti del tuo servizio che devono essere ridimensionate diversamente dalle altre.

Il vantaggio dei microservizi è che è possibile aggiungere istanze per ridimensionare il lavoro svolto su richiesta. Se alcuni dei tuoi lavori arrivano a raffica, potrebbe essere logico separarli nel proprio microservizio.

In generale:

• Se hai già creato microservizi, riutilizzali
• Se stai costruendo qualcosa di nuovo, fai funzionare prima l'idea
• Durante la costruzione, cerca di mantenere le cose modulari in modo che alcuni servizi possano essere facilmente risolti
• Mentre stai costruendo, se una parte del tuo servizio deve essere in grado di scalare su richiesta a un ritmo diverso, separalo nel proprio servizio

Troppo spesso sentiamo utili linee guida da persone intelligenti con una buona reputazione come Martin Fowler, e poi lo trasformiamo in una dura dottrina da cui non si può in alcun modo influenzare.

Devi prendere dichiarazioni del genere nello spirito del loro significato. Martin Fowler sta cercando di salvare le persone dalla paralisi mediante analisi e di dire loro di costruire qualcosa che funzioni per primo. Puoi sempre separarlo in seguito, quando sai di più su come funziona davvero la tua applicazione.

I vantaggi più preziosi dei microservizi possono essere ottenuti con una semplice modularizzazione del codice. Puoi isolare gruppi di funzionalità in moduli usando qualunque sistema di moduli tu abbia (maven, npm, nuget, qualunque cosa). Ogni modulo può servire a un unico scopo, gestire il proprio repository, utilizzare il proprio schema DB, gestire la propria configurazione, disporre del proprio backlog di funzionalità e pianificazione delle versioni. Possono ancora essere schierati insieme su un monolite. Questa è una quantità molto gestibile di spese generali e offre alcuni buoni benefici. Il sovraccarico maggiore deriva dalla separazione delle distribuzioni che è davvero preziosa solo quando si ha una scala sufficiente per renderla necessaria. Se il tuo codice è già modulare, al momento sarà una migrazione più semplice.

A mio avviso, può essere utile sviluppare prima un monolito (o meglio: sviluppare parti della tua applicazione come monolito).

Ci sono casi in cui non sei sicuro del dominio e dei limiti del tuo problema (ad esempio, costruisco un sito di gestione della nave, ho bisogno di un servizio di nave E un servizio di flotta o è un servizio di nave sufficiente?), E in questi casi un il monolito può essere più facile da sviluppare.

Dovresti smettere di farlo se hai bisogno di integrare tecnologie diverse nel mix (ad es. Le tue parti esistenti sono scritte in C #, ma il tuo nuovo problema richiede l'apprendimento automatico, con si fa meglio con Python), avere una buona conoscenza dei domini nel tuo progetto o il tuo monolito tratta di galvanizzare, ad esempio tutti costruiscono questo monolito e schiacciano il concetto di servizi separati.

Sono abbastanza sicuro che ci siano state un paio di domande su questo esatto articolo di MF.

La mia opinione è questa:

Un monolite con problemi di manutenzione o scalabilità viene migliorato suddividendolo in microservizi. Un tale progetto avrà quasi sempre "successo", poiché anche la suddivisione di una piccola sezione può comportare guadagni misurabili e puoi tracciare una linea sotto di essa quando sei felice.

Se il tuo mezzo monolito + una coda di messaggi e un paio di processi di lavoro contano come "Architettura di microservizi" è un argomento da tenere giù per il pub, ma sicuramente lo chiamerai così quando parlerai del progetto.

D'altra parte, qualsiasi nuovo progetto, indipendentemente dall'architettura scelta, corre il rischio di non soddisfare le aspettative, quindi naturalmente ti aspetteresti un tasso di successo inferiore. Inoltre, se hai iniziato con l'obiettivo di rendere l'intero progetto "Best Practice Microservice Architecture" da zero, potresti avventurarti in nuove tecnologie e nei bit più difficili dei microservizi.

Inoltre, dobbiamo ricordare che MF scrive da una grande prospettiva OOP. È naturalmente scettico su un approccio distribuito più moderno.

Al giorno d'oggi mi aspetterei che qualsiasi soluzione aziendale di grandi dimensioni includa un elemento di microservizi e solo un pazzo ti consiglierebbe di creare un'applicazione monolite gigante a meno che non si stia distribuendo un'unica applicazione in stile desktop.

Nella mia (vasta) esperienza ho visto molti più progetti fallire a causa di problemi di persone piuttosto che di problemi tecnologici. Sfortunatamente, alla gente non piace fallire e quindi tendono a riportare erroneamente le ragioni del fallimento e incolpare la tecnologia.

Nel mio dominio, finanza, oggigiorno la maggior parte dei nuovi progetti segue architetture di microservizi e sembra essere un'architettura vincente dal punto di vista del TCO (costo totale di proprietà). Questi progetti non sembrano fallire così spesso e quando lo fanno i motivi indicati non elencano spesso l'architettura dell'applicazione come problema.