Molti 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.

1. Il LOCK-IN NEI SERVIZI CLOUD

2. Introduzione
M 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.

3. 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-as-
a-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 è

4. 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

5. 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 l’uso di tutte le API
disponibili in Java, specialmente se queste richiedono l’accesso 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

6. 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 dell’organizzazione occupata
negli standard OASIS, con l’obiettivo 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

7. 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.