SOA e microservizi: qual è la differenza?

Se lavori nel campo dell'IT o del cloud computing, probabilmente sei a conoscenza del dibattito tra  architettura orientata ai servizi (SOA) e microservizi. Dopotutto, oggigiorno tutti parlano di microservizi e applicazioni agili.

A prima vista, i due approcci sembrano simili e, in un certo senso, lo sono. Entrambi coinvolgono ambienti cloud o hybrid cloud per lo sviluppo e la distribuzione agile delle applicazioni, ed entrambi possono essere scalati per soddisfare la velocità e le esigenze operative dei big data. Entrambi suddividono le applicazioni grandi e complesse in componenti piccoli e flessibili con cui è più facile lavorare. Ed entrambi si differenziano da un'architettura tradizionale, monolitica, in quanto ogni servizio ha la propria responsabilità.

Tuttavia, anche con questi punti in comune, un esame più attento dei due approcci rivela importanti differenze.

L'architettura orientata ai servizi (SOA) è un approccio a livello aziendale allo sviluppo software di componenti di applicazione che utilizza al meglio i componenti software riutilizzabili o servizi. Nell'architettura software SOA, ogni servizio è composto dalle integrazioni di codice e dati necessarie per eseguire una specifica funzione aziendale, ad esempio, la verifica del credito di un cliente, l'accesso a un sito web o l'elaborazione di un'applicazione di mutuo.

Le interfacce di servizio forniscono un legame debole, il che significa che possono essere chiamate con poca o nessuna conoscenza del modo in cui viene implementata l'integrazione nel livello sottostante. A causa di questo legame debole e del modo in cui i servizi vengono pubblicati, i team di sviluppo possono risparmiare tempo riutilizzando i componenti in altre applicazioni all'interno dell'azienda. Ciò rappresenta sia un beneficio che un rischio. Come risultato dell'accesso condiviso all'enterprise service bus (ESB), eventuali problemi possono avere ripercussioni anche sugli altri servizi connessi.

I dati XML sono un ingrediente fondamentale per le soluzioni che si basano sull'architettura SOA. Le applicazioni SOA basate su XML possono essere utilizzate per creare servizi web, ad esempio.

La SOA è emersa alla fine degli anni '90 e rappresenta una fase importante nell'evoluzione dello sviluppo e dell'integrazione delle applicazioni. Prima che SOA diventasse un'opzione, collegare un'applicazione monolitica a dati o funzioni in un altro sistema richiedeva una complessa integrazione point-to-point che gli sviluppatori dovevano ricreare per ogni nuovo progetto di sviluppo. L'esposizione di tali funzioni tramite SOA elimina la necessità di ricreare ogni volta l'integrazione profonda.

La SOA fornisce quattro diverse tipologie di servizi:

1. Servizi funzionali (ovvero servizi aziendali), che sono fondamentali per le applicazioni aziendali.
2. Servizi Enterprise, che servono a implementare funzioni.
3. Servizi applicativi, che sono utilizzati per sviluppare e distribuire app.
4. Servizi di infrastruttura, che sono fondamentali per i processi backend come la sicurezza e l'autenticazione.

Ogni servizio è composto da tre componenti:

1. L'interfaccia, che definisce il modo in cui un fornitore di servizi esegue le richieste di un consumatore di servizi.
2. Il contratto, che definisce il modo in cui il fornitore di servizi e il consumatore di servizi devono interagire.
3. L'implementazione, che è il codice del servizio.

I servizi SOA possono essere combinati per creare servizi e applicazioni di livello superiore.

Come la SOA, le architetture di microservizi sono costituite da componenti legati debolmente, riutilizzabili e specializzati che spesso funzionano indipendentemente l'uno dall'altro. I microservizi utilizzano anche un elevato grado di coesione, altrimenti noto come contesto delimitato. Il contesto delimitato si riferisce alla relazione tra un componente e i relativi dati come entità o unità autonoma con poche dipendenze. Piuttosto che essere adottati a livello aziendale, i microservizi comunicano in genere tramite application programming interface (API) per creare applicazioni che eseguono una specifica funzionalità aziendale. Questo approccio li rende più agili, scalabili e resilienti, soprattutto per aree specifiche dell'azienda. In genere, Java è il linguaggio di programmazione preferito per sviluppare microservizi. Possono essere utilizzati anche altri linguaggi di programmazione, come Golang e Python.

I microservizi sono un vero e proprio approccio architettonico cloud-native, spesso operanti in container, il che li rende più scalabili e portabili per la creazione di servizi indipendenti. I team possono utilizzare i microservizi per aggiornare il codice più facilmente, utilizzare stack diversi per componenti diversi e scalare i componenti in modo indipendente l'uno dall'altro. I componenti possono essere scalati indipendentemente l'uno dall'altro, riducendo gli sprechi e i costi associati alla necessità di scalare intere applicazioni perché una singola funzione potrebbe essere sottoposta a un carico eccessivo. Grazie alla loro indipendenza, i microservizi producono servizi più tolleranti agli errori rispetto alle alternative.

Per altre informazioni sull'architettura dei microservizi, guarda il video seguente:

La principale distinzione tra i due approcci si riduce all'ambito di applicazione. In parole povere, l'architettura orientata ai servizi (SOA) ha un ambito aziendale, mentre l'architettura dei microservizi ha un ambito applicativo.

Molti dei principi fondamentali di ciascun approccio diventano incompatibili quando si trascura questa differenza. Se accetti la differenza di ambito, potresti renderti subito conto che le due cose possono potenzialmente completarsi a vicenda, invece di competere.

Ecco alcuni casi d'uso in cui entra in gioco questa distinzione:

Nella SOA, la riutilizzabilità delle integrazioni è l'obiettivo primario e, a livello aziendale, l'impegno per un certo livello di riutilizzo è essenziale. La riutilizzabilità e la condivisione dei componenti in un'architettura SOA aumentano la scalabilità e l'efficienza.

Nell'architettura a microservizi, la creazione di un componente di microservizi che viene riutilizzato in tempo di esecuzione in tutta l'applicazione comporta dipendenze che riducono l'agilità e la resilienza. I componenti dei microservizi preferiscono generalmente riutilizzare il codice copiando e accettando la duplicazione dei dati per contribuire a migliorare il disaccoppiamento.

I servizi riutilizzabili in SOA sono disponibili in tutta l'azienda utilizzando protocolli prevalentemente sincroni come le API RESTful.

Tuttavia, all'interno di un'applicazione di microservizi, le chiamate sincrone introducono dipendenze in tempo reale, con conseguente perdita di resilienza. Queste dipendenze possono anche causare latenza, che influisce sulle prestazioni. All'interno di un'applicazione di microservizi, sono preferiti modelli di interazione basati sulla comunicazione asincrona, come l'event sourcing, in cui viene utilizzato un modello publish/subscribe per consentire a un componente di microservizi di rimanere aggiornato sulle modifiche che si verificano nei dati di un altro componente.

Un chiaro obiettivo della fornitura di servizi in una SOA è che tutte le applicazioni ottengano e modifichino i dati in modo sincrono direttamente dalla fonte primaria, il che riduce la necessità di mantenere modelli complessi di sincronizzazione dei dati.

Nelle applicazioni di microservizi, idealmente, ogni microservizio ha accesso locale a tutti i dati di cui ha bisogno per garantire la propria indipendenza da altri microservizi e da altre applicazioni, anche se ciò significa una certa duplicazione dei dati in altri sistemi. Naturalmente, questa duplicazione aggiunge complessità, quindi deve essere bilanciata con i guadagni in termini di agilità e prestazioni, ma questa è accettata come una realtà della progettazione di microservizi.

• Comunicazione: in un'architettura a microservizi, ogni servizio è sviluppato indipendentemente, con il proprio protocollo di comunicazione. Con la SOA, ogni servizio deve condividere un meccanismo di comunicazione comune chiamato enterprise service bus (ESB). La SOA gestisce e coordina i servizi che eroga attraverso l'ESB. Tuttavia, l'ESB può diventare un singolo punto di errore per l'intera azienda e, se un singolo servizio rallenta, l'intero sistema può risentirne.
• Interoperabilità: per mantenere le cose semplici, i microservizi utilizzano protocolli di messaggistica leggeri come HTTP/REST (Representational State Transfers) e JMS (Java Messaging Service). Le SOA sono più aperte a protocolli di messaggistica eterogenei, ad esempio SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) e MSMQ (Microsoft Messaging Queuing).
• Granularità del servizio: le architetture a microservizi sono costituite da servizi altamente specializzati, ognuno dei quali è progettato per fare una cosa molto bene. I servizi che compongono le SOA, invece, possono spaziare da servizi piccoli e specializzati a servizi a livello aziendale.
• Velocità: sfruttando i vantaggi della condivisione di un'architettura comune, le SOA semplificano lo sviluppo e la risoluzione dei problemi. Tuttavia, questo tende anche a far funzionare le SOA più lentamente rispetto alle architetture a microservizi, che minimizzano la condivisione a favore della duplicazione.
• Governance: la natura della SOA, che prevede risorse condivise, consente l'implementazione di standard comuni di governance dei dati in tutti i servizi. La natura indipendente dei microservizi non consente una governance dei dati coerente. Ciò offre una maggiore flessibilità per ogni servizio, che può incoraggiare una maggiore collaborazione all'interno dell'organizzazione.
• Storage: SOA e microservizi differiscono anche in termini di allocazione delle risorse di storage. L'architettura SOA comprende in genere un unico livello di data storage che viene condiviso da tutti i servizi all'interno di una determinata applicazione, mentre i microservizi dedicheranno un server o un database per il data storage per qualsiasi servizio che ne abbia bisogno.

Per alcune organizzazioni, l'architettura SOA è un trampolino di lancio per sostituire il monolite, fornendo un ambiente più flessibile e agile. I servizi SOA possono essere sviluppati e utilizzati in un ambiente di grandi dimensioni, ma non soddisfano le esigenze specifiche delle singole aziende che desiderano gestire i processi aziendali di loro competenza. DevOps può essere utilizzato per aiutare un'organizzazione a passare dall'architettura SOA ai microservizi per soddisfare esigenze specifiche.

Gli stili architettonici hanno i loro vantaggi, ma come puoi stabilire quale si adatta meglio ai tuoi scopi? In generale, dipende dalle dimensioni e dalla diversità del tuo ambiente di applicazione.

Sia la SOA che i microservizi possono utilizzare l'automazione per accelerare i processi aziendali. Gli ambienti più grandi e diversificati tendono a propendere per l'architettura orientata ai servizi (SOA), che supporta l'Integrazione tra applicazioni eterogenee e protocolli di messaggistica tramite un enterprise service bus (ESB). Gli ambienti più piccoli, comprese le applicazioni web e mobili, non richiedono un livello di comunicazione così robusto e sono più facili da sviluppare utilizzando un'architettura a microservizi.

Alcuni sottolineeranno che il dibattito che il dibattito tra SOA e microservizi è molto più complicato, ed è vero. C'è molto di più. Per una spiegazione tecnica più dettagliata di queste sfumature, ti invitiamo ad approfondire gli articoli di Learn Hub su SOA e microservizi, che forniscono molte informazioni approfondite. Tuttavia, da un punto di vista commerciale, la distinzione cruciale è l'ambito di applicazione.

• Che cosa sono i microservizi?
• Che cos'è la SOA (architettura orientata ai servizi)?
• Agile e Waterfall a confronto

Per maggiori informazioni su come creare applicazioni agili, scarica gratuitamente la tua copia dell'ebook Agile Applications Architecture.