Il falso dilemma: monolite o microservizi
Il dibattito "monolite vs microservizi" presenta una falsa dicotomia. Un monolite non deve essere per forza un Big Ball of Mud dove tutto dipende da tutto. E i microservizi non sono l'unico modo per avere separazione e modularita. Il monolite modulare e la terza via: un'applicazione deployata come un singolo artefatto, ma organizzata internamente in moduli con confini espliciti.
Shopify — una delle piattaforme e-commerce più grandi del mondo — ha scelto il monolite modulare con Rails. GitHub ha un monolite modulare Ruby. Basecamp idem. Non e una scelta per principianti: e una scelta architetturale consapevole che privilegia la semplicità operativa senza sacrificare la struttura.
Cos'e un modulo
Un modulo e una porzione dell'applicazione con:
-
Confini espliciti: un namespace dedicato, una directory propria.
App\Modules\Orders\,App\Modules\Catalog\,App\Modules\Users\. - API pubblica: ogni modulo espone un'interfaccia limitata (un Service, un Facade) che gli altri moduli possono usare. Le classi interne sono private al modulo.
- Database isolato (logicamente): ogni modulo possiede le proprie tabelle. Il modulo Orders non accede direttamente alle tabelle del modulo Catalog — passa attraverso l'API pubblica.
- Comunicazione esplicita: i moduli comunicano tramite interfacce definite o eventi, non tramite import diretti di classi interne.
Esempio: un gestionale e-commerce modulare
-
Modulo Catalog: gestisce prodotti, categorie, prezzi. Espone
CatalogService::getProduct(int $id)eCatalogService::checkAvailability(int $productId, int $qty). -
Modulo Orders: gestisce ordini, carrello, checkout. Chiama
CatalogServiceper verificare disponibilita, non accede alle tabelle prodotti direttamente. -
Modulo Payments: gestisce pagamenti e fatturazione. Riceve eventi
OrderPlaceddal modulo Orders. - Modulo Users: gestisce registrazione, profili, permessi. Gli altri moduli lo usano per autenticazione e autorizzazione.
Ogni modulo può evolvere indipendentemente. Il team che lavora sul Catalog non rischia di rompere gli Orders. Le dipendenze sono esplicite e unidirezionali.
Vantaggi rispetto al monolite classico
- Confini chiari: sai dove finisce un modulo e dove inizia un altro. I refactoring sono localizzati.
- Dipendenze visibili: se un modulo importa classi da un altro, e un code smell visibile — non un accoppiamento nascosto in una query SQL.
- Team scaling: team diversi possono lavorare su moduli diversi con meno conflitti.
- Migrazione futura: se un modulo diventa un collo di bottiglia, estrarlo in un microservizio e fattibile perché i confini sono già definiti.
Vantaggi rispetto ai microservizi
- Deploy singolo: un artefatto, un server, un deploy. Nessun orchestratore, nessun service mesh, nessun distributed tracing.
- Transazioni atomiche: le operazioni cross-modulo possono usare transazioni database. Nei microservizi servono saga e compensazioni.
- Debugging semplice: un processo, uno stack trace, un log. Niente chiamate di rete da debuggare.
- Costo operativo basso: un VPS da 20 EUR/mese invece di un cluster Kubernetes.
Quando scegliere il monolite modulare
- Scegli il monolite modulare quando il team e piccolo-medio (2-10 sviluppatori) e la complessità e nel dominio, non nell'infrastruttura
- Scegli il monolite modulare quando vuoi struttura e separazione senza il costo operativo dei microservizi
- Scegli il monolite modulare come punto di partenza: puoi sempre estrarre un microservizio dopo, ma non puoi facilmente tornare indietro
- Scegli i microservizi solo quando hai team grandi (50+), requisiti di scalabilità asimmetrica reali, e budget operativo adeguato
Il monolite modulare e la scelta pragmatica per la maggior parte dei progetti reali. Non e meno sofisticato dei microservizi — e più disciplinato: richiede la stessa cura nella definizione dei confini, senza la complessità della rete distribuita.
Top comments (0)