Microservizi: quando servono e quando no

Negli ultimi anni “microservizi” è diventata quasi una parola d’ordine: sembra che ogni applicazione moderna vada spezzata in tanti piccoli servizi. Nei nostri progetti li usiamo spesso, ma non sempre: risolvono problemi reali di crescita e di organizzazione, e ne introducono altri, che hanno un costo.

Vediamo cosa sono, quali benefici portano davvero, quanto costano e quando un monolite ben strutturato è la scelta migliore. La domanda giusta non è “usiamo i microservizi?”, ma “quale problema dobbiamo risolvere?”.

Cosa sono i microservizi

Un’architettura a microservizi divide un’applicazione in servizi piccoli e indipendenti, ognuno con un compito preciso: gestire gli utenti, i pagamenti, i documenti, le notifiche. Ogni servizio ha il proprio codice, si rilascia per conto suo e comunica con gli altri attraverso API leggere (interfacce con cui un programma dialoga con un altro, di solito REST su HTTP) oppure attraverso messaggi.

L’alternativa è il monolite: un’unica applicazione che contiene tutte le funzioni e si rilascia in un blocco solo. Monolite non vuol dire codice vecchio: può essere moderno, ben diviso in moduli e adatto al suo scopo.

I benefici reali

• Rilasci indipendenti: si aggiorna il servizio dei pagamenti senza toccare il resto, con rilasci più piccoli e meno rischiosi.
• Scalare solo ciò che serve: se è il catalogo a ricevere il carico, si aggiungono copie del catalogo, non dell’intera applicazione.
• Autonomia dei team: ogni gruppo cura i propri servizi e lavora con i propri tempi, purché rispetti i contratti delle API.
• Isolamento dei guasti: se un servizio secondario si ferma, il resto può continuare a funzionare, a patto di averlo progettato per farlo.

Nell’ERP Atac per Ernst & Young, per esempio, l’applicazione che segue le procedure di gara è divisa in microservizi Java e Spring Boot, con Spring Cloud Gateway come ingresso unico e ogni microservizio in un container Docker sul sistema on-premise fornito dal cliente.

I costi che non si vedono subito

Un sistema distribuito è più difficile da progettare, testare e gestire di un’applicazione unica.

• Complessità distribuita: una chiamata che prima era una funzione diventa una richiesta di rete, che può essere lenta, fallire o arrivare due volte.
• Rete: latenza, timeout, tentativi ripetuti e sicurezza tra i servizi vanno gestiti in modo esplicito.
• Consistenza dei dati: con un database per servizio non esiste più una transazione unica; servono eventi o saghe (sequenze di passi con azioni di compensazione) e si accetta che i dati si allineino dopo qualche istante.
• Osservabilità: per capire cosa succede servono log centralizzati, metriche e il tracciamento delle richieste tra i servizi.
• Maturità DevOps: DevOps è l’insieme di pratiche che unisce sviluppo e gestione dell’infrastruttura; con molti servizi, pipeline automatiche di build e rilascio e monitoraggio diventano indispensabili.

Un caso noto: nel 2023 il team Video Quality Analysis di Prime Video (Amazon) ha raccontato sul proprio blog tecnico di aver riunito in un unico processo un servizio di monitoraggio dei flussi video nato come insieme di componenti distribuiti, riducendo i costi di infrastruttura di oltre il 90%. Non è una bocciatura dei microservizi, ma un promemoria: l’architettura si sceglie in base al carico reale, non alla moda.

Quando un monolite modulare è la scelta migliore

Per molti progetti, soprattutto all’inizio, la scelta più solida è un monolite modulare: un’unica applicazione divisa in moduli con confini netti, ognuno con le proprie responsabilità e senza accessi diretti ai dati degli altri. Si rilascia come un blocco solo, ma è già pronta per essere divisa un giorno.

È la strada giusta quando il team è piccolo, il dominio non è ancora stabile, il carico è prevedibile o mancano pipeline e monitoraggio maturi. Martin Fowler, nell’articolo “MonolithFirst” del 2015, osservava che quasi tutte le storie di successo con i microservizi sono partite da un monolite diventato troppo grande e poi diviso. E i confini tra i servizi si tracciano meglio quando il prodotto esiste già.

I segnali che è ora di dividere

• Rilasci bloccati: una piccola modifica richiede di ricompilare, testare e rilasciare tutto, e i team si intralciano a vicenda.
• Carichi molto diversi: una parte dell’applicazione riceve molto più traffico delle altre o ha bisogno di risorse diverse.
• Team in crescita: più gruppi lavorano sullo stesso codice e il coordinamento costa più dello sviluppo.
• Requisiti diversi: un componente critico ha bisogno di più affidabilità o di più sicurezza e va isolato dal resto.
• Confini già chiari: i moduli hanno interfacce stabili e dati propri, quindi estrarli è un lavoro di ingegneria, non una riprogettazione.

In questi casi conviene estrarre un servizio alla volta, partendo da quello con il beneficio più evidente, invece di riscrivere tutto.

I pattern che usiamo nei nostri progetti

• API gateway: un ingresso unico che riceve le richieste, verifica l’accesso e le inoltra al servizio giusto.
• Un database per servizio: ogni servizio è l’unico proprietario dei suoi dati e gli altri li leggono solo attraverso le sue API.
• Messaggi e code: per le operazioni lunghe o non urgenti i servizi comunicano attraverso una coda, così chi invia non resta in attesa.
• Container: ogni servizio è impacchettato in un container, cioè un pacchetto standard con il codice e tutto ciò che serve per eseguirlo, identico in sviluppo e in produzione.
• Registro dei servizi e rilascio automatico: i servizi si trovano tra loro senza indirizzi scritti a mano e ogni modifica passa da una pipeline di CI/CD (integrazione e rilascio continui).

In 2VitaBCognitive per Atlantia l’applicativo è composto da 6 microservizi Spring Boot con il registro dei servizi Eureka, in container Docker su Amazon ECS e rilasciati con i servizi di CI/CD di AWS. Nell’ERP Hera per Atos i microservizi REST girano su Microsoft Azure, con Spring Cloud Gateway, Eureka, accesso tramite Azure Active Directory (oggi Microsoft Entra ID) e report in Power BI.

Se stai valutando se dividere un’applicazione esistente o come impostare un progetto nuovo, partiamo dai tuoi obiettivi e dal carico reale, non da un’architettura scelta in anticipo. Scrivici e ne parliamo insieme.