Microservices: MonolithFirst?

Se la tua azienda ha effettuato microservizi per un po 'di tempo, alcuni pezzi potrebbero essere già stati creati e devi semplicemente incorporarli. Esempi probabili potrebbero essere l'autenticazione come servizio o la memorizzazione di dati BLOB. In tal caso, hai già definito i limiti e stai riutilizzando il codice in una nuova applicazione. Questa è una buona cosa.

Per un nuovo codice in cui non si è sicuri di dove debba essere il limite, crearlo in un unico servizio. Se lo tieni modulare, puoi separare i microservizi da esso se necessario. Soprattutto perché trovi pezzi del tuo servizio che hanno bisogno di scalare in modo diverso rispetto agli altri.

Il vantaggio dei microservizi è che è possibile aggiungere istanze per ridimensionare il lavoro eseguito su richiesta. Se alcuni dei tuoi lavori arrivano a raffiche, potrebbe aver senso separarli nel proprio microservizio.

In generale:

• Se disponi già di microservizi, riutilizzali
• Se stai creando qualcosa di nuovo, fai in modo che l'idea funzioni per prima
• Mentre stai costruendo, prova a mantenere le cose modulari in modo che alcuni servizi possano essere facilmente scomposti
• Mentre stai costruendo, se una parte del tuo servizio deve essere in grado di scalare su richiesta a una velocità diversa, separala nel suo stesso servizio

All too often, we hear useful guidelines from smart people with good reputations like Martin Fowler, and then turn it into a hard doctrine that can't be swayed from in any way.

Devi prendere dichiarazioni come quelle nello spirito di come sono intese. Martin Fowler sta cercando di salvare le persone dalla paralisi attraverso l'analisi e dire loro di costruire qualcosa che funzioni per primo. Puoi sempre smembrarlo in un secondo momento, quando ne sai di più sul funzionamento della tua applicazione.

I vantaggi più immediati dei microservizi possono essere ottenuti mediante la 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 singolo scopo, sedersi sul proprio repository, utilizzare il proprio schema DB, gestirlo con la propria configurazione, disporre del proprio backlog di funzionalità e pianificazione del rilascio. 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 dal separare gli schieramenti, che è davvero prezioso solo quando si dispone di una scala sufficiente per renderlo necessario. Se il tuo codice è già modulare, allora sarà una migrazione più semplice quando sarà il momento.

Secondo me, può essere utile sviluppare prima un monolite (o meglio: sviluppare parti della tua applicazione come un monolite).

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

Dovresti smettere di farlo se hai bisogno di introdurre diverse tecnologie nel mix (ad es. le tue parti esistenti sono scritte in C #, ma il tuo nuovo problema richiede l'apprendimento automatico, con il meglio con python), avere una buona comprensione del domini nel tuo progetto o il tuo monolith di trattare per galvanizzare, ad es ognuno costruisce questo monolite e schiaccia la nozione di servizi separati.

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

Il mio punto di vista è questo:

Un monolite con problemi di manutenzione o scalabilità è migliorato suddividendolo in micro servizi. Un simile progetto sarà quasi sempre "di successo" in quanto anche abbattere una piccola parte può portare a guadagni misurabili e puoi tracciarne una linea quando sei felice.

Se il tuo mezzo monolite + una coda di messaggi e un paio di processi di lavoro contano come 'Microservice Architecture' è un argomento per avere giù il pub, ma lo chiamerai chiamandolo che quando parli riguardo al progetto.

D'altra parte, qualsiasi nuovo progetto indipendentemente dall'architettura scelta rischia di non soddisfare le aspettative, quindi naturalmente ti aspetteresti un tasso di successo più basso. Inoltre, se hai iniziato a mirare a rendere l'intera "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 verso un approccio distribuito più moderno.

Al giorno d'oggi mi aspetterei che qualsiasi soluzione aziendale di grandi dimensioni incorporasse un elemento dei microservizi e solo un pazzo ti consiglierebbe di realizzare una gigantesca applicazione monolite a meno che non stia distribuendo un'unica applicazione in stile desktop.

Nella mia (vasta) esperienza ho assistito al fallimento di molti altri progetti a causa di problemi di persone rispetto ai problemi di tecnologia. Sfortunatamente, alla gente non piace fallire e quindi tendono a riportare erroneamente le ragioni del fallimento e incolpare la tecnologia.

Nel mio dominio, la finanza, la maggior parte dei nuovi progetti seguono le architetture dei microservizi in questi giorni, e sembra essere un'architettura vincente dal punto di vista del TCO (total cost of ownership). Questi progetti non sembrano fallire così spesso, e quando fanno le ragioni fornite spesso non elencano l'architettura dell'applicazione come il problema.