Il LOCK-IN NEI SERVIZI CLOUD

Introduzione

olti utenti sanno gi dalla propria esperienza personale che cambiare da un service provider ad un altro pu rivelarsi un'operazione difficile.

D'altronde Un service provider non di certo incline a fornire un processo semplice di invio clienti ai propri concorrenti. Ci che i clienti per spesso non capiscono che molte aziende possono arrivare a costruire dei blocchi all'uscita da un servizio o una piattaforma con l'intento di bloccare all'interno della propria offerta i clienti. Per questo motivo poi il processo di transizione pu diventare difficile se non impossibile. Questo succede nel cloud computing come in ogni altro settore informatico, i service provider cloud a volte rendono la transizione verso l'esterno della loro piattaforma pi difficile di quanto non potrebbe essere. Un modo con cui fanno questo attraverso i controlli di sicurezza. L'obiettivo dei controlli di sicurezza quello di limitare l'accesso ai dati: questo fatto rende pi semplice per un service provider invocare i requisiti di sicurezza come scusa per il fatto che non sono in grado di fornire parti di dati fondamentali per permettere una transizione tranquilla. E' importante quindi porre qualche domanda riguardo a come i controlli di sicurezza sono progettati in modo che possiate prevenire il lock-in nel cloud. Ecco alcune domande di cui tener conto e qualche strategia per mantenere i servizi che comprate (e i vostri dati) svincolati e platform-agnostic.

La propriet e la gestione dei dati

Chi possiede i vostri dati. Un argomento importante riguarda il possesso dei dati che inviate ai service provider. A meno che non abbiate stabilito da contratto che il possesso dei dati specificamente vostro, la risposta su chi li possiede potrebbe essere meno chiara di quanto si pensi. Un buon service provider riconosce che i dati sono vostri senza bisogno che questo sia richiesto esplicitamente dal cliente, ma non tutti lo fanno. E' quindi buona norma stabilire da contratto che la propriet dei dati rimane vostra per tutta la durata del rapporto.

Il service provider restituir a voi i dati? Supponendo che possediate la propriet dei dati, la domanda ora come ed in quale formato il vostro service provider vi render indietro questi dati. Uno dei problemi che pu verificarsi che i dati vi siano restituiti in un formato non semplice da usare. Specificate quindi nel contratto il formato in cui volete che i dati vi vengano restituiti. Eseguite il testing per verificare che il provider possa realmente soddisfare le vostre richieste. Potete accedere ai dati? Accertatevi del fatto che qualsiasi controllo di sicurezza applicato ai dati - come ad esempio la crittografia non vi impedisca di effettuare l'accesso logico ai dati anche quando ne avete la propriet fisica. Per esempio, se i dati sono criptati avete accesso alle chiavi per decriptarli? Anche in questo caso necessario testare i processi per essere sicuri di poter accedere senza problemi ai dati. Fate attenzione alle strutture di database che potrebbero avere crittografia di colonna applicata ad elementi particolari, in quanto questi potrebbero non essere immediatamente visibili in un'esportazione e potrebbero richiedere intervento da parte del service provider per fornire le chiavi se la crittografia svolta al livello applicazione. Come si effettua l'accesso alle risorse. In caso di IaaS (Infrastructure-asa-Service), quando i dati in questione includono immagini virtuali, siate sicuri di avere la possibilit di accedere al livello amministrativo sia alle applicazioni che all'OS sottostante. Non sempre banale guadagnare l'accesso quando non sappiamo la password amministrativa, anche quando abbiamo accesso fisico. Quindi se il vostro provider vi restituisce le immagini VM assicuratevi che possiate ottenere l'accesso ai livelli OS e applicazione dei servizi eseguiti. L'accesso ai dati utente. Potreste avere bisogno di ulteriori informazioni oltre ai dati perch i vostri servizi continuino senza interruzioni. Per esempio, se il vostro provider sfrutta un datastore che contiene informazioni sugli utenti (il loro ID, informazioni di autenticazione), anche voi necessiterete di queste informazioni. Assicuratevi di poter riavere indietro i dati oltre alle informazioni utente, in quanto questi dati potrebbero essere archiviati in un posto separato rispetto ai dati applicazione. Testare i processi che supportano una transizione tranquilla una strategia solida per evitare il lock-in del cloud provider, che

sempre dietro l'angolo.

Scelta del modello di servizio

In base al tipo di servizio cloud di cui avrete bisogno, cambieranno anche i rischi di lock-in. A seconda che scegliate Software-as-a-Service, Platform-as-a-Service o Infrastructure-as-a-Service cambia anche la dipendenza dell'azienda dal servizio cloud scelto. Ovviamente dipende anche dalla bont del fornitore, ma certamente meno rischioso usare un servizio IaaS che usare un servizio PaaS o SaaS, in cui il rischio di lock-in sensibilmente superiore. In un servizio IaaS abbiamo una maggiore flessibilit ed un controllo delle risorse, mentre gi i servizi PaaS rischiano di chiudere le vostre applicazioni all'interno della loro piattaforma. Le applicazioni progettate per un particolare fornitore PaaS non sono trasportabili senza cambiamenti radicali su altre aziende PaaS. Chiudendovi in un particolare servizio PaaS, siete in grado di personalizzare la vostra applicazione e trarre vantaggio da funzionalit specifiche di quella piattaforma, ma d'altro canto se un giorno non siete pi soddisfatti di quella soluzione dovrete pur andarvene, e questa operazione rischia di diventare costosissima. Mantenendo la vostra applicazione agnostica nei confronti di qualsiasi tecnologia specifica di piattaforma, pur facendo pi fatica nel deployment mantenere la flessibilit necessaria per sopravvivere ad un forte cambiamento nel business dell'azienda o nelle politiche dei fornitori. Un fornitore IaaS quale Amazon vi d l'opportunit di tornare indietro rispetto alla migrazione cloud a qualsiasi stage e permette una maggiore portabilit tra i provider. Lock-in di servizio. Per far comprendere come il blocco in un ambiente costituito da un servizio remoto possa provocare grossi problemi prendiamo l'esempio di un servizio comunemente usato da molti utenti, ovvero Gmail. Fin dall'uscita di Gmail l'unica specifica del servizio che gli utenti non possono cambiare il proprio indirizzo email, che deve sempre rimanere uguale, cosa normale perch se un utente vuole davvero cambiare il proprio indirizzo email pu sempre registrarne un nuovo e trasferire le proprie mail usando mail client ed IMAP. Un attuale indirizzo Gmail per viene utilizzato per molte altre

funzioni, oltre al semplice invio ed archiviazione di email, fornendo infatti accesso all'account Google di un utente che usato da Google Reader, Docs, Google Plus, YouTube e Picasa. Poich Google non fornisce un modo per cambiare l'indirizzo mail associato con un account Google, se un utente crea un nuovo indirizzo Gmail per cambiare il nome dell'indirizzo deve creare anche un nuovo account Google. Se invece si vuole cambiare mail provider sar possibile esportare le email, ma per via di tutto l'ambiente di servizio nato attorno all'account di Gmail, chiudere la mail vorrebbe dire dover rinunciare a tutti i servizi ad essa associati. Inoltre cambiando mail provider non possibile esportare insieme alle mail features quali ad esempio le etichette di Gmail. Lock-in di piattaforma. Prendiamo l'esempio di una PaaS quale Google App Engine. Google App Engine per Java non permette luso di tutte le API disponibili in Java, specialmente se queste richiedono laccesso al file system. Il fatto che ci sia tale restrizione imposta da Google ci obbliga a guardare da qualche altra parte per alcuni dei nostri progetti, e se vogliamo integrarli con GAE dobbiamo cambiare drasticamente l'architettura delle nostre applicazioni. Il costo di risviluppo delle nostre applicazioni molto pi alto che quello di distribuirle da qualche altra parte. Un altro lato negativo di Google App Engine che non supporta le specifiche servlet JEE. Non possiamo implementare una sicurezza personalizzata per le nostre applicazioni attraverso il nostro file web.xml, e siamo costretti ad usare il meccanismo di sicurezza di Google. E se un giorno volessimo trasferire la nostra applicazione sviluppate per GAE su un'altra piattaforma? Il prodotto PaaS di Salesforce Force.com un altro esempio lampante di lock-in di piattaforma. Force.com consente agli sviluppatori esterni di creare applicazioni che si integrino alle principali applicazioni dell'ambiente SaaS di Salesforce, distribuite nell'infrastruttura cloud della compagnia. Queste applicazioni devono essere costruite usando Apex, un linguaggio proprietario simile a Java, e Visualforce, una sintassi simile a XML per progettare le interfacce utente in HTML. Un'applicazione sviluppata in un linguaggio proprietario come Apex non pu funzionare al di fuori dell'ambiente di Salesforce, quindi se vogliamo cambiare fornitore PaaS la perderemo

totalmente.

Il rischio di lock-in al momento reso pi sensibile dal fatto che il cloud computing una tecnologia relativamente nuova che soffre ancora di una bassa standardizzazione, anche se sono molte le organizzazioni che si sono messe in moto per colmare questa lacuna. A fine agosto del 2012 ad esempio un consorzio composto da 7 organizzazioni, tra cui Oracle e Red Hat, si riunito allo scopo di produrre uno standard industriale che dovrebbe rendere semplice per gli utenti gestire applicazioni distribuite in ambienti PaaS. Denominato Cloud Application Management for Platforms (CAMP), il documento che conterr tali specifiche definir API generiche per costruire, eseguire, amministrare, monitorare applicazioni cloud. Finora i fornitori PaaS hanno tutti fornito le loro personali interfacce per queste funzioni di gestione, rendendo difficile per i clienti spostare le applicazioni cloud esistenti verso nuove piattaforme che potrebbero offrire interfacce di gestione completamente diverse di quelle attualmente in uso. Il gruppo arrivato a completare una prima bozza delle specifiche CAMP, ha formato il comitato tecnico per continuare a lavorare sotto gli auspici dellorganizzazione occupata negli standard OASIS, con lobiettivo di definire le interfacce per i servizi di piattaforma presenti nel mercato e pi diffusi entro i prossimi 18 mesi. Si presume quindi che gli scenari legati al rischio di lock-in tecnologico possano cambiare repentinamente nel momento in cui ci sar uno standard aperto accettato dalla maggioranza dei grandi fornitori di servizi cloud.

L'errore strategico di dipendere da un unico fornitore

Molte volte i provider cloud ed anche le organizzazioni private configurano il loro cloud sulla base di Amazon Web Services. Nonostante questo servizio leader abbia i suoi innegabili vantaggi diventare cos dipendenti da un unico fornitore un grave errore in un settore in cui oltretutto le previsioni di crescita sono alle stelle. Il blocco nel cloud ha due volti, il primo riguarda la portabilit dei dati, mentre il secondo lo stack dell'ambiente applicativo. Sul

primo punto ci siamo soffermati nel primo capitolo, il secondo scenario chiarito nel seguente esempio. Sottoscriviamo un servizio cloud consistente in un'applicazione CRM e vogliamo svolgere operazioni quali il social monitoring o automatizzare i processi di marketing. Questo ci porta a due scelte, o acquistare gli strumenti del nostro fornitore CRM per il contesto social o per il marketing, oppure decidere di spendere tempo e soldi per scrivere un'integrazione personalizzata con un altro fornitore a mia scelta, cosa che pu essere complessa da realizzare, considerando la variabilit di API e l'accesso ai dati tra diversi fornitori. In questo contesto si forzati a scegliere tra le offerte del nostro fornitore di CRM e magari un fornitore di funzionalit per il marketing migliore. Per questi motivi la migliore opzione quella di dirigersi verso standard aperti e verso la portabilit, o adottare una soluzione cloud open source tra quelle pi diffuse e sviluppate, di cui il progetto OpenStack costituisce l'esempio pi celebre.

Cloudup un servizio IaaS di cloud server on demand, a consumo, completamente scalabile, pay per use. Consente di creare, modificare e cancellare server cloud, Linux o Windows, in pochi minuti. Propone una versione trial gratuita per 7 giorni e offerte a partire13,73 Euro. Cloudup tutto italiano. un servizio di Enter s.r.l., Internet Service Provider dal 1996, insediata da tempo con il proprio data center al Campus Tecnologico di Milano Caldera.