Microservizi vs Monolite: Come Scegliere in Base alla Dimensione del Team

In questo articolo:

• La falsa dicotomia nel dibattito microservizi vs monolite
• Quando il monolite è la scelta architetturale corretta
• Quando i microservizi hanno senso
• Il costo della decomposizione prematura
• La scomposizione del monolite con lo strangler fig pattern
• Conclusione

Il dibattito microservizi vs monolite ha consumato enormi energie ingegneristiche nell’ultimo decennio. I microservizi sono diventati sinonimo di architettura moderna e i monoliti sono stati associati ai sistemi legacy di cui i team si vergognavano. Nessuna delle due associazioni è accurata. L’architettura giusta dipende dalla dimensione del team, dalla struttura organizzativa, dalla complessità del sistema e dalla maturità del processo di consegna. Scegliere i microservizi prima che l’organizzazione sia pronta per loro crea una complessità distribuita più difficile da gestire del monolite che ha sostituito. Questo articolo fornisce un framework per fare la scelta basandosi su vincoli reali piuttosto che sulla moda architetturale.

La Falsa Dicotomia nel Dibattito Microservizi vs Monolite

L’inquadratura microservizi vs monolite implica due opzioni discrete. In realtà, lo spettro dei pattern architetturali software include monoliti modulari, architetture orientate ai servizi e vari approcci ibridi che non si adattano perfettamente a nessuna delle due categorie.

Un monolite modulare è un’unità deployabile singola con confini di modulo interni ben definiti. Viene distribuito come un unico processo ma ha la struttura interna di un sistema orientato ai servizi. Questa architettura è spesso il passo intermedio corretto per i team che hanno superato un monolite disorganizzato ma non sono ancora pronti per l’overhead operativo dei microservizi.

La scelta tra monolite e microservizi non è nemmeno permanente. Molte architetture a microservizi di successo sono iniziate come monoliti e sono state decomposti incrementalmente man mano che il team cresceva e i requisiti di scalabilità del sistema diventavano più chiari.

La Legge di Conway afferma che le organizzazioni costruiscono sistemi che rispecchiano le loro strutture di comunicazione. Un team di cinque ingegneri che sviluppa un prodotto SaaS non ha l’overhead di comunicazione che i microservizi sono progettati per gestire. L’architettura dovrebbe adattarsi all’organizzazione, non viceversa.

Quando il Monolite è la Scelta Architetturale Corretta

Un monolite è il punto di partenza corretto per la maggior parte dei nuovi prodotti e per i team al di sotto di una certa dimensione. La semplicità operativa di un’unità deployabile singola è significativa. C’è una sola pipeline CI, un solo processo di deployment, un solo posto dove guardare quando qualcosa si rompe e un solo codebase da navigare.

Condizioni specifiche che favoriscono un monolite:

Team con meno di venti ingegneri. Al di sotto di questa soglia, l’overhead di comunicazione che i microservizi sono progettati ad affrontare non esiste in modo significativo. Gli ingegneri possono coordinarsi direttamente.

Confini di dominio poco chiari. Se il prodotto sta ancora evolvendo rapidamente e il modello di dominio non è stabile, i confini dei microservizi definiti oggi saranno sbagliati tra sei mesi.

Maturità infrastrutturale limitata. I microservizi richiedono service discovery, tracing distribuito, logging centralizzato e infrastruttura di orchestrazione. I team senza una forte capacità DevOps trascorreranno più tempo a gestire l’infrastruttura che a costruire il prodotto.

Prodotti in fase iniziale. La velocità di iterazione conta di più all’inizio. Un monolite ben strutturato può essere refactorizzato. Un’architettura a microservizi mal decomposta richiede negoziazioni di contratti e deployment coordinati per ogni modifica.

Quando i Microservizi Hanno Senso

I microservizi sono appropriati quando sono soddisfatte condizioni specifiche. Non sono appropriati semplicemente perché l’azienda ha raggiunto un certo round di finanziamento o perché altre aziende li stanno usando.

Requisiti di scaling indipendenti. Se una parte del sistema ha caratteristiche di scalabilità significativamente diverse dal resto, isolarla come servizio le consente di scalare in modo indipendente.

Proprietà indipendente del team. Quando team diversi posseggono parti diverse del prodotto e devono effettuare deployment indipendentemente senza coordinarsi con altri team, i confini dei servizi che si allineano con i confini del team abilitano il deployment autonomo.

Isolamento normativo o di conformità. Alcuni sistemi richiedono che i componenti che gestiscono dati sensibili vengano distribuiti, verificati e protetti separatamente dal resto del sistema.

Confini di dominio provati. I microservizi funzionano meglio quando il modello di dominio è stabile e ben compreso. Se stai eseguendo un monolite da anni e i confini di dominio sono chiari, decomporlo lungo quei confini è meno rischioso che definirli da zero.

Il Costo della Decomposizione Prematura

La decomposizione prematura è uno degli errori architetturali più costosi che un team può commettere. Il costo non è solo immediato. Si accumula nel tempo.

Quando un sistema viene decomposto prima che i confini di dominio siano compresi, vengono definiti i confini di servizio sbagliati. Le chiamate che dovrebbero essere in-process diventano chiamate di rete. I dati che dovrebbero essere in una singola transazione abbracciano più servizi.

L’overhead operativo dei microservizi è anche sottovalutato. Ogni servizio ha bisogno della propria pipeline di deployment, del proprio monitoraggio, della propria configurazione di scaling e del proprio runbook. Per un team di dieci ingegneri che gestisce quindici servizi, una frazione significativa della capacità ingegneristica va a overhead operativo.

I team che hanno decomposto prematuramente si trovano spesso con un monolite distribuito: servizi che vengono distribuiti in modo indipendente ma strettamente accoppiati a livello di dati e API. Questa architettura ha la complessità operativa dei microservizi senza i benefici di indipendenza. È più difficile da modificare rispetto al monolite originale.

Affrontare questo tipo di debito tecnico architetturale richiede o il riconsolidamento dei servizi o il refactoring attento dell’accoppiamento.

La Scomposizione del Monolite con lo Strangler Fig Pattern

Per i team che hanno un monolite funzionante e vogliono decomporlo in modo incrementale, lo strangler fig pattern è l’approccio più affidabile. Prende il nome da un albero che cresce attorno a una pianta ospite, sostituendola gradualmente.

Il pattern funziona come segue: identifica un bounded context all’interno del monolite che ha input e output chiari. Estrai la funzionalità dietro un’interfaccia mantenendo l’implementazione all’interno del monolite. Sposta gradualmente l’implementazione a un nuovo servizio mantenendo l’interfaccia. Una volta che l’implementazione è completamente esterna, rimuovi il codice interno.

Questo approccio ha diversi vantaggi rispetto alla decomposizione big-bang. Il sistema continua a funzionare durante tutta la migrazione. Il confine del servizio è provato dal codice esistente prima di essere reso permanente. Il rollback è possibile in qualsiasi fase. E il team costruisce esperienza con i microservizi in modo incrementale piuttosto che impegnarsi in una decomposizione completa prima di comprendere i requisiti operativi.

Lo strangler fig pattern richiede disciplina. L’interfaccia deve essere mantenuta in modo coerente durante la migrazione e il team deve resistere alla tentazione di costruire nuove funzionalità su entrambi i lati del confine. Un piano di modernizzazione legacy chiaro con milestone definite previene il blocco della migrazione a metà.

Conclusione

La decisione microservizi vs monolite è una funzione della dimensione del team, della struttura organizzativa, della maturità del dominio e della capacità infrastrutturale. Per la maggior parte dei team con meno di venti ingegneri e un dominio in evoluzione, un monolite ben strutturato o un monolite modulare è la scelta corretta. I microservizi diventano appropriati quando lo scaling indipendente, l’autonomia del team o i requisiti di conformità giustificano l’overhead operativo.

Quando la decomposizione è la mossa giusta, lo strangler fig pattern fornisce un percorso incrementale che evita il costo della decomposizione prematura consentendo all’architettura di evolversi con l’organizzazione.

Hai un codebase con questi problemi? Parliamo del tuo sistema