l’analisi

Microservizi nella PA: quando e perché adottarli



Indirizzo copiato

La diffusione delle architetture a microservizi richiede un’attenta valutazione nel contesto della Pubblica Amministrazione. Non sempre rappresentano la soluzione ottimale, soprattutto per progetti di piccola scala con requisiti ben definiti

Pubblicato il 8 gen 2025

Francesca De Luzi

Sapienza Università di Roma

Francesco Leotta

Sapienza, Università di Roma

Massimo Mecella

Sapienza Università di Roma, Dipartimento di Ingegneria Informatica Automatica e Gestionale Antonio Ruberti

Flavia Monti

Sapienza, Università di Roma



pubblica amministrazione (1) falso documentale

Le architetture a microservizi rappresentano un approccio all’ingegneria del software basato sulla decomposizione di un’applicazione in una serie di servizi indipendenti, ognuno focalizzato su una specifica funzionalità applicativa.

Ogni microservizio è progettato per essere autonomo, modulare e facilmente scalabile, consentendo un’evoluzione più flessibile del software. Ogni servizio opera come un’entità indipendente, con il proprio ciclo di vita, che può essere sviluppato, distribuito e scalato separatamente.

Questo è reso possibile grazie all’uso di API – Application Programming Interface – ben definite per comunicare tra i microservizi, mantenendo al tempo stesso un basso accoppiamento tra di essi.

Vantaggi e sfide dei microservizi

Tra i principali vantaggi delle architetture a microservizi vengono comunemente citati:

  • Scalabilità: i microservizi possono essere scalati in modo indipendente in base alle esigenze.
  • Resilienza: ùn guasto in un microservizio specifico non compromette l’intera applicazione.
  • Flessibilità tecnologica: è possibile utilizzare linguaggi di programmazione e framework diversi per ogni microservizio.

Tuttavia, questa architettura introduce anche complessità, come la gestione della comunicazione tra i microservizi, l’orchestrazione, e la necessità di strumenti avanzati per il monitoraggio e il logging.

Domain-Driven Design nell’architettura a microservizi

Tra le metodologie di sviluppo software, il Domain-Driven Design (DDD) si integra perfettamente con le architetture a microservizi. DDD si concentra sulla comprensione e modellazione del “dominio” (applicativo), ovvero del contesto specifico in cui l’applicazione opera. In un’architettura a microservizi, il DDD guida la suddivisione di un sistema complesso in Bounded Contexts, che diventano la base naturale per identificare i microservizi.

L’adozione dei Bounded Contexts permette di definire confini logici entro i quali termini e concetti del dominio assumono un significato univoco e specifico. Questa segmentazione facilita la mappatura dei singoli Bounded Contexts a microservizi, migliorando la coesione interna e riducendo le ambiguità tra i vari moduli.

A supporto di questo approccio, il DDD incoraggia l’utilizzo di un’Ubiquitous Language, un linguaggio condiviso tra sviluppatori e stakeholder che promuove una comprensione comune e profonda del dominio, migliorando la comunicazione tra i team tecnici e aziendali. Infine, tecniche come l’Event Storming si rivelano fondamentali per identificare gli eventi chiave e analizzare i processi sottostanti, guidando in modo efficace la decomposizione del dominio in microservizi e allineando la progettazione alle esigenze operative e organizzative.

Pattern architetturali nei microservizi

L’uso del DDD consente una progettazione più chiara e focalizzata dei microservizi, assicurando che ciascun servizio sia costruito per risolvere un problema specifico senza sovrapposizioni.

I pattern sono strumenti fondamentali per affrontare le sfide di progettazione e implementazione delle architetture a microservizi. Alcuni dei più utilizzati includono:

  • API Gateway: è un punto di ingresso unico per l’accesso ai microservizi. Gestisce la sicurezza, il routing delle richieste e la composizione delle risposte.
  • Service Discovery: consente ai microservizi di trovare dinamicamente le istanze disponibili di altri servizi attraverso un registro centralizzato.
  • Circuit Breaker: protegge l’applicazione da guasti a cascata. Se un microservizio non risponde, il circuito si “apre” e interrompe temporaneamente le chiamate.
  • Database per microservizio: ogni microservizio possiede il proprio database, riducendo l’accoppiamento e consentendo un’evoluzione indipendente dei dati.
  • Saga: è un pattern per la gestione delle transazioni distribuite. Organizza le operazioni in una sequenza di eventi compensabili.
  • Event-Driven Architecture: i microservizi comunicano attraverso eventi pubblicati in un broker (es. Kafka o RabbitMQ), facilitando l’asincronia e la scalabilità.

Gestione dei dati e pattern di persistenza

Come anticipato, un aspetto cruciale delle architetture a microservizi è la gestione dei dati, poiché i microservizi devono essere progettati per essere “autonomi” anche in termini di persistenza. I principi chiave sono:

  • Database per microservizio: ogni microservizio possiede un proprio database, che può essere di tipo relazionale o NoSQL, in base ai requisiti. Questo garantisce indipendenza e isolamento.
  • Denormalizzazione dei dati: poiché i dati sono distribuiti, è spesso necessario denormalizzarli per evitare frequenti comunicazioni tra microservizi.
  • Event Sourcing: consiste nel registrare tutti gli eventi che cambiano lo stato di un’entità nel database. I microservizi possono quindi ricostruire il loro stato riproducendo gli eventi.
  • CQRS (Command Query Responsibility Segregation): divide le operazioni di scrittura (Command) e lettura (Query) dei dati in modelli separati. Questo pattern migliora le prestazioni e facilita l’integrazione tra microservizi.

Sfide nella gestione dei dati distribuiti

Le architetture a microservizi introducono sfide significative nella gestione dei dati, principalmente a causa della natura distribuita delle informazioni. Garantire la consistenza dei dati diventa un compito complesso, richiedendo l’adozione di tecniche avanzate e pattern specifici.

Operazioni come i joins distribuiti, necessari per correlare dati provenienti da microservizi diversi, necessitano di un design accurato o dell’implementazione di pattern come il Data Aggregator, che consente di centralizzare e aggregare le informazioni in modo efficiente. Inoltre, le transazioni distribuite rappresentano un ulteriore livello di complessità.

Per garantire coerenza e affidabilità, vengono utilizzati pattern come Saga, che orchestrano eventi e azioni tra microservizi, e meccanismi di compensazione esplicita, che permettono di annullare operazioni in caso di errore, preservando l’integrità del sistema.

Architetture monolitiche: caratteristiche e vantaggi

Spesso le architetture a microservizi vengono contrapposte a quelle monolitiche. Le architetture monolitiche rappresentano un modello tradizionale di progettazione del software in cui tutte le funzionalità di un’applicazione sono integrate in un unico sistema indivisibile. Un’applicazione monolitica è strutturata come un’unica unità eseguibile, dove la logica di business, l’interfaccia utente e l’accesso ai dati sono strettamente accoppiati. Le caratteristiche principali delle architetture monolitiche sono:

  1. Singolo deploy: l’intero sistema viene compilato, distribuito e avviato come un’unica entità.
  2. Condivisione della base di dati: una base di dati centralizzata è condivisa tra tutte le componenti del sistema.
  3. Comunicazione interna diretta: le componenti comunicano tra loro attraverso chiamate dirette di metodo o funzione.
  4. Tight coupling: le diverse parti del sistema sono strettamente interdipendenti, rendendo le modifiche complesse e potenzialmente rischiose

Le architetture monotiche presentano anche dei vantaggi, come:

  • Semplicità iniziale: è più semplice progettare e sviluppare un sistema monolitico, specialmente per applicazioni di medie dimensioni o servizi digitali ben definiti (rilascio di documenti, ecc.).
  • Facilità di debugging: le componenti sono tutte integrate, il che rende il debugging meno complesso rispetto a un sistema distribuito.
  • Efficienza di runtime: l’assenza di comunicazioni di rete tra le componenti riduce l’overhead rispetto alle architetture distribuite.
  • Minori costi infrastrutturali: un monolite può essere distribuito su un’unica macchina o ambiente di esecuzione.

Confronto sistematico tra approcci

La seguente tabella mostra in modo sistematico un confronto tra i due approcci.

Confronto tra architetture monolitiche e a microservizi

CaratteristicaArchitettura MonoliticaArchitettura a Microservizi
StrutturaUn unico blocco indivisibileServizi indipendenti e autonomi
DistribuzioneUn unico deployOgni servizio ha il proprio ciclo di vita e deploy
ComunicazioneDiretta (chiamate di metodo o funzione)API o eventi, spesso su TCP/IP
ScalabilitàScalabilità verticale (aumentare risorse su una macchina)Scalabilità orizzontale (scalare solo i servizi necessari)
ManutenzioneDifficile per sistemi molto complessiPiù flessibile grazie alla modularità
TecnologieUnico stack tecnologicoOgni microservizio può usare tecnologie diverse
ResilienzaUn guasto può bloccare l’intero sistemaI guasti sono confinati al servizio interessato (ma se si adotta circuit breaker si blocca tutto)
PerformancePiù efficiente per applicazioni piccole e medieOverhead dovuto alla comunicazione tra servizi
Investimento inizialePiù economico per progetti di piccola scalaRichiede competenze e strumenti avanzati

Considerazioni per la Pubblica Amministrazione

È importante notare quindi che non necessariamente, soprattutto nel caso della Pubblica Amministrazione, le architetture a microservizi debbano essere privilegiate e/o esplicitamente richieste in fase di stesura dei capitolati tecnici e/o piani dei fabbisogni. Queste scelte devono essere lasciate al fornitore, dopo un’attenta analisi dei requisiti e dei vincoli imposti dall’amministrazione.

Le architetture monolitiche, possono essere infatti preferite per progetti di piccole dimensioni o MVP (Minimum Viable Product), dove i requisiti sono ben definiti e l’applicazione non richiede frequenti aggiornamenti o scalabilità complessa, quali sono molti servizi digitali richiesti dal cittadino e/o imprese e che le amministrazioni stanno provvedendo a realizzare. Di contro, le architettura a microservizi sono adatte a applicazioni di grandi dimensioni con team multipli, necessità di scalabilità indipendente e frequenti aggiornamenti.

È una scelta strategica per sistemi che richiedono flessibilità tecnologica e resilienza, ma progetti di questi tipo non sono sempre all’ordine del giorno nelle pubbliche amministrazioni. Un approccio sano allo sviluppo del software nel settore delle Pubbliche Amministrazioni non deve essere guidato dalle mode del momento, spesso spinte dai vendor, ma da considerazioni più approfondite sulla tipologia di applicazione/servizio digitale da realizzare e su cosa sia realmente meglio per l’utenza finale.

Bibliografia

Di Francesco, P., Lago, P., & Malavolta, I. (2019). Architecting with microservices: A systematic mapping study. Journal of Systems and Software, 150, 77-97.

Richards, M., & Ford, N. (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media.

Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O’Reilly Media.

Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall.

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.

Richards, M., & Ford, N. (2020). Fundamentals of Software Architecture: An Engineering Approach, O’Reilly Media.

EU Stories - La coesione innova l'Italia

Tutti
Iniziative
Social
Analisi
Video
Finanza sostenibile
BEI e E-Distribuzione: investimenti per la sostenibilità energetica
Professioni
Servono competenze adeguate per gestire al meglio i fondi europei
Master
Come formare nuove professionalità per governare e gestire al meglio i fondi europei?
Programmazione UE
Assunzioni per le politiche di coesione: prossimi passi e aspettative dal concorso nazionale. Il podcast “CapCoe. La coesione riparte dalle persone”
innovazione sociale
Rigenerazione urbana: il quartiere diventa un hub dell’innovazione. La best practice di San Giovanni a Teduccio
Programmazione europ
Fondi Europei: la spinta dietro ai Tecnopoli dell’Emilia-Romagna. L’esempio del Tecnopolo di Modena
Interventi
Riccardo Monaco e le politiche di coesione per il Sud
Iniziative
Implementare correttamente i costi standard, l'esperienza AdG
Finanziamenti
Decarbonizzazione, 4,8 miliardi di euro per progetti cleantech
Formazione
Le politiche di Coesione UE, un corso gratuito online per professionisti e giornalisti
Interviste
L’ecosistema della ricerca e dell’innovazione dell’Emilia-Romagna
Interviste
La ricerca e l'innovazione in Campania: l'ecosistema digitale
Iniziative
Settimana europea delle regioni e città: un passo avanti verso la coesione
Iniziative
Al via il progetto COINS
Eventi
Un nuovo sguardo sulla politica di coesione dell'UE
Iniziative
EuroPCom 2024: innovazione e strategia nella comunicazione pubblica europea
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia
Finanza sostenibile
BEI e E-Distribuzione: investimenti per la sostenibilità energetica
Professioni
Servono competenze adeguate per gestire al meglio i fondi europei
Master
Come formare nuove professionalità per governare e gestire al meglio i fondi europei?
Programmazione UE
Assunzioni per le politiche di coesione: prossimi passi e aspettative dal concorso nazionale. Il podcast “CapCoe. La coesione riparte dalle persone”
innovazione sociale
Rigenerazione urbana: il quartiere diventa un hub dell’innovazione. La best practice di San Giovanni a Teduccio
Programmazione europ
Fondi Europei: la spinta dietro ai Tecnopoli dell’Emilia-Romagna. L’esempio del Tecnopolo di Modena
Interventi
Riccardo Monaco e le politiche di coesione per il Sud
Iniziative
Implementare correttamente i costi standard, l'esperienza AdG
Finanziamenti
Decarbonizzazione, 4,8 miliardi di euro per progetti cleantech
Formazione
Le politiche di Coesione UE, un corso gratuito online per professionisti e giornalisti
Interviste
L’ecosistema della ricerca e dell’innovazione dell’Emilia-Romagna
Interviste
La ricerca e l'innovazione in Campania: l'ecosistema digitale
Iniziative
Settimana europea delle regioni e città: un passo avanti verso la coesione
Iniziative
Al via il progetto COINS
Eventi
Un nuovo sguardo sulla politica di coesione dell'UE
Iniziative
EuroPCom 2024: innovazione e strategia nella comunicazione pubblica europea
Iniziative
Parte la campagna di comunicazione COINS
Interviste
Marco De Giorgi (PCM): “Come comunicare le politiche di coesione”
Analisi
La politica di coesione europea: motore della transizione digitale in Italia
Politiche UE
Il dibattito sul futuro della Politica di Coesione
Mobilità Sostenibile
L’impatto dei fondi di coesione sul territorio: un’esperienza di monitoraggio civico
Iniziative
Digital transformation, l’Emilia-Romagna rilancia sulle comunità tematiche
Politiche ue
Fondi Coesione 2021-27: la “capacitazione amministrativa” aiuta a spenderli bene
Finanziamenti
Da BEI e Banca Sella 200 milioni di euro per sostenere l’innovazione di PMI e Mid-cap italiane
Analisi
Politiche di coesione Ue, il bilancio: cosa ci dice la relazione 2024
Politiche UE
Innovazione locale con i fondi di coesione: progetti di successo in Italia

Articoli correlati

Articolo 1 di 4