La scorsa settimana ho parlato spesso con utenti finali che, per un motivo o l’altro, stanno pensando ad una seconda infrastruttura di virtualizzazione da affiancare a quella attuale (in tutti i casi erano utenti VMware). I motivi sono diversi, ma c’è un vero interesse a valutare piattaforme di cloud privato nuove al posto di infrastrutture più classiche. Spesso il discorso è finito su OpenStack (anche se qui ho sempre il dubbio che lo si faccia più per moda che per reale intenzione di adottarlo nel breve).

Vorrei quindi fare un paio di considerazioni su cosa significa un approccio “cloud tradizionale” Enteprise contro uno alla “cloud pubblico”/”cloud commodity” e descrivere brevemente alcuni aspetti che molti danno spesso per scontati.
Intendiamoci non c’è nulla di sbagliato ad adottarne uno o l’altro, l’importante è capire quale è il modello giusto per la propria struttura IT.

Verso il cloud privato

Applicare i concetti di cloud ad una infrastruttura privata, anche se di dimensioni medio grandi (i clienti di cui parlo hanno più di 1000 VM) non è facilissimo ma porta dei potenziali vantaggi concreti. Infatti, l’obiettivo di molti non è tanto quello di dare portali per fare self provisioning a tutti i costi ma di poter gestire l’infrastruttura con dei livelli di automazione molto superiori (es. auto-scaling?) garantendo SLA adeguati e specifici ai diversi interlocutori. Massimo Re Ferrè in una interessante presentazione durante l’ultimo VMUGIT, ha affermato che molti clienti VMware stanno adottando vCloud Director proprio per use cases diversi da quello “istituzionale”.

C’è poi un interesse crescente degli utenti, soprattutto di quelli di grandi dimensioni, a valutare un prodotto alternativo a VMware… anche solo in affiancamento e magari per task di secondaria importanza (certo si apre il Problema del management di due ambienti e della loro Integrazione, P e I maiuscole, ma questo è un’altro film). L’obiettivo di questi utenti è facile da intuire ed è legato non tanto alla qualità del prodotto VMware ma più alla ricerca di una diversa forza commerciale e ad avere un secondo interlocutore per evitare il lokck-in.

Due modelli diversi

Molti utenti ignorano comunque che al momento esistono due diverse filosofie per implementare un cloud (banalizzo per non farla troppo lunga): “Alla Amazon” e “alla Vmware”.

“alla Vmware”, ma avrei potuto scrivere anche Citrix o Microsoft, è quella più tradizionale dove c’è uno storage condiviso in cui risiedono le VM ed esistono funzionalità molto apprezzate dagli utenti finali come, ad esempio, live migration e HA. L’infrastruttura si occupa di garantire un livello di affidabilità elevato e spesso il sistema di management ha anche degli agenti/tool che installati all’interno delle VM verificano il funzionamento di alcune componenti (S.O. o applicazioni). Le API di controllo dell’infrastruttura, se ci sono, non vengono usate dai software. In pratica è il classico ambiente virtualizzato dove la parola virtualizzato ha un senso chiaro e c’è una chiara trasposizione di quello che sarebbe stato nell’ambiente fisico.

“alla Amazon”, ma anche qui avrei potuto dire Openstack (e altri), siamo oltre. Infatti le funzionalità dell’hypervisor sono molto meno importanti. Le caratteristiche di alta affidabilità e movimentazione dei dati/risorse perdono molto del loro significato. Lo storage non è condiviso e le API sono il vero strumento per accedere e amministrare il tutto. Semplificando, le VM sono delle istanze di template e forniscono potenza di elaborazione, spazi di memoria e altre risorse in maniera assolutamente commodity. E quando uso il termine commodity intendo proprio con l’idea che hanno poco lavoro e che vanno misurate un tanto al Kg: se un istanza (o un intero server) fallisce, non è importante e ne nascerà un’altra a prendere il suo posto.

Per chi avesse voglia di leggere, c’è un bell’articolo del su menzionato Massimo che parla proprio di questi due diversi modelli di implementare un cloud.

Troppo diversi

Due disegni architetturali così diversi impongono un a ragionamento molto importante su quanto ci gira sopra. Le applicazioni, nel caso di una architettura tradizionale, danno per scontato che è stato già previsto un meccanismo di alta affidabilità di un qualche tipo: se Linux (o l’applicazione che ci gira dentro) va in panic per un qualche motivo ci sarà qualcosa che lo fa ripartire.
Nell’altro caso invece non funziona così! L’applicazione sa che sta girando su una piattaforma non affidabile, e quindi deve avere insiti tutti i meccanismi che gli possano garantire di sopravvivere ad un fail!

La scimmia del caos

Quando parlo di quello che ho appena descritto menziono sempre Netflix e la sua Chaos Monkey. In due parole, questi signori hanno creato un sistema che gira continuamente per la loro infrastruttura e Killa uccide processi a caso. L’obiettivo è quello di verificare che i meccanismi di resilienza disegnati a livello applicativo facciano il proprio mestiere. Nella maggior parte dei casi gli utenti finali si rendono precisamente conto di cosa significa sposare un modello piuttosto che un altro proprio grazie a questo esempio

Evoluzione o rivoluzione

Far evolvere la propria infrastruttura virtualizzata in un’infrastruttura cloud è la scelta più facile. Esistono già prodotti commerciali che promettono di fare questo, alcuni promettono anche di gestire più hypervisor. Ovviamente più spari in alto (più prometti di gestire) e più è difficile mantenere le promesse, ma ci stanno lavorando tutti i principali vendor.

Dall’altro lato, se ci sono le risorse (sviluppatori), i soldi da investire e il tempo per migrare al modello “alla Amazon”, quella è una strada percorribile. La maggiore efficienza, e scalabilità, si misurerà tutta nel lungo termine.

Nota finale

Per ragioni anche di lunghezza dell’articolo non potevo andare più a fondo (e di sfumature ce ne sono diverse); comunque, quello che volevo far trasparire, è l’idea di base che dovrebbe sostenere una scelta piuttosto che l’altra.
Adottare due distinti stack tecnologici non è difficile (basta comprarli) e sono diverse le aziende che lo stanno valutando o l’hanno già fatto. Usarli e gestirli al meglio è già un’altra faccenda.
Alla fine, penso che adottare un secondo stack tecnologico e replicare quanto si sta già facendo oggi (virtualizzare) rischi di dimostrarsi una tattica per cercare di spendere meno nell’acquisto: c’è il rischio concreto che nel lungo termine abbia un TCO più elevato.
Al contrario, se ci sono necessità e risorse, pensare ad affiancare un’architettura tradizionale ad una di prossima generazione può essere una scelta strategica e premiante nel lungo periodo.