La SOA, o service-oriented architecture, ossia architettura orientata ai servizi, definisce un modo per rendere i componenti software riutilizzabili e interoperabili mediante delle interfacce di servizio. I servizi utilizzano standard di interfaccia comuni e un modello architettonico tali da poter essere rapidamente incorporati in nuove applicazioni.  Questo solleva da alcuni compiti lo sviluppatore di applicazioni che in precedenza ha sviluppato o duplicato la funzionalità esistente o doveva sapere come connettersi o fornire interoperabilità con le funzioni esistenti.

Ogni servizio in una SOA incorpora il codice e le integrazioni dei dati necessari per eseguire una funzione aziendale completa e discreta (ad esempio, il controllo del credito del cliente, il calcolo di un pagamento di un prestito mensile o l'elaborazione di un'applicazione ipotecaria). Le interfacce di servizio forniscono un legame debole, il che significa che possono essere chiamate con poca o nessuna conoscenza di come il servizio è implementato, riducendo le dipendenze tra le applicazioni. 

Questa interfaccia è un contratto di servizio tra il fornitore del servizio e il consumatore del servizio. Le applicazioni che sono dietro l'interfaccia di servizio possono essere scritte in Java, Microsoft.Net, Cobol o qualsiasi altro linguaggio di programmazione, fornite come applicazioni software confezionate da un fornitore (ad esempio, SAP), applicazioni SaaS (come, ad esempio, Salesforce CRM), oppure ottenute come applicazioni open source.  Le interfacce di servizio sono spesso definite usando i Web Service Definition Language (WSDL), una struttura tag standard basata su xml (extensible markup language).  

I servizi vengono erogati usando protocolli di rete, come SOAP (simple object access protocol), HTTP o Restful HTTP (JSON/HTTP), per inviare richieste di lettura o modifica dei dati. La governance dei servizi controlla il ciclo di vita per lo sviluppo e nella fase appropriata i servizi sono pubblicati in un registro che permette agli sviluppatori di trovarli rapidamente e di riutilizzarli per assemblare nuove applicazioni o processi aziendali.

Questi servizi possono essere sviluppati partendo da zero ma spesso vengono creati esponendo funzioni da sistemi legacy di record come interfacce di servizio.

In questo modo, SOA rappresenta una tappa importante nell'evoluzione dello sviluppo e dell'integrazione delle applicazioni negli ultimi decenni. Prima che la SOA emergesse alla fine degli anni 90, il collegamento di un'applicazione a dati o funzionalità ospitate in un altro sistema richiedeva una complessa integrazione point-to-point, integrazione che gli sviluppatori dovevano ricreare, in parte o completamente, per ogni nuovo progetto di sviluppo. L'esposizione di queste funzioni attraverso i servizi SOA ha permesso allo sviluppatore di riutilizzare semplicemente la funzionalità esistente e collegarsi tramite l'architettura SOA ESB  (vedi sotto).

Sebbene la SOA e la più recente architettura a microservizi, condividono molte parole in comune (ossia "servizio" e "architettura"), sono solo vagamente collegate e, infatti, operano in ambiti diversi, come discusso più avanti in questo articolo.

Un ESB, o enterprise service bus, è un modello architettonico in cui un componente software centralizzato esegue l'integrazione tra le applicazioni.  Esso esegue trasformazioni di modelli di dati, gestisce connettività e messaggistica, esegue il routing, converte i protocolli di comunicazione e gestisce potenzialmente la composizione di richieste multiple. L'ESB può rendere queste integrazioni e trasformazioni disponibili come interfaccia di servizio per il riutilizzo da parte di nuove applicazioni. Il modello ESB viene generalmente implementato utilizzando un toolset e un runtime di integrazione progettati appositamente per garantire la migliore produttività possibile.

È possibile implementare una SOA senza un ESB, ma questo sarebbe equivalente ad avere solo un gruppo di servizi.  Ogni proprietario di un'applicazione dovrebbe connettersi direttamente a qualsiasi servizio di cui ha bisogno ed eseguire le trasformazioni dei dati necessarie per soddisfare ciascuna delle interfacce di servizio. Ma ciò richiede molto lavoro (anche se le interfacce sono riutilizzabili) e crea una significativa difficoltà di manutenzione futura, dato che ogni connessione è point to point.  In realtà gli ESB sono stati considerati un elemento di fatto di qualsiasi implementazione SOA al punto che i due termini vengono talvolta utilizzati come sinonimi, creando confusione.

Leggi di più sugli ESB

Rispetto alle architetture che l'hanno preceduta, la SOA ha offerto notevoli vantaggi alle aziende:

• Maggiore agilità del business e time-to-market più rapido: la riutilizzabilità è la chiave.  L'efficienza dell'assemblaggio di applicazioni da servizi riutilizzabili, ossia i building block, piuttosto che riscrivere e procedere alla reintegrazione con ciascun nuovo progetto di sviluppo, permette agli sviluppatori di costruire applicazioni molto più rapidamente in risposta a nuove opportunità di business. L'approccio architettonico orientato ai servizi supporta scenari per l'integrazione delle applicazioni, l'integrazione dei dati e l'automazione dei processi aziendali o dei flussi di lavoro in stile orchestrazione dei servizi.  Questo accelera la progettazione e lo sviluppo del software consentendo agli sviluppatori di dedicare molto meno tempo all'integrazione e molto più tempo a alla consegna ed al miglioramento delle loro applicazioni. 
  
  
• Possibilità di sfruttare le funzionalità legacy in nuovi mercati: una SOA ben fatta permette agli sviluppatori di utilizzare facilmente la funzionalità 'bloccata' in una piattaforma o ambiente elaborativo e di estenderla a nuovi ambienti e mercati. Ad esempio, molte aziende hanno utilizzato la SOA per portare delle funzionalità dai sistemi finanziari basati su mainframe a nuove applicazioni web, permettendo ai loro clienti di servirsi di processi e informazioni precedentemente accessibili solo attraverso l'interazione diretta con i dipendenti o i business partner dell'azienda.
  
  
• Miglioramento della collaborazione tra azienda e IT: in una SOA, i servizi possono essere definiti in termini di business (per esempio, "generare un preventivo assicurativo" o "calcolare il ROI di un bene strumentale"). Questo consente agli analisti aziendali di lavorare in modo più efficace con gli sviluppatori su importanti insight, quali l'ambito di un processo aziendale definito da un servizio o le implicazioni aziendali della modifica di un processo, che possano portare ad un risultato migliore.

Fino al 2010 le implementazioni SOA sono state utilizzate a pieno regime presso aziende leader praticamente in ogni settore. Ad esempio:

• Delaware Electric è passata alla SOA per integrare sistemi che in precedenza non comunicavano tra loro, con conseguente miglioramento dell'efficienza, il che ha aiutato l'organizzazione a rimanere solvente durante un periodo di congelamento quinquennale delle tariffe elettriche imposto dallo stato.
  
  
• Cisco ha adottato la SOA per assicurarsi che il proprio processo di ordinazione dei prodotti fosse coerente per tutti i prodotti e in tutti i canali, e ha quindi reso disponibili i processi di ordinazione come servizi che le divisioni, le acquisizioni e i business partner di Cisco potevano incorporare nei propri siti web.
  
  
• La Independence Blue Cross (IBC)of Philadelphia ha implementato un SOA per garantire che le diverse componenti che trattavano i dati dei pazienti, agenti di assistenza ai clienti IBC, uffici dei medici, utenti del sito web IBC, lavorassero sulla stessa origine dati (una "unica fonte di verità").

Gli esperti hanno riempito alcune migliaia di pagine cartacee e digitali comparando SOA e microservizi, e definendo le sottigliezze della loro reciproca relazione. Ai fini del presente articolo, le differenze principali tra i due sono l'accoppiamento dei componenti e l'ambito dell'utilizzo:

• La SOA è uno stile architettonico di integrazione e un concetto esteso a livello aziendale. Permette alle applicazioni esistenti di essere disponibili su interfacce tra esse poco collegate, ciascuna corrispondente a una funzione aziendale, il che consente alle applicazioni in una parte di un'azienda estesa di riutilizzare la funzionalità in altre applicazioni.
  
  
• L'architettura con microservizi è uno stile architettonico e un concetto di applicazione. Permette di suddividere gli elementi interni di un'unica applicazione in piccoli pezzi che possono essere modificati, scalati e gestiti in modo indipendente. Non definisce il modo in cui le applicazioni comunicano tra loro, per questo torniamo all'ambito aziendale delle interfacce di servizio fornite dalla SOA.

L'architettura con microservizi è emersa e ha guadagnato terreno con l'aumento di virtualizzazione, cloud computing, pratiche di sviluppo agili e DevOps. La maggior parte dei vantaggi dei microservizi in questi contesti deriva dal disaccoppiamento completo dei componenti, che semplifica e migliora quanto segue:

• Agilità e produttività dello sviluppatore: i microservizi permettono agli sviluppatori di incorporare nuove tecnologie in una parte dell'applicazione senza influenzare il resto dell'applicazione. Qualsiasi componente può essere modificato, testato e distribuito indipendentemente dagli altri, velocizzando i cicli di iterazione.
  
  
• Scalabilità: i microservizi possono sfruttare al massimo la scalabilità del cloud, le dimensioni di qualsiasi componente possono essere adeguate in modo indipendente per ottenere una risposta più rapida alle richieste del carico di lavoro e per un utilizzo più efficiente delle risorse di elaborazione.
  
  
• Resilienza: ancora, grazie al disaccoppiamento, il malfunzionamento di un microservizio non ha impatto sugli altri. Ed ogni microservizio può essere utilizzato in base ai propri requisiti di disponibilità senza impegnare gli altri componenti o l'intera applicazione in base ai più grandi requisiti di disponibilità comune.

Per un'analisi più approfondita delle differenze tra SOA e microservizi, consulta "SOA e Microservizi: qual è la differenza?"

Così come l'architettura dei microservizi ha il potenziale per apportare miglioramenti in agilità, scalabilità e resilienza al design delle applicazioni, queste stesse tecniche possono essere applicate anche all'integrazione. Questo è importante perché, nel tempo, lo schema ESB fortemente centralizzato e il relativo team centralizzato di specialisti dell'integrazione possono diventare un collo di bottiglia. Prendendo in prestito dai principi dei microservizi, possiamo potenzialmente suddividere l'ESB in integrazioni più dettagliate e decentrate. Questa è una delle premesse fondamentali alla base dell'integrazione agile.