Il mito dei microservizi
I microservizi sono diventati una buzzword dell industria software: sembrano la scelta moderna, scalabile, da "azienda seria". Ogni conferenza tech ne parla, ogni architettura su Medium li include, ogni job posting li menziona. Ma la realta e che per il 90% dei progetti — startup, PMI, gestionali interni, e-commerce fino a milioni di euro di fatturato — un monolite Laravel ben organizzato e la scelta tecnicamente superiore.
Non lo dico per pigrizia o per mancanza di competenze distribuite. Lo dico perché ho visto progetti affondare sotto il peso di un architettura a microservizi adottata troppo presto, senza il team, il budget o la scala per giustificarla. E ho visto monoliti Laravel gestire carichi importanti senza un singolo problema architetturale.
Cosa offre il monolite Laravel nel concreto
Un monolite ben strutturato non e un ammasso di codice spaghetti. E un applicativo organizzato con Service Layer, domain separation, interfacce pulite e responsabilità chiare — tutto in un unico repository deployabile.
- Un solo repository, un solo deploy: una pipeline CI/CD, un ambiente di staging, un server di produzione. La complessità operativa e minima
- Transazioni database atomiche: quando un operazione coinvolge più tabelle, puoi wrappare tutto in una transazione. Con i microservizi servono saga pattern, compensating transactions e gestione di stati inconsistenti
- Debugging diretto: lo stack trace ti porta dal controller al service al repository al problema in pochi secondi. Nessun distributed tracing, nessun correlation ID da seguire attraverso 5 servizi
- Refactoring sicuro: rinomini un metodo, un interfaccia, una classe — e l IDE aggiorna tutto il codebase. Con i microservizi rinomini un endpoint e devi aggiornare tutti i consumer manualmente
- Team onboarding veloce: un nuovo sviluppatore clona un repo, esegue le migration, fa partire il server e sta lavorando. Con i microservizi deve capire 10-15 servizi, le loro dipendenze, i loro contratti, il docker-compose con 20 container
- Testing integrato: i test end-to-end in un monolite sono semplici. Con i microservizi serve contract testing, test di integrazione tra servizi, mock dei servizi esterni — un ordine di complessità superiore
Quando i microservizi hanno davvero senso
I microservizi non sono sbagliati — sono sbagliati per la maggior parte dei contesti in cui vengono adottati. Hanno senso in situazioni molto specifiche.
- Team di 50+ sviluppatori: quando troppi sviluppatori lavorano sullo stesso codebase, i conflitti di merge, i deploy che si bloccano a vicenda e le dipendenze incrociate diventano il vero collo di bottiglia. I microservizi permettono a team indipendenti di lavorare e deployare autonomamente
- Componenti con requisiti di scaling radicalmente diversi: se il servizio di notifiche gestisce 10 milioni di messaggi al giorno ma il pannello admin ha 50 utenti, ha senso scalarli indipendentemente
- Deploy indipendenti critici: se un bug nel modulo fatturazione non deve MAI bloccare il modulo ordini, la separazione fisica ha un valore concreto
- Team DevOps dedicato: gestire microservizi richiede competenze specifiche in orchestrazione (Kubernetes), service mesh, monitoring distribuito, log aggregation. Senza un team DevOps, stai aggiungendo complessità che nessuno sa gestire
- Requisiti di polyglot: se una parte del sistema deve essere in Python per il ML e un altra in Go per le performance, i microservizi permettono di usare il linguaggio giusto per il problema giusto
Il costo nascosto dei microservizi nel dettaglio
Infrastruttura
Un monolite Laravel gira su un server da 30-50 euro/mese: Nginx, PHP-FPM, MySQL, Redis. Tutto su una macchina, gestibile con un deploy script di 20 righe.
La stessa applicazione spezzata in 8-10 microservizi richiede: un cluster Kubernetes (o almeno Docker Swarm), un load balancer, un API gateway, un service registry, monitoring per ogni servizio, log aggregation centralizzato. Costo minimo: 300-500 euro/mese — dieci volte tanto, per la stessa funzionalita.
Comunicazione tra servizi
Nel monolite, una chiamata tra moduli e un metodo PHP: istantanea, type-safe, con gestione errori nativa. Nei microservizi, ogni comunicazione e una chiamata HTTP o un messaggio su coda: latenza di rete, serializzazione/deserializzazione JSON, gestione timeout, retry logic, circuit breaker, eventual consistency.
Ogni chiamata tra servizi e un potenziale punto di fallimento. E quando un servizio e lento o irraggiungibile, l effetto cascata può portare giu l intero sistema — esattamente il problema che i microservizi dovrebbero risolvere.
Debugging distribuito
Un errore che attraversa 4 servizi richiede distributed tracing (Jaeger, Zipkin), correlation ID propagati in ogni request, log aggregati in un sistema centrale (ELK stack o simile). Nel monolite basta leggere lo stack trace e il log file. La differenza in tempo di diagnosi e di ordini di grandezza.
Competenze richieste
Un team che gestisce microservizi deve padroneggiare: containerizzazione, orchestrazione, networking, monitoring distribuito, event-driven architecture, eventual consistency, contract testing. Un freelance o un team di 3-5 persone non ha la banda per acquisire e mantenere tutte queste competenze — e non dovrebbe provarci.
Il pattern che funziona: monolite modulare
Laravel rende naturale un approccio che prende il meglio di entrambi i mondi: il monolite modulare. Strutturi il codice in moduli con confini chiari, interfacce esplicite e dipendenze controllate — ma tutto vive nello stesso processo e si deploya insieme.
- Service Layer: ogni dominio ha i suoi service, i suoi repository, le sue regole. I controller sono sottili, la logica e nei service
- Events e Listeners: i moduli comunicano tramite eventi, non tramite chiamate dirette. Questo crea un disaccoppiamento logico senza il costo della distribuzione fisica
- Queues e Jobs: i processi pesanti vanno in coda e vengono eseguiti in background. Scalabilità senza microservizi
- Interfacce e contratti: i moduli dipendono da interfacce, non da implementazioni concrete. Se un giorno devi estrarre un modulo in un servizio separato, l interfaccia diventa un client API — il resto del codice non cambia
L approccio che consiglio ai clienti
Parti monolite. Struttura bene il codice con separazione chiara dei domini, service layer e interfacce pulite. Usa le Queues di Laravel per separare i processi pesanti. Usa gli Events per disaccoppiare i moduli. Misura le performance reali, non quelle teoriche.
Se un giorno una parte del sistema dovra scalare indipendentemente, estrai quel pezzo in un servizio separato — ma solo quando hai i numeri che lo giustificano. Un monolite Laravel su un server da 50 euro/mese gestisce facilmente migliaia di utenti concorrenti. Quando non basta più, lo sai — e a quel punto hai i dati per decidere cosa estrarre e perché.
La complessità architetturale non e un pregio — e un costo. Aggiungila solo quando il valore che porta supera il costo che impone.
Top comments (0)