Pagina 1 di 1
Microservizi sono la soluzione corretta per certi problemi di scala e team, e pessima per la maggior parte delle PMI. Introdurre microservizi senza avere i problemi che essi risolvono significa aggiungere complessità operativa, costi infrastrutturali, superficie di attacco — tutto per niente.
In questa categoria ragiono su architettura a microservizi applicata con lucidità: quando funzionano, quando i monoliti modulari sono la scelta migliore, come migrare incrementalmente con strangler-fig quando serve. Parliamone, scopri il mio approccio.
Ogni microservizio PHP implementava la propria autenticazione JWT in modo leggermente diverso. Con Kong come API gateway, l'autenticazione è centralizzata e i servizi ricevono un header con l'utente già validato. Ho aggiunto rate limiting per client, logging centralizzato e circuit breaker - senza toccare il codice PHP. Continua a leggere
Quando hai dieci microservizi che si parlano tra loro, la gestione della sicurezza e dell'osservabilità a livello applicativo diventa insostenibile. Con Istio, mutual TLS tra tutti i servizi, distributed tracing con Jaeger e circuit breaker configurabili via YAML - senza cambiare una riga di codice PHP. Continua a leggere
La 'riscrittura totale' è quasi sempre un errore. Con il pattern Strangler Fig ho aiutato una società logistica a estrarre gradualmente funzionalità dal loro monolite Laravel: prima il modulo di tracking, poi la fatturazione. Due anni dopo, tre microservizi autonomi e il monolite ridotto del 40%, sempre in produzione. Continua a leggere
Il motore di raccomandazione di un cliente e-commerce richiedeva librerie Python di ML che non esistono in PHP. Ho estratto quella funzionalità in un microservizio FastAPI che Laravel consulta via HTTP con JWT. Latenza p95 di 40ms, deployment Docker su Hetzner. Vi mostro l'architettura e i pattern di integrazione. Continua a leggere
Un cliente mi ha chiesto di trasformare il suo monolite Laravel in microservizi 'perché lo fanno tutti'. Ho fatto l'analisi: 15 sviluppatori, 3 domini di business ben separati, un servizio con requisiti di scaling indipendenti. Alla fine ne abbiamo estratti due soli. Vi racconto i criteri di decisione reali. Continua a leggere
Una PMI lombarda con 8 sviluppatori e un monolite Laravel 10 lento aveva speso quattro mesi e 120.000 euro per migrare a microservizi. Risultato: tre servizi parzialmente funzionanti, zero in produzione, latenza raddoppiata e metà del team impegnato in infrastruttura Docker anziché in feature. La mia raccomandazione: fermare la migrazione, modularizzare il monolite con bounded context, e risolvere i veri problemi di performance. In due settimane il team era tornato produttivo. Continua a leggere
