Smart Cloud Enterprise+ realizza una soluzione di tipo Private Cloud che viene data in outsourcing a IBM. Essa permette di coprire la fascia dei clienti che desiderano un’offerta equivalente all’outsourcing, affiancando anche i vantaggi permessi dal paradigma cloud; la sua realizzazione si avvale delle conoscenze e degli strumenti di gestione e migrazione accumulati da IBM nell’ambito dell’outsourcing. Questa duplice esigenza di avere una soluzione che risponde a SLA di affidabilità, robustezza, implementando anche un servizio Cloud permette di fornire un servizio adeguato anche ad aziende che debbano gestire dati sensibili, quali banche o aziende pubbliche.
Rispetto alla soluzione SCE viene previsto un aumento del livello di flessibilità a livello di piattaforma, con la possibilità di avere sistemi aggiuntivi di monitoraggio e funzionalità ulteriori per la sicurezza, come ad esempio il backup fornito da IBM e integrato nella so- luzione; rimangono tuttavia i vincoli sulla standardizzazione dei workload e dello strato di management che sono alla base di un progetto cloud di successo. Vengono inoltre previsti nuovi point of delivery oltre ai sei già visti per lo Smart Cloud Enterprise e viene prevista l’opzione di avere uno SLA garantito di 99,9%, che raggiunge il 99,99% per quanto riguar- da lo storage; per ogni singola istanza è possibile scegliere il livello di SLA desiderato e le garanzie sulla replicazione, così da poter prevedere utilizzi anche per fini di produzione. Dal punto di vista economico, la fatturazione avviene su base mensile piuttosto che su ba- se oraria, come avviene in Smart Cloud Enterprise e nella maggior parte delle soluzioni di cloud pubblico.
Aumenta poi il numero di sistemi offerti: oltre a piattaforme di tipo Intel, si hanno anche piattaforme di tipo Power 7 con sistema operativo AIX, molto diffuso in ambito aziendale come backend. Il virtualizzatore alla base di Smart Cloud Enterprise+ è VMware per sistemi di tipo x86, mentre per gli IBM System p viene utilizzata la virtualizzazione PowerVM; sono previsti, infine, strumenti per l’importazione di immagini virtuali esistenti, così da facilitare il processo di migrazione.
Dal punto di vista architetturale, anche SCE+ sfrutta una diversa architettura fisica sulla base della Reference Architecture esposta in precedenza. In particolare, l’architettura
prevede una strato di managing, utilizzato per fornire dei servizi ai clienti e che consiste a sua volta in una parte centralizzata ed una distribuita nei vari point of delivery. A esso si affianca lo strato managed, che è un insieme di nodi dedicati o condivisi, che possono essere ospitati presso il datacenter IBM o direttamente presso il cliente.
Purtroppo questa soluzione sarà disponibile solamente nel secondo quadrimestre del 2012, per cui non è stato possibile fare delle prove sul campo, né sfruttarne le nuove funzionalità previste.
Valutazione dell’opportunità di
migrazione
D
opo aver stabilito caratteristiche, vantaggi e limiti del cloud computing, poniamola nostra attenzione su come si possa arrivare all’utilizzo di queste idee in modo efficiente nel mondo delle applicazioni industriali. Come si è visto, alla base del paradigma cloud, vi è una serie di concetti già esistenti e sviluppatisi in maniera separata, che sono stati integrati inoltre con nuove evoluzioni tecnologiche, quali la banda larga. Per le aziende, vista la maturità raggiunta dal settore dell’Information Technology, l’interesse maggiore è orientato a una sua introduzione per evoluzione di soluzioni preesistenti, così da permettere anche ad esse di sfruttare i vantaggi offerti (pensiamo al self-service delle risorse o alla maggior flessibilità e scalabilità), consentendo nel contempo una possibile riduzione dei costi infrastrutturali e di gestione.Il cloud richiede di base un’idea di standardizzazione e uniformità, anche su centri di elaborazione remoti, per cui non è una soluzione che offra benefici per qualsiasi applica- zione. Quindi, prima di procedere con un progetto di migrazione che coinvolga elementi già esistenti, le aziende chiedono agli esperti un’analisi che permetta il confronto con le of- ferte disponibili sul mercato e stabilisca, a seconda dei diversi punti di vista affrontati, cosa possa essere migrato e cosa no. Tale analisi prevede il confronto tra i workload dell’intero sistema informativo di origine e i diversi modelli di delivery cloud. Poiché i workload possono essere in numero piuttosto elevato, comprendendo nei casi più complessi anche migliaia di server, nasce l’esigenza di disporre di strumenti automatizzati, destinati a fa- cilitare il consulente in questo compito, che sarà il tema di maggior interesse nel seguito
della trattazione.
Andremo ora a vedere lo stato dell’arte per quanto riguarda il tema della migrazione verso ambienti cloud, prima in breve dal punto di vista consumer, poi più in dettaglio l’aspetto enterprise, che sarà l’argomento centrale della tesi.
3.1
Migrazione in ambiente consumer
Dal punto di vista consumer, la migrazione è sentita soprattutto a livello di Software-as-a- Service e Platform-as-a-Service, visto che la virtualizzazione, ingrediente di base del cloud computing, non ha ancora avuto molta diffusione a livello dei singoli utenti. La maggior parte degli utilizzi è quindi relativo a nuove applicazioni, godendo della possibilità di avere dei server al momento del bisogno oppure sfruttando nuove tecniche come MapReduce/- Hadoop che, grazie alle tecniche del calcolo parallelo, riducono i tempi di elaborazione rispetto all’esecuzione su una macchina singola. Per quanto riguarda la migrazione di un software da uno scenario desktop ad uno in cloud, esistono diversi studi che si soffermano sulle difficoltà riscontrate e le modifiche necessarie sia a livello concettuale sia pratico, che di seguito andiamo ad analizzare.
3.1.1
Stato dell’arte
Per quanto riguarda la migrazione di software, non esistono soluzioni universali. Le va- riabili in gioco sono moltissime, partendo dallo scopo del programma fino al linguaggio utilizzato, per cui è difficile fare delle generalizzazioni. Uno studio generale sulla fattibilità della migrazione si trova in [TKLF11], dove gli autori presentano un’analisi che coinvolge tutti gli aspetti relativi alla migrazione di un applicativo on-premise verso il cloud, con una particolare attenzione sui fattori di costo di tale migrazione. Il test case è stato quello di un software n-tier basato sulla tecnologia .NET e gli autori hanno individuato cinque fasi necessarie: addestramento, installazione e configurazione dell’ambiente di destinazione, modifiche al codice, migrazione vera e propria e infine testing. I singoli costi di queste fasi dipenderanno poi dalle capacità del gruppo di lavoro e dalla complessità dell’applicazione in oggetto.
Un’esperienza simile è quella proposta in [BC11], dove si analizza, da un punto di vista prettamente tecnico, la migrazione verso un cloud pubblico di un’applicazione opensource.
Gli autori sottolineano innanzitutto l’importanza di suddividere il software per componen- ti, così da poter anche effettuare il deployment su provider diversi ed essere indipendenti anche dai singoli database. Viene anche specificato come, in ambienti di tipo PaaS, la mi- grazione sia più difficile e potrebbe richiedere molte modifiche perché tecnologie e librerie a disposizione sono limitate; in generale, più il sistema è complesso e dipende da molte librerie, più la migrazione diventa lunga. Gli autori concludono individuando vari fattori che influenzano la migrazione, fra i quali si segnalano la sicurezza delle comunicazioni e la difficoltà di accedere alle librerie sottostanti in un ambiente di tipo PaaS, che potrebbe rendere difficile la ricerca di bug.
In [JMW+11] si analizza invece la parte successiva alla migrazione, quella dell’otti-
mizzazione; nello specifico, viene studiata un’applicazione n-tier che viene migrata su due diversi provider IaaS e le prestazioni vengono confrontate con un tradizionale ambiente cluster. Il risultato interessante dello studio è che le ottimizzazioni richieste variano molto da provider a provider, in quanto le prestazioni computazionali e di rete sono molto diverse e possono anche avere una notevole variabilità nel tempo, per cui, al momento della mi- grazione, bisognerà porre attenzione ed effettuare dei refactoring per raggiungere gli SLA richiesti. Un interessante studio dedicato completamente alla variabilità di prestazioni di un ambiente cloud si può trovare in [SDQR10].
In [ZL] viene affrontato uno scenario n-tier simile ai precedenti, che viene migrato da un datacenter locale a Amazon EC2, attraverso la reinstallazione di tutti i componenti necessari (application server, database, ecc.) sul cloud. Gli autori analizzano gli errori riscontrati in questa fase dopo averla fatta ripetere da operatori diversi, li categorizzano e ne misurano la frequenza, per poi proporre un framework per la configurazione semi- automatica. Tale framework consiste in due parti: una di controllo periodico delle politiche di configurazione e una che offre un sistema automatico di installazione basato su modelli e quindi estendibile.