Differenza tra Architettura a Microservizi e Architettura SOA

Differenza tra Architettura a Microservizi e Architettura SOA

Architettura a Microservizi vs Architettura SOA

Nell’architettura a microservizi troviamo fondamentalmente due tipi di servizi: servizi funzionali, i quali esplicano un’azione di business specifica, e servizi d’infrastruttura i quali non sono esposti all’esterno, cioè chi chiama i servizi funzionali non comunica con i servizi di infrastruttura.
Nelle architetture SOA invece troviamo numerosi servizi, abbiamo servizi business, servizi d’infrastruttura, servizi Enterprise e servizi applicativi. Questi servizi sono spesso inglobati in sovrastrutture che sono parti di un sottosistema interno. Quindi abbiamo una moltitudine di tipologie di servizi che vengono coordinati tra loro mediante un middleware di messaggistica.

Differenza tra Architettura a Microservizi e Architettura SOA

Quindi possiamo dire che l’architettura SOA è molto più complessa di quella a microservizi. Nell’architettura a microservizi, i servizi tendono ad essere molto piccoli, mentre nell’architettura SOA possono essere, in alcuni casi, addirittura interi sottosistemi.
Nelle architetture a microservizi, di solito, viene usato un solo tipo di protocollo, il REST Representational State Transfer; è uno stile architetturale molto diffuso per la comunicazione di tipo richiesta/risposta dove il client invia una richiesta a un servizio, il servizio elabora le richieste e restituisce la risposta. Il REST ignora i dettagli di implementazione dei componenti e della sintassi di protocollo al fine di concentrarsi sui ruoli delle componenti, sui vincoli della loro interazione e sulla loro interpretazione. Quindi abbiamo un accesso diretto ai servizi ed una semplificazione dei protocolli e delle implementazioni. Comunque va ricordato che la comunicazione tra client e servizi può avvenire sia in modo asincrono che sincrono, in quest’ultimo caso mediante l’uso di bloker di messaggi (AMQP).

In un’architettura SOA invece, grazie al middleware di messaggistica, si possono usare protocolli diversi poichè l’accesso al servizio avviene tramite ESB che inoltre effettua anche una” trasformazione” dei messaggi così che possano dialogare sistemi che hanno un contratto diverso.

Inoltre bisogna osservare che in una architettura a microservizi non avremo mai un microservizio troppo “spinto”, in altre parole avere tutto microservizi significherebbe avere tantissimi piccoli servizi per una solo transazione di business, e visto che ai servizi si accede in maniera remota, avremo che la maggior parte del tempo di responsività per una transazione di business sarà dovuta alla latenza di rete. Viceversa spostare tutto lo slider verso l’architettura SOA porterebbe ad un problema di integrazione e quindi di oneri non banali. Quindi la scelta giusta sta nell’analizzare il contesto di business e di dominio dell’applicazione per capire il livello giusto dove posizionarsi.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *