Monolito vs microservizi: casi d'uso e una checklist per decidere

La domanda "monolite o microservizi?" è uno dei quesiti a cui è stata data più scarsa risposta nell'ingegneria del software. Risposta scarsa perché quasi sempre decisa dalla moda, dal curriculum o dall'imitazione dei big tech, e quasi mai dal problema reale che il team ha davanti.

Questo testo è per chi ha davvero bisogno di decidere. Leader tecnici, CTO, product manager di fronte alla scelta dell'architettura. Non difenderò una parte come superiore. Mostrerò i casi d'uso per ciascuno e fornirò una lista di controllo onesta per consentirti di prendere una decisione in base al tuo contesto, non a quello di Netflix.

La tesi è semplice e impopolare: per la maggior parte dei progetti, il più delle volte, il monolite ben fatto è la scelta giusta. I microservizi risolvono problemi specifici che molti team ancora non hanno e adottarli troppo presto è uno degli errori più costosi che si commettono.

Cos'è realmente ogni architettura

Monolith è il sistema costruito come un'unità: un'applicazione, una distribuzione, una banca principale. Tutto insieme, strettamente integrato. Per molto tempo la parola ha avuto un tono ingiustamente peggiorativo, monolito non è sinonimo di disordine. Un monolite mal organizzato è un disastro. Ben organizzato, è semplicità.

I microservizi suddividono il sistema in piccoli servizi indipendenti, ognuno dei quali possiede una funzionalità, comunicando attraverso interfacce. Ottengono autonomia e scalabilità granulare al prezzo della complessità distribuita.

La scelta tra loro non è tecnica in fondo. È una decisione aziendale: riguarda le dimensioni del team, la velocità del cambiamento, la portata e la tolleranza alla complessità operativa.

Casi d'uso in cui il monolite vince

monolith è la risposta giusta il più delle volte.

Vince quando la squadra è piccola. Pochi sviluppatori in un unico codice si coordinano in modo naturale, senza il sovraccarico di mantenere dozzine di servizi. Vince quando il prodotto è in una fase iniziale, ancora cercando di capire di cosa si tratta, perché cambiare i confini all’interno di un monolite è banale e cambiare i confini tra i servizi è doloroso.

Vince quando la scala è moderata, la stragrande maggioranza dei sistemi non raggiunge mai il volume che giustifica la distribuzione. E vince quando la semplicità operativa conta: una sola distribuzione, un posto per eseguire il debug, uno stack da padroneggiare. Nel settore pubblico e nei team snelli, questa semplicità è spesso ciò che garantisce la continuità.

Casi d'uso in cui vincono i microservizi

I microservizi brillano in condizioni specifiche.

Vincono quando il team è numeroso e più team devono lavorare in parallelo senza sovraccaricarsi a vicenda, ciascuno proprietario del proprio servizio e della propria implementazione. Vincono quando c’è una scala molto diseguale, con parti del sistema che richiedono risorse che altre non richiedono, consentendo la scalabilità solo di ciò che è necessario.

Vincono quando parti diverse hanno esigenze tecniche divergenti che giustificano stack diversi. E vincono quando l’isolamento dei guasti è fondamentale, quando una funzione non può, in nessun caso, sostituirne un’altra.

Notate lo schema: tutti questi casi presuppongono un problema di dimensioni. Grande squadra, grande scala, grande complessità. Senza il problema, la soluzione diventa un peso morto.

La checklist decisionale

Prima di scegliere, rispondi onestamente. Più sono i "sì" del secondo gruppo, più la bilancia pende verso i microservizi.

Segni a favore di monolith. Il team è composto da meno di, diciamo, una dozzina di persone? Il prodotto sta ancora convalidando quello che è? La scala attuale è comoda per un singolo sistema? Il team ha poca esperienza con i sistemi distribuiti? La semplicità operativa e i bassi costi infrastrutturali sono una priorità? Se la maggioranza è "sì", resta con il monolite.

Segni a favore dei microservizi. Diversi team si sovrappongono sullo stesso codice e le implementazioni diventano una coda? Ci sono parti che sono drammaticamente diverse in scala? C’è davvero bisogno di stack diversi? È necessario isolare i guasti a causa dei requisiti aziendali? L'organizzazione ha già una maturità in osservabilità, automazione e funzionamento distribuito? Se la maggioranza è “sì”, la migrazione comincia a giustificarsi.

La domanda che riassume la checklist

Se hai solo bisogno di una domanda: "Quale problema concreto i microservizi mi risolverebbero questa settimana?" Se la risposta è vaga, "diventare più moderni", "prepararsi per il futuro", non ne hai ancora bisogno. Se è specifico e doloroso, forse ne hai bisogno.

La via di mezzo che pochi considerano

La maturità richiede di parlare di una terza via. Raramente la decisione deve essere binaria e definitiva.

Il percorso più sensato per la maggior parte è quello modulare monolito: un unico sistema, ma organizzato internamente in moduli con confini chiari, come se fossero servizi non ancora separati. Si raccoglie la semplicità operativa del monolite e, quando uno specifico modulo ha davvero bisogno di diventare un servizio, l'estrazione è molto più semplice perché il confine esiste già.

Questo percorso evita i due errori opposti: il monolite di fango, impossibile da separare in seguito, e l’esplosione prematura dei microservizi che soffoca un piccolo team. Inizia in modo semplice, mantieni i confini puliti e lascia che l'architettura si evolva sotto reale pressione.

Riflessione: il costo nascosto della scelta sbagliata

Entrambi gli errori hanno dei costi, ma sono diversi.

Scegliere un monolite quando serve microservizi crea attriti di coordinamento e limiti di scala, problemi reali, ma compaiono gradualmente e danno tempo per reagire. Scegliere i microservizi troppo presto crea una complessità distribuita immediata: il piccolo team affoga nel networking, nella coerenza dei dati e nel debug distribuito e spreca mesi a costruire infrastrutture anziché prodotti. Questo errore tende ad essere più letale, perché consuma la risorsa più scarsa per chi è appena agli inizi: il tempo.

Chiusura

Monolite e microservizi non sono una disputa su quale sia l'architettura migliore. È una domanda su quale problema hai. Senza il problema della scalabilità, del team o dell’isolamento, i microservizi non rappresentano un progresso, sono una sofisticazione che costa molto e offre poco.

Una decisione matura inizia in modo semplice e si evolve su richiesta. Un buon leader tecnico resiste alla tentazione di costruire per un futuro che potrebbe non arrivare mai e sceglie l'architettura che risponde ai problemi di oggi senza chiudere le porte di domani.

Se adesso ti trovi a questo bivio, vale la pena esaminare onestamente la lista di controllo prima di decidere. Ho altri post sul blog sull'architettura, sulla scalabilità e sui casi d'uso dei microservizi e, se vuoi analizzare il tuo scenario specifico, è il tipo di conversazione che vale la pena avere.