Hai un'applicazione che funziona. Forse è un gestionale interno, forse un portale clienti, forse un e-commerce con logica custom. A un certo punto qualcuno in riunione dice: "Dovremmo passare ai microservizi."
La frase suona moderna. Suona come la cosa giusta da fare. Ma raramente chi la dice sa spiegare cosa cambierebbe, per chi, e a quale costo.
Questa guida serve a rispondere a quella domanda in modo concreto, senza hype, guardando al tipo di azienda che sei oggi e a quella che potresti diventare.
Un'architettura monolitica mette tutta la logica applicativa in un unico codebase: autenticazione, gestione ordini, notifiche, reportistica, tutto insieme. Si compila, si testa e si deploya come un blocco unico.
I microservizi spezzano quella logica in servizi separati, ciascuno con il proprio codebase, il proprio database, il proprio ciclo di rilascio. Il servizio "ordini" non sa niente del servizio "notifiche": comunica con lui via API o messaggi asincroni.
La differenza non è solo tecnica. Cambia come il team lavora, come si scala l'infrastruttura, quanto costa tenere il sistema in piedi.
Diciamolo chiaramente: il monolite ha una cattiva reputazione che non si merita del tutto.
Amazon, Netflix, Shopify hanno iniziato con architetture monolitiche. Hanno migrato verso i microservizi quando avevano centinaia di sviluppatori che si pestano i piedi a vicenda sullo stesso codebase, non prima. Per una PMI con un team di 3-10 persone, quella situazione è lontana anni luce.
Un monolite ben strutturato è più veloce da costruire, più semplice da debuggare e molto meno costoso da mantenere. Se il tuo backend regge il carico attuale senza problemi, non hai nessun motivo tecnico per cambiarlo.
Il problema reale dei monoliti non è l'architettura in sé: è quando crescono senza disciplina, accumulando dipendenze circolari e logica sparpagliata ovunque. Quel tipo di monolite diventa impossibile da toccare. Ma è un problema di qualità del codice, non di architettura.
| Situazione | Architettura consigliata | Perché |
|---|---|---|
| Startup o MVP in fase iniziale | Monolite | Velocità di sviluppo prioritaria, requisiti ancora fluidi |
| PMI con 1-2 sviluppatori backend | Monolite modulare | I microservizi richiedono competenze DevOps che non si ammortizzano |
| Team distribuito su più prodotti distinti | Microservizi (selettivi) | Team diversi possono rilasciare in autonomia senza bloccarsi |
| Un modulo specifico sotto carico estremo | Estrai solo quel modulo | Scalare tutto il monolite per un solo collo di bottiglia è inefficiente |
| Piattaforma con SLA differenziati per area | Microservizi | Puoi garantire uptime diverso per funzionalità critiche vs secondarie |
La regola pratica: se il tuo team non ha già esperienza con Kubernetes, Docker Compose in produzione e monitoring distribuito, i microservizi ti costeranno mesi di setup prima di scrivere una riga di logica di business.
Ogni servizio separato porta con sé un overhead che spesso non viene conteggiato nella stima iniziale.
Servono strumenti per orchestrare i container (Kubernetes o alternative più leggere), un sistema per tracciare le richieste che attraversano più servizi (distributed tracing), un modo per gestire la coerenza dei dati tra database separati. Serve anche qualcuno che sappia fare tutto questo.
Su un monolite, un bug si traccia aprendo i log di un'applicazione. Su un sistema a microservizi, la stessa richiesta passa per tre o quattro servizi: capire dove si è rotto richiede strumenti dedicati e una cultura di monitoring che va costruita dall'inizio.
Questo non significa che i microservizi siano sbagliati. Significa che il costo operativo nel tempo è sensibilmente più alto, e va messo in conto prima di partire.
Il modular monolith, o monolite modulare, è probabilmente l'architettura più adatta alla maggior parte delle PMI italiane che sviluppano software custom.
L'idea è semplice: un unico deployment, ma con confini netti tra i moduli interni. Il modulo "fatturazione" non importa classi dal modulo "magazzino" in modo diretto: comunica attraverso interfacce definite, come se fossero servizi separati. Il codebase è uno, ma la struttura interna è già pronta per una futura separazione.
Con Laravel, per esempio, si ottiene questo risultato usando i Domain-Driven Design modules o i package interni: ogni dominio di business ha la sua cartella, i suoi modelli, la sua logica. Il giorno in cui un modulo deve diventare un microservizio separato, il lavoro di estrazione è già per metà fatto.
Se stai costruendo un'applicazione custom da zero e hai qualche dubbio su dove potrebbe arrivare, raccontaci il tuo caso prima di scegliere l'architettura: a volte bastano 30 minuti di confronto per evitare mesi di refactoring.
Tre domande concrete da farti prima di decidere.
Quante persone toccano il codice contemporaneamente? Se hai un team piccolo e compatto, un monolite ben organizzato è quasi sempre la scelta migliore. I microservizi nascono per risolvere problemi di coordinamento tra team grandi, non problemi tecnici puri.
Hai moduli con requisiti di carico radicalmente diversi? Se il 90% del tuo traffico colpisce un solo modulo mentre il resto è quasi inattivo, ha senso estrarre quel modulo e scalarlo in modo indipendente. Scalare l'intera applicazione per un collo di bottiglia localizzato è uno spreco di risorse.
Qual è il tuo orizzonte temporale? Un MVP che deve essere live in due mesi non può permettersi l'overhead di setup di un'architettura a microservizi. Un sistema che deve reggere per cinque anni con team in crescita ha un calcolo diverso.
La migrazione non si fa tutta in una volta. Il pattern più usato si chiama Strangler Fig: si estrae un servizio alla volta, reindirizzando gradualmente il traffico, mentre il monolite originale rimane attivo e si "svuota" progressivamente.
Il primo servizio da estrarre è quasi sempre quello con il carico più alto o il team più autonomo. Non si inizia dal modulo più complesso o da quello con più dipendenze: si sceglie il confine più netto e si impara il processo su qualcosa di controllabile.
Una migrazione complessa richiede mesi, non settimane. Chi ti promette il contrario sta sottostimando il lavoro di allineamento dei dati, gestione delle transazioni distribuite e testing end-to-end tra servizi.
Il marketing intorno ai microservizi è gonfiato. Vengono venduti come la scelta "moderna" e il monolite come la scelta "legacy", ma questa narrativa serve più ai vendor di infrastruttura cloud che alle PMI che devono consegnare prodotti funzionanti.
Per la maggior parte delle aziende italiane con meno di 50 dipendenti e un team tech di 2-5 persone, un monolite modulare ben scritto è la scelta più intelligente oggi. Lascia aperta la porta ai microservizi domani, senza pagare il prezzo dell'infrastruttura adesso.
La domanda giusta non è "microservizi o monolite?". È: "quale architettura mi permette di muovermi veloce oggi e di non bloccarmi domani?"
Q: Qual è la differenza principale tra microservizi e architettura monolitica?
A: In un monolite, tutta la logica applicativa vive in un unico codebase deployato insieme. Con i microservizi, ogni funzionalità è un servizio indipendente con il proprio ciclo di rilascio. La differenza pratica si sente nel come si scala, si aggiorna e si gestisce il sistema nel tempo.
Q: Una PMI dovrebbe iniziare con i microservizi?
A: Nella maggior parte dei casi, no. Un monolite ben strutturato è più veloce da costruire, più semplice da mantenere e sufficiente per quasi tutti i carichi di lavoro iniziali di una PMI. I microservizi aggiungono complessità operativa che raramente si giustifica nelle fasi iniziali.
Q: Quando ha senso migrare da monolite a microservizi?
A: Quando team diversi modificano le stesse parti del codice creando colli di bottiglia, quando un singolo modulo consuma risorse sproporzionate rispetto al resto, o quando hai bisogno di rilasciare parti del sistema in modo indipendente senza bloccare tutto il resto.
Q: I microservizi costano di più da sviluppare e mantenere?
A: Sì, quasi sempre. Richiedono infrastruttura aggiuntiva (orchestrazione container, distributed tracing, monitoring dedicato), più ore di sviluppo e competenze DevOps specifiche. Il costo operativo nel tempo è sensibilmente più alto rispetto a un monolite equivalente.
Q: Esiste una via di mezzo tra monolite e microservizi?
A: Sì: il monolite modulare. Il codice vive in un unico deployment ma è organizzato in moduli con confini netti e dipendenze esplicite. Permette di separare i servizi in futuro senza la complessità operativa immediata dei microservizi puri.
Se stai progettando l'architettura di un'applicazione custom e vuoi capire quale approccio regge il tuo caso specifico, in Press Start possiamo fare un'analisi tecnica della tua situazione. Scrivici e ti diciamo cosa ha senso per te oggi.
