Differenze tra Architettura a Microservizi (MSA) e SOA

Sia l’architettura a Microservizi (MSA) che l’architettura SOA possiede vantaggi e svantaggi molto simili.
Più nel dettgalio, nell’architettura SOA sappiamo bene che lo sviluppo di servizi può essere organizzato in più team e ogni team ha bisogno di conoscere il meccanismo di comunicazione comune per poter comunicare con gli altri team.

Tutto ciò richiederà una maggiore dipendenza e collaborazione tra i vari team favorendo un aumento dei tempi di sviluppo e messa in produzione dell’applicazione.
Nei microservizi invece, i servizi possono funzionare e essere distribuiti indipendentemente dagli altri servizi, diminuendo la dipendenza trai i vari team di sviluppo.

In SOA, l’ESB, potrebbe essere oggetto di errore per l’intera applicazione, in quanto ogni servizio comunica tramite l’ESB e se uno di essi rallenta potrebbe causare l’intasamento dell’ESB stesso, di conseguenza il rallentamento dell’intera applicazione. Questa cosa invece, non accade nei microservizi, infatti, essendo indipendenti gli uni dagli altri, se vi è un rallentamento su un determinato microservizio, gli altri microservizi continueranno a gestire tranquillamente le richieste.
Un’altra differenza sostanziale tra le due architetture è che SOA possiede un Database comune per tutti i servizi, mentre in un’architettura a microservizi, ogni servizio possiede un database privato, indipendente dagli altri servizi.

Le applicazioni a microservizi tendono ad essere più modulari (nell’ordine di decine) rispetto a quelle SOA che mediamente non coinvolgevano più di tre o quattro servizi distinti.
La comunicazione tra microservizi nell’architettura MSA, può essere più articolata rispetto a quella SOA, poiché la prima tratta con API piuttosto sofisticate, mentre la seconda con API standard.

Inoltre bisogna notare che in un’architettura a microservizi e SOA, per garantire l’esecuzione di query su dati, si preferisce l’utilizzo di un meccanismo di comunicazione di tipo richiesta/risposta dove: Il client invia una richiesta a un servizio, il servizio elabora le richieste e restituisce la risposta.
Uno stile architetturale diffuso per la comunicazione di tipo richiesta/risposta (utilizzato soprattutto quando si creano servizi) è lo stile architetturale REST (Il Representational State Transfer), ovvero un’astrazione degli elementi di un’architettura all’interno di un sistema hypermedia distribuito.