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

Question

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

#1 da (48 voti)

29

Sto iniziando un nuovo progetto al lavoro, e sarà probabilmente 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'ingest / elaborazione dei dati di massa e di streaming su piccola scala e l'esecuzione di codice sia su evento che su richiesta. Alcune parti del framework saranno pesantemente vincolate alla CPU, e alcune parti potrebbero essere strongmente vincolate all'I / O; la maggior parte dei dati deve vivere su una singola macchina, ma siamo in grado di creare un cluster e collegare 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 principale. La lingua principale sarà Python per quasi tutto.

La mia domanda è se dovrei adottare un approccio microservizi a uno sforzo del genere o attenermi a un'applicazione monolitica, dato che svolgerò la maggior parte dello sviluppo da solo. Il mio pensiero è che i microservizi (utilizzando Nameko) forniscono una separazione naturale tra elementi del framework che hanno diversi modelli di esecuzione (pipeline di dati, eventi lanciati, on-demand, 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 per Kubernetes), più servizi (rabbitmq, redis, ecc.) Richiesti solo per facilitare l'esecuzione del sistema, e potenzialmente molti piccoli pezzi di codice per implementare effettivamente tutte le funzionalità necessarie di cui abbiamo bisogno nel framework.

Per un progetto con poco più di un singolo sviluppatore, i microservizi semplificano ancora lo sviluppo e il mantenimento di un sistema complicato come questo? Ci sono metodi / sistemi / framework che dovrei considerare di utilizzare, o ridurre l'overhead coinvolto nella progettazione del sistema in questo modo?

python microservices application-design

posta scnerd 05.10.2018 - 16:42

fonte

1 risposta

Leggi altre domande sui tag python microservices application-design

Motivi per non utilizzare più sistemi di controllo versione? Quali sono i profitti che hai visto prendersi cura del debito tecnico?

score 48 · Accepted Answer

I microservizi sono generalmente indesiderati perché trasformano il 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 scalati in modo indipendente

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

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

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

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

So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.