Quando sviluppo un sistema da solo, dovrei usare i microservizi?

Sto iniziando un nuovo progetto al lavoro e probabilmente sarò quasi l'unico sviluppatore del progetto, anche se uno o due altri sviluppatori dovranno integrare applicazioni esistenti o semplici script nel progetto principale. Il progetto deve gestire l'importazione / elaborazione su larga scala di dati in streaming e in streaming, nonché l'esecuzione di codice sia guidata dagli eventi che su richiesta. Alcune parti del framework saranno fortemente legate alla CPU e alcune parti potrebbero essere pesantemente associate all'I / O; la maggior parte dei dati deve risiedere su un singolo computer, ma siamo in grado di creare un cluster e connettere le macchine virtuali per aumentare la potenza di calcolo disponibile. Probabilmente ci saranno una o più piccole applicazioni web che dipendono dai servizi forniti da questo framework di base. La lingua principale sarà Python per quasi tutto.

La mia domanda è se dovrei o meno adottare un approccio ai microservizi per uno sforzo come questo o attenermi a un'applicazione monolitica, dato che farò la maggior parte dello sviluppo da solo. Il mio pensiero è che i microservizi (usando Nameko) forniscano una naturale separazione tra elementi del framework che hanno diversi modelli di esecuzione (pipeline di dati, eventi lanciati, applicazioni su richiesta, applicazioni web, ecc.) E un modo chiaro per distribuire il carico di lavoro e comunicazione attraverso più processi. La mia preoccupazione è che probabilmente finirò con un cluster Kubernetes da gestire (ho familiarità con Docker, ma ancora abbastanza nuovo con Kubernetes), sono necessari più servizi (rabbitmq, redis, ecc.) Solo per facilitare l'esecuzione del sistema, e potenzialmente un sacco di piccoli pezzi di codice per implementare effettivamente tutte le funzionalità necessarie che

Per un progetto con poco più di un singolo sviluppatore, i microservizi semplificano ancora lo sviluppo e la manutenzione di un sistema complicato come questo? Esistono invece metodi / sistemi / framework che dovrei prendere in considerazione o per ridurre le spese generali di progettazione del sistema in questo modo?

I microservizi sono generalmente indesiderabili perché trasformano il tuo software in un sistema distribuito e i sistemi distribuiti rendono tutto molto più difficile. Ma un'architettura orientata ai servizi presenta alcuni importanti vantaggi:

• servizi diversi possono essere sviluppati e distribuiti in modo indipendente da diversi team
• servizi diversi possono essere ridimensionati in modo indipendente

Poiché sarai l'unico sviluppatore, non avrai bisogno della flessibilità necessaria per sviluppare i servizi in modo indipendente.

Tuttavia, si nota che alcune parti potrebbero essere associate alla CPU. Quindi potrebbe essere desiderabile ridimensionare quelli indipendentemente dal resto dell'applicazione. In tal caso, ciò non significa che devi trasformare l'intero progetto in un'architettura a microservizi. Hai solo bisogno di spostare quella parte ad alta intensità di CPU nel proprio servizio e puoi tenere il resto in un comodo monolite. Lungo quali linee il sistema dovrebbe essere diviso è difficile da dire, ma in generale l'idea DDD di "contesti limitati" è una buona linea guida.

Nota che i monoliti non sono male. I monoliti non eguagliano un enorme progetto disordinato disordinato. Dove è possibile dividere il sistema in diversi microservizi, è anche possibile dividere il sistema in diversi componenti all'interno di un monolite. La separazione tra questi componenti è solo più visibile e applicata più chiaramente in un'architettura orientata ai servizi. Ciò significa anche che per un sistema ben progettato, in un secondo momento dovrebbe essere abbastanza semplice trasformare un componente in un servizio. Quindi non devi decidere adesso, puoi passare ai microservizi se e quando un monolite si è dimostrato inadatto.

Considera anche il concetto di Microservice Premium (2015) di Martin Fowler : i microservizi presentano una sostanziale complessità propria, oltre alla complessità di base del tuo sistema. Devi pagare questo "premio" in termini di riduzione della produttività. Ciò significa che per progetti semplici, i microservizi ti rendono meno produttivo. Questo cambia per progetti più complessi: mentre una soluzione monolitica potrebbe diventare sempre più difficile da lavorare, un'architettura a microservizi si ridimensiona molto meglio e richiede uno sforzo pressoché costante. Devi sapere se lo sforzo iniziale aggiuntivo dei microservizi vale la pena dato al tuo sistema software. Dato che stai ponendo questa domanda, la risposta è probabilmente "no". Fowler continua:

Quindi la mia linea guida principale sarebbe quella di non considerare nemmeno i microservizi a meno che tu non abbia un sistema troppo complesso da gestire come monolite. La maggior parte dei sistemi software dovrebbe essere costruita come una singola applicazione monolitica. Presta attenzione alla buona modularità all'interno di quel monolito, ma non cercare di separarlo in servizi separati.