Microservizi: quando servono davvero e quando sono un errore costoso

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 è più complesso, più lento e più costoso del monolite che voleva sostituire.

Questo articolo non è contro i microservizi — è contro i microservizi adottati per le ragioni sbagliate. I microservizi sono uno strumento potente quando le condizioni lo giustificano. Il problema è 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 è 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 è 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 è fattibile perché i confini sono già definiti.

Quando scegliere i microservizi

• Sì: 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 è come comprare un camion per andare a fare la spesa: funziona, ma il costo di gestione non si giustifica.