Service Oriented Architecture, fino a ieri chiave di uno sviluppo applicativo incentrato sulla modularità e ispirato alla programmazione ad oggetti. In base al reciproco comportamento, le applicazioni erano ripartite tra soluzioni fornitrici di servizi e soluzioni consumatrici di servizi. Attraverso una Service Oriented Architecture, dunque, qualunque software modulare con determinate funzionalità applicative abilita una programmazione granulare lato back end, grazie a un’interfaccia formalizzata secondo standard specifici. Questo facilita poi la delivery dell’applicazione sul front end.
Oggi che cosa è cambiato? Cloud computing e virtualizzazione hanno spianato la strada a una modalità di programmazione incentrata sui microservizi. Il che non ha invalidato alcuni principi SOA. Per capire differenze e analogie bisogna entrare più nel dettaglio a livello di implementazione.
Service Oriented Architecture e microservizi: differenze e analogie
Lo sviluppo di un’architettura orientata ai servizi (SOA): è stato l’abbrivio per i software di rete. Per oltre 50 anni il lavoro degli sviluppatori era stato quello di costruire moduli software che facevano parte di applicazioni monolitiche più ampie.
L’evoluzione delle tecnologie di networking ha potenziato la qualità della programmazione, consentendo di distribuire, ridimensionare e ridistribuire le varie componenti a seconda delle esigenze specifiche. Ecco 6 aspetti che evidenziano similitudini e differenze tra una programmazione in chiave SOA e una che emula il modello dei microservizi:
1) La mission delle SOA
Le Service Oriented Architecture permettevano di capitalizzare i progressi della rete per distribuire componenti software, individuando i componenti attraverso un servizio di directory per collegarli tra loro senza diminuire la sicurezza o l’affidabilità della soluzione. Oggi questi componenti possono fornire servizi ad altri componenti e applicazioni, scambiare richieste e risposte su una rete e utilizzare un broker API per trovarsi l’uno con l’altro. Un modello che viene oggi emulato dalla programmazione basata sui microservizi.
2) La componentizzazione
SOA e microservizi condividono il concetto della componentizzazione. Una componente è una porzione di applicazione che gli sviluppatori scrivono e distribuiscono in modo indipendente, collegando le connessioni di rete e i flussi di lavoro. Sia le SOA che i microservizi, infatti, partono dal presupposto che le applicazioni saranno suddivise in vari componenti, collegati tra loro attraverso una connessione di rete. La componentizzazione consente alla programmazione di diffondersi su più server, migliorando le prestazioni. In questo modo il lavoro di sviluppo del team risulta semplificato poiché i componenti per aggregarsi utilizzano un’interfaccia comune e ben definita.
Più in dettaglio, le Service Oriented Architecture sono basate su un concetto di accoppiamento di rete. Ogni componente a cui si accede tramite una connessione di rete, dunque, viene tratto come se fosse un componente locale. In che modo? Attraverso una versione evoluta di una procedura remota chiamata Simple Object Access Protocol.
I microservizi, invece, utilizzano il modello REST orientato al web. Questa differenza riflette semplicemente i cambiamenti nelle pratiche di programmazione scatenate dall’evoluzione di Internet. Il REST chiama le risorse servizi, mentre le SOA le chiama oggetti. In realtà gli approcci sono molto similari.
3) Integrazione e scoperta
L’accoppiamento di rete è anche associato alla nozione di scoperta e associazione tardiva (late binding). Un componente non si integra in fase di sviluppo (in gergo tecnico: early binding) ma, piuttosto, si collega ai servizi di esecuzione (runtime). Questo comporta un processo di identificazione di quell’interfaccia del componente chiamata API.
Con le Service Oriented Architecture il processo di individuazione si collega alla directory Universal Description, Discovery and Integration (UDDI), mentre i microservizi, invece, utilizzano un broker API. Questo modello di integrazione e identificazione semplifica la modifica di un servizio senza interferire con il resto dell’applicazione o delle applicazioni correlate.
4) Indipendenza dal servizio
Un altro dei principi SOA che si applica anche ai microservizi è l’indipendenza del linguaggio. I servizi non hanno bisogno di usare lo stesso linguaggio di programmazione, middleware o OS: basta che supportino l’API che hanno in comune. È vero anche che i microservizi sono più indipendenti l’uno dall’altro, dal momento che le API RESTful utilizzano solo strumenti e convenzioni di programmazione comuni sul web. Questa indipendenza a livello di implementazione aiuta a riutilizzare il codice e a distribuire il lavoro in una più ampia varietà di server.
5) Classificazione del servizio
Le SOA hanno introdotto diverse classificazioni di servizio. In generale, i servizi possono supportare una funzione aziendale, come l’immissione degli ordini o una funzione di piattaforma, così come l’inserimento nel journal per la registrazione della conformità. Alcuni documenti SOA definiscono in realtà quattro classi di servizio specifiche, dividendo ulteriormente il lato funzionale del modello. Analogamente, anche i microservizi seguono questo principio di classificazione del servizio. Tuttavia, i servizi SOA sono in genere più espliciti, mentre i microservizi tipicamente utilizzano una classificazione basata sulle funzionalità fornite piuttosto che su come sono richiamati e strutturati i servizi.
6) Orchestrazione
Un altro concetto che evidenzia le analogie tra Service Oriented Architecture e microservizi è l’idea di orchestrazione delle applicazioni. Con le SOA, la maggior parte delle applicazioni vengono costruite attorno a un bus di servizio che fornisce la gestione dei messaggi in base alle regole aziendali, spesso redatte in BPEL (Business Process Execution Language). Le applicazioni collegate ai microservizi, invece, possono utilizzare una varietà di strumenti per l’orchestrazione, tra cui il broker API, un componente storefront o persino un’app mobile.
SOA e microservizi oggi
Come ribadiscono gli esperti, SOA e microservizi presentano più che altro differenze a livello di implementazione più che in linea di principio. La maggior parte delle applicazioni SOA sono costruite attorno a un bus di servizio aziendale che, all’interno dell’applicazione, fornisce le linee guida della programmazione all’interno di un’applicazione, ma anche tra le applicazioni correlate. I principi SOA, in sintesi, dipendono dal livello di componentizzazione all’interno di una o più applicazioni specifiche, ma si tratta di una questione pratica più che politica.
Un’altra sottile differenza a livello di implementazione è che i microservizi sono essenzialmente strumenti di tipo infrastrutturale piuttosto che strumenti applicativi. Una Service Oriented Architecture crea servizi di base mentre i microservizi lavorano su componenti separati, analogamente ai siti Web su Internet. Il riutilizzo dei microservizi tra le applicazioni rende più importante la gestione delle API e più difficile affidarsi a modelli specifici di implementazione, ridistribuzione e ridimensionamento.
In conclusione, se è vero che i microservizi sono un approccio nuovo e diverso che risolve un problema di vecchia data radicato nei concetti di software e di rete è vero anche che le SOA hanno risolto la maggior parte di questi problemi a suo tempo, introducendo principi di base dello sviluppo software che sono validi ancora oggi.
