microservices-feature

in Architetture Software

Microservizi Vs SOA

Reading Time: 2 minutes

Una domanda piuttosto frequente che mi viene posta riguarda la differenza tra architettura a microservizi e SOA. Sviluppando un applicazione seguendo il paradigma dei microservizi significa suddividere l’intero ecosistema in una serie di piccoli servizi ciascuno in esecuzione all’interno di un un proprio ambiente / processo e comunicando tra loro tramite meccanismi di comunicazione semplici e leggeri.

Uno dei vantaggi dello sviluppo di applicazioni a microservizi è quello di effettuare il deploy dei singoli servizi in maniera indipedendente dagli altri e soprattutto attraverso processi di CI/CD.

Inoltre, caratteristica non di poco conto, è quella che non lega l’intera applicazione ad un singolo linguaggio di programmazione, ma è possibile utilizzare differenti linguaggi a patto di definire una meccanismo di comunicazione condiviso.

Un’altra fondamentale caratteristica di un’architettura a microservizi è quella che consente di realizzare tanti singoli servizi ognuno con un compito predefinito e soprattutto singolo.

Questa caratteristica è perfettamente in linea con il principio di singola responsabilità introdotto da Robert C. Martin (Uncle Bob) all’interno dei 5 principi SOLID.

I microservizi sono ormai molto diffusi e stanno sostituendo in molti casi le applicazioni SOA e soprattutto le applicazioni “monolitiche” ovvere tutte quelle applicazioni che per funzionare necessitano la compilazione di tutte le parti che le compongono con evidenti problemi legati all’introduzione di bug risolvibili soltanto con una nuova compilazione / deploy.

Il numero di microservizi che vanno a comporre un’applicazione è spesso molto elevato: centinaia di servizi ed in molti casi si parla addirittura di migliaia.

Ma cosa sono le applicazioni SOA?

Archittettura SOA

SOA per molti aspetti si può considerare l’architettura precedente a quella basata sui microservizi. Il concetto di SOA si basa su una serie di servizi che comunicano tra loro utilizzando un canale comune, denominato bus, all’interno del qualce viaggiano i messaggi di comunicazione. Il termine tecnico che viene utilizzato per questo canale è Enterprise Service Bus (ESB).

A differenza di un’architettura a microservizi dove i servizi vengono scomposti fino ad individuarne una singola responsabilità applicativa, nell’architettura SOA il numero di servizi non supera 20.

Il bus di comunicazione rappresenta un punto di fail: se, per qualche motivo, si verificassero problemi sul canale di comunicazione, l’intera architettura SOA smetterebbe di funzionare. Nell’architettura a microservizi, la comunicazione viene gestita direttamente tra i singoli servizi e con protocolli semplici e leggeri.

A livello di isolamento, in un’architettura SOA tutti i servizi condividono lo stesso storage, mentre in un architettura a microservizi ogni microservizio può avere un suo storage (eventualmente non accessibile dagli altri microservizi).

Lo sviluppo di applicazioni con un’architettura a microservizi permette di sviluppare applicazioni con team distribuiti, delegando ai singoli microservizi specifiche funzionalità e responsabilità. Inoltre, è possibile implementare soluzioni di CI/CD garantendo il continuous delivery ed il rollback. Un discorso a parte meritano le funzionalità di logging, che in ambiente distribuito richiedono un maggiore impegno nello sviluppo e nel tracciamento delle attività.

Nel mondo dei microservizi, un elemento fondamentale è sicuramente docker, che ho parzialmente introdotto nei post precedenti, e che permetti di implementare soluzioni “containerizzate”. L’orchestrazione dei singoli containers può essere fatto utilizzando kubernetes.