La migrazione verso il cloud prevede un processo con varie fasi che permette quindi di partizionare le attività previste e di identificare i responsabili coinvolti. La definizione di un processo o di un framework a supporto di quest’attività consente non solo di identificare i possibili strumenti utili nelle varie fasi, ma di individuare anche gli skill necessari e richiesti alle società di consulenza che sono interpellate a supporto di queste attività.

Il processo

Il processo che verrà adesso presentato consiste di una serie di fasi, che potranno essere applicate tutte o meno, in base alle esigenze business e commerciali. Il processo illustrato nella figura 1 consta di 6 fasi che vanno dalla fase di Valutazione (assessment, valutazione dello stato dell’arte) alla fase di Ottimizzazione.

Figura 1 – Le 6 fasi del processo proposto per la migrazione alle soluzioni cloud: Cloud Assessment, Proof of Concept, Data Migration, Application Migration, Leverage the Cloud, Optimization.

Ma vediamo nello specifico ciascuna di queste fasi

Fase 1: Assessment sul cloud

La fase di Assessment è lo step iniziale che consente di valutare lo stato iniziale delle cose nelle varie aree di interesse, e sulla base di un’attenta valutazione, si può decidere la fattibilità o meno degli step successivi.

Questa fase prevede tra l’altro un assessment finanziario per il calcolo del TCO. Per TCO si intende il Total Cost of Ownership, in italiano costo totale di proprietà o costo totale di possesso, è un approccio sviluppato da Gartner nel 1987, utilizzato per calcolare tutti i costi del ciclo di vita di un’apparecchiatura informatica IT, per l’acquisto, l’installazione, la gestione, la manutenzione e il suo smantellamento.

L’analisi TCO deve quindi tener conto di:

• costi per l’acquisto dei componenti hardware o software (ricerca del fornitore sul mercato, costi di amministrazione per le ricerche di mercato, costi delle licenze software);
• costi per lo sviluppo di personalizzazione degli applicativi implementati dai dipendenti interni;
• costi operativi, legati all’aggiornamento e alla manutenzione e all’esercizio del software; questi costi denominati “costi operativi” comprendono: formazione di personale IT e di end-users, supporto degli end-users nei problemi riscontrati nell’utilizzo della tecnologia, gestione della sicurezza informatica, utilizzo di spazi per ospitare apparecchiature hardware (p.e. server, mainframe), consumi di energia, costi di connessione Internet, costi derivanti dal down-time del sistema per malfunzionamenti o errori degli end-users;
• costi legati alla dismissione del sistema (smantellamento delle apparecchiature hardware, eliminazione dei cavi portanti delle reti LAN).

L’approccio TCO è basato sulla considerazione che il costo totale di utilizzo di una apparecchiatura IT non dipende solo dai costi di acquisto, ma anche dai tutti i costi che intervengono durante l’intera vita di esercizio dello strumento.

I costi connessi alla stessa formulazione del TCO, che rientrano allo stesso modo nel TCO, sono abbastanza rilevanti, dunque tale metodo viene spesso utilizzato solo da grandi aziende, in cui l’IT rappresenta una variabile strategica rilevante.

Il TCO è un’analisi statica dei costi di esercizio di una apparecchiatura: esso quindi non tiene conto di eventuali ritorni dovuti all’investimento in innovazione, del risparmio operativo, delle nuove mansioni create; dunque il TCO monitorando solamente i costi non può essere usato in fase di analisi strategica degli investimenti.

• assessment sulla Sicurezza e la Compliance;
• assessment tecnico (per classificare i tipi di applicazione);
• identificazione dei tool riusabili e di quelli che è necessario procurarsi.

Assessment finanziario

Occorre fare un’accurata analisi per poter paragonare gli aspetti finanziari implicati nel possedere un centro dati con le rispettive facility, rispetto all’utilizzo di un’infrastruttura cloud.

Sono tante le caratteristiche da considerare perche’ il confronto tra le due alternative sia valido. È da notare come esistano già in letteratura delle pubblicazioni, come The Economics of the AWS cloud, che aiutano a mettere insieme le informazioni necessarie.

È importante precisare che l’analisi confronta solo i costi diretti dell’infrastruttura IT e non prende in considerazione i benefici economici indiretti del cloud, come per esempio la disponibilità, l’affidabilità, la scalabilità, la flessibilità, la riduzione del time-to-market, e tanti altri aspetti trasversali al cloud.

Assessment sulla Sicurezza e la Compliance

Se la propria organizzazione ha delle specifiche policy di sicurezza e dei requisiti di compliance, è raccomandabile coinvolgere i propri consulenti della sicurezza e gli auditor in questa fase specifica. Per definire lo stato dell’arte sugli aspetti di sicurezza, occorre porsi domande di questo tipo:

• Qual è la tolleranza totale ai rischi? Esistono delle classificazioni dei dati da esporre sulla base della loro sensibilità?
• Quali sono i principali rischi correlati all’affidabilità e all’integrità dei dati?
• Quali sono le regolamentazioni e gli obblighi contrattuali per poter salvare i dati in una specifica giurisdizione?
• Qual è il grado di interesse riguardo alla protezione della proprietà intellettuale delle proprie applicazioni?
• Quali sono le opzioni messe a diposizione nel momento in cui si decide di ritirare i propri dati dal cloud?

Sulla base delle riposte a domande come quelle sopra indicate, si potrà valutare lo stato della sicurezza attuale del sistema e della sensibilità dei dati che si intende migrare. La sicurezza dei dati può essere un problema scoraggiante se non inteso e analizzato in maniera opportuna. Per cui, è necessario comprendere bene i rischi sulla base della sensibilità dei propri dati e classificarli in diverse categorie. Ciò aiuterà a identificare quali set di dati è possibile e conveniente spostare nel cloud e quali invece è necessario mantenere in casa.

Assessment tecnico e funzionale

L’assessment tecnico è richiesto per capire quali applicazioni risultano più idonee al cloud dal punto di vista architetturale e strategico. Allo stesso tempo, l’enterprise determina quale applicazione muovere per prima nel cloud, quale dopo, e quali applicazioni mantenere in casa. In questa fase, occorre porsi queste domande:

• Quali applicazioni business occorre muovere per prime nel cloud? Quali invece dopo?
• Il cloud mette a disposizione tutti i layer infrastrutturali necessari?
• È possibile riusare le proprie risorse di gestione e i tool di configurazione già esistenti?

Creazione di un albero delle dipendenze

Per classificare le applicazioni candidate o meno al cloud si può partire prima di tutto dalle dipendenze esistenti tra le stesse, dai rischi e dai requisiti di sicurezza e di compliance. Un buon approccio potrebbe essere quello di identificare le applicazioni e le loro dipendenze con altri componenti e servizi; successivamente si potrebbe creare un albero che metta in evidenza tutte le varie parti delle applicazioni e le rispettive dipendenze di queste ultime con altre applicazioni, sia a valle che verso l’alto.

Un possibile diagramma potrebbe essere come quello illustrato in figura 2 in cui sono inclusi i sistemi ERP, i sistemi HR, i sistemi batch e di pagamento a backend, le applicazioni web rivolte ai clienti, le applicazioni IT aziendali, i sistemi CRM, etc., così come i servizi di basso livello come i server LDAP.

Figura 2 – Albero delle dipendenze.

Identificazione dei “candidati” per il cloud

Dopo aver creato l’albero delle dipendenze e aver classificato gli asset IT, occorre esaminare le dipendenze di ciascuna applicazione di modo da determinare quali di queste è possibile spostare nel cloud anche velocemente. Nel caso di applicazioni web o applicazioni SaaS, l’albero delle dipendenze consisterà di componenti logici come database, indici, servizi di login e autenticazione, vendita e pagamenti, etc. Per i processi di backend, è possibile tenere in considerazione processi come sistemi di workflow, di logging e di reportistica come gli ERP o i sistemi CRM.

Nella maggior parte dei casi, i migliori candidati per il cloud sono quei servizi o componenti che hanno il minor numero di dipendenze. Pertanto, alcuni esempi di questa tipologia sono i sistemi di backup, le applicazioni batch, i sistemi di logging, di sviluppo, test e build, le applicazioni web, i sistemi di coda, etc. Le applicazioni candidate sono quelle che hanno un immediato business di essere scalate, quelle che hanno una certa flessibilità architetturale, quelle che sono usate dai partner.

Una volta definita la lista delle applicazioni e dei sistemi candidati alla migrazione, occorre dare una certa priorità ad alcune di esse. Cosa occorre chiedersi in questa fase:

• Si è capaci di mappare l’architettura attuale delle applicazioni candidate alla migrazione, all’architettura del sistema cloud? Se no, qual è l’effort necessario per rifattorizzare?
• L’applicazione candidata può essere distribuita in una istanza di VM (virtual machine) ed essere eseguita nel cloud, oppure è necessario dedicarle dell’hardware apposito?
• La società è autorizzata a spostare il software usato dalle applicazioni candidate nel cloud?
• Qual è l’effort richiesto per migrare un’applicazione?
• Quali componenti devono rimanere in-house e quali possono essere migrati?
• Il cloud mette a disposizione i meccanismi di autenticazione e autorizzazione richiesti?

Identificazione dei tool riusabili

È necessario analizzare non solo gli applicativi e le parti infrastrutturali, ma occorre prendere in considerazione anche i tool utilizzati, verificando che questi possano essere riusati nell’ambiente cloud senza nessuna modifica. Sono parecchi gli strumenti commerciali che non potranno più essere utilizzati nel cloud, per esempio per motivi di licenza, e quindi occorrerà trovare dei sostituti per:

• Resource Management Tools: utile per gestire molte risorse come le istanze di server, immagini di macchine virtuali, database, etc…
• Resource Configuration Tools: utile per automatizzare l’utilizzo delle risorse nel cloud e aiutare nel processo.
• Integration Tools: l’introduzione  di framework e di librerie/SDK consentono l’integrazione con quanto distribuito nel cloud. Un esempio potrebbe essere la necessità di doversi integrare coi web services, messi a disposizione nella “nuvola”, semplicemente da un ambiente di sviluppo come Eclipse.

Fase 2: Definizione del Proof of Concept

Per verificare la fattibilità  della migrazione delle applicazioni candidate con gli strumenti di supporto previsti nel cloud, in questa fase si definisce per l’appunto un Proof  Of  Concept (prova di fattibilità, POC). Realizzare un POC significa definire gli elementi base dell’applicazione, coinvolgendo tutti i pezzi del modello architetturale, e coinvolgere tutti gli elementi infrastrutturali per verificare soprattutto l’integrazione degli stessi.

In questa fase occorrerà chiedersi:

• Quanto costa o qual è l’effort necessario per passare da un POC alla realizzazione finale da produzione?

Fase 3: Migrazione dei dati

Superati gli step che confermano la fattibilità della migrazione, si continua con la fase di migrazione dei dati.
Ecco le domande da porsi per l’attuazione di questa fase:

• Quali sono le varie opzioni di storage oggi disponibili nel cloud?
• Quali sono i vari RDBMS (commerciali e open-source) disponibili per il cloud?
• Qual è la strategia per la segmentazione dei dati che si intende adottare?
• Qual è l’effort previsto per migrare tutti i dati nel cloud?

Una volta scelta l’opzione di storage appropriata, occorre però tener presente che una sola tipologia (in termini di dimensioni) non è sufficiente. Occorre prendere in considerazione varie dimensione di storage, di modo da poter scalare le applicazioni col minimo effort.

Bisogna trovare il giusto compromesso tra dimensioni e costi, durata, abilità nelle query, disponibilità, latenza, performance (inteso come tempo di risposta), dimensione degli oggetti memorizzabili, accessibilità, frequenza di aggiornamento, capacità di cache, consistenza e transitorietà. Occorre quindi pesare attentamente il trade-off e da lì decidere per la propria applicazione.

Fase 4: Migrazione delle applicazioni

Vediamo cosa chiedersi in questa delicata fase:

• Come muovere le varie parti applicative del sistema nel cloud senza compromettere o alterare il corretto funzionamento a supporto del business?

Le strategie possibili di migrazione sono due:

• Migrazione forklift (tutto in una volta);
• Migrazione ibrida.

Illustreremo adesso i pro e i contro di ciascuna delle due strategie e vedremo anche qual è l’approccio migliore in base alla tipologia di applicazione indagata.

Migrazione forklift (tutto in una volta)

È conveniente applicare questo approccio a questo tipo di applicazioni:

• stateless;
• strettamente accoppiate;
• auto-contenute.

Piuttosto che muovere la varie parti di un sistema nel tempo, questa strategia prevede di spostare tutto in una volta nel cloud. Esempi di applicazioni da migrare secondo questo approccio sono:

• le applicazioni web;
• i sistemi di archiviazione e di backup;
• le componenti di applicazioni web a 3 strati che richiedono una connettività dalla latenza veramente bassa per poter funzionare perfettamente.

La migrazione comprenderebbe anche le seguenti attività:

• la configurazione di una macchina virtuale, predisposta a ospitare la nuova applicazione;
• la creazione di gruppi di utenti coi diritti di accesso;
• la configurazione di indirizzi IP dinamici;
• la creazione di un database (o di tabelle) dedicato alla nuova applicazione;
• …

Dopo lo step iniziale della migrazione potrebbe sembrare che tutti i vantaggi di elasticità e di scalabilità non siano sfruttabili, caratteristiche che invece permettono di differenziarsi dai competitor perche’ saranno sfruttabili nel tempo sulla base dell’utilizzo della stessa applicazione.

Migrazione ibrida

Questa strategia prevede che la migrazione verso il cloud non venga fatta coinvolgendo subito tutte le componenti applicative e infrastrutturali ma prendendo solo alcune parti dell’applicazioni e muovendole verso il cloud, lasciandone altre in loco. Questo tipo di approccio riduce i rischi di comportamenti inaspettati dopo la fase di migrazione, ed è possibile inoltre circoscrivere le cause dei problemi.

Solitamente, questo approccio è preferibile su applicazioni che prevedono l’utilizzo di processi batch, tant’è che in questo caso sarebbero i primi candidati a dover essere migrati, lasciando in loco la parte web. Soprattutto in questo approccio, occorre definire un design e un processo che preveda quali siano le parti da migrare prima o dopo, sulla base anche dei dati che vengono usati dall’applicazione e sulla base di quale /i database sono coinvolti.

È possibile sfruttare questa strategia per integrare applicazioni cloud con altre applicazioni legacy che non si prestano al cloud (applicazioni mainframe o applicazioni che richiedono hardware specifici per funzionare). In queste situazioni, occorre definire dei wrapper sulle applicazioni legacy di modo da poterle esporle mediante servizi web, il che implica un effort superiore rispetto alla semplice migrazione dell’applicazione in ambiente cloud.

Fase 5: Sfruttare il cloud

In questa fase è arrivato il momento di sfruttare i benefici offerti dal cloud come la scalabilità e l’elasticità.

• Ma cosa è necessario fare sulle proprie applicazioni per poter usufruire di queste caratteristiche?
• Quali sono i processi che consentono di manutenere e gestire le applicazioni nel cloud?
• Come occorre predisporsi per poter fare restore delle proprie applicazioni in caso di failure (software o hardware)?

Proviamo a darci delle risposte in base a ciò che ci viene messo a disposizione dal cloud.

Automatizzare l’elasticità

L’elasticità (ciòè la possibilità di startare/stoppare un numero necessario di istanze dell’applicazione) può essere realizzata a vari livelli dell’architettura applicativa e richiede la rifattorizzazione e la scomposizione dell’applicazione nei suoi vari componenti, di modo che risulti scalabile.

Riuscire ad automatizzare l’elasticità, renderebbe più facile il processo di scalabilità orizzontale dell’applicazione e di conseguenza aumenterebbero i benefici nel mantenere un’applicazione nel cloud.

Sicurezza

Ogni step del processo di migrazione deve prevedere l’applicazione del giusto grado di sicurezza. Vediamo alcuni esempi:

• protezione delle proprie credenziali;
• accesso limitato alle risorse a determinati utenti;
• protezione dei dati mediante la crittografia sia sui dati salvati che su quelli in transito;
• adozione di strategie che consentano il recovery.

Fase 6: Ottimizzazione

In questa fase ci si dovrebbe concentrare su come ottimizzare il cloud-based, al fine di aumentare il risparmio sui costi. Dal momento che si paga solo per le risorse che si consumano, si dovrebbe cercare di ottimizzare il sistema, quando possibile.

Re-ingegnerizzare la propria applicazione

Per creare un’applicazione altamente scalabile, potrà essere necessario riprogettare alcuni componenti di modo da farli funzionare in maniera ottimale in ambiente cloud. Ecco alcune domande che occorre porsi per verificare il grado di re-factoring che occorre applicare alla propria applicazione:

• L’applicazione è distribuibile (packaging e deploy) in una istanza di server presente su una macchina virtuale?
• È possibile eseguire più istanze della stessa applicazione in una sola istanza di server, se necessario? Oppure occorre avere tante istanze di server quante sono le istanze applicative?
• È possibile scomporre l’applicazione in vari componenti di modo che ciascuno di essi possa essere eseguito in istanze diverse di server? Per esempio, è possibile scomporre una web application nei suoi componenti web, business e database ed eseguire ciascuno di essi su istanze diverse di server?
• È possibile estrarre i componenti stateful e renderli stateless?
• È possibile disaccoppiare il codice mediante configurazione?

In risposta a queste domande si può risalire al grado di intervento che occorre attuare per migliorare il grado di ottimizzazione che si può ottenere dal mettere in cloud la propria applicazione.

Conclusioni

Con l’ultimo articolo della serie sulle soluzioni per il cloud computing si è voluta mettere in evidenza l’importanza di un processo a supporto di un’attività quale può essere la migrazione verso il cloud. Al di là del dettaglio delle singole fasi che sono state individuate da questo processo, il valore che si vuole sottolineare è che, alla base di una qualsiasi attività, occorre partire dalla definizione di uno “strumento” che possa fare da guida nelle varie fasi. Così facendo si riescono non solo ad individuare le attività ma anche i diretti responsabili (da non intendersi come coloro a cui dare la colpa…), intesi come le persone di competenza che occorre prevedere sia trasversalmente a tutte le attività che in maniera verticale, dedite alle singole fasi.

Quindi l’individuazione del processo è speculare sia per un cliente che vuole attuare un piano di migrazione e deve individuare gli skill che gli occorrono, sia interni che esterni, ma anche per un fornitore che riesce a capire come innestarsi nelle varie fasi con una consulenza efficace.

Riferimenti

[1] La voce TCO su Wikipedia

http://it.wikipedia.org/wiki/Total_Cost_of_Ownership