Sono sempre più numerose le aziende che decidono di abbracciare la filosofia dei sistemi IT “nella nuvola”. Se è vero che questo approccio porta con sé indubbi vantaggi, esistono alcuni rischi da valutare attentamente in fase di definizione del contratto, per non incorrere in futuro in brutte sorprese…
Una questione fondamentale spesso sottovalutata è quella relativa alla “paternità” dei dati. I responsabili IT devono garantire che il contratto tra la loro organizzazione e il provider di servizi cloud sia tale che l’organizzazione sia sempre considerata l’istituto proprietario dichiarato dei dati.
Questo lascia, però, aperto il problema di capire cosa accade, poi, una volta esauritisi i tempi fisiologici del contratto, di questi record. In definitiva, la risposta corretta è “dipende”. Occorre, infatti, comprendere anzitutto qual è l’applicazione che ha creato i dati.
Ecco perché bisogna sempre chiedersi se sarà possibile accedere alla stessa applicazione anche se cambia il service provider di servizi cloud di riferimento. Se l’accordo esistente era di tipo infrastruttura come servizio (IAAS) o piattaforma come servizio (PAAS), allora la vostra organizzazione detiene la proprietà delle applicazioni in ogni caso e sarà, quindi, possibile reinstallarle con relativa facilità su una piattaforma cloud diversa senza sperimentare grossi problemi.
La difficoltà di spostare i dati nel cloud
Nel caso del software come servizio (SAAS), tuttavia, ci potrebbero essere problemi più grandi. Se il servizio offerto si basa su un’applicazione standard (per esempio, SugarCRM o OpenERP) dovrebbe essere possibile trovare un altro fornitore di servizi in grado di ospitare la stessa applicazione. Ci potranno essere differenze nell’implementazione, ma tutto ciò che dovrebbe essere richiesto sarebbe l’utilizzo di un software ETL (estrazione, trasformazione e caricamento) per assicurarsi che i dati si adattino allo schema di implementazione utilizzato dal nuovo prestatore di servizi.
I responsabili IT devono sempre ricordare che le modifiche autorizzate da parte del fornitore precedente (ad esempio l’applicazione di un logo o l’aggiunta di tutte le funzioni extra) dovrà essere, inevitabilmente, ripetuta con il nuovo provider. In molti casi, non sarà possibile migrare al nuovo provider una qualsiasi delle modifiche attuate dal precedente fornitore e la loro ri-attuazione sarà la parte più difficile della transizione. Questo che cosa ci insegna? Che tutte le modifiche apportate in un ambiente SAAS devono sempre essere documentate e conservate anche al di fuori dell’ambiente SAAS: un registro completo delle modifiche è necessario per far sì che i cambiamenti possano essere ri-attuati nel caso in cui la decisione di cambiare il fornitore di servizi lo renda necessario.
I veri problemi, però, arrivano solitamente nel momento in cui un’azienda decide di abbandonare un provider che non utilizza software standard ma proprietario. In questi casi, il fornitore potrebbe aver apportato tali e tante modifiche a un’applicazione open source da creare, di fatto, una nuova applicazione. Oppure, potrebbe trattarsi di un fornitore SAAS con un’applicazione proprietaria che non permette a nessun altro provider cloud di offrirla come servizio tramite la propria piattaforma, come accade per Salesforce.com.
E se è improbabile che Salesforce.com finisca “gambe all’aria”, alcuni piccoli operatori dedicati che operano come provider di servizi SAAS potrebbero, invece, fallire. Quocirca raccomanda che la scelta originale del provider SAAS prenda in considerazione tale rischio. Se non è stato già adottato il software come servizio, allora sì che il rischio del fallimento del provider deve essere attentamente valutato, in parallelo allo sforzo che sarebbe necessario per prelevare i dati dal sistema del fornitore in una forma che possa essere utilizzata da un altro provider in un periodo di tempo che possa definirsi “breve”.
Pianificare il recupero dei dati nell’ipotesi SAAS
Le imprese che hanno già fatto il passaggio a un provider SAAS dovrebbero essere certe di avere un “piano B” utile per raggiungere un certo Recovery Point Objective (RPO) e un certo RTO (Recovery Time Objective) prefissati.
La prima cosa che serve, in questi casi, è individuare in dettaglio come sarà l’applicazione di destinazione. Quocirca suggerisce dovrebbe trattarsi di un programma ampiamente adottato tra i fornitori di servizi SAAS, oppure l’applicazione proprietaria di un fornitore dalla solidità finanziaria appurata.
In seguito occorrerà individuare gli schemi utilizzati da entrambi i sistemi. Le corrispondenze a livello di tipologia e nomi dei campi è necessaria per assicurarsi che la fedeltà delle informazioni venga mantenuta anche dopo lo spostamento dei dati da un provider a un altro. Questo definirà, inoltre, la portata delle attività ETL che dovranno essere effettuate.
A seguire, occorrerà testare il tutto. Nulla può essere lasciato al caso; sarà necessario effettuare una prova prendendo i dati dall’ambiente esistente e spostandoli al nuovo ambiente. Sulla base della probabilità di avere successo, sarà possibile creare un piano formale completo per stabilire ciò che la vostra organizzazione ha bisogno di fare qualora si verificasse un evento catastrofico.
Questo dovrebbe includere anche le indicazioni in merito a quanto tempo queste attività dovrebbero durate – ivi compresa la definizione dei piani che indichino come l’azienda continuerà a funzionare durante questo tempo di inattività. Questo potrebbe richiedere numerosi processi manuali e tutti i dati raccolti attraverso questi processi manuali dovranno essere inseriti nel nuovo sistema nel momento in cui questo sarà attivo.
L’ultima area da regolamentare a livello contrattuale è quella che riguarda il modo in cui il vecchio fornitore di servizi dovrà cancellare i dati dell’organizzazione dai propri sistemi informativi, cosa questa che viene molto spesso trascurata.
La maturità del cloud
Speriamo che, col passare del tempo, gli standard del cloud divengano sempre più la norma e non l’eccezione. Solo in questo caso, infatti, sarà possibile spostare applicazioni e dati su piattaforme cloud uniformi, come OpenStack, in modo semplice e lineare, senza grossi intoppi.
Gli analisti preconizzano anche l’arrivo sul mercato di nuovi sistemi commerciali in grado di rendere la vita più facile a chi si prepara ad affrontare un’eventualità di questo tipo. Ad esempio, Double-Take Move di Vision Solutions può essere utilizzato per la migrazione dei dati da un provider cloud a un altro, anche nel caso in cui il provider di origine si rifiuti di collaborare. Quocirca stima che altri servizi simili si affacceranno a breve sul mercato, tuttavia per molte organizzazioni un solido piano per affrontare una migrazione da zero sarà comunque necessario.
