Monolite, microservizi, quando ha senso sceglierli e quando è overengineering. Una guida completa per chi commissiona software su misura e vuole capire davvero le differenze di architettura.
Microservizi e monolite non sono una gara. La decisione utile nasce da confini di dominio, team, carico e rischio: distribuisci una responsabilità quando l'autonomia che ottieni vale la complessità operativa che introduci.
Immagina un hotel. Nel modello tradizionale (monolite), una singola persona gestisce tutto: check-in, pulizie, ristorante, manutenzione. Se quella persona si ammala, l'intero hotel si ferma. Nel modello moderno (microservizi), ogni reparto ha il suo team: reception, housekeeping, cucina, tecnici. Ciascuno lavora in autonomia, comunica con gli altri quando serve, e se un reparto ha un problema, gli altri continuano a funzionare.
In ambito software, l'architettura a microservizi significa dividere l'applicazione in servizi indipendenti, ciascuno con una responsabilità specifica, che comunicano tra loro tramite API (interfacce standardizzate).
Esempio concreto: Un gestionale tradizionale (monolite) contiene tutto il codice in un unico blocco: fatturazione, magazzino, clienti, contabilità. Un gestionale a microservizi divide queste funzioni in servizi separati: ogni servizio ha il suo database, il suo codice, il suo team di sviluppo. Comunica con gli altri tramite API web.
La differenza non è solo tecnica: cambia il modo in cui i team lavorano, come scala l'applicazione, come fallisce quando qualcosa va male.
Un'applicazione monolitica (un blocco unico)
Un'applicazione a microservizi (un insieme di servizi)
La parte più importante: la scelta non è 'microservizi = meglio'. Dipende da cosa stai costruendo, da quante persone lo sviluppano, da come vuoi che evolva nel tempo.
1. Team autonomi e paralleli
Con un monolite, due team che lavorano su parti diverse dell'applicazione si creano dipendenze costanti: 'il tuo codice aspetta il mio, non puoi deployare finché non finisco io'. Con i microservizi, ogni team gestisce il suo servizio, deploya quando è pronto, comunica tramite API ben definite. La velocità di sviluppo aumenta perché non sei bloccato dalle scelte altrui.
2. Scalabilità mirata
Se il tuo gestionale ha una parte che riceve molte richieste (ad esempio, le ricerche nel magazzino), con un monolite devi scalare l'intera applicazione. Con i microservizi, scala solo il servizio magazzino, risparmiando risorse e costi. Ogni servizio ha le sue risorse, la sua topologia, la sua strategia di caching.
3. Resilienza: il fallimento non è totale
Se il servizio di fatturazione va down, i tuoi clienti non possono emettere fatture. Ma possono ancora fare ordini, gestire il magazzino, registrare spedizioni. Il sistema degrada gracefully (con eleganza) invece di crollare completamente. Questo è fondamentale per applicazioni business-critical.
4. Libertà tecnologica
Il servizio fatturazione può essere scritto in Python, il magazzino in Java, gli ordini in Go. Non devi forzare tutto nello stesso linguaggio e framework. Scegli lo strumento migliore per ogni problema.
5. Evoluzione graduale
Con un monolite, rinnovare il codice è rischioso: una modifica tira tutto. Con i microservizi, puoi riscrivere un servizio completamente senza toccare gli altri, e poi switchare il traffico. Riduce il rischio di regressioni.
1. Complessità operativa maggiore
Un monolite è semplice da deployare: accendi un server, ci metti la tua applicazione, funziona. Con i microservizi, ogni servizio ha il suo deploy, il suo ciclo di vita, la sua versione. Devi orchestrare, monitorare, aggiornare molte cose. Senza buoni strumenti (Kubernetes, Docker, automazione), diventa un caos.
2. Network complexity e latenza
Dentro un monolite, una funzione chiama un'altra e i dati passano in memoria: istantaneo. Con i microservizi, il servizio A chiama il servizio B tramite rete HTTP/gRPC: più lento, meno affidabile. Una catena di servizi significa round trip di rete multipli. Se uno è lento, tutto rallenta.
3. Debugging diventa un incubo
Con un monolite, un errore è in un punto. Con i microservizi, un bug potrebbe essere causato da interazioni tra servizi, timing, ordini di operazioni. Tracciare una singola operazione attraverso più servizi richiede distributed tracing, log centralizzati, monitoraggio sofisticato.
4. Gestione della coerenza dei dati
Con un database centralizzato, una transazione garantisce coerenza. Con i microservizi, ogni servizio ha il suo database. Se il servizio A aggiorna un cliente e il servizio B aggiorna i suoi ordini, come garantisci che i due dati rimangono coerenti se uno dei due fallisce? Serve application-level logic complessa (compensating transactions, saga pattern).
5. Non adatto a piccoli team o progetti semplici
Se sei una startup di poche persone che scrive una semplice app, i microservizi ti uccidono di overhead. Stai investendo gran parte del tempo a gestire infrastruttura e il resto a scrivere logica di business. È antieconomico.
Ha senso se:
NON ha senso se:
| Criterio | Monolite | Microservizi |
|---|---|---|
| Numero di developer | Pochi (1-5) | Diversi (6+) |
| Carico di traffico | Omogeneo (crescita uniforme) | Non omogeneo (picchi su funzioni specifiche) |
| Ritmo di deploy | Una volta alla settimana / al mese | Più volte al giorno per servizi diversi |
| Criticità (SLA) | Downtime accettato a intervalli | Disponibilità elevata richiesta, downtime minimo accettabile |
| Infrastruttura | Server tradizionale, VPS, hosting semplice | Cloud (AWS, Azure, GCP), Kubernetes, containers |
| Competenze DevOps | Minime (deploy, database, backup) | Avanzate (orchestration, monitoring, logging distribuito) |
| Costo iniziale | Basso | Alto |
| Orizzonte del progetto | Breve / MVP | Lungo / prodotto core |
Regola empirica: Inizia con un monolite. Migra ai microservizi quando il monolite diventa un problema (difficile scalare, difficile deployare, difficile per i team). Non il contrario.
Se sei una PMI che commissiona software personalizzato, ecco cosa devi sapere.
Scenario 1: Hai un team interno piccolo (poche persone)
Richiedi un monolite. È più semplice, più veloce da mettere in produzione, più economico. Puoi sempre evolvere se il business cresce. Se l'agenzia ti propone microservizi, chiedi 'perché?'. Se la risposta è 'è moderno', è il segnale sbagliato. La giustificazione deve essere tecnica e misurabile.
Scenario 2: Hai più team (una divisione sviluppo interna)
Valuta i microservizi, ma solo se:
Scenario 3: È un software su misura per risolvere un problema specifico
Inizia semplice (monolite, se non è enorme). Se e quando il software cresce, i dati e il traffico aumentano realmente, e i team si moltiplicano, allora valuta una migrazione graduale. Non costruire per un futuro che potrebbe non venire.
Costo: la conversazione che conta
Un monolite ben fatto costa meno da sviluppare e meno da mantenere. Un'architettura a microservizi ben fatta costa di più, ma quando è necessario, ne vale la pena. Un'architettura a microservizi male implementata è il peggior dei due mondi: costosa, lenta, fragile.
Prima di firmare il contratto con l'agenzia, definisci chiaramente: quanti developer lavoreranno? Per quanto tempo? Quale ritmo di deploy? Quale disponibilità serve? Sulla base di questa analisi, l'agenzia dovrebbe proporre l'architettura, non il contrario.
I microservizi non sono una soluzione a un problema di architettura. Sono una soluzione a un problema di organizzazione: come diversi team lavorano insieme su un'applicazione gigante senza intralciarsi.
Approfondisci i temi correlati a questa guida:
Monolite, microservizi, o un'architettura ibrida: ti aiutiamo a valutare cosa ha senso per il tuo business e il tuo team.