Architetture a microservizi e monoliti modulari: rendere più agili le nostre applicazioni

Lo scenario del software engineering ha cambiato radicalmente faccia negli ultimi anni, passando da un’architettura prevalentemente monolitica a una basata su microservizi. Un’architettura a microservizi offre molti vantaggi rispetto ai monoliti applicativi, ma, come ogni scelta tecnologica, presenta anche le sue sfide. Ce ne parla Stefano Bruna, Chief Technology Officer di adesso.it.

I vantaggi delle architetture a microservizi

Dato che ogni componente è funzionalmente slegata dalla altre, comunicando tra loro tramite API, è possibile scalare ognuna di queste indipendentemente dalle altre. Ciò permette di ottimizzare l’uso delle risorse e di mantenere alte prestazioni anche in presenza di un elevato carico di lavoro. Questo è un aspetto cruciale, che permette ai microservizi di aggiungere o modificare funzionalità senza impattare negativamente sul sistema nel suo complesso.

Inoltre, la modularità dei microservizi facilita lo sviluppo indipendente, il che permette ai team di lavorare in parallelo su diverse funzionalità indipendentemente dagli altri e senza interferenze. Questo si traduce in una rapida evoluzione tecnologica, dato che ogni microservizio può adottare le tecnologie più consone al proprio dominio applicativo.

Ultimo, ma non meno importante: le architetture a microservizi sono nate per il cloud. Infatti, si integrano perfettamente con i servizi Platform as a Service (PaaS) offerti dai vari provider cloud. Ciò permette di astrarre dettagli tecnici e rendere i servizi facilmente riutilizzabili in diversi contesti applicativi.

Non mancano le sfide tecniche da affrontare

Nonostante i numerosi vantaggi offerti, le architetture a microservizi non sono prove di sfide. Naturalmente, la suddivisione in domini più piccoli e interconnessi rende l’insieme di microservizi più complesso da gestire. In particolare, la comunicazione e la collaborazione tra microservizi, checome abbiamo già accennato avviene tramite API, introducono diverse sfide, soprattutto per la gestione delle condizioni di errore.

Eseguire un’applicazione a microservizi non è semplice come cliccare un .exe, ma necessita dell’automazione dei processi di build e deploy tramite altre applicazioni. Inoltre, per orchestrare i vari componenti, e buona prassi dotarsi di strumenti di monitoring e observability, oltre che ad adottare un approccio DevOps e fare largo uso della containerizzazione.

Bounded context e transazioni distribuite

I bounded context rappresentano aree di responsabilità chiaramente definite all’interno di un sistema, con ciascun microservizio incaricato di implementare funzionalità ben precise. Nonostante la suddivisione del dominio applicativo in bounded context permetta di gestire meglio il singolo microservizio, ciò aggiunge complessità soprattutto per quanto riguarda la gestione delle transazioni distribuite, in quanto alcuni processi funzionali possono attraversare più bounded context.

Naviga in sicurezza – Ottieni da questo link il 69% di Sconto con NordVPN

La soluzione più semplice è quella di aumentare la comunicazione tra microservizi, ma ciò può portare a problemi di performance, congestioni di rete e riduzione delle prestazioni complessive del sistema. È quindi importante cercare di evitare questi problemi progettando i microservizi e le loro interfacce in modo che le dipendenze tra di essi siano ridotte al minimo.

Alcune dipendenze rimangono inevitabili. È qui che entra in gioco il pattern di progettazione SAGA, che rappresenta una soluzione robusta per gestire tali dipendenze. Il termine “SAGA” non è un acronimo, ma si riferisce al concetto di “saga” di libri o racconti, che descrive come eseguire una sequenza di operazioni atomiche. Il pattern prevede la suddivisione di una transazione complessa in passi più piccoli, ognuno dei quali è gestito da un microservizio specifico. Ogni passo della transazione è rappresentato da una “saga” composta da operazioni di conferma (commit) e operazioni di annullamento (rollback). Se un passo della transazione fallisce, la “saga” può essere eseguita all’indietro, annullando le operazioni precedenti tramite le operazioni di annullamento corrispondenti. 

Una via di mezzo tra monoliti e microservizi: i monoliti modulari e le soluzioni ibride

E se si volessero conservare i vantaggi dei monoliti senza dire di no ai vantaggi delle architetture a microservizi? Uno degli approcci che si possono adottare è quello dei monoliti modulari, un’architettura che cerca di mantenere i vantaggi dei microservizi, come la modularità e il disaccoppiamento, riducendo allo stesso tempo la complessità tecnologica. I monoliti modulari permettono inoltre di evitare le transazioni distribuite accorpando i bounded context coinvolti e delegando la gestione delle transazioni alla base di dati.

Per aiutare gli sviluppatori a creare monoliti modulari, stanno emergendo framework come Spring Modulith, che supportano la verifica dei moduli, i test di integrazione e l’osservazione del comportamento dell’applicazione a livello di modulo.

Un altro approccio intermedio è quello ibrido, che prevede che una grande applicazione sia costituita sia da monoliti modulari che da microservizi, riducendo la complessità delle transazioni distribuite e preservando al contempo i benefici della modularità.

Per maggiori informazioni, vi invitiamo a visitare adesso.it.

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

• Newman, Sam (Autore)

50,95 EUR

Acquista su Amazon