Il fascino dei microservizi
I microservizi promettono: deploy indipendenti, scalabilità per servizio, team autonomi, tecnologie diverse per ogni servizio, resilienza ai guasti parziali. Suona bene nelle conferenze. Nella pratica, la maggior parte dei team che adotta i microservizi prima di averne bisogno finisce con un sistema distribuito che e più complesso, più lento e più costoso del monolite che voleva sostituire.
Questo articolo non e contro i microservizi — e contro i microservizi adottati per le ragioni sbagliate. I microservizi sono uno strumento potente quando le condizioni lo giustificano. Il problema e che quelle condizioni sono molto più rare di quanto il marketing tecnologico voglia far credere.
I costi che nessuno menziona
Complessità operativa
Un monolite si deploya copiando un artefatto su un server. Tre microservizi richiedono: un orchestratore (Kubernetes o equivalente), service discovery, load balancing per servizio, health checks, log aggregation (ELK, Grafana Loki), distributed tracing (Jaeger, Zipkin), circuit breakers, retry policies. Il costo infrastrutturale di 10 microservizi e ordini di grandezza superiore a un monolite.
Consistenza dei dati
In un monolite, due operazioni correlate possono vivere nella stessa transazione database. Con i microservizi, ogni servizio ha il proprio database (o dovrebbe averlo). Un ordine che coinvolge inventario e pagamento richiede una saga — una sequenza di transazioni locali con compensazioni in caso di fallimento. Le saga sono complesse da implementare, testare e debuggare.
Latenza di rete
Una chiamata di metodo in-process costa nanosecondi. Una chiamata HTTP tra servizi costa millisecondi — mille volte tanto. Quando un singolo endpoint aggrega dati da 5 servizi, quei millisecondi si sommano. Le fan-out query che nel monolite erano un JOIN da 2ms diventano 5 chiamate HTTP da 20ms ciascuna.
I segnali reali che giustificano i microservizi
- Team grandi (50+ sviluppatori): quando il coordinamento su un singolo codebase diventa il collo di bottiglia, team autonomi con servizi propri accelerano lo sviluppo
- Scalabilità asimmetrica reale: il servizio di ricerca ha bisogno di 10 istanze, il servizio utenti di 1. Scalare tutto insieme spreca risorse.
- Deploy indipendenti critici: il team pagamenti deve poter deployare senza aspettare il team catalogo. Se i deploy sono settimanali e coordinati, il monolite funziona.
- Isolamento dei guasti: un bug nel servizio raccomandazioni non deve bloccare il checkout. Se il sistema deve funzionare parzialmente degradato, i microservizi offrono isolamento naturale.
L'errore del "micro" troppo micro
Servizi troppo piccoli ("nanoservizi") creano più problemi di quelli che risolvono. Se ogni CRUD diventa un servizio, il risultato e un sistema distribuito con centinaia di servizi che fanno poco e comunicano tanto. La regola pratica: un microservizio dovrebbe essere abbastanza grande da essere utile da solo e abbastanza piccolo da essere gestito da un team di 2-5 persone.
L'alternativa pragmatica
Per la stragrande maggioranza dei progetti PHP — gestionali, e-commerce, piattaforme SaaS con team di 2-15 persone — il monolite modulare offre il 90% dei benefici strutturali dei microservizi con il 10% della complessità operativa. Se un giorno un modulo ha bisogno di scalare indipendentemente, estrarlo in un servizio e fattibile perché i confini sono già definiti.
Quando scegliere i microservizi
- Si: team grandi, requisiti di scalabilità asimmetrica reali, deploy indipendenti critici, budget infrastrutturale adeguato
- No: team piccolo, progetto giovane, "perché Netflix li usa", "perché vogliamo essere moderni"
- Mai come punto di partenza: inizia con un monolite modulare, estrai servizi quando (e se) il bisogno si manifesta
I microservizi non sono il futuro di ogni applicazione: sono la risposta a problemi specifici di scala organizzativa e tecnica. Usarli quando non servono e come comprare un camion per andare a fare la spesa: funziona, ma il costo di gestione non si giustifica.
Top comments (0)