I vantaggi delle architetture a microservizi

Il crescente utilizzo del cloud e le continue evoluzioni del parco applicativo sono solo alcuni degli elementi che stanno rendendo sempre più popolare l’utilizzo delle architetture basate sui microservizi. L’orientamento verso una logica a container vuole consentire un utilizzo migliore e più rapido delle risorse, che siano locali o nel cloud, ridimensionandole per soddisfare le variazioni della domanda, oltre che favorire modularità e riusabilità. Cambia inoltre il modo di ‘pensare e realizzare’ il software applicativo in una logica collaborativa che abbraccia gli stili DevOps/Agile per ‘continuous delivery’ e ‘continuous integration’, con rilascio continuo in produzione. Un approccio differente rispetto ai modelli Soa e Web Services, così come al vecchio modello monolitico, e che interviene, modificandolo, sullo sviluppo applicativo. In che modo? Quali sono le novità in ambito di ‘tecnologico’ e di ‘modalità di sviluppo’ che meglio supportano il modello a microservizi? Quali i vantaggi e gli ambiti di utilizzo in cui questo modello esprime le maggiori potenzialità?

La redazione di Office Automation lo ha chiesto ai protagonisti del settore durante “Architetture a Microservizi e Container: agilità e sicurezza nell’era del multicloud e dell’azienda ‘aperta’”, la web roundtable che ha riunito attorno a un unico ‘tavolo’ Citrix, Dell Technologies, E4 Computer Engineering, IBM, Microsoft, Omnia Comunicazioni, Oracle, Red Hat, Veeam, Veritas e VMware. Un incontro che, come potete leggere nelle prossime pagine, ha fornito diversi spunti di riflessione utili a comprendere le evoluzioni, le peculiarità e i benefici che caratterizzano queste architetture.

Giorgio Loddo, strategic account sales engineer di Citrix

La transizione dai sistemi monolitici all’utilizzo dei microservizi nasce da esigenze di business che si sono tramutate nello sviluppo delle applicazioni. Una transizione che ha creato una complicazione a livello di integrazione: i microservizi permettono di disporre di collegamenti che possono essere intra-data center ma anche extra-data center. Si parla, in tal senso, di hybrid multicloud. Questa è la differenza sostanziale tra un ambiente monolitico e un ambiente Soa basato su un service: non esistono più frontiere o elementi sempre all’interno dello stesso data center. Tutto ciò, dal punto di vista tecnologico, richiede delle funzionalità che prima erano assenti, o comunque non erano richieste: un’integrazione sulla sicurezza, con API che consentano un dialogo sicuro tra i microservizi, oltre che una gestione del traffico volta a fare in modo che i container e le applicazioni possano comunicare agevolmente. Il tutto, senza dimenticare gli strumenti di controllo che devono essere messi a disposizione delle operation. Se da un lato i team DevOps possono realizzare il delivery e il deployment in automatico, l’aumento della complessità che deriva dalla containerizzazione sul fronte infrastrutturale richiede maggiore granularità nella visibilità e negli analytics presenti in un’architettura. Citrix permette l’implementazione della containerizzazione utilizzando il suo standard de facto: grazie a Citrix ADC, il nostro application delivery controller, la nostra società ha permesso alle aziende di pubblicare in sicurezza servizi partendo da modelli fisici e virtuali per arrivare a modelli CPX. Nel mondo della containerizzazione, in particolare, Citrix propone un application delivery controller che racchiude tutti i vantaggi della tecnologia Citrix ADC, come appunto la granularità del controllo, della visibilità e le caratteristiche di sicurezza. Una soluzione che consente di lavorare su una piattaforma, Citrix ADC CPX, tale per cui cambia solo il fattore di forma ma non si modificano le funzionalità. Grazie alla componente di application delivery management, riusciamo a offrire inoltre la visibilità di tutte le attività e le interazioni applicative sfruttando un singolo pannello di controllo. La containerizzazione permette il riutilizzo degli sviluppi realizzati e porta con sé delle evoluzioni significative che percepiamo direttamente anche in Citrix. Tra queste, un diverso approccio dell’IT in cui un ruolo di primo piano oggi è ricoperto proprio dalla componente di sviluppo, di programmazione e di utilizzo di API. In questo scenario, tenuto conto che con la containerizzazione il perimetro di applicazioni è distribuito, risulta necessario però lato operation disporre di una componente di analytics e di visibilità ottimale. Funzionalità che la nostra società riesce a garantire proprio grazie a Citrix ADC e alla sua componente di application delivery management che ricopre un ruolo chiave per approcciare al meglio queste nuove architetture.

Fabrizio Garrone, senior presales manager di Dell Technologies

Le architetture a microservizi si basano su un approccio che suddivide l’applicazione in una serie di componenti più piccole e specializzate, ciascuna delle quali comunica con le altre attraverso interfacce comuni. Un approccio in netto contrasto con il vecchio modello monolitico che prevedeva di creare applicazioni come singole entità. Le architetture a microservizi rappresentano un’evoluzione delle architetture Soa, ma da queste si differenziano su diversi fronti: sono costituite da servizi indipendenti tra loro ognuno dei quali si concentra su un particolare aspetto di business per poi realizzare un’applicazione più complessa. La tecnologia di base che ha contribuito al successo del modello a microservizi è quella dei container che semplifica al massimo il concetto di macchina virtuale includendo in un unico pacchetto software sia il sistema operativo sia l’applicazione. Una delle notevoli differenze rispetto ai modelli monolitici e alla Soa è data dal fatto che con i microservizi le architetture sono distribuite e condivise: possono risiedere all’interno del data center ma anche essere distribuite in cloud pubblici o in ambienti ibridi. Progettare un’architettura di questo tipo richiede sicuramente degli sforzi aggiuntivi e società come la nostra hanno l’obbligo di semplificare questo lavoro. Dell Technologies, in questo scenario, aiuta le aziende a ottimizzare i tempi richiesti per essere operativi lasciando sempre e comunque la scelta tra un approccio buy, in termini di soluzioni già pronte, o build, fornendo ai clienti la possibilità di comporre i vari elementi delle infrastrutture necessarie allo sviluppo e il supporto di tali applicazioni. Un esempio di approccio buy che Dell Technologies offre al mercato è rappresentato dalle nostre soluzioni iperconvergenti realizzate per ospitare infrastrutture di gestione e orchestrazione di microservizi, siano esse basate su Kubernetes piuttosto che su altri strumenti di orchestrazione. Con queste soluzioni adottiamo un approccio decisamente chiavi in mano al deployment e al self-management, attraverso un’offerta completa di infrastrutture integrate. Il nostro obiettivo è fornire all’infrastruttura IT la stessa flessibilità e scalabilità che le architetture a container oggi offrono e consentire – allo stesso tempo – alle aziende una crescita coerente sia dal punto di vista della metodologia di sviluppo applicativo sia delle infrastrutture IT a supporto. Con questo fine, la piattaforma iperconvergente di riferimento di Dell Technologies, VxRail, è in grado di supportare diverse modalità di sviluppo a container essenzialmente basate su Kubernetes. Grazie ad essa, siamo in grado di ospitare le versioni open source o comunque stand-alone, e soluzioni Kubernetes completamente integrate, basate sulla più recente tecnologia VMware, per fornire in un’unica infrastruttura iperconvergente una modalità computazionale tradizionale, basata sulla classica virtual machine, e una piattaforma di sviluppo cloud native fondata sui microservizi. Dell Technologies si pone l’obiettivo di supportare i clienti e i partner affinché possano cogliere e massimizzare i benefici che portano queste architetture; con le nostre soluzioni diamo la possibilità alle aziende di iniziare un percorso di trasformazione semplificando la piattaforma sistemistica.

Simone Zanotti, digital transformation officer di E4 Computer Engineering

E4 Computer Engineering, player da sempre attivo in ambito HPC e con un focus forte sulle componenti hardware, di calcolo parallelo e di prestazioni elevate, negli ultimi tre anni ha deciso di estendere la propria proposizione anche alle soluzioni software, in particolare con componenti open source.

Dal nostro osservatorio, rispetto alla Soa tutta la logica di microservizi e di architetture containerizzate può essere considerata una naturale evoluzione di un modello che prevedeva la suddivisione per silos applicativi. Un cambio di paradigma che porta sicuramente a dei benefici ma che evidenzia ancora diverse lacune a livello di approccio.

Costruire un’architettura a microservizi containerizzata non significa introdurre tutti gli elementi che prima caratterizzavano uno stack monolitico in un container: significa evidenziare, tramite una fase iniziale di analisi, quali sono le funzionalità necessarie per un applicativo e raggiungere un livello di granularità e di atomicità molto preciso.

Il classico esempio di un progetto di questo tipo è un sito web in cui un container di un singolo microservizio può essere rappresentato dalla funzione di login. Una volta che quella funzionalità avrà raggiunto il suo stato ottimale, difficilmente riscontrerà problemi: sarà aggiornata nuovamente solo quando dovrà essere evoluta con eventuali nuove versioni, ma il processo sarà più solido in quanto il singolo ‘mattoncino’ avrà raggiunto una pulizia di scrittura che oggi non può essere raggiunta sfruttando un layout più complesso.

L’altro elemento fondamentale portato dalle architetture a microservizi è l’interoperabilità: ogni container e microservizio deve essere realizzato per poter interagire con un’infinità di altri container nel modo più agnostico possibile. Per garantire questa interazione, è necessario utilizzare linguaggi che forniscano flessibilità di comunicazione tra le differenti funzioni, a discapito di soluzioni chiuse o caratterizzate da protocolli personalizzati o proprietari.

Nell’ottica della miglior consulenza possibile verso i clienti, per E4 Computer Engineering è importante sottolineare questi aspetti al fine di disegnare soluzioni basate su microservizi e container che siano a prova di futuro, senza dimenticare che da parte delle aziende vi è una necessità sempre più forte di semplicità d’uso e di un’immediatezza. Questo livello è già stato raggiunto nel mondo consumer e privato e ormai gli utenti, e colleghi, si attendono la stessa esperienza d’uso anche nel contesto corporate. Le aziende desiderano questo livello di semplicità anche nelle architetture IT e noi addetti ai lavori dobbiamo essere in grado di fornirla, consapevoli che dietro le quinte risiede una complessità che continua a crescere e che richiede nuovi protagonisti e diverse competenze.

Il mondo dei microservizi ha un’infinità di vantaggi: fornisce agli sviluppatori una maggiore libertà di movimento, la possibilità di creare container, infrastrutture e servizi con una maggiore possibilità di sperimentare e magari sbagliare all’interno di un contesto controllato.

Questa libertà si porta dietro una quotidianità operativa che deve cambiare e in cui è importante mettere al centro un salto culturale: in questo senso, è fondamentale disporre internamente, non solo di una profonda conoscenza tecnologica, ma anche e soprattutto metodologica per cogliere appieno i benefici e i vantaggi che le architetture a microservizi oggi riescono a garantire.

Oltre alla proposta tecnologica e consulenziale in E4 cerchiamo di diffondere questo approccio, benefico sia per gli addetti ai lavori che per gli utenti, attraverso approfondimenti e divulgazione tramite il nostro blog www.E4Company.com/blog.

Roberto Pozzi, hybrid cloud architect di IBM

L’architettura a microservizi risponde a un desiderio insito nel software architect di costruire sistemi modulari. La modularità è un beneficio che si può ottenere in diversi modi e il concetto di servizio come elemento indipendente consente certamente di seguire questa direzione.

La differenza tra il modello a microservizi e la Soa risiede sì nello stile architetturale, che ovviamente presenta delle diversità, ma anche nel modello di sviluppo. In questo senso, la differenza sostanziale non è tanto tecnologica, ma soprattutto organizzativa. L’architettura a microservizi comporta un’organizzazione dei team attorno al confine degli stessi microservizi e un certo livello di responsabilità decentralizzata: si opera maggiormente in un’ottica di prodotto, non di progetto, con un approccio vicino al DevOps in cui la responsabilità del livello di servizio è a vario titolo condivisa.

Il modello a microservizi è uno stile architetturale che può essere implementato con diverse modalità e non vi è dubbio che alcune delle caratteristiche ottimali dei microservizi si sposino quasi perfettamente con le caratteristiche peculiari dei container, in quanto un microservizio è per sua natura eseguibile in un processo a sé stante.

In questo scenario, esistono delle tecnologie che dal mio punto di vista sono particolarmente rilevanti anche nell’ambito della proposta di IBM. La prima è Kubernetes, che concretizza e amplifica una potenzialità intrinseca dei microservizi di essere indipendentemente scalabili, facilmente bloccabili e riavviabili, oltre che ripianificabili.

IBM ha puntato in maniera significativa su Red Hat OpenShift, piattaforma di abilitazione di queste nuove architetture che consente di sviluppare, adottare e gestire in un’ottica ibrida questi aspetti, e ha posto un importante focus su due elementi che sempre più saranno rilevanti per i modelli a microservizi: l’approccio serverless e i service mesh.

Una tecnologia perfettamente abilitata dalle offerte IBM è Knative: costruita su Kubernetes, Knative astrae gli sviluppatori dalla complessità, semplifica il deployment e introduce gli elementi di un’architettura asincrona, quindi event driven, ritagliata perfettamente su un modello fortemente distribuito come i microservizi.

Una soluzione di valore è Istio, service mesh supportata da IBM e Red Hat che rende più semplice lo sviluppo e la gestione di alcuni aspetti, come il load balance e il monitoring. Elementi che, se da un lato l’architettura a microservizi abilita più facilmente rispetto ad architetture tradizionali monolitiche, dall’altro devono essere gestiti nella loro complessità. Le soluzioni presenti nell’ambito della proposta di IBM hanno l’obiettivo di rispondere a questa primaria necessità.

Marco D’Angelo, Azure dev. advocacy manager, Western Europe, Microsoft

Nel 2002, anno in cui sono entrato in Microsoft, lo sviluppo delle applicazioni monolitiche era lo standard in tale campo. Le architetture SOA a quei tempi erano la novità del momento, anche se le specifiche e i protocolli definiti da utilizzare erano già stati normati e alcuni di questi erano stati creati internamente in Microsoft. Una società, la nostra, che essendo un provider di piattaforma ha sempre avuto un palcoscenico di primo piano per seguire tutte le evoluzioni in tale ambito. Microsoft, ai tempi delle architetture monolitiche, aveva il suo web server, il suo application server, il suo database, ed era quindi in grado di creare la perfetta architettura che scalava solo verso l’alto. Negli anni ci siamo evoluti dando anche un importante supporto alla creazione degli standard che sono stati poi utilizzati.

Lo sviluppo di applicazioni sul paradigma Soa avveniva sulla base di specifiche, sulla base di qualcosa di prescrittivo. Con le architetture a microservizi lo scenario è cambiato nell’ottica di una maggiore flessibilità: i microservizi possono essere scritti con il framework e il linguaggio ritenuto più idoneo e possono comunicare tra loro sfruttando protocolli leggeri, senza quei vincoli definiti dalle applicazioni basate su un’architettura Soa, dove anche il modello di sviluppo era estremamente rigido.

Una differenza sostanziale, questa, indotta dall’evoluzione che è avvenuta nel corso degli anni: come il monolitico si è evoluto nel modello Soa, così il modello Soa sta evolvendo verso un modello a microservizi. Un cambiamento che comporta una sfida: ripensare il modo in cui sviluppare le applicazioni prima di metterle in esercizio. In questo scenario, un ruolo chiave dal mio punto di vista è ricoperto dal modello ‘agile’: un modello iterativo che prevede dei team più ristretti che si occupano di una componente a prospettiva di prodotto. Microsoft è cambiata significativamente nel corso degli anni e in questo percorso ha abbracciato modalità molto più aperte di sviluppo, convertendo negli ultimi tre anni circa 37mila sviluppatori proprio alla modalità ‘agile’.

La nostra società oggi sviluppa i propri servizi con questa modalità e li costruisce su un’infrastruttura sottostante di ulteriori servizi e microservizi. Un esempio di questo approccio è rappresentato da Microsoft 365, la nostra soluzione di produttività basata su Microsoft Azure che in questo periodo di emergenza ha registrato crescite di utilizzo di ben il 755% in tutta Europa. Una crescita che siamo riusciti ad accompagnare, non solo grazie alle 54 Region di data center a livello globale, ma perché chi aveva sviluppato quelle applicazioni lo aveva fatto disaccoppiando determinate funzionalità per consentirne la scalabilità in maniera asimmetrica.

L’evoluzione all’architettura a microservizi ha portato a una revisione di quelli che sono i modelli di sviluppo con la necessità di fare ‘embrace’ di una serie di complessità che toccano anche il tema delle competenze. Un argomento centrale per Microsoft che è impegnata con iniziative specifiche dedicate alla formazione e al reskilling nell’ambito dello sviluppo applicativo. Una missione, questa, che nel tempo si è concretizzata in Microsoft Learn, la nostra piattaforma di training gratuita, e che in Italia ha portato al lancio di Ambizione Italia, programma volto alla trasformazione digitale del Paese che pone un importante focus sulla crescita delle competenze digitali a tutti i livelli.

Marco Ferra, IT consultant di Omnia Comunicazioni

I microservizi rappresentano un insieme di servizi autonomi nel loro funzionamento, costruiti su esigenze di dominio e gestibili in modo indipendente. Un paradigma importante nell’ambito dello sviluppo per le aziende che come sappiamo hanno sempre più la necessità di essere veloci nell’output delle funzionalità dei propri prodotti e nel test delle nuove tecnologie da offrire ai clienti. Uno degli elementi caratterizzanti i microservizi è la possibilità di poter introdurre nuove funzionalità in modo indipendente dal resto dell’ecosistema. Una differenza sostanziale rispetto a un modello Soa o a un modello monolitico in cui, nel momento in cui si ha la necessità di introdurre una nuova funzionalità o di risolvere un bug, bisogna agire in modo più rigido, meno flessibile. Con i microservizi viene garantita maggiore elasticità e confidenza nel deployment e questo cambio di approccio incide anche sull’organizzazione interna dei team di sviluppo, che sono più piccoli, cross funzionali e non più dipartimentali in senso orizzontale.

La logica a microservizi modifica in modo sostanziale il modello di sviluppo applicativo e alcune buone pratiche che prima non erano necessarie con questa architettura diventano fondamentali. Faccio riferimento, per esempio, al domain-driven design, alla test automation, alla containerizzazione, alla continuous integration e al continuous deployment.

Omnia Comunicazioni è impegnata nell’indirizzare tecnologie che rispondono a queste esigenze: soluzioni che, prima di proporre sul mercato, studiamo in modo meticoloso internamente per fare in modo che tutta la complessità che comporta un’architettura a microservizi non sia visibile ai clienti. Tra queste tecnologie, un ruolo di primo piano è sicuramente ricoperto dalla virtualizzazione, essenziale per aiutare il passaggio graduale da un sistema monolitico a un sistema a microservizi, così come essenziale è la gestione della continuous integration e del test automatico.

Un insieme di soluzioni che ha l’obiettivo di gestire la complessità dei microservizi, il cui aspetto caratteristico è anche la capacità di adattarsi a quelle che negli ultimi anni sono state le principali parole d’ordine in questo ambito: l’agilità nello sviluppo e il cloud. Due temi, questi, che sposano appieno una delle filosofie basilari del microservizio: essere scalabile e veloce nella risposta ai bug e alle nuove funzionalità che nel tempo possono essere richieste dal business. Il tutto, senza dimenticare un tema chiave anche per queste architetture: la sicurezza informatica, da garantire non solo con tecnologie, ma con competenze allargate e una maggiore maturità da parte dei team interni. Team che dal mio punto di vista sono chiamati a sviluppare anche capacità di analisi utili a comprendere sin dalle fasi iniziali di ogni progetto quando risulta veramente necessario adottare un ambiente a microservizi in base alle esigenze e agli obiettivi da raggiungere.

Matteo Sassi, principal solution engineer di Oracle

Il modello Soa risponde a un concetto di efficienza; il suo obiettivo è riutilizzare le risorse il più possibile in un approccio che mette al centro il tema del controllo e della standardizzazione. I microservizi, invece, si legano maggiormente a un concetto di efficacia in termini di velocità di innovazione e consentono di realizzare esperimenti in modo rapido e flessibile. È questa la differenza principale tra la Soa e un’architettura a microservizi, la cui sede naturale è a tutti gli effetti il cloud.

Il cloud permette di eliminare la complessità e di abbassare le barriere all’ingresso di queste architetture: consente di ottenere l’infrastruttura per ogni microservizio nel momento in cui serve in modo flessibile, rendendo efficiente ed economica anche la gestione e l’adozione di questi nuovi modelli con tutte le facilitazioni che li accompagnano.

Oracle è convinta che il cloud ricopra un ruolo chiave per l’adozione ottimale di un ambiente a microservizi e in tal senso fornisce un cloud che integra tutti gli elementi utili a raggiungere al meglio questo obiettivo. Crediamo nell’intelligenza artificiale, nell’automazione per permettere ai team DevOps di concentrarsi esclusivamente sulle attività a valore aggiunto. Una visione, questa, che si concretizza nel nostro Autonomous Database, il database di Oracle in grado di gestirsi completamente in modo autonomo in termini di self patching, self secure e self scaling, automatizzando quindi anche la parte di ottimizzazione e sicurezza. Una soluzione di valore che consente agli sviluppatori di dedicarsi unicamente alla parte di sviluppo, demandando la componente di operation e dando la possibilità, in un’ottica di poliglottismo, di scegliere il linguaggio e le tecnologie più idonee per ogni tipologia di necessità e microservizio.

Un approccio utile a cogliere appieno i vantaggi che un ambiente a microservizi garantisce e che dal mio punto di vista risiedono in primo luogo nella possibilità di sviluppare ed evolvere applicazioni in modo agevole, rinnovando anche quelle realizzate a layer. Per abbracciare pienamente queste opportunità, oltre agli aspetti tecnologici è necessario per i team interni rafforzare le proprie competenze e superare le barriere culturali ancora presenti in molte aziende. Si tratta di freni figli di un passato caratterizzato da un modello di sviluppo in cui gli aspetti di operation, development, engineering, architecture e security vivevano in silos separati. Oggi diventa necessario organizzare gruppi verticali capaci di approcciare tutti questi temi ed essere in grado di ridisegnare le applicazioni distribuendo il controllo, prima centralizzato, ai diversi team. Un aspetto centrale anche per Oracle che con la propria Oracle University è in grado di fornire tutte le certificazioni specifiche in questo campo e indirizzare le giuste competenze per consentire alle aziende di cogliere le opportunità e i benefici che le architetture a microservizi garantiscono.

Filippo Crea, sales specialist di Red Hat

Un’applicazione composta da un insieme di servizi indipendenti tra loro, disaccoppiati e atomici, organizzati per implementare una funzionalità di business.

Può essere descritta così l’architettura a microservizi: un’evoluzione della Service Oriented Architecture (SOA) di cui ne eredita molti dei principi fondanti. Per capire meglio le caratteristiche distintive tra le architetture monolite e la SOA, occorre però ricordare un passaggio importante dell’evoluzione architetturale delle applicazioni. Mi riferisco alle al multi-layer. Nelle architetture multi-layer l’applicazione prevedeva la scomposizione del monolite in tre layer principali: il primo dedicato ai dati, il secondo alle logiche applicative e il terzo alla presentazione dei servizi. La SOA è l’evoluzione di questo modello suddividendo le logiche all’interno del back end e del front end in più servizi. Un approccio, questo, che ha consentito uno sviluppo applicativo più agile, perché distribuito, dando la possibilità di riciclare la singola funzionalità che era stata implementata per un’applicazione e renderla utilizzabile anche in altri contesti, rendendo lo sviluppo del software più efficiente.

L’architettura a Microservizi è l’ultimo anello della catena evolutiva delle architetture applicative ed ovviamente si porta dietro una serie di concetti già presenti nella SOA, cercando però di indirizzarne e superarne le debolezze.

Tra i punti che accomunano i due modelli vi è sicuramente la definizione di interfacce standard per comunicare con i servizi, la possibilità di implementare il software con tecnologie differenti tra loro e l’opportunità di eseguirlo su piattaforme eterogenee e distribuite.

L’architettura a microservizi non si è dimenticata di questi concetti, anzi: li ha fatti evolvere e in alcuni casi li ha rafforzati, differenziandosi però dalla SOA sotto diversi punti di vista. Primo fra tutti, la gestione del dato. Uno dei principi cardine dell’architettura a microservizi è che ogni servizio deve essere gestore esclusivo e proprietario del dato. Un elemento fondamentale, questo, in quanto consente una maggiore scalabilità ai processi applicativi. Altro elemento fondamentale è la gestione da parte di un servizio di un singolo dominio di business, per favorire una maggiore autoconsistenza delle funzionalità di business implementate.

Con i microservizi si modifica anche il modello di comunicazione e il coordinamento del flusso delle informazioni, che come sappiamo nella SOA avveniva attraverso il classico Enterprise Service Bus. I singoli Microservices vengono generalmente innescati in maniera asincrona da un evento come una chiamata ad una API o attraverso l’inserimento di un dato in coda. Con questo approccio, non esiste un vero e proprio modello di orchestrazione dal momento che ogni microservizio non deve essere a conoscenza dell’esistenza degli altri microservizi con i quali può interagire.

Un cambio di approccio importante che rende il singolo microservizio indipendente dagli altri consentendo di scalare più facilmente e di eliminare il singolo ‘point of failure’.

L’approccio a microservizi porta numerosi vantaggi, ma per disegnare, implementare e gestire al meglio applicazioni che seguono questi principi, è necessario per i team di sviluppo, operations e anche al business di acquisire nuove competenze tecnologiche e culturali.

Un tema centrale per Red Hat che in questo ambito è attiva con due proposte mirate: DevOps Culture and Practice, training che combina gli aspetti culturali di approccio nello sviluppo delle applicazioni calandoli in un contesto tecnico, e l’Open Innovation Labs, che opera con l’obiettivo di accelerare il processo di trasformazione del cliente attraverso un’esperienza immersiva delle nuove tecnologie e modelli di sviluppo per creare valore di business.

Alessio Di Benedetto, senior presales manager South EMEA di Veeam

I microservizi rappresentano un nuovo modello, non solo per lo sviluppo, ma anche per l’organizzazione dell’architettura software: una composizione di piccoli servizi indipendenti con dei compiti ben specifici ma comunque interconnessi tramite interfacce standard.

Due gli elementi che maggiormente caratterizzano queste architetture. Il primo è l’autonomia: ogni microservizio può essere sviluppato in maniera indipendente, senza produrre effetti sul funzionamento degli altri componenti, in quanto l’unico punto di contatto sono le interfacce. Il secondo, invece, è la specializzazione: un microservizio è specializzato in quanto viene progettato per svolgere un ruolo ben specifico.

La differenza con un approccio di tipo monolitico, in questo senso, è abbastanza evidente. Nelle architetture monolitiche tutti i processi venivano gestiti come un grande unico singolo servizio e nel momento in cui risultava necessario fornire più risorse a un processo, l’intera architettura doveva scalare ed essere ridimensionata.

La transizione al modello Soa aveva già introdotto un concetto di modularità grazie all’evoluzione tecnologica del networking e dell’architettura distribuita. I microservizi rappresentano un’evoluzione ulteriore di un servizio di questo tipo dove la specializzazione e l’autonomia vengono sviluppate maggiormente. Il tutto, passando a un approccio ‘agile’, di continuous integration e continuous deployment, differente dall’approccio ‘waterfall’ caratterizzato da grandi rilasci, grande fatica e grossi rischi.

Il modello più idoneo per lo sviluppo dei microservizi è sicuramente quello del cloud e dei container. I container permettono di eseguire le applicazioni in modo indipendente, riutilizzando anche lo stesso hardware. A differenza delle macchine virtuali che emulano il funzionamento di una macchina fisica, ma che condividono l’host grazie all’hypervisor, i container compiono un passo in più: emulano il sistema operativo all’interno di una macchina condivisa.

In questo scenario, Veeam può supportare le aziende fornendo accesso, gestione dei dati e monitoraggio delle infrastrutture. Quando parliamo di novità tecnologiche, soprattutto a livello infrastrutturale, la direzione è quella del cloud, dell’iperconvergenza, dell’object storage. In questo scenario la nostra società ha stretto già da tempo una serie di partnership strategiche con i maggiori player, cloud provider, hardware vendor, ma anche con diversi fornitori di hypervisor al fine di consentire la piena compatibilità con tutte le infrastrutture.

Veeam, nello specifico, si propone di supportare questi modelli di servizi con soluzioni di copy data management: con i microservizi ciascun team lavora in modo indipendente, però è fondamentale verificare la correttezza delle interfacce ed effettuare dei test di integrazioni in quanto ogni squadra deve comunque accedere ai dati delle altre componenti.

Le nostre soluzioni permettono di gestire e ridurre per quanto possibile la duplicazione di dati che non sono necessari, di diminuire le risorse storage e di rete. Una sorta di data virtualization, quindi, in cui si possono sfruttare tecnologie hardware ma anche software. Veeam propone questo approccio tramite soluzioni che partono direttamente dai dati del backup o dagli snapshot degli storage grazie a DataLabs, tecnologia che elimina l’impatto sui sistemi di produzione assicurando il pieno accesso ai dati.

Carlo Viganò, presales manager di Veritas

L’evoluzione del modello a microservizi è stata dettata dalle aziende per ragioni di business, di agility, di time to market: dall’essere pronti a far fronte ai cambiamenti tecnologici e di approccio ma anche, da un punto di vista di riduzione dei costi, dal limitare ulteriormente i lock-in che nella storia dell’informatica si sono via via presentati. L’architettura a microservizi è una risposta a queste domande di mercato e pone i vendor davanti a un’importante sfida di riduzione della complessità, migliorando la flessibilità e l’efficacia nella produzione/gestione del software. Questo modello assume una posizione centrale anche per Veritas, software vendor operativo da oltre 30 anni in vari ambiti della gestione dei dati.

Il nostro obiettivo è offrire una governance dei dati a 360 gradi, garantendo disponibilità, protezione, sicurezza e compliance, e in questo scenario operiamo ponendoci nella logica operativa dei nostri clienti che devono adottare a loro volta questi nuovi modelli di sviluppo.

Questo impegno comporta un cambio di approccio, di metodologia dei processi di costruzione del software e l’adozione all’interno di tutte le nostre soluzioni di alcuni concetti basilari: l’esigenza di definire, adottare degli standard, di creare una modularità in cui sia facile riadattare la costruzione delle nostre soluzioni e di farle evolvere su nuove basi e infine quella di adottare massivamente il machine learning per aumentare le velocità di deployment a fronte di cambiamenti di scenari/modelli e regulation, attraverso l’astrazione e l’adattibilità dei software.

Rispetto al mercato, questi scenari chiamano in campo l’attuazione di cooperazioni e partnership in dinamiche consortili, di co-development con altri players, al fine di massimizzare l’integrazione, la standardizzazione, e raggiungere così l’obiettivo di fornire una customer experience che sia la più semplice ed efficace possibile per i clienti. È nostra missione e onere addossarci la semplificazione e l’astrazione dei layer di complessità che sottendono le nuove infrastrutture IT ibride; in Veritas questo approccio ha portato a una ridefinizione delle strategie di prodotto secondo tre pillars fondamentali di soluzioni: Availability, Protection, Insight.

Il primo è l’Availability, che riprende il concetto storico di inizio anni ’90 del Client/Server e del Cluster, ed evolve verso una Business Continuance a microservizi fruibili in modelli XaaS, su infrastrutture IT di tipo Hybrid: non bisogna dimenticare infatti che molte aziende a livello enterprise dispongono ancora di realtà fisiche importanti e di applicazioni che non sono nate e non potranno essere migrate così facilmente e velocemente in container e/o cloud. Anche tutte queste realtà pregresse debbono essere migrate, messe in alta disponibilità e mantenute, in scenari IT radicalmente diversi attraverso la Cloud Adoption.

L’altro pillar strategico di Veritas è la Protection; significa proporre al mercato soluzioni massimamente modulari, scalabili, flessibili, in grado di abbracciare tutto quello che è il panorama storico immutabile dell’azienda, ma anche all’avanguardia per applicazioni e ambienti che nascono e devono gestire dati in modalità nuove: no-SQL, Container, e ‘Scale Out’ più in generale; diviene cosi fondamentale disporre di soluzioni di data protection che spazino fra N generazioni applicative ed infrastrutturali, astraendo complessità e novità di modelli di adozione, sostenendo gli SLA di business, e mantenendo sempre protetto anche il pregresso storico ancora presente nei nostri clienti con un’unica soluzione semplice e intuitiva.

Il terzo pillar, infine, è il Data Insight sia su tutti gli asset infrastrutturali locali o in cloud, sia sulle informazioni aziendali vere e proprie legate agli SLA di servizio o alle necessità di compliance, ovunque esse siano. Tutto questo con il fine preciso di migliorare l’efficienza dei processi IT e di business, monitorando e controllando le dinamiche di costo. Quando si opera per segmentare e ridurre la complessità e migliorare il rapporto costi/benefici delle infrastrutture è necessario essere in grado di produrre report analitici predittivi per analisi di crescita e/o per valutazioni di adozione nuovi modelli IT (what-if: Hybrid Cloud vs full Public Cloud vs On Prem) oppure per tutte le temaniche di compliance e audit interni o esterni, con granularità di dettaglio su tutto quello che è il ciclo di vita dell’informazione, dell’applicazione e degli utenti che ne hanno avuto accesso e fatto uso.

Nicola Buonanno, senior regional director Italy & Iberia for Tanzu, VMware

La divisione Tanzu di VMware si occupa della modernizzazione del portfolio applicativo delle aziende enterprise e ha come mandato quello di catalizzare la trasformazione digitale dei propri clienti attraverso il software.

La nostra società è stata protagonista negli anni della modernizzazione applicativa, del DevOps, dell’agile e dello sviluppo a microservizi. In questo ambito, l’esperienza ci dice che il modello monolitico aveva una sua logica che in alcuni casi oggi mal si sposa con quelle che sono le opportunità, le esigenze e le nuove tecnologie a causa di problematiche di scalabilità e di flessibilità.

La SOA introduceva sicuramente alcuni elementi moderni di riuso, di disaccoppiamento, di aumento della granularità: la possibilità di disporre di servizi capaci di utilizzare linguaggi diversi e di integrare ambienti differenti. Elementi sicuramente importanti che però vedono pienamente luce in quella che è l’architettura a microservizi, dove la granularità viene esasperata, in cui i vari servizi diventano appunto micro e si comincia ad approcciare uno sviluppo realmente moderno. Con i microservizi, le logiche di deployment sono assolutamente differenti e si ha l’opportunità di dare maggiore concretezza ai concetti di continuous integration, continuous delivery, DevOps e di utilizzare appieno logiche ‘agile’.

I vantaggi di un’architettura di questo tipo sono sotto gli occhi di tutti, in termini di velocità, di time to market, di resilienza, di rapidità nella fruizione dei servizi. A questi benefici si aggiunge la possibilità di migliorare ogni giorno le funzionalità e di cogliere le opportunità delle nuove tecnologie e i nuovi trend di mercato.

Un esempio tradizionale di un modello di questo tipo sono i siti di e-commerce, in cui ogni singolo elemento è un microservizio e in cui non sono infrequenti rilasci di migliorie che colgono anche le nuove evoluzioni tecnologiche per offrire un servizio ottimale e più aderente alle necessità delle aziende. Il tutto, senza ritoccare l’applicazione nella sua interezza e creare disservizi.

Un vantaggio e una velocità che viene portata verso i clienti, ma che ha dei costi in termini di complessità. In questo senso, nasce l’esigenza per le aziende di cambiare anche dal punto di vista organizzativo e culturale utilizzando tecnologie, strumenti e metodologie che possano supportare questi nuovi approcci.

Un aspetto chiave per VMware Tanzu, che in tale ambito pone un forte accento sull’automation e sull’utilizzo di framework utili a facilitare la vita degli sviluppatori. Questa visione si concretizza in Spring di cui siamo steward della community open source, il primo framework al mondo per lo sviluppo di microservizi in Java che consente di facilitare la vita dello sviluppatore, fornendo una serie di ‘mattoncini’ e percorsi utili a standardizzare e velocizzare il processo di sviluppo. Un framework fondamentale per rispondere alle esigenze tipiche dei microservizi per i quali è essenziale disporre di ambienti e piattaforme di automation dedicate alla componente di sviluppo, deployment e runtime che vadano nell’ottica della continuous integration, continuous delivery e del DevOps. Un impegno che in VMware trova riscontro anche in Tanzu Kubernetes Grid (VMware è il secondo contributore nella community Kubernetes), in Tanzu Application Service e nella collaborazione come principale contributore della Cloud Foundry Open Source Community.

Il nostro obiettivo è eliminare la complessità insita e intrinseca dell’architettura a microservizi che richiede un approccio, non solo tecnologico, ma anche e soprattutto metodologico. Lo sa bene VMware che con i propri Pivotal Labs da anni affianca i clienti per consentire loro di cogliere appieno le opportunità e i vantaggi di queste evoluzioni.