I Quaderni del Cloud : Interoperabilità 6+1

Il concetto di interoperabilità ha significati diversi a seconda di quale area del cloud ci si stia riferendo. Per questo motivo ho suddiviso quelle aree di interoperabilità che ritengo più importanti in ambito Cloud evidenziando 6 componenti più 1 (poi sarà più chiaro perchè ci tengo a questa distinzione 6+1 e non 7).

 

Queste le 6 aree principali :

• Interoperabilità di piattaforma per la Governance, Maintenance e Configuration presente in tutti i layer del Cloud (IaaS,PaaS e SaaS),
• l’interoperabilità nei servizi di Identity & Access Management, I servizi applicativi di interoperabilità ,
• l’ interoperabilità nell’ accesso ai dati ed infine
• l’interoperabilità nello sviluppo del codice suddivisibile tra tools e framework.
• Il settimo elemento è l’interoperabilità tra piattaforme cloud diverse (Cloud-to-Cloud Interoperability) . Perchè l’ho tenuto separato dai 6 precedenti aspetti? Semplice, perchè ad oggi è un semplice desiderata! Ci sono vari comitati e gruppi di lavoro, ma per gli architetti IT e i progettisti di infrastrutture e applicazioni ad oggi non c’è nulla di tangibile (a differenza dei 6 precedenti aspetti)!!

Ma vediamo nel dettaglio questi punti:

Interoperabilità di Piattaforma

La piattaforma Cloud, indipendentemente dal livello (IaaS,PaaS o SaaS) deve esporsi verso il mondo esterno tramite API e standard (come ad esempio SOAP, REST, XML,…)

Questo è un aspetto strategico perchè il proprio sistema informativo on-premises deve poter integrarsi con quello Cloud senza alcun impedimento tecnologico. Inoltre questa caratteristica diventerà sempre più strategica perchè oggi il Cloud non ha nessun particolare standard dedicato ma al contrario utilizza quelli già consolidati del Web (HTML, XML, JSON, SOAP, REST, …)… garantendo una più sicura integrazione e riutilizzo delle esperienze e competenze!

 

Interoperabilità nell’ Identity & Access Management

Una delle prime cose che dovremmo fare quando progettiamo un servizio o un’ applicazione (in realtà spesso è l’ ultima delle cose che facciamo) è quella di definire i meccanismi di autenticazione, autorizzazione e identity flow. Oggi, il modello di riferimento è quello Claims-Based . Questo significa che le nostre applicazioni nel Cloud, per garantire un meccanismo di Single-Sign-On, devono potersi “fidare” di un IDP (Identity Provider) anch’esso ospitato nel cloud o on-premises ( tramite i meccanismi di Federation).   Questo comporta utilizzare meccanismi standard ed interoperabili per la gestione di tutti gli aspetti di autenticazione, autorizzazione ed identity Flow. Infatti, quando ad esempio abbiamo un Active Directory on-premises non vogliamo duplicare i nostri contatti sul Cloud al solo scopo di accedere a servizi esterni ma al contratio tramite gli aspetti di federazione (ADFS 2.0 – Active Directory Federation Services) possiamo scambiarci token in formati standard (Token SAML) indipendentemente dalla locazione geografica dei servizi e delle applicazioni. Se questa distribuzione è sul Cloud, ecco che abbiamo bisogno di un modello standard per la gestione delle identità che possibilmente sia conforme a quello on-premises!

 

 

Su Windows Azure, esiste un servizio dedicato all Access Control che guarda caso si chiama : Access Control e fa parte di quei servizi di infrastruttura applicativa che va sotto il nome di Windows Azure appFabric. L’Accesso Control nella sua prima versione per il Cloud sfrutta il protocollo OAuth Web Resource Authorization Protocol (OAuth WRAP) per supportare la claims-based security tramite REST senza imporre requirement lato client garantendo quindi il massimo dell’interoperabilità indipendentemente dalla tipologia di client!

 

Servizi applicativi di Interoperabilità

Una piattaforma Cloud che ambisca ad estendere un vero sistema informativo aziendale deve fornire anche servizi di interoperabilità applicativa per rendere quanto più semplice la connessione tra applicazioni e servizi on-premises e/o nel cloud. Questo significa applicazioni che ad esempio girano su un qualsiasi sistema operativo on-premises con dei servizi/applicazioni sul Cloud scritti con qualsiasi linguaggio! Se ci pensate bene, un sistema di questo tipo esiste già in molte realtà aziendali (ovviamente senza l’accezione del Cloud) e si chiama Enterprise Service Bus!
Come un ESB in azienda permette di integrare vari silos aziendali e si pone come backbone di comunicazione così un Internet Service Bus permette di integrare silos (aziende/realtà disgiunte geograficamente/filiali) semplicemente tramite Internet e i suoi standard!

 

In casa Microsoft il secondo componente del Windows Azure appFabric  è appunto il Service Bus. Il Service Bus permette di creare un meccanismo di connettività tra servizi ed applicazioni diversi permettendo vari communication patterns anche tramite i firewalls aziendali indipendentemente dalla topologia di rete e dagli aspetti di sicurezza (grazie all’Access Control). Inoltre il Service Bus dispone di un servizio di Registry che permette facilmente il discovery dei servizi indipendentemente dalla loro locazione geografica.
Risulta chiaro, credo, quanto un elemento di questo tipo sia fondametale in ambito interoperabilità perchè permette la comunicazione tra servizi ed applicazioni indipendentemente dallo stack applicativo utilizzato, dai linguaggi, dai protocolli di comunicazione e dalla locazione fisica!

 

Interoperabilità per l’accesso ai dati

Tutte le piattaforme e le applicazioni Cloud hanno un solo scopo : fornire dati agli utenti! In questo contesto è necessario il supporto agli standard più comuni per l’accesso ai dati da una qualsiasi tipologia di client. L’adozione di standard aperti significa consumare informazioni indipendentemente dai client e dalle modalità di utilizzo. L’ Open Data Protocol (oData) è oggi uno degli standard più importanti sviluppato per questi obiettivi !! Questo protocollo permette quindi di eliminare i silos applicativi ma soprattutto di eliminare la creazione di quel codice custom che viene scritto al solo scopo di permettere l’accesso in lettura e scrittura dei dati applicativi in modo standard…E’ necessaria una qualsiasi piattaforma che supporti HTTP e l’uso di librerie come .NET, Java, PHP, ATAX…

In casa Microsoft il protocollo oData è già disponibile sia on-premises che nel Cloud : SQL Server 2008 R2, SQL Azure, Windows Azure Storage, Excel 2010, SharePoint Server 2010, Open Government Data Initiative… Anche altri vendor stanno implementando tale protocollo : Websphere Extreme Scale (IBM), Db4objects (Versant), OpenAccess ORM (telerik), LINQpad,…

Per maggiori dettagli visitare : www.odata.org

 

Interoperabilità per i programmatori

Come nei sistemi operativi tradizionali (Windows, Linux, Mac OS, …) è possibile usare tools e tecnologie diverse per lo sviluppo del software, così i sistemi Cloud (come ad esempio Windows Azure - PaaS) devono permettere ai programmatori di usare i tools e i linguaggi che già conoscono.

Ad esempio Windows Azure permette a programmatori con skill completamente diversi di creare soluzioni per il cloud con i propri strumenti.

Ma cosa deve fare il programmatore?

Semplice, scaricare l’ SDK per il proprio linguaggio e tool per poter “estendere” il proprio ambiente di sviluppo con il Cloud!

 

Interoperabilità Cloud-to-Cloud

Infine eccoci al Cloud-to-Cloud ovvero l’ Interoperabilità a supporto della portabilità !

Cosa intendo per Cloud-to-Cloud? Una serie di API condivise tra tutti i fornitori di piattaforme cloud per spostare automaticamente risorse e dati da una piattaforma all’altra. In questo ambito, l’intero settore del Cloud è veramente agli albori anche se intravedo dei segnali molto positivi. Infatti a mio avviso tutto il lavoro che si sta facendo in ambito di interoperabilità dei dati e dei relativi formati può essere visto come un precursore del Cloud-to-Cloud. Solo il tempo però mi potrà dare ragione :-)

Sempre in casa nostra stiamo lavorando in vari comitati per la creazione di standard inter fornitori, ma il percorso è ancora lungo! Un esempio in questo contesto lo potete trovare qui :https://www.simplecloud.org/

 

 

A questo punto concluderei con una precisazione, ovvero che, come negli scenari on-premises, anche nel Cloud decidere come la propria applicazione sarà interoperabile con l’esterno resta a carico dell’architetto software e dello sviluppatore !!! Nessuna magia :-)

--Mario