Cos'è l'architettura SOA - Service Oriented Architettura, come dice il nome stesso architettura orientata ai servizi e perché non va confusa con i microservizi
L’importanza dell’architettura SOA – architettura orientata ai servizi è per molti versi contrassegnata dall’aver segnato un significativo punto di svolta nello sviluppo software, superando il modello monolitico e aprendo la via dei modelli service oriented, dove rientra a pieno titolo anche l’architettura a microservizi, ormai diventata un punto di riferimento nello sviluppo delle applicazioni cloud native.
L’origine della SOA ha avuto luogo negli anni 90, quando le connessioni tra applicazioni e servizi erano ancora rigorosamente sviluppate punto a punto, costringendo gli sviluppatori a ricreare per lo meno tutta l’interfaccia all’avvio di ogni progetto.
Vediamo dunque quali sono state le novità introdotte dalla Service Oriented Architetture, quali sono i vantaggi generazionali che hanno avuto luogo con la sua implementazione, oltre a comprendere quali sono le principali differenze rispetto a quell’architettura a microservizi con cui viene spesso confusa.
Cos’è la SOA (o service oriented architecture)?
L’architettura SOA – ossia Service Oriented Architecture – è letteralmente traducibile come un’architettura orientata ai servizi, un modello di progettazione basato sull’impiego di componenti software accoppiabili per formare applicazioni in sistemi diversi, con la possibilità di riutilizzarli attraverso le interfacce di servizio senza doverle ricreare e riconfigurare da zero ad ogni utilizzo.
Se in primo luogo tale definizione potrebbe apparire complessa, basti pensare al fatto che la SOA è nata per superare le tradizionali architetture monolitiche, decomponendo il software in vari elementi secondo vari criteri, ad esempio distinguendo le varie funzioni, piuttosto che le parti funzionali ad una particolare divisione aziendale, in modo da poterle sviluppare, gestire e aggiornare in maniera distinta.
Ancor prima di entrare nel merito dei vantaggi specifici dell’architettura SOA e delle sue eventuali criticità, appare evidente come tra le architetture monolitiche e le SOA vi sia una differente filosofia nell’impostazione generale di un progetto. Se nel primo caso l’applicazione è strettamente interdipendente e di fatto compresa in un unico eseguibile, nel caso dell’architettura orientata ai servizi, l’applicazione viene scomposta in componenti a basso accoppiamento, il più possibile indipendenti tra loro, in modo da poterli ricombinare senza eccessivi vincoli di sorta.
Tale approccio diversifica in maniera sostanziale anche la gestione e il mantenimento delle applicazioni. Nel caso di un software monolitico, l’aggiornamento di un’applicazione presume un periodo di down utile a caricare i nuovi file sul sistema. Nel caso di un’applicazione SOA l’aggiornamento può coinvolgere i vari pacchetti che compongono il software in momenti differenti, senza rendere necessaria un’interruzione di servizio.
Nel caso di una architettura SOA, i servizi stessi sono richiamabili attraverso i web services, disponibili ovunque attraverso i più diffusi protocolli di comunicazione. È inoltre frequente l’impiego di modelli come l’Enterprise Service Bus (ESB) per integrare i componenti con i sistemi di backend e renderli a loro volta disponibili come interfacce di servizio. Tali interfacce facilitano il riuso dei componenti grazie all’utilizzo di descrizioni standardizzate.
In altri termini, grazie all’impiego di un modello SOA le nuove applicazioni aziendali possono essere create connettendo in maniera differente vecchi e nuovi componenti, grazie al ridotto livello di dipendenza di un’architettura che evita di fatto di dover riscrivere ogni volta il codice da zero.
I vantaggi dell’architettura SOA
L’adozione di un’architettura orientata ai servizi ha consentito alle aziende una serie di vantaggi rispetto al tradizionale modello monolitico, che discendono nella maggior parte dei casi proprio dalle differenze architetturali.
- Maggior flessibilità nello sviluppo: rispetto ad un’applicazione monolitica, la pacchettizzazione in vari componenti consente una gestione per natura molto più agile, con la possibilità di intervenire puntualmente senza dover coinvolgere il software nella sua interezza, ad esempio rilasciando un nuovo modello.
- Riduzione time to market e costi del software: la possibilità di poter assemblare applicazioni da interfacce riutilizzabili consente di risparmiare molto tempo rispetto a dover riscrivere e integrare ogni nuovo progetto di sviluppo software. Un notevole vantaggio è costituito dalla possibilità di riutilizzare delle funzionalità legacy molto collaudate adattandole alle esigenze applicative di un nuovo business.
- Facilità di gestione nel medio e lungo termine: la scomposizione delle principali funzioni di un software in differenti componenti consente di delegare lo sviluppo a team distinti, senza costringere tutti i programmatori ad essere costantemente aggiornati su tutti i contenuti, il che costituirebbe un’inutile distrazione al proprio lavoro. Grazie ad un buon project management è pertanto possibile superare in maniera piuttosto indolore anche sostanziali variazioni nei team di sviluppo che concorrono alla realizzazione dei vari pacchetti di un software.
- Manutenzione semplificata e maggior resilienza: La possibilità di intervenire in maniera indipendente sui singoli elementi di un software consente di lavorare a varie velocità sulle funzioni previste, senza dover programmare e attendere dei rilasci concentrati, come avviene nel caso del software monolitico. Allo stesso modo, tale approccio consente una maggior resilienza dell’applicazione, in quanto se dovesse verificarsi un problema, sarebbe possibile intervenire puntualmente, senza dover rilasciare una nuova versione complessiva del software.
È evidente che un’organizzazione architetturale come quella citata abbia un senso quando si parla di progetti di una certa rilevanza. Per applicazioni semplici o rapide nello sviluppo, su cui è ad esempio attivo un solo programmatore, oppure nelle condizioni in cui non si prevedono aggiornamenti frequenti può infatti risultare più conveniente sviluppare con un’architettura monolitica. Non vi sono regole assolute. Al di là di alcuni requisiti tipologici che si possono intendere quali dei veri e propri standard, è soprattutto l’esperienza ad orientare la scelta di un’architettura rispetto ad un’altra.
Alcuni esempi di architettura SOA
Prendendo spunto dalle classificazioni del W3C, potremmo concordare sul fatto che il caso di architettura SOA più celebre sia rappresentato dal World Wide Web. Indubbiamente basato su un’architettura a servizi, il www è un sistema informativo che utilizza quali risorse dei dati in formati molto popolari come .xml, .html, .css, .jpeg, .pdf. Gli URIs (Uniform Resource Identifiers) consentono a chiunque di richiamarli attraverso i vari protocolli utilizzati dai web browser su reti aperte alla navigazione pubblica.
Se il WWW costituisce l’esempio di implementazione pubblico più diffuso, per quanto riguarda le applicazioni aziendali le SOA vengono utilizzate in svariati ambiti, sia per sviluppare soluzioni utili alla comunicazione interna che per garantire servizi ai clienti. L’elemento che le accomuna è il fatto di essere finalizzate ad interfacciare le applicazioni con determinate funzioni aziendali, facilitando per l’appunto il riutilizzo delle funzionalità sviluppate in precedenza.
Anche se l’architettura service oriented può apparire complessa nella sua topologia, è possibile esemplificarla in maniera piuttosto semplice. Pensiamo ad esempio ad un servizio di internet banking. Nella sua manifestazione ricorrente si basa su vari componenti distinti come l’interfaccia utente, l’anagrafica del cliente, le info sui conti correnti, le operazioni online, il conto titoli, i mutui e i finanziamenti attivi, le carte di credito, il sistema di customer care, ecc. Tali informazioni con ogni probabilità provengono dalla pluralità di sistemi informativi che fa capo all’istituto di credito che eroga il servizio. I singoli componenti possono essere gestiti da team diversi e vengono connessi grazie ad un’unica applicazione centralizzata, capace di rendere disponibili tutte le funzioni all’utente finale. Un’analoga composizione modulare delle funzioni, focalizzata sul catalogo prodotto, è alla base delle applicazioni e-ecommerce.
Prendendo spunto dall’esempio appena citato, è possibile sottolineare come le SOA vengano utilizzate nel fintech anche in ambiti differenti dall’internet banking, ad esempio per gestire in maniera flessibile i componenti relativi alle applicazioni per il rilascio di polizze assicurative, piuttosto che per l’erogazione dei mutui. Nelle applicazioni molto complesse, che prevedono contributi estremamente specialistici, le architetture SOA consentono di affidare lo sviluppo in outsourcing di determinati componenti, assicurandosi la possibilità di integrarli in qualsiasi momento nell’applicazione principale. Tale eventualità può rivelarsi comoda per gestire i servizi di ticketing, ad esempio quando si rivela utile il subappalto a terzi dei servizi di customer care, come nel caso di molte compagnie attive in ambito telco.
Le applicazioni SOA sono inoltre molto diffuse nelle società fornitrici di energia. Un’architettura orientata ai servizi risulta infatti congeniale allo sviluppo dei layout process-driven di quelle applicazioni dotate di componenti funzionali molto ben distinti tra loro, che non avrebbe alcun senso gestire in maniera monolitica. È ad esempio il caso delle aziende attive nella grande distribuzione, che devono continuamente integrare dati provenienti da centinaia di fornitori, integrandole ad esempio con funzioni relative all’approvvigionamento e alla disponibilità a scaffale.
SOA o microservizi?
Come anticipato, le service oriented architecture vengono spesso confuse con i microservizi. È dunque arrivato il momento di disambiguare questa vicissitudine, precisando le distinzioni tra due dei modelli a servizi più diffusi in ambito IT.
A livello teorico, confonderle è molto semplice, dal fatto che per molti aspetti concettuali SOA e microservizi sono addirittura analoghi. Tale confusione svanisce dal momento in cui entriamo nel merito delle loro applicazioni. Le SOA costituiscono un approccio architetturale a livello enterprise, relazionandosi con interfacce corrispondenti ad una precisa funzione aziendale, mentre i microservizi rappresentano una tecnologia più moderna ed orientata nello specifico a supportare gli ambienti di sviluppo delle applicazioni cloud native.
Entrambi i modelli si basano sulla decomposizione delle applicazioni da una struttura monolitica in vari componenti disaccoppiati. In tal senso i microservizi possono essere intesi quale una evoluzione delle SOA, concepito nello specifico per supportare i modelli di sviluppo basati su metodologie recenti come DevOps e Agile con logiche operative strutturate su flussi CI/CD (integrazione continua / rilascio continuo). Le applicazioni cloud native sono ad esempio dei microservizi a basso accoppiamento distribuiti in container, tra loro connessi tramite API o tecnologie similari.
Mentre le SOA prevedono comunque un design centralizzato, con l’utilizzo di un ESB, i microservizi non definiscono a priori il modo con cui i componenti comunicano tra loro, il che consente di fatto il loro totale disaccoppiamento. I microservizi devono naturalmente la loro enorme fortuna alla diffusione dei servizi in cloud, dal momento che i nuovi software che prevedono la distribuzione con modello a servizio (es. SaaS) vengono implementati con logiche cloud native, profondamente differenti rispetto alle logiche monolitiche.
Possiamo dunque sostenere con fermezza che, pur essendo di fatto entrambi dei modelli a servizi, mettere sullo stesso piano SOA e microservizi non abbia alcun senso pratico, dal momento che si tratta di applicazioni del tutto differenti, nate e cresciute per risolvere esigenze altrettanto distinte tra loro.
