Quando OpenStack rappresenta un’alternativa nel campo del cloud computing. Migrazione, supporto e flessibilità: le criticità maggiori con l’open source.
L’ultima volta che abbiamo parlato di OpenStack era ottobre e ci trovavamo a Barcellona per l’OpenStack Summit. In quell’occasione avevamo parlato dell’ambiziosa piattaforma open source per la creazione di framework, cioè un insieme di standard per gestire un’infrastruttura cloud aperta.
Ma oggi, che ne sappiamo qualcosa in più, ci chiediamo se OpenStack possa rappresentare a tutti gli effetti un’alternativa alle infrastrutture dei leader mondiali del cloud.
“Chi mi fornisce l’assistenza?”
Quando si utilizzano software proprietari, a fronte dell’acquisto della licenza, normalmente si può usufruire di servizi di supporto, che consistono sia nella certezza di ricevere tutti gli aggiornamenti sia nella possibilità di richiedere l’intervento da parte del provider.
Spindox, ad esempio, come venditore dei servizi Amazon, offre supporto tramite un servizio di help desk di primo livello per problemi di qualunque natura (infrastrutturale, sistemistico, applicativo). Per problematiche di secondo livello, Spindox si rivolge invece direttamente a AWS.
Nel modello open source, però, l’assistenza non è sempre inclusa. O meglio: è possibile ricercare supporto dalla community che sviluppa e utilizza un determinato software open, ma solitamente non esiste un soggetto incaricato di gestire e risolvere le problematiche degli utenti. Anche nel caso di OpenStack – se utilizzato da privato – l’unico supporto possibile sarebbe quello che deriva dal confronto sul suo forum.
Attenzione, non si tratta di una debolezza di OpenStack ma di una sua caratteristica: chi sceglie un prodotto open source dovrebbe essere consapevole del fatto che non può aspettarsi lo stesso supporto di un software a pagamento. Anche se il livello di servizio può variare di molto in base al modello di business in cui la piattaforma è implementata e alla presenza o meno di figure intermedie.
Le tre facce di OpenStack
I modelli di business che possono essere implementati con OpenStack sono tre:
– Self Private Cloud: qualsiasi player IT può costruirsi “in casa” il proprio il cloud privato con OpenStack. In questo caso la gestione dell’intera infrastruttura (dall’hardware al software) sarà autonoma e – come già detto – l’unica possibilità per ricevere supporto consisterà nel rivolgersi alla community della piattaforma.
– Outsourced Private Cloud: una società terza, come Spindox, utilizza OpenStack e delle macchine per erogare a terzi un servizio.
– Public cloud hosted by Red Hat: ci si rivolge direttamente a Red Hat – azienda statunitense che ha acquisito OpenStack da Rackspace e NASA – pagando una fee per l’utilizzo di OpenStack, come fosse un cloud pubblico. In questo caso OpenStack diventa un player di cloud pubblico al pari di Amazon, Microsoft, SoftLayer e Google Platform.
OpenStack? Meglio per il privato
L’ultimo modello potrebbe non rivelarsi conveniente, in quanto le funzionalità che mette a disposizione Red Hat sono molto ridotte rispetto ai big player del cloud pubblico. Sposare OpenStack con Red Hat su cloud pubblico vorrebbe dire quindi avere a disposizione un minor numero di funzionalità rispetto a AWS o Azure. È per questo che Red Hat ha deciso di ridefinire la propria strategia, consapevole di non avere con OpenStack la forza per aggredire il settore del cloud pubblico con un prodotto al pari di AWS – che di fatto è il cloud pubblico di riferimento in questo momento.
Il secondo modello – l’Outsourced Private Cloud – potrebbe invece essere una scelta interessante, laddove si voglia dare vita a un cloud privato. Ad esempio, con OpenStack, Spindox potrebbe creare un cloud privato su misura delle esigenze del cliente. Eludendo alcuni dei problemi che si porta dietro il cloud pubblico, tra cui la privacy o le conformità rispetto a una soluzione on-primise, e offrendo al cliente finale anche supporto di primo livello.
Questo è il settore nel quale OpenStack convince maggiormente: il cloud privato, segmento di mercato in cui né AWS né Azure sono presenti.
Così OpenStack potrebbe vincere la sfida ai big del cloud: proponendo un’infrastruttura trasparente in un contesto privo di competitor e accogliendo i suoi utenti in modo semplice, senza troppe complicazioni. A patto che tra la piattaforma e il cliente ci sia la presenza di un intermediario. Meglio se si stratta degli specialisti italiani del cloud (a buon intenditore…).
Migrare solo se conviene
Adottare OpenStack per la propria attività può comportare un’ulteriore problematica, oltre alla possibile mancanza di assistenza. Ciò avviene nel momento in cui un cliente deve migrare il proprio sistema informativo dal suo attuale servizio cloud a uno nuovo.
Pensate a cosa potrebbe succedere se i sistemi informativi di un’azienda venissero messi sul cloud di Amazon e un bel giorno si decidesse di spostarli e affidarli a Microsoft. Quanto sarebbe gestibile un’operazione di questo tipo? E più in generale, quali garanzie ci sarebbero sulla riuscita di una migrazione di applicazioni complesse – soprattutto in un contesto di applicazioni e sistemi informativi fra loro integrati – da Azure a AWS? (Stavolta invertiamo, per la par condicio.)
Lo sforzo per migrare un’infrastruttura IT dipende in genere dal modello di servizio utilizzato.
Mettendo da parte il SaaS, che presenta diverse problematiche e rende molto complicata l’operazione, i modelli principali utilizzati dai provider sono due: IaaS (Infrastructure as a Service) e PaaS (Platform as a Service).
Nel primo caso la migrazione sarà a low effect, nel secondo sarà invece a high effect. Questo rende lo IaaS il modello di servizio in grado di garantire un impatto nettamente inferiore sulla difficoltà di queste operazioni. Innanzitutto perché, con lo IaaS, alcune componenti base come networking, macchine virtuali, rete e dischi vengono virtualizzati come servizio. Inoltre, la maggior parte delle componenti di tutti i cloud provider sono in IaaS, tra cui network, virtual machine e dischi, e ciò semplifica ulteriormente la procedura.
Con il modello PaaS aumentano invece le componenti in gestione al provider. E poiché tutti i cloud provider possiedono proprie specificità, diventa più difficile migrare. Potrebbe infatti capitare che, passando a un altro cloud provider, non esista nulla di simile alla soluzione originale. Per citare un esempio concreto, AWS offre un servizio mail, Azure invece non ne possiede uno e si appoggia a un terzo vendor, Sendgrid.
Quando si decide di cambiare provider è necessario quindi effettuare attente valutazioni insieme all’utilizzatore finale del servizio, considerando che con la migrazione da un vendor all’altro a volte ci si può ritrovare con infrastrutture profondamente mutate. In alcuni casi i cambiamenti sono riduttivi, come quando si utilizza il modello IaaS. Altre volte diventa fondamentale un reengineering dell’applicazione, soprattutto quando si utilizza il PaaS, e i costi potrebbero aumentare di molto. In altre fattispecie ancora, come con il modello SaaS, la soluzione più giusta potrebbe addirittura consistere nel comunicare al cliente che la migrazione richiesta non può essere svolta, poiché è impossibile migrare la componente o perché il nuovo provider non offre un equivalente.
