Microservizi nella PA: quando e perché adottarli

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

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.