Sei sulla pagina 1di 46

Juku

Think Global, Act Local!

Virtualizzazione e Cloud

Copyright 2011 di Enrico Signoretti e Fabio Rapposelli, Alcuni


diritti riservati.
Questo libro viene offerto sotto licenza Creative Commons BYNC-ND, questo significa che sei libero di:
riprodurre, distribuire, comunicare al pubblico, esporre in
pubblico, rappresentare, eseguire e recitare quest'opera.
Alle seguenti condizioni:
Attribuzione Devi attribuire la paternit dell'opera
nei modi indicati dall'autore o da chi ti ha dato l'opera
in licenza e in modo tale da non suggerire che essi
avallino te o il modo in cui tu usi l'opera.
Non commerciale Non puoi usare quest'opera per
fini commerciali.
Non opere derivate Non puoi alterare o
trasformare quest'opera, n usarla per crearne un'altra.
Tutti i termini menzionati in questo libro riconosciuti come
trademarks o service marks sono stati capitalizzati in modo
appropriato.

Indice
Juku ..................................................................1
Perch Juku .........................................................................1
Chi Juku ............................................................................3

Introduzione ....................................................4
Partiamo dallinizio .........................................5
Un cenno storico .................................................................5
Perch virtualizzare .............................................................6
Prima di iniziare ...................................................................8

Pianificazione ................................................10
Non tutto virtualizzabile ................................................10
La scelta dellhypervisor ...................................................11

Management di base ........................................................14


La connettivit ...................................................................16
I server ...............................................................................18
Lo storage ..........................................................................20
Gli stack .............................................................................22

Virtualizziamo ................................................25
Da fisico a virtuale ............................................................25
I rischi della virtualizzazione selvaggia ...........................26
Virtualizzazione e Consolidamento .................................28
Capacity Planning .............................................................29
Chargeback .......................................................................30
Cloud ..................................................................................31

Il Private Cloud ..............................................33


La fase dei Servizi IT in Produzione ................................34
Virtualizzare il Business in Produzione ...........................35
Private Cloud .....................................................................38
Conclusioni ........................................................................42

Virtualizzazione e cloud

Juku
Perch Juku
I Juku sono scuole, private, giapponesi che hanno lobiettivo di
aiutare gli studenti a migliorare il rendimento nelle loro normali
attivit scolastiche ed a garantire una preparazione migliore per
gli esami. Bench questo tipo di scuola sia principalmente
concepita per le materie accademiche, non raro trovare dei
juku anche per discipline artistiche, sportive e arti marziali.
Il nostro obiettivo proprio quello di non sostituirci
allinformazione istituzionale ma di aiutare chi deve prendere le
decisioni per il proprio IT con articoli, informazione e confronto
sulle tematiche tecnologiche che conosciamo meglio:
linfrastruttura IT ed in particolare virtualizzazione e storage.
Non pi come una volta, chi lavora nellIT deve guardarsi
intorno: le cose cambiano velocemente e c la necessit di
rimanere informati, o di informarsi velocemente, per sostenere
decisioni importanti. Come fare? E semplice, il sito contiene le
nostre idee, il risultato del confronto quotidiano che abbiamo
globalmente sul web ed i social network con vendor, analisti,
1

Juku

blogger, giornalisti e consulenti. Ma il nostro lavoro non si ferma


qui, il confronto e la ricerca sono globali ma la condivisione e
lapplicazione delle nostre idee deve essere locale: ed qui che
la nostra esperienza quotidiana, con aziende radicate sul
terriorio italiano, diviene fondamentale per offrire una visione
sincera ed utile. Ecco perch abbiamo sceltothink global, act
local come payoff per Juku.
Juku gi diventato, durante il suo primo mese di vita, un punto
di riferimento per i decision maker del mondo IT, ed i suoi articoli
vengono linkati dai maggiori autori della blogosfera dello storage
e della virtualizzazione. Il sito contiene articoli in Italiano ed
Inglese ed raggiungibile allindirizzo http://juku.it oppure con
una semplice scansione del QR Code qui in basso.

Virtualizzazione e cloud

Chi Juku
Enrico Signoretti, Fondatore e CEO di
Cinetica, realt di rilievo nel panorama dello
s t o r a g e e v i r t u a l i z z a z i o n e i n c e n t ro
Italia. Frequenta gli ambienti IT da oltre 20
anni, la sua carriera iniziata con lassembler
nella seconda met degli anni 80 per poi
passare allo Unix (ma sempre con il Mac nel cuore) fino ad
approdare al Cloud dei giorni nostri. Attento alle evoluzioni del
mercato e alla costante ricerca di idee e soluzioni innovative.
un appassionato velista ed un pescatore mancato. Enrico
raccoglie i suoi profili Social qui: http://about.me/esignoretti
Fabio Rapposelli, specialista di Storage e
Virtualizzazione con oltre 10 anni di
esperienza nel settore della consulenza
IT. Attualmente gestisce e coordina il team
tecnico di Cinetica sviluppando e dispiegando
i n f r a s t r u t t u re i n f o r m a t i c h e s u s c a l a
globale. Nato come uomo UNIX al termine degli anni 90 ha
iniziato a lavorare con le piattaforme di virtualizzazione dai loro
albori fino ad oggi, cerca di evangelizzare il concetto di Cloud
agli IT manager. Nel 2010 viene insignito della ambita
certificazione VCDX (Numero #58) da VMware. Appassionato
musicofilo ed incallito viaggiatore. Fabio raccoglie i suoi profili
Social qui: http://about.me/frapposelli
3

Juku

Introduzione
La virtualizzazione dei server uno degli argomenti pi caldi di
questi anni. Molte aziende stanno gi affrontando la loro
seconda ondata di virtualizzazione che spesso si traduce in una
rivisitazione radicale di quello che stato fatto negli anni passati
per correggere errori e, magari, aggiornare linfrastruttura con
lespressione degli ultimi trend tecnologici.
Lobiettivo di questo documento quello di sottolineare alcuni
aspetti di base per chi si avvicina per la prima volta alla
virtualizzazione ma anche di ricordare, a chi ha gi intrapreso
questo percorso, alcuni punti focali per migliorare il pi possibile
la propria infrastruttura.

Virtualizzazione e cloud

Partiamo dallinizio
Un cenno storico
La virtualizzazione dei server non nata nel mondo x86. I primi
hypervisor (anche se allepoca non si chiamavano cos) sono nati
negli anni 60 sui mainframe.

Gi, quello che oggi viene chiamato z/OS (il sistema operativo di
IBM per i suoi mainframe) aveva funzionalit di virtualizzazione
gi allepoca. Negli anni, poi, altri sistemi operativi, come ad
esempio alcuni Unix, hanno aggiunto funzionalit di
virtualizzazione (software o HW+SW) che emulavano in parte
quanto gi visto sui mainframe. La virtualizzazione nacque in
primo luogo per ottimizzare luso delle risorse di sistemi costosi

Juku

e male utilizzati ma fu parzialmente abbandonata negli anni


80/90, durante lera dei PC e delle applicazioni client/server.
VMware, azienda leader nella produzione di software per la
virtualizzazione, ha avuto il grande merito di sviluppare per
prima (nel 1999) questa tecnologia su hardware standard x86.
Fra gli anni 90 ed i primi del 2000 ci si rese conto che la
proliferazione di server X86 sottoutilizzati (spesso 1 Server = 1
Sistema Operativo = 1 Applicazione) stava portando ad una
impennata dei costi per gestire lIT non pi affrontabili ed qui
che aziende come VMware trovarono i loro primi sostenitori.
Negli ultimi anni lhypervisor di VMware stato affiancato da
molte altre soluzioni concorrenti tra cuiMicrosoft Hyper-V eCitrix
Xen. Ognuna di queste ha vantaggi e svantaggi che vedremo nei
paragrafi successivi.

Perch virtualizzare
La virtualizzazione porta dei vantaggi indiscutibili:
Migliora sensibilmente i livelli di utilizzo
dellinfrastruttura: molto improbabile che una singola
applicazione possa occupare tutte le risorse messe a
disposizione da un hardware fisico per tutto il tempo. Il
meccanismo della virtualizzazione, con la possibilit di
creare tanti server virtuali, permette di utilizzare in maniera

Virtualizzazione e cloud

molto pi efficiente le risorse a disposizione allocando le


risorse dove servono e quando servono.
Diminuisce i costi dellinfrastruttura: come
conseguenza del punto precedente, se ho la possibilit di
ottimizzare al meglio luso delle risorse hardware a
disposizione avr bisogno di meno risorse hardware da
comprare e gestire.
Diminuisce i costi di gestione: ancora una volta, meno
hardware significa abbattere i costi di gestione ma non solo.
La virtualizzazione porta con s strumenti molto sofisticati
che permettono una semplificazione importante di molte
attivit tecniche che vanno dalla pi banale fornitura di un
nuovo server, al backup, alla creazione di ambienti di test,
ecc.
Migliora i livelli di servizio: Una infrastruttura virtuale ha
una serie di vantaggi non indifferenti dal lato del livello di
servizio, esistono molti meccanismi che permettono di
reagire prontamente ad un intervento pianificato o ad un
problema hardware, al ripristino di un server virtuale
danneggiato o anche a prevenire e ripristinare il servizio a
fronte di un disastro.
La virtualizzazione dei server ha quindi molti aspetti positivi che
aumentano la semplicit operativa del datacenter, ne aumentano
la sicurezza e ne diminuiscono i costi. Ovviamente, pi il
datacenter grande e pi i vantaggi sono evidenti ma anche chi

Juku

ha pochi server trover sempre pi vantaggioso virtualizzare


piuttosto che dover aggiungere hardware fisico alla propria
infrastruttura.

Prima di iniziare
Virtualizzare facile! (troppo facile, aggiungerei). Questo il
messaggio che spesso arriva da chi vende la virtualizzazione
ma le cose non stanno proprio cos.Spesso incontro clienti che
hanno infrastrutture non progettate e mal cresciute da una prima
implementazione di valutazione che, nel tempo, diventato
test, poi sviluppo e poi, magari, produzione! Certo, funziona
tutto, ma come funziona? Con questo tipo di approccio si vanno
ad eliminare, almeno in parte, tutti i principali motivi per i quali si
inizia a virtualizzare: ottimizzazione, diminuzione dei costi, facilit
di gestione, migliorare i livelli di servizio.
Prima di virtualizzare importante progettare linfrastruttura che
ospiter le macchine virtuali. Gli hypervisor moderni hanno un
numero di funzionalit impressionanti che, se male utilizzate,
possono minare la scalabilit, la sicurezza ed anche le
performance. Inoltre, con una profonda e chiara conoscenza
delle architetture, delle best practices e delle tecnologie,
possibile garantire una crescita sicura dellinfrastruttura senza
spiacevoli disservizi che potrebbero verificarsi.
Per ottenere una infrastruttura virtuale efficiente sempre
fondamentale fare un progetto che preveda una analisi
dettagliata di tutto quanto gi in opera allinterno del
datacenter. Nessun aspetto deve essere sottovalutato:
8

Virtualizzazione e cloud

networking e sicurezza, storage, risorse di calcolo e memoria,


applicazioni, sistemi operativi, processi, ecc. Sottovalutare
anche uno solo degli aspetti menzionati e progettare una nuova
infrastruttura virtuale meno efficiente e performante della
precedente sarebbe un fallimento poco raccomandabile a
chiunque.

Juku

Pianificazione
Non tutto virtualizzabile
Quando si esegue lanalisi di una infrastruttura fisica con
lobiettivo di virtualizzarla non si riuscir quasi mai ad ottenere un
risultato pieno al 100%. Alcuni server fisici, per diversi motivi,
non saranno virtualizzabili ma dovranno rimanere tali. Nella
categoria dei server non virtualizzabili troviamo sicuramente:
server non x86 (per ovvi motivi).
server che hanno particolari caratteristiche hardware: come
ad esempio schede PCI particolari (un esempio pu essere
il fax server).
server con sistemi operativi non supportati dallhypervisor.
particolari tipi di cluster.
Questi sono i pi diffusi e per alcuni di questi esiste anche una
soluzione (almeno parziale). Ovviamente sar necessario capire
bene cosa fanno questi server, che applicazioni e servizi di base
stanno erogando ed anche la loro criticit. Con tutte le
informazioni e le precauzione del caso, sar possibile migrare
tutti (o parte) dei servizi applicativi contenuti ed anche ipotizzare

10

Virtualizzazione e cloud

nuovi meccanismi di alta affidabilit per i cluster (spesso gi insiti


e forse migliori nell hypervisor). Nel caso specifico di server
con componenti hardware particolari, ad esempio, potrebbe
essere ipotizzabile leliminazione di tutte le parti virtualizzabili
lasciando sul fisico il minimo indispensabile.

La scelta dellhypervisor
La scelta dellhypervisor, secondo il mio personale punto di vista,
abbastanza a senso unico. Esistono comunque alcune
eccezioni alla regola da verificare con attenzione prima di
procedere con una scelta che potrebbe limitare lo sviluppo
dellinfrastruttura ed aumentare i costi in modo sensibile.
Il mio primo consiglio quello di fare una scelta oculata perch
mettersi in casa pi di un hypervisor (ad esempio: uno per i
server ed uno diverso per i desktop) una follia dal punto di
vista del management, gestione delle risorse e probabilmente
costi (consulenze, minor potere dacquisto, storage pi
complesso da gestire, ecc.).
11

Juku

Un altro aspetto da considerare, ancora prima di concentrarsi


sulle singole funzionalit dellhypervisor, il supporto tecnico che
si pu ottenere. Supporto tecnico non significa solo numero
verde da chiamare (con dietro qualcuno che risponda in modo
decente e, magari, in italiano) ma anche una comunit attiva
(una ricerca su google pu salvarti la giornata), knowledge base
da consultare, facilit di reperire patch e aggiornamenti di
sicurezza.
Non scender nei dettagli tecnici degli hypervisor
(virtualizzazione, para-virtualizzazione, ecc.): non lobiettivo di
questo documento e vorrei semplificare al massimo la lettura,
quindi mi permetto di azzardare una macro suddivisione degli
hypervisor in 3 macro aree:
senza compromessi
open source-based
Microsoft
Nella prima categoria, senza compromessi, lunico che trova
posto VMware. il primo ad essere nato, il primo in termini
di quote di mercato, quello che ha la maggior sofisticazione
tecnologica, il pi supportato, il pi scalabile e potrei
continuare. Lunico difetto di questo hypervisor il costo di
acquisto (al momento in cui scrivo licenziato per socket max
12 core per socket). Come in tutte le cose per c da dire che
paghi per quello che ottieni: alcune funzionalit esistono solo qui
e soprattutto per i progetti pi sofisticati (es. con problematiche,
12

Virtualizzazione e cloud

anche complesse, di Disaster Recovery o alta affidabilit, fino


alla fault tolerance) lunica via per ottenere un risultato sicuro
ed un TCO basso e predicibile nelle installazioni importanti. Devo
aggiungere, a onor di cronaca, che ultimamente VMware ha
anche messo a listino diverse licenze limitate nelle funzionalit
e con prezzi aggressivi: in questo caso il vantaggio che si pu
partire con una implementazione ritagliata (pi simile anche
come funzionalit a quelle dei concorrenti) per poi,
eventualmente, crescere se sar necessario.
Nella categoria dellopen source based trovano posto
principalmente Xen ed i suoi derivati oltre anche a KVM (spinto
da RedHat). Xen ora di Citrix che per, per motivi sia
commerciali che tecnici, non sembra molto interessata a
spendere troppo in R&D, mentre KVM ha come unico
sostenitore RedHat e non mi ancora capitato di vedere
installazioni in produzione, se non qualche schermata durante gli
eventi di presentazione. Il vantaggio di Xen che costa poco,
performante e open. I difetti primari sono sicuramente
limmaturit, la ruvidit con cui molte funzionalit sono state
implementate (la CLI la fa da padrone) ed il supporto da parte
dei vendor esterni un po carente. I principali utilizzatori di Xen
sono quelli che ne preferiscono laspetto open a tutti gli altri, il
che comprende: smanettoni, service e cloud provider, ambienti
accademici ed in generale tutti quelli che hanno pochi soldi e
molto tempo a disposizione. Gli utenti Xen devono avere cultura
e tempo da spendere per il supporto superiori alla media, oltre a
molta buona volont. Xen comunque alla base delle
13

Juku

piattaforme Cloud e VPS pi importanti in circolazione (es.:


Amazon, rackspace).
Infine c la categoria che ho definito Microsoft. Lhypervisor di
casa Microsoft si chiama Hyper-V. Microsoft partita in enorme
ritardo (fallendo un paio di colpi in precedenza) ma lultima
incarnazione del suo Hypervisor inizia ad essere interessante ed
sicuramente uno dei player per un progetto di virtualizzazione
in azienda (almeno per lSMB). Il prodotto Microsoft limitato se
comparato a VMware ma sta crescendo molto bene, la base
installata cresce velocemente, il supporto dai vendor non
manca. Se un utente ha una infrastruttura basata principalmente
su prodotti Microsoft, non troppo grande, Hyper-V potrebbe
essere una scelta valida. Il costo, anche nella sua versione pi
completa, non elevato e garantisce gi un set di funzionalit di
tutto rispetto. Rimarco il fatto che i migliori risultati con Hyper-V
si ottengono su ambienti Microsoft anche perch il supporto per
altri sistemi operativi decisamente limitato e questo potrebbe
compromettere il processo di virtualizzazione di una infrastruttura
multi vendor.

Management di base
Parlare di management di base nel 2010 quasi ridicolo, infatti
per management di base intendo una console di
amministrazione unica che permetta di gestire pi server fisici e
molti server virtuali. Mi spiego meglio: ogni hypervisor (installato
sul server fisico) pu essere amministrato accedendovi
14

Virtualizzazione e cloud

direttamente, il problema che, in realt, anche il pi piccolo dei


progetti di virtualizzazione prevede un minimo di due server fisici
per garantire alta affidabilit. Dal secondo server in poi devo
avere a disposizione una console di management (ogni
produttore la chiama in modo diverso: vCenter per VMware,
SCVMM per Microsoft, ecc.) che, in alcuni casi, una ulteriore
macchina virtuale. La console di management serve per fare
praticamente tutto: interagire con lHW, creare, modificare e
amministrare le VM, schedulare ogni tipo di attivit, gestire gli
aggiornamenti dellinfrastruttura, gestire lalta affidabilit,
reporting, insomma tutto. La console di management, a parte
casi particolari (es.: quella di Citrix pu gestire anche Hyper-V)
strettamente legata al suo hypervisor, linterfaccia grafica
dellinfrastruttura da virtualizzare ed bene valutarla insieme ad
ogni altra caratteristica dellambiente che si sta progettando.

15

Juku

La connettivit
Il primo aspetto da tenere sempre bene a mente che i server
virtuali sono allinterno di diversi, a volte molti, server fisici e che,
a loro volta, sono collegati ad uno storage ed a un network: il
tutto a formare un cluster. Questa affermazione meno banale di
quanto si possa pensare: la connettivit va dimensionata
correttamente ed necessario prevedere ed analizzare molti
particolari come le latenze per laccesso allo storage e alla
comunicazione fra i nodi, il throughput necessario, leventuale
scalabilit del network, la ridondanza, un adeguato backend e
un frontend allaltezza della aspettative. Se vero che molto di
quanto detto si pu sottovalutare in progetti di minore
importanza, diventa fondamentale quando i numeri si fanno
anche solo mediamente importanti, per non creare colli di
bottiglia tali da compromettere seriamente le prestazioni e
loperativit dellintero cluster.

In passato dovevano essere tenute in considerazione le esigenze


di connettivit di un singolo sistema operativo / applicazione, e
16

Virtualizzazione e cloud

nella grande maggioranza dei casi la dotazione HW standard


della macchina (le classiche 2 interfacce gigabit ethernet + 2
porte fibre channel) era pi che sufficiente, oggi con le densit
raggiunte dalle piattaforme di virtualizzazione (nei casi di
deployment VDI si parla anche di 6/8 VM per core) la connettivit
uno dei punti focali, questo mette in luce alcuni side-effects:
proliferazione di NIC/HBA e cavi (es.: separazione fisica
delle reti e ridondanza)
complessit di gestione (trunking, network management,
troubleshooting difficoltoso)
limitazioni dei nodi (pochi slot PCI, poche porte ethernet a
disposizione, ecc.)
Per rimediare a questi aspetti negativi lindustria si attrezzata
cercando di unificare il pi possibile la parte di networking
tradizionale e, nelle ultime incarnazioni, di inglobare anche la
parte di connessione verso lo storage. Ladozione di una rete
ethernet a 10Gb/s pu ridurre drasticamente il numero di
connessioni necessarie fino a 2 (pi per motivi di ridondanza che
altro) e, attraverso strumenti e protocolli moderni (VLAN, Virtual
Switches, QoS, etc), possibile comunque separare in maniera
semplice e relativamente sicura tutto il traffico. Sicuramente la
modalit di trasporto oggi pi diffusa (e probabilmente rimarr)
lethernet, resta aperta la scelta tra i protocolli di pi alto livello
deputati alla comunicazione lato storage: FC, FCoE, iSCSI, NFS
sono tutti protocolli validi e supportati. La scelta su come e

17

Juku

quando usarli dipende dalla dimensione dellinfrastruttura, dal


tipo di storage, dallarchitettura che si sceglie di adottare e,
molto, anche dai costi. Lunica nota che mi sento di aggiungere
a quanto detto su quello che viene normalmente chiamato
converged networking riguarda Infiniband. Infiniband una
tecnologia di connessione molto efficiente e performante
(attualmente la sua versione QDR arriva fino a 40Gb/s)
caratterizzata da una bassissima latenza ed adottata
principalmente in ambienti HPC (High Performance Computing)
sotto molti punti di vista decisamente migliore dellEthernet,
ma supportata da pochissimi nomi dellindustria (a parte uno
tutti nomi di secondaria importanza), le installazioni sono poche
ed i prodotti decisamente costosi.

I server
Uno dei grandi vantaggi che ha portato la virtualizzazione, in
termini di costi e funzionalit hardware, la reciproca rincorsa
che (gli unici due) produttori di CPU per server X86 hanno fatto
negli ultimi anni. Io sono un forte sostenitore dellhardware
standard e ormai, fortunatamente, tutta lindustria sta andando
in quella direzione. Non ha pi senso per nessuno, se non per
AMD ed Intel, sviluppare CPU, chipset o altre componenti
particolari per i server. Tutti i produttori montano le stesse CPU,
la stessa RAM, gli stessi chipset, le stesse schede PCI, gli stessi
controller RAID, stesse porte ethernet in server delle medesime
dimensioni, con gli stessi consumi e via dicendo! Insomma, I
18

Virtualizzazione e cloud

server sono tutti uguali. Dell, HP, IBM Fujitsu hanno


caratteristiche decisamente confrontabili e non portano nessun
valore aggiunto sensibile. La differenza nella scelta di un vendor
piuttosto che un altro la possono fare: il livello del servizio di
assistenza, il prezzo o la simpatia per il rivenditore e poco pi.
Certo, sempre preferibile sposare un unico vendor alla volta
per avere una certa omogeneit nellhardware da gestire e un
solo numero da chiamare per lassistenza ma vero anche che
non necessario legarsi per la vita ad un unico fornitore.

La cosa pi importante nella scelta dellhardware non la velocit


della CPU (a parte casi particolari) ma la quantit di RAM,
sempre pi probabile trovare nodi a corto di RAM piuttosto che
con poche risorse di CPU ed per questo che, quando si valuta
lhardware, necessario prendere in considerazione i server pi
espandibili in questo senso.
Il discorso server si complica un pochino se linfrastruttura
complessa. In questo caso, spesso, si preferiscono soluzioni pi

19

Juku

dense basate su piattaforme blade. I blade sono particolari


server montati su chassis (non standard) che hanno diversi
vantaggi: compattezza fisica, interconnessione fra le blade
integrata ed un unico punto di management del sistema. il server
blade, in passato, aveva dei seri problemi di espandibilit del
singolo nodo, ma le ultime generazioni (di tutti i server vendor)
hanno un po sfatato questo mito. Gli innegabili vantaggi dati da
una migliore gestione complessiva, un notevole risparmio di
corrente elettrica e, prosaicamente, da un minor numero di cavi,
si pagano con un pi forte legame con il vendor. Nel campo
delle blade esistono anche delle soluzioni di particolare
eccellenza che integrano una parte di virtualizzazione
dellhardware molto utile se usata correttamente ma che
purtroppo non sono alla portata di tutti.

Lo storage
Tutti gli storage (certificati) funzionano. Il problema, poi, non pi
il fatto che uno storage funzioni o meno ma tutto si riconduce
allefficienza! Efficienza significa principalmente: automazione,
integrazione, facilit duso, funzionalit avanzate.
Non esiste una soluzione uguale per tutti e i produttori offrono
soluzioni che vanno da una banale scatola di dischi con
controller RAID senza funzionalit, a sistemi complessi che
implementano in hardware molte funzionalit altrimenti delegate
agli strati superiori, ovviamente anche i prezzi sono molto diversi
e tutto dipende da come lazienda valuta il rapporto tra TCA e
20

Virtualizzazione e cloud

TCO (costo di acquisto contro costo totale nel tempo


compresa la gestione).
Quando si effettua la scelta per la soluzione di storage pi
indicata al proprio progetto di virtualizzazione, bene tenere a
mente che si avr a che fare con problematiche diverse da
quelle cui si era abituati a vedere in precedenza: prima, ogni
server ospitava un S.O. e una applicazione con il suo set di dati
su un disco/volume specifico ora, molto probabilmente, ogni
server fisico ospiter decine di VM con relativi S.O., Applicazioni
e dati: i workload e le necessit di throughput si complicheranno
notevolmente. Pi linfrastruttura complessa e critica e
maggiore sar il bisogno di strumenti che permettono di isolare e
monitorare ogni parametro dello storage.
Unaltro fattore fondamentale dello storage la scalabilit,
acquistare un sistema troppo ritagliato per le esigenze attuali e
poco espandibile pu facilmente generare spiacevoli sorprese
(anche nel breve periodo). I produttori di hypervisor mettono a
disposizione dei vendor alcune API per integrare al meglio lo
storage con gli strati superiori, il primo passo verso lintegrazione
passa proprio da qui: se lhardware e lo storage sanno
vicendevolmente con chi hanno a che fare molto probabile che
alcune funzionalit verranno delegate allhardware sottostante
limitando inutili sprechi di risorse di calcolo e memoria e
velocizzando di molto le operazioni.
Molti storage vendor hanno poi realizzato dei plug-in per le
console di management in modo da rendere pi semplice (in
21

Juku

alcuni casi quasi trasparente) lamministrazione, il (self-)


provisioning ed il monitoring dello storage da parte degli
amministratori, rendendo cos la console dellhypervisor il punto
centrale di amministrazione di tutta linfrastruttura. Ultimo, ma
dovrebbe essere sempre il primo, pi ancora delle funzionalit,
il supporto tecnico. indispensabile che il sistema di storage
che adottiamo per la nostra infrastruttura sia proattivo e avvisi
prontamente chi di dovere (in molti casi anche il vendor stesso)
di un possibile guasto o di una deriva particolare sul fronte
prestazioni o uso di spazio.
Per ottenere uninfrastruttura virtuale efficiente sempre
fondamentale fare un progetto che preveda una analisi
dettagliata di tutto quanto gi in opera allinterno del
datacenter. Nessun aspetto deve essere sottovalutato:
networking e sicurezza, storage, risorse di calcolo e memoria,
applicazioni, sistemi operativi, processi, ecc. Sottovalutare
anche uno solo degli aspetti menzionati, e progettare una nuova
infrastruttura virtuale meno efficiente e performante della
precedente, sarebbe un fallimento poco raccomandabile a
chiunque.

Gli stack
Molti produttori spingono per ladozione di stack tecnologici
preconfigurati o, perlomeno, pre-certificati. Lo fanno
principalmente per tre motivi:

22

Virtualizzazione e cloud

Commercialmente molto meglio (per il vendor) perch


possono vendere un pacchetto di hardware (in alcuni casi
hardware + software + servizi) molto pi importante e quindi
guadagnare di pi.
molto pi facile nascondere le pecche di una singola
componente dellinfrastruttura in una offerta globale: il
cliente compra la soluzione e non indaga particolarmente
a fondo su cosa c dentro
Si riesce ad incatenare molto meglio il cliente con una
soluzione chiusa da cui non avr via di scampo per i futuri
aggiornamenti.
Questo approccio ha comunque degli aspetti positivi dovuti alla
semplificazione: un unico numero da chiamare, un unico
referente commerciale, una teorica
omogeneit nella documentazione,
nella qualit del servizio e nei tempi
di risposta del supporto.
Affidarsi ad uno stack tecnologico da
un unico fornitore pu essere una
ottima soluzione quando laspetto
tecnico del progetto meno
importante di quello organizzativo e
magari lazienda non ha risorse
u m a n e a d e g u a t e p e r g e s t i re
infrastrutture tecnologiche
complesse o una cultura aziendale
23

Juku

sufficiente a prendere decisioni di questo tipo. bene


comunque fare molta attenzione sulla differenza che passa fra
uno stack tecnologico integrato e una offerta completa ma di
tutte componenti separate e disaggregate. Lesempio classico
quello dellassistenza: posso telefonare ad un unico numero che
vede il mio stack come una unit? Oppure devo specificare gi
alla prima chiamata su quale dei vari strati dello stack penso di
avere il problema? E se poi ho sbagliato? Succede come con il
gioco delloca: riparti dal via!

24

Virtualizzazione e cloud

Virtualizziamo
Da fisico a virtuale
Il processo per passare da fisico a virtuale non banale. Certo,
esistono casi abbastanza fortunati, soprattutto nelle infrastrutture
piccole e/o poco critiche, dove questa attivit si pu fare con
grande tranquillit e magari anche per tentativi successivi ma,
nella grande maggioranza dei casi, non ci si possono permettere
errori e tempi lunghi di migrazione.

Lesperienza ed il buon senso insegnano che bene migrare


prima tutte le macchine meno influenti per la produzione
(sviluppo e test in primis) per poi passare a quelle di produzione
meno critiche e infine a quelle mission critical. Lapproccio
descritto permette di iniziare con calmae rodare linfrastruttura:
testare gli strumenti di management, impostare le prime
schedulazioni (backup, snapshots, ecc.), fare le prime attivit di

25

Juku

tuning e le opportune verifiche. Lattivit di migrazione pu


durare anche molti mesi e coinvolgere tutta lazienda (non solo
chi fisicamente deve migrare i server ma anche poi chi dovr
fruire dei servizi, chi si occupa della sicurezza, ecc.).
Esistono diversi metodi per migrare da fisico a virtuale, in alcuni
casi (sempre pi rari) necessario ricostruire il server da zero, reinstallare tutti i software e migrare i dati (un po come si farebbe
per una migrazione da fisico a fisico). Lo standard nelle
migrazioni fisico-virtuale comunque quello di utilizzare alcuni
tool specifici, spesso messi a disposizione dal fornitore
dellhypervisor, che consentono, con pochi click, di clonare il
contenuto di un server fisico in un server virtuale in poco tempo
e con la ragionevole certezza di fornire gli stessi identici servizi,
da una macchina virtuale, causando il minor disservizio
possibile. da una macchina virtuale con un disservizio minimo.
Ad onor di cronaca posso aggiungere che, alcuni fornitori di
soluzioni terze parti, hanno sviluppato nel tempo dei tool molto
sofisticati che permettono migrazioni da fisico a virtuale (ma
anche da virtuale a virtuale e da virtuale a fisico) su piattaforme
differenti, questi tool hanno il grande vantaggio di poter operare
su ambienti multivendor con ununica interfaccia e possono
essere una soluzione in ambienti molto complessi.

I rischi della virtualizzazione selvaggia


Dopo i primi passi nel mondo della virtualizzazione capita spesso
di assistere ad una ubriacatura di tutto lIT (e parte del
26

Virtualizzazione e cloud

management) che pu portare a risultati spiacevoli nel medio/


lungo periodo. Quello che in gergo viene definito VM sprawl
un fenomeno abbastanza diffuso e si pu tradurre in una
crescita spropositata e scomposta del numero e della qualit
delle macchine virtuali allinterno dellinfrastruttura.
Purtroppo, al contrario di quanto succede per le risorse fisiche,
tutto quanto riguarda il virtuale si pu allocare anche
virtualmente! Questo significa che se parte un nuovo progetto
non dovr fare una richiesta per nuove risorse (es.: server e
storage) che, normalmente, soggetta ad un gli stessi identici
servizi, da una macchina virtuale, causando il lungo processo,
dalla validazione allapprovvigionamento, porta con s ma
semplicemente le attiver sulla mia infrastruttura virtuale. Una
pratica di questo genere, ne va ad inficiare molte altre di corrette
e consolidate e si inizia a sottovalutare il capacity planning ed i
costi indotti dallaccensione di queste VM (licenze, tempo,
management, backup, ecc.). Con landare del tempo c il
rischio concreto di perdere di vista il capitolo TCO
dellinfrastruttura e di innescare una rincorsa affannosa a
sostenere le richieste di una infrastruttura di cui si perso il
controllo.
Nel tempo, ho vissuto direttamente situazioni del tipo: progetto
di virtualizzare 155 server e risultato di oltre 350 VM nel giro di
pochi mesi dalladozione dellinfrastruttura (lamentandosi poi che
il tutto non era adeguato alle aspettative!): scoperto che
virtualizzare era facile i vari manager iniziarono a chiedere VM di

27

Juku

dimensioni assurde in termini di CPU, RAM e disco, anche pi di


quanto realmente necessario! Certo, questo un caso limite che
poi si risolse cambiando alcuni processi aziendali, ma sono cose
che possono succedere. Gli aspetti legati al capacity planning e
alluso delle risorse decisamente pi importante ora di prima e
uno strumento di reportistica, spesso integrato con la console di
amministrazione, fondamentale per tener traccia del consumo
di risorse ed avere modo di reagire prontamente alle richieste
dellazienda.

Virtualizzazione e Consolidamento
Durante il processo di virtualizzazione non dovrebbe essere mai
dimenticato un aspetto altrettanto fondamentale: il
consolidamento. La proliferazione di sistemi allinterno del
datacenter porta con se dei costi importanti legati al
management dei sistemi. Ogni server che viene acceso (sia
fisico che virtuale) deve essere gestito, aggiornato, manutenuto,
backuppato e cos via. Quando possibile, sarebbe sempre
buona norma cercare di consolidare pi server in uno o pochi
(ad es. pi server SQL in uno solo). Il consolidamento pu
permettere di razionalizzare anche gli acquisti di licenze software
oltre a consolidare alcuni tipi di workload omogenei,
semplificando sensibilmente tutte le attivit legate al
performance tuning e facilitando il raggiungimento degli standard
di servizio prefissati.

28

Virtualizzazione e cloud

Capacity Planning
Come gi spiegato nel paragrafo precedente, esiste il rischio di
proliferazione incontrollata delle virtual machines in azienda (il
cosiddetto "vm sprawl").

Questo fenomeno da evitare con cura in quanto costringe le


infrastrutture a dei ratio di consolidamento per cui non sono
state disegnate, il classico esempio quello dellinfrastruttura
che viene disegnata per ospitare 150 virtual machines con
determinate configurazioni e finisce per averne 300. Questo
fenomeno purtroppo contrastabile solo ed esclusivamente
tramite il polso duro dellIT manager che deve sapere quali e
dove sono i limiti della sua infrastruttura, ed evitare di trovarsi in
spiacevoli impasse quando, ad esempio, linfrastruttura non
riesce pi a garantire un livello di alta affidabilit per colpa delle
troppe risorse occupate (e vi assicuro che uno scenario, ahim
molto comune).

29

Juku

Per alleviare questo lavoro di stima delle potenzialit (o delle


necessit) di una infrastruttura virtuale (quello che gli inglesi
chiamano guesswork) esistono diversi strumenti di Capacity
Planning.
Questi strumenti ci aiutano a capire quali sono le potenzialit
ancora inespresse della nostra infrastruttura, come, ad esempio,
quante altre nuove virtual machines potr ospitare, senza
incorrere in problemi di overcommitment, e soprattutto ci
possono aiutare quando dobbiamo pianificare una nuova
virtualizzazione, per capire quanto e quale hardware ci pu
servire per supportare, ad esempio, una nuova applicazione da
virtualizzare. E sempre molto importante pianificare la crescita
dellinfrastruttura poich le risorse sono finite.

Chargeback
Uno dei grandi problemi che i dipartimenti IT incontrano quando
devono espandere le infrastrutture virtuali quello di giustificare
le spese.
Il meccanismo di chargeback , a mio avviso, il modo pi
efficiente per giustificare gli investimenti nella infrastruttura IT.
Il chargeback un meccanismo di billing in realt molto antico,
nasce con i primi sistemi di time-sharing multiutente che, dato
lalto costo, venivano fatti pagare ad ora-CPU. Questo
meccanismo si poi un po perso nel cosiddetto periodo del

30

Virtualizzazione e cloud

distributed computing in quanto tanti server eterogenei fra loro


erano pi difficili da gestire in fatto di singolo costo CPU, RAM o
disco, mentre gli hypervisor di nuova generazione ci offrono un
layer standardizzato (tutte le cpu, ram e disco virtuali sono
standardizzate in ciascun hypervisor) su cui possibile effettuare
il conteggio del billing proprio come si faceva nei mainframe.
Ci sono poi delle situazioni in cui fare il vero e proprio charge
non possibile, ma nessuno ci vieta di fare anche solo lo
showback e cio far vedere allazienda quanto costa tenere
attiva una macchina virtuale con certe caratteristiche e quindi
pianificare gli investimenti di conseguenza. La consapevolezza
pu essere unarma fortissima nelle mani degli IT manager:
mostrare un grafico al management (o anche alla propriet) su
come viene sfruttato il budget pu essere di grande aiuto per
richiedere eventuali nuovi investimenti.
Inoltre, il chargeback/showback, un passo fondamentale per la
strada verso il Cloud, sia esso Privato o Ibrido, ed infatti un
preludio allultimo argomento trattato in questo documento.

Cloud
Il viaggio verso il Private Cloud non pu certamente essere
affrontato in un paragrafo solo, richiede una pi ampia
digressione.

31

Juku

Si tratta di realizzare un vero e proprio tessuto dellIT aziendale


in cui non sono pi n il server, e neppure lapplicazione, al
centro dellobiettivo, bens lo il servizio. Il servizio diventa quindi
il focus dellIT: con questo approccio, ed utilizzando gli strumenti
messi a disposizione dai vendor, possibile creare dei cataloghi
di servizi IT aziendali e rendere le persone che ne devono fruire
autonome al 100%. Mediante tutte le tecnologie menzionate in
questo documento possibile rendere questi servizi accessibili
ed automatizzati, semplificando la vita agli operatori IT, agli
application owner (i gestori delle applicazioni) e soprattutto, agli
utenti finali.

32

Virtualizzazione e cloud

Il Private Cloud
Questo capitolo illustra cosa il Private Cloud di cui molti
parlano e quali / quanti benefici pu portare alla vostra
architettura IT interna.
Se avete letto fino a qui, immagino che tutti voi abbiate in
qualche modo gi implementato una qualche forma di
virtualizzazione nel vostro datacenter, probabilmente utilizzando
VMware, Xen o Hyper-V, se non avete ancora implementato
nessuna di queste tecnologie immagino che a questo punto vi
sarete per lo meno fatti unidea di cosa comporti a livello IT la
loro adozione.
Queste tecnologie appunto, hanno consentito alle aziende una
razionalizzazione a livello fisico molto importante consentendo
cospicui risparmi soprattutto sui consumi elettrici, diretti ed
indiretti (climatizzazione). In alcune aziende, la virtualizzazione ha
guadagnato una fiducia tale che, rotti gli indugi, si iniziato a
virtualizzare anche i workload business-critical e mission-critical.
Questo processo ha consentito di ottenere una certa
padronanza e dimestichezza con lambiente virtuale, tanto da
adottare in alcuni casi una politica di tipo Virtualization First

33

Juku

ovvero considerare ogni nuovo deployment come una macchina


virtuale e non pi come un server fisico.
Raggiunto questo risultato, spesso
si pensa di aver raggiunto il
traguardo del viaggio verso la
virtualizzazione, in realt possiamo
considerarlo lultimo step prima di
arrivare al vero e proprio Private
Cloud o come ad alcuni piace
definirlo IT la carte. Possiamo
suddividere la maturazione della
virtualizzazione in azienda in tre
fasi:

La fase dei Servizi IT in Produzione


Questa fase consiste nella virtualizzazione dei processi
totalmente in mano allIT, come ad esempio i servizi di
infrastruttura: DNS, Active Directory, DHCP, Print Server, Mail
Server ed altri server di servizio.
Per addentrarsi nella prima fase di adozione sufficiente il
sostegno dellIT Manager, non vengono generalmente coinvolte
persone al di fuori dellIT department, il valore aziendale
rappresentato dal risparmio ottenuto nella gestione delle
operazioni (OPEX) e dal risparmio dovuto al mancato acquisto di
nuovo hardware durante i deploy di nuove macchine (CAPEX).
34

Virtualizzazione e cloud

Da qui arriviamo alle funzionalit chiave per questa fase che


sono: il gi menzionato risparmio sui costi, il provisioning molto
rapido (non dobbiamo infatti attendere settimane per ordinare
dellhardware nuovo) e soprattutto si comincia ad instaurare una
certa credibilit e fiducia nei confronti della virtualizzazione
allinterno dellazienda.
La fiducia nella soluzione da considerarsi reattiva in quanto il
reparto IT reagisce ad una esigenza del business come il
rinnovo dellhardware o il necessario consolidamento del
datacenter, in questa fase il team IT comincia a prendere
confidenza con gli strumenti base messi a disposizione dalla
piattaforma di virtualizzazione.

Virtualizzare il Business in Produzione


Ovvero quella che si pu anche chiamare la fase del Quality of
Service, questa fase pu essere considerata la pi critica delle
tre in quanto la virtualizzazione entra nel mondo delle
applicazioni business e missioncritical e quindi il processo di
accettazione diventa pi complesso e coinvolge non pi solo il
reparto IT ma anche gli application owner (quindi i responsabili
delle applicazioni), i quali devono necessariamente dare il proprio
sostegno al processo.
Ottenere il sostegno dagli application owner pi che
fondamentale, le loro aspettative infatti non sono paragonabili a
quelle del gruppo IT (che normalmente sono: consolidamento
35

Juku

server, contenimento dei costi, semplificazione dellinfrastruttura)


sono bens orientate alla disponibilit (HA, Fault Tolerance,
possibilit di DR) ed alle performance, in parole povere:
abbassare il rischio e massimizzare le performance della propria
applicazione.

importante, per un IT department che si avvicina a questa


fase, far capire agli application owner che la virtualizzazione
porta con s una serie di vantaggi impliciti, dati
dallincapsulamento delle applicazioni in entit virtuali, che si
traduce in un immediato ritorno di benefici, come la possibilit di
effettuare manutenzione dellhardware anche durante gli orari di
operativit, utilizzando le tecnologie di live migration.
Al valore aziendale della virtualizzazione si aggiungono la
maggiore disponibilit delle applicazioni, che vengono meglio
protette, ed una reattivit molto pi alta alle esigenze della
produzione, grazie alle tecniche di rapid provisioning, i tempi di
deploy sono praticamente azzerati.

36

Virtualizzazione e cloud

La fiducia in questa fase da considerarsi selettiva visto che


vengono scelte in modo oculato le applicazioni che offrono
meno resistenza alla virtualizzazione, sia per una questione
puramente interna, come il rapporto che c tra il reparto IT e
lapplication owner, sia per questioni, invece, puramente
tecniche, come il supporto della piattaforma di virtualizzazione
da parte del vendor Software. Microsoft ad esempio ha avuto in
passato una politica poco amichevole nei confronti di VMware
che si risolta solo negli ultimi anni con un programma di
certificazione delle soluzioni virtualizzate che ha accontentato
molto i clienti congiunti.
Il raggiungimento di questa fase viene considerato il punto di
rottura, in cui le competenze del reparto IT sono ormai
consolidate e la resistenza degli application owner stata quasi
completamente annullata. E questo il momento in cui
normalmente viene introdotta la gi menzionata Virtualization-first
policy, che apre la strada alladozione massiva della
virtualizzazione allinterno dellazienda, a questo punto le nuove
applicazioni vengono tutte virtualizzate a meno che non ci sia
una difficolt tecnica tale da impedirlo.
Come dicevamo allinizio, questa fase viene considerata da molti
il punto di arrivo del viaggio verso la virtualizzazione ed in effetti
abbiamo gi incontrato un rilevante numero di benefici tramite la
sua adozione, ma qual il passo successivo?

37

Juku

Private Cloud
Lautomazione.
Questa la chiave per conseguire un vero IT-as-a-service:
lautomazione rende possibile lorchestrazione completa di tutti i
componenti e rende il processo IT un vero e proprio servizio ondemand in cui le risorse vengono allocate su richiesta dove e
quando servono.
Per far in modo che il servizio IT si trasformi in un vero Private
Cloud necessario un sostegno ai massimi livelli, direttamente
dal CIO o addirittura dal CEO, mentre la fiducia nella parte di
virtualizzazione deve essere anchessa altissima.
Questo porta a realizzare dei processi aziendali molto
razionalizzati ed incentrati completamente sul servizio e, aspetto
non da poco, ad un innalzamento della qualit della vita per lIT
department che viene sgravato dagli impegni fuori orario che
caratterizzano questa funzione aziendale.
Ma quali e quanti sono i pilastri del Private Cloud? Quelli che
necessariamente una azienda deve adottare per abbracciare
questa filosofia?
Prima di tutto lazienda deve dotarsi di uninfrastruttura
computazionale che sia dinamica e self-managed, significa che
linfrastruttura su cui pogger il nostro Private Cloud dovr
essere realizzata in modo da essere:
Resiliente, quindi garantire un alto livello di disponibilit.
38

Virtualizzazione e cloud

Scalabile, con facilit e senza richiederne la rielaborazione,


linfrastruttura deve essere espandibile con il minimo sforzo.
Virtualizzata, ovviamente una architettura Private Cloud
d e v e e s s e re v i r t u a l i z z a t a , s i a p e r g a r a n t i re l a
standardizzazione della piattaforma di HW virtuale sia per
garantire la trasportabilit verso un eventuale Public Cloud.
Dinamica, deve essere possibile ribilanciare i workload in
modo automatico in base a degli SLA ben precisi e definiti.

Inoltre, come ho gi ribadito, la chiave di volta del Private Cloud


lAutomazione, una vera infrastruttura IT-as-a-service
comprende un motore di provisioning delle applicazioni che
possa farne il deploy ed il ritiro in modo automatizzato
recuperando immediatamente le risorse occupate in
precedenza, deve avere dei meccanismi per schedulare e
riservare le risorse, strumenti per controllare laccesso alle

39

Juku

risorse e delle policy per dichiarare come le risorse possano


essere utilizzate.
Queste capacit creano lagilit necessaria e
contemporaneamente ci danno il necessario controllo
amministrativo, uninfrastruttura di questo tipo un pilastro
fondamentale per il nostro Private Cloud data la natura elastica
dellIT-as-a-service.
Il Cloud computing incentrato al servizio, in forte contrasto al
modello tradizionale che invece incentrato sul sistema, se non
addirittura sul server.
In molti casi, gli utenti del nostro Private Cloud vogliono far girare
un servizio o una applicazione senza dover entrare nel merito
degli aspetti tecnici dellamministrazione di sistema o del
network, preferiscono avere un accesso veloce e semplice ad
una istanza dedicata di un determinato servizio o applicazione;
astraendo la componente server-centrica gli utenti possono
avere accesso ad ambienti predefiniti disegnati specificamente
attorno ai loro servizi.
Un approccio incentrato al servizio conferisce una forte business
agility, pi velocemente vengono compiute queste operazioni,
pi veloce si muover il business riducendo i costi ed
accelerando i processi.
Interagire con il Cloud richiede un certo livello di autonomia degli
utenti, le piattaforme cloud pi evolute danno la possibilit di

40

Virtualizzazione e cloud

costruire, rilasciare, schedulare, gestire e creare dei report sui


servizi del business in modo on-demand.
Linterfaccia di self-service deve essere il pi possibile intuitiva,
per permettere agli utenti di gestire autonomamente tutto il ciclo
di vita del servizio, dal deploy al ritiro.
Il beneficio di questo modello il conferimento di un certo livello
di autorit ed indipendenza agli utenti, in cascata aumenter
l'agilit nella gestione dei processi. Un positivo effetto collaterale
sar il poter delegare tutta una serie di mansioni e task ripetitivi
agli utenti, sgravando il reparto IT che si pu concentrare su
responsabilit pi strategiche e di alto livello.
Infine, il cloud computing guidato dallutilizzo, I consumatori
pagano solamente per le risorse che utilizzano e quindi gli deve
essere applicato un modello di costo a consumo (il cosiddetto
chargeback di cui abbiamo parlato qualche paragrafo pi
indietro). La piattaforma di Private Cloud deve prevedere un
meccanismo per catturare le informazioni di utilizzo e creare una
reportistica per realizzare il chargeback delle risorse utilizzate dai
vari centri di costo dellazienda.
Il valore di questo pilastro : dal lato utente labilit di pagare
solo leffettivo utilizzo, tenendo I costi bassi, dalla parte dellIT
questo modello importante perch permette sempre di
autofinanziare le ulteriori crescite dellinfrastruttura cloud interna.

41

Juku

Conclusioni
Il Cloud un termine molto abusato in questo periodo, oggi
tutto, in qualche modo, viene considerato Cloud, in realt
dietro a questo termine si nasconde una filosofia veramente
rivoluzionaria che potrebbe stravolgere completamente la
concezione dellIT aziendale come lo conosciamo oggi, ma
come tutte le rivoluzioni ci vorranno anni prima che le aziende
capiscano e abbraccino completamente le tematiche discusse in
questa sezione.

42