Introduzione al Cloud Computing

Capitolo 1
Introduzione al Cloud Computing
Dopo aver completato questo capitolo, sarai in grado di
Q
Sapere la differenza tra IaaS, SaaS, e PaaS.
Q
Capire la strategia seguita da Microsoft per il suo cloud.
Q
Conoscere le basi della Windows Azure Platform.
Questo libro è basato sulla mia personale esperienza maturata studiando, insegnando e sviluppando soluzioni basate sul cloud in grado di sfruttare i vantaggi dei diversi componenti
della piattaforma Windows Azure, vale a dire Windows Azure Compute, Windows Azure
Storage, Windows Azure AppFabric, e SQL Azure. Questo capitolo introduce la filosofia che
sta dietro al cloud computing.
Sull’homepage di Windows Azure (Microsoft Corporation, Windows Azure website, 2011,
http://www.microsoft.com/windowsazure/compute/default.aspx) è possibile leggere:
Microsoft Windows Azure provides a scalable and fault-tolerant environment that
lets developers create powerful applications without the need to purchase and
configure hardware and operating systems. Instead, you can simply rent what you
need following the PaaS (Platform as a Service) model.
Nota Dal momento che URL, nomi e procedure possono cambiare nel tempo, alcuni di questi
potrebbero essere non più aggiornati nel momento in cui ti appresti a leggere il presente libro.
In questo caso, il mio consiglio è di cercare le informazioni relative al prodotto a partire dalla
home page di Windows Azure (http://www.azure.com). Le informazioni contenute in questo
libro erano accurate al momento in cui è stato scritto.
Differenti approcci al Cloud Computing
L’idea di base di qualunque piattaforma cloud è applicare un canone in base all’effettivo
utilizzo della piattaforma, scalando verso l’alto o verso il basso in base alle necessità del
business. I diversi fornitori di cloud computing in genere interpretano questo principio
in modi diversi, fornendo differenti tipologie di servizi per raggiungere questo obiettivo.
Fondamentalmente, esistono tre tipi di approcci al cloud computing: Infrastructure as a
Service (IaaS), Software as a Service (SaaS), e Platform as a Service (PaaS).
1
2
Windows Azure Passo per Passo
Infrastructure as a Service
Alcuni fornitori mettono a disposizione dei clienti l’infrastruttura per realizzare proprie soluzioni, consentendo a questi di noleggiare hardware come server, load balancer, firewall
e cablaggi. Ricade sull’utente il compito di configurare e installare da remoto le proprie
soluzioni. È possibile potenziare l’infrastruttura richiedendo più server o modificando le
politiche di load-balancing, senza per questo dover acquistare nuovo hardware. Allo stesso
modo, in ogni momento è possibile ridimensionare l’infrastruttura noleggiata dal fornitore
di cloud computing. Questo approccio è definito Infrastructure as a Service (IaaS), perché
l’utente può noleggiare l’infrastruttura senza doversi preoccupare di stimare in anticipo i
picchi di massima domanda, ma ricade su quest’ultimo la responsabilità di configurare correttamente l’infrastruttura noleggiata.
Questi sono i punti importanti da ricordare a proposito dell’approccio IaaS:
Q
I livelli più bassi dell’infrastruttura sono gestiti dal fornitore.
Q
Solo pochi fornitori mettono a disposizione dei clienti un sistema operativo. Spetta a
questi ultimi il compito di acquistare, installare e configurare il sistema operativo e le
relative applicazioni.
Q
L’ovvio beneficio che deriva da una IaaS è che questa solleva l’utente dal doversi preoccupare di molti degli aspetti fisici legati all’infrastruttura.
Software as a Service
Un altro approccio possibile è quello di noleggiare il servizio offerto da un fornitore, configurandolo attraverso l’interfaccia messa a disposizione dal fornitore medesimo, senza
per questo dover conoscere i dettagli dell’infrastruttura per veicolare il servizio. Questo
approccio è denominato Software as a Service (SaaS), perché si paga per utilizzare determinati servizi. Ad esempio, Microsoft Exchange Online prevede un costo per ciascuna casella
email utilizzata. Per poter configurare il servizio, è necessario utilizzare un’applicazione web
messa a disposizione del fornitore, mediante la quale è possibile richiedere caselle email,
definirne il nome e le dimensioni. Tutto ciò che l’utente riceve è una password con la quale
è già in grado di accedere alla propria casella email.
Questa interfaccia web ha davvero poco in comune con la versione on-premises di
Microsoft Exchange. In un modello SaaS l’utente non ha il controllo (né la responsabilità)
dell’infrastruttura sulla quale il servizio è installato. Allo stesso modo, non ha il controllo
sul sistema operativo sul quale il servizio gira, né su qualunque altro elemento software, se
non quelli che la stessa interfaccia espone all’utente. In altre parole, spetta al fornitore del
servizio il compito di predisporre tutto ciò che serve per eseguire l’applicazione, isolando
l’utente dai componenti sottostanti.
Capitolo 1
Introduzione al Cloud Computing
3
Platform as a Service
Il terzo tipo di approccio è definito Platform as a Service, o PaaS. In questo approccio,
l’utente noleggia una piattaforma sulla quale effettuare il deploy delle proprie applicazioni
senza dover configurare l’infrastruttura e senza le limitazioni proprie dell’approccio SaaS.
Ecco la definizione offerta da Wikipedia per il PaaS (Wikipedia, Platform as a Service, 2011,
http://en.wikipedia.org/wiki/Platform_as_a_service):
…the delivery of a computing platform and solution stack as a service. PaaS offerings facilitate deployment of applications without the cost and complexity of
buying and managing the underlying hardware and software and provisioning
hosting capabilities, providing all of the facilities required to support the complete
life cycle of building and delivering web applications and services entirely available from the Internet.
PaaS offerings may include facilities for application design, application development, testing, deployment and hosting as well as application services such as team
collaboration, web service integration and marshaling, database integration, security, scalability, storage, persistence, state management, application versioning,
application instrumentation and developer community facilitation. These services
may be provisioned as an integrated solution over the web.
La piattaforma Windows Azure rientra nella definizione di PaaS, dato che non fornisce l’accesso al sottostante ambiente di virtualizzazione o ai dettagli del sistema operativo quali
l’interfaccia di rete, la configurazione degli IP o la gestione dei dischi.
I concetti chiave da ricordare quando si ha a che fare con una PaaS sono i seguenti:
Q
Il fornitore della piattaforma è responsabile di tutto, dalla connettività di rete al
runtime.
Q
Le offerte PaaS riducono il carico di lavoro dello sviluppatore fornendo il runtime della piattaforma e i relativi servizi applicativi.
Q
Gli sviluppatori possono iniziare sin da subito a concentrarsi sulla logica di business
delle loro applicazioni.
Q
PaaS, rispetto alle tradizionali offerte di hosting, mette a disposizione il potenziale per
incrementi significativi nella produttività, dal momento che ricade sul fornitore cloud
il compito di gestire tutti gli aspetti hardware e i dettagli operativi della piattaforma
cloud.
4
Windows Azure Passo per Passo
Cloud Service
La responsabilità dell’utente e del fornitore sono sintetizzate nella seguente immagine:
On-premises
solution
IaaS
PaaS
SaaS
Application
Application
Application
Application
Data
Data
Data
Data
Runtime
Runtime
Runtime
Runtime
Framework
Framework
Framework
Framework
Operating
System
Operating
System
Operating
System
Operating
System
Server
Server
Server
Server
Disk
Disk
Disk
Disk
Network Stack
Network Stack
Network Stack
Network Stack
Come si può vedere, accanto a significative differenze, tutte le variegate offerte nel settore
del cloud prevedono la fornitura di un set di servizi che possono essere noleggiati in modo
da non doversi preoccupare dei livelli sottostanti (presentati in bianco, al di sotto della
linea).
La definizione di cloud computing offerta da Wikipedia è la seguente (Wikipedia, Cloud
Computing, 2011, http://en.wikipedia.org/wiki/Cloud_computing):
Cloud computing is Internet-based computing, whereby shared servers provide
resources, software, and data to computers and other devices on demand, as
with the electricity grid. Cloud computing is a natural evolution of the widespread
adoption of virtualization, service-oriented architecture and utility computing.
Details are abstracted from consumers, who no longer have need for expertise in,
or control over, the technology infrastructure "in the cloud" that supports them.
Cloud computing describes a new supplement, consumption, and delivery model
for IT services based on the Internet, and it typically involves over-the-Internet
provision of dynamically scalable and often virtualized resources. It is a byproduct
and consequence of the ease-of-access to remote computing sites provided by the
Internet. This frequently takes the form of web-based tools or applications that
Capitolo 1
Introduzione al Cloud Computing
5
users can access and use through a web browser as if it were a program installed
locally on their own computer.
Questa definizione mette in luce due importanti aspetti che ricorrono nelle varie offerte:
l’uso di risorse distribuite (IaaS, SaaS, e PaaS) e l’astrazione dello sviluppatore rispetto alle
tecnologie sottostanti. Abbiamo già accennato al primo aspetto. Per quanto riguarda il
secondo aspetto, invece, esso consiste nella possibilità di gestire risorse astratte, come lo
storage distribuito, senza dover conoscere i dettagli tecnici sulla loro configurazione, messa
in sicurezza e distribuzione.
Una prospettiva di lungo termine
Possiamo immaginare un futuro nel quale tutti gli aspetti fisici legati a dati e programmi
siano completamente superflui dal punto di vista dell’utente, ma resta ancora molta strada
da percorrere per raggiungere questo scenario futuristico.
Oggigiorno, un acronimo molto diffuso è SOA (Service Oriented Architecture), un termine
che definisce un “ecosistema” di servizi interconnessi che possono scambiare dati e condividere processi, usando pattern e standard comuni. Un servizio SOA può essere consumato
da applicazioni installate su piattaforme eterogenee, che utilizzano sistemi operativi differenti e si basano su ambienti di programmazione diversi. L’architettura service oriented definisce concetti di interoperabilità che funzionano su sistemi e piattaforme diverse. Ciascun
servizio può essere implementato con approcci e tecnologie differenti, dato che SOA si
limita a definire il modo con cui questi servizi comunicano tra di loro e con le applicazioni
client, dando così agli sviluppatori la libertà di implementare la logica interna nel modo che
desiderano. Per esempio, un servizio implementato in .NET può utilizzare solo altri componenti .NET e API di Windows; questo servizio si presenta come completamente diverso
rispetto ad analoghi servizi sviluppati in Java o Ruby. Ma, per quanto ciascuno di questi
servizi possa internamente utilizzare differenti pattern di comunicazione, essi devono comunque aderire al comune contratto di comunicazione per poter “parlare” con altri servizi
SOA o applicazioni client.
L’evoluzione dei linguaggi, dei sistemi operativi e dei framework già fornisce uno strato di
astrazione rispetto alla piattaforma locale; per esempio, nella maggior parte dei linguaggi
moderni, non c’è più bisogno di gestire la RAM in modo diretto. Al contrario, negli attuali
ambienti basati sul garbage collector, una volta rilasciate le proprie istanze nel modo corretto, è il framework ad occuparsi rilasciare memoria al sistema operativo. Questa astrazione
significa che lo stesso codice può funzionare sul framework Microsoft .NET su un notebook
performante con 8 GB di RAM e in un ambiente Microsoft .NET Compact Framework su un
device con 256 MB of RAM su cui è installato Microsoft Windows CE, e questo nonostante
il garbage collector lavori nei due ambienti in modo decisamente diverso. Non sto dicendo
che lo stesso codice possa funzionare ovunque ma che, per quante siano le differenze tra
Windows e Windows CE, molte di queste sono state rese trasparenti allo sviluppatore dal
.NET Framework.
6
Windows Azure Passo per Passo
I compilatori di oggi consentono di astrarre rispetto al codice macchina. I sistemi operativi,
dal canto loro, aggiungono un livello di astrazione rispetto ai dettagli della memoria, dei
dischi e delle schede grafiche, lasciando ai runtime, come il Common Language Runtime
(CLR) o la Java Virtual Machine (JVM), il compito di gestire i dettagli fisici al posto nostro.
Questo è un ottimo inizio, ma il prossimo passo richiede di rimuovere la dipendenza tra
l’ubicazione fisica di una risorsa e il codice che la utilizza, in modo da creare un sistema
distribuito in cui è possibile effettuare il deploy di applicazioni e servizi, e che consenta di
gestire le risorse in maniera “astratta”. Dal punto di vista del consumatore, l’ubicazione non
è di per sé importante; ciò che conta è ottenere risposte alle proprie richieste in modo veloce e indolore. Dal punto di vista dello sviluppatore, l’obiettivo principale risiede nel potersi
concentrare sulla logica applicativa, piuttosto che doversi confrontare con le particolarità
degli ambienti sottostanti.
Windows Azure come Soluzione PaaS
In una PaaS, non c’è bisogno di conoscere i dettagli tecnici di ciascun componente, né la
differenza tra un hard disk RAID 0 e uno RAID 1. Non occorre pensare alla velocità o alla
capienza dell’hard disk, né se questo è configurato come C o D. È sufficiente chiedere alla
piattaforma dove salvare i propri dati e lasciare tutti i dettagli tecnici dell’operazione alla
piattaforma stessa. La piattaforma Windows Azure nasconde completamente questi dettagli tecnici, mettendo a disposizione le API necessarie per una gestione logica delle risorse.
È sufficiente creare uno storage, dargli un nome e usare l’endpoint fornito dal sistema per
gestire le risorse.
L’idea dietro Windows Azure è quella di fornire un sistema operativo in cui è possibile caricare ed eseguire le proprie applicazioni senza aver a che fare con la classica interfaccia di
Windows. Per esempio, non è necessario copiare i file sul file system di Windows Azure, né
usare la console di gestione di Internet Information Services (IIS) per configurare siti, directory virtuali o application pool. In realtà, non sappiamo neppure se dietro le quinte ci sia IIS.
Se hai bisogno di spazio disco, puoi semplicemente creare uno Storage Account e usare l’endpoint fornitoti dal sistema per gestire le risorse dello storage. Con una PaaS, ogni
volta che devi salvare dati sul cloud puoi dimenticarti dei dischi rigidi, delle storage area
network, e della configurazione dei load balancer. Puoi usare standard quali REST e HTTP
per interagire con questo tipo di storage. Dove sono salvati i file? Semplicemente non hai
bisogno di saperlo. Sto usando i dischi più performanti presenti sul mercato? Non tocca a te
preoccupartene; in una soluzione PaaS tutte le operazioni di gestione del disco (dalla fase
di ordinazione fino alla sostituzione di un disco malfunzionante) ricadono sul fornitore della
piattaforma.
Sulla piattaforma Windows Azure, non è possibile vedere l’ubicazione esatta dello spazio
disco che hai noleggiato, non puoi scegliere l’UPS, il modello o il produttore dei dischi rigidi
o dei server, oppure i tuoi indirizzi IP, né devi preoccuparti dei nomi delle macchine.
In un sistema come questo, ogni accesso a qualsivoglia risorsa consiste in un accesso al relativo servizio. Ciascuna API deve essere esposta come web service.
In pratica, un sistema PaaS è una sorta di “SOA for everything” nel quale l’utente:
Capitolo 1
Introduzione al Cloud Computing
7
Q
Richiede un servizio storage dove salvare i propri file.
Q
Richiede al servizio di storage di cercare uno specifico file.
Q
Richiede al servizio di gestione della piattaforma di aumentare o diminuire la scalabilità sulla base delle proprie immediate esigenze.
Q
Richiede al servizio di storage di creare una nuova cartella.
Q
Il servizio replica alle richieste dell’utente con una risposta che necessita di essere
analizzata.
Conosceremo i dettagli di come questa piattaforma funziona nei prossimi capitoli, ma l’idea
base è riuscire a scrivere un programma, caricarlo da qualche parte ed eseguirlo senza
neppure conoscere l’ubicazione fisica del codice binario o dei dati. Dopo aver pubblicato
la tua applicazione, puoi dimenticartene completamente (a parte dover risolvere eventuali
bug!), perché sarà la piattaforma stessa a provvedere alla sua gestione. In particolare, la
piattaforma:
Q
Applica le patch non appena queste vengono rese disponibili.
Q
Replica dati e runtime in modo da garantire fault-tolerance e load balancing.
Q
Gestisce i dischi e il resto dell’hardware. Per esempio, se un disco subisce un guasto,
il sistema usa immediatamente una replica senza che sia necessario alcun intervento
da parte dell’utente e senza che questo neppure si accorga del malfunzionamento del
disco.
Q
Se la quantità di dati aumenta, il sistema alloca automaticamente più dischi e riconfigura il load balancer senza alcun downtime.
Q
Se l’applicazione smette di funzionare, il sistema la riavvia automaticamente.
Q
Se è necessario maggiore capacità computazionale, l’utente può richiederla in qualunque momento, o addirittura automatizzare questa procedura, come vedremo nei
prossimi capitoli
Q
Se la macchina assegnata all’applicazione dell’utente smette di rispondere, il servizio
viene automaticamente spostato in una nuova macchina, senza alcun intervento da
parte dell’utente.
Grandi opportunità per piccole aziende
La mia personale opinione è che il cloud computing – e in particolare la piattaforma
Windows Azure — rappresenta una grande opportunità per qualunque organizzazione, e
un’opportunità incredibile per le piccole software house. Senza una piattaforma o un’infrastruttura di cloud computing, una piccola azienda non potrebbe competere con società più
grandi quando si tratta di sviluppare applicazioni destinate a servire migliaia di utenti contemporaneamente, per il semplice motivo che le sue capacità d’investimento nell’acquisto
di hardware sono limitate.
Una piccola azienda dovrebbe tenere conto di molteplici aspetti quando progetta una nuova soluzione, come un sito di e-commerce, un’applicazione di advertising o un’applicazione
finanziaria per il web. Tra gli aspetti più importanti da considerare vanno annoverati non
8
Windows Azure Passo per Passo
soltanto i costi iniziali, ma anche i costi necessari ad assumere personale qualificato per
configurare e manutenere, quantomeno:
Q
Server web per la produzione e lo staging
Q
Un database cluster
Q
Router e load balancer
Q
Firewall e sicurezza
In aggiunta, vanno considerati i costi fissi per la banda richiesta dall’applicazione, così come
i costi delle licenze del software. E questo investimento non può essere certo limitato a soddisfare le esigenze iniziali. L’azienda deve infatti comprare sin dall’inizio un numero di web
server sufficiente a offrire una soluzione fault-tolerant per la propria applicazione a partire
già dal primo deployment. I danni collaterali conseguenti a un fallimento possono essere
persino più costosi dell’investimento iniziale necessario ad evitare tali situazioni.
A parte i costi iniziali, spesso proibitivi, per sviluppare un’applicazione, una piccola azienda necessita di trovare persone altamente competenti per configurare i server nel modo
più appropriato ed efficiente possibile. Spesso, queste competenze devono essere cercate
all’esterno dell’azienda stessa, il che significa costi addizionali nelle fasi iniziali del progetto.
Il ricorso a personale esterno può inoltre porre molteplici problemi se qualcosa va storto
una volta raggiunta la fase di produzione, dal momento che il personale dell’azienda può
avere poca o nessuna dimestichezza del sistema. Inoltre, assumere nuovo personale (o
formare quello già presente) per avere le competenze richieste può costringere l’azienda a
posporre la data di rilascio, con conseguente ulteriore lievitazione dei costi.
Ammettiamo infine che, nonostante tutti questi sforzi iniziali, l’azienda riesca a mettere in
produzione (o vendere) l’applicazione e che gli utenti comincino a usarla. Se il numero di
utenti cresce, l’azienda sarà costretta a comprare e configurare nuovo hardware, riconfigurando l’intero sistema grazie al personale appena assunto o a consulenti esterni. Questo
può rappresentare un grande problema quando l’applicazione ha successo e il numero di
utenti cresce troppo in fretta. Anche se i ricavi derivanti dall’applicazione sono maggiori di
quanto ci si aspettasse, malfunzionamenti hardware e altri problemi sono dietro l’angolo
(come insegna del resto la Legge di Murphy: “Se qualcosa può andare storto, sicuramente
lo farà”).
D’altro canto, una grande azienda potrebbe avere le competenze necessarie a sviluppare
un ambiente fault-tolerant in grado di gestire eventi simili e, in questo caso, ogni problema potrebbe essere risolto dal personale interno in un ragionevole lasso di tempo. Ma se
la società si è avvalsa di consulenze esterne, dovrà comunque spendere ulteriori soldi per
risolvere il problema, una volta che questo si sia manifestato, senza contare il fatto che i
tempi per l’intervento si allungherebbero notevolmente. Normalmente, le piccole aziende
tendono a spendere meno per i servizi esterni, comprando direttamente ciò che ritengono
sarà necessario allo sviluppo e alla distribuzione dell’applicazione, spesso sottovalutando
l’inesorabilità della Legge di Murphy. Dall’altro lato, però, se il numero di utenti non dovesse raggiungere le previsioni, l’azienda avrà già sprecato una considerevole somma per
acquistare hardware in eccesso rispetto agli effettivi bisogni.
Se l’azienda dispone di un dipartimento marketing particolarmente efficace, potrebbe lanciare una campagna pubblicitaria per spingere la propria applicazione o servizio. In genere,
Capitolo 1
Introduzione al Cloud Computing
9
questo tipo di campagne prevedono un periodo di prova del prodotto per i nuovi utenti.
Dal punto di vista del marketing, questa rappresenta una buona pratica, ma può condurre
a drammatici picchi nel traffico durante o immediatamente dopo il lancio pubblicitario.
Questo conduce a due ordini di problemi:
Q
Il rischio che i clienti già esistenti rivogliano i loro soldi indietro a causa della ridotta
qualità del servizio
Q
Il rischio che gli utenti che stanno provando l’applicazione non acquistino un servizio
percepito come lento e inefficiente
Se l’applicazione di cui parliamo è un sito di e-commerce, potete immaginare i problemi
che nascerebbero in una situazione simile. I clienti esistenti comincerebbero a sperimentare
latenza durante le loro visite al sito, mentre i nuovi utenti vedrebbero un sito assai poco
performante. La soluzione più semplice in casi del genere, almeno dal punto di vista tecnico, sarebbe quella di incrementare il livello dell’hardware in concomitanza con il lancio della campagna pubblicitaria, ma in realtà i costi necessari rendono spesso questo approccio
poco praticabile.
C’è poi un ulteriore elemento da tenere in considerazione. Un gran numero di applicazioni
prima o poi devono fare i conti con quello che si definisce “peak time”. Per esempio, le visite
ad un sito di e-commerce tendono ad aumentare durante le vacanze o prima della stagione estiva, oppure quando un nuovo prodotto è lanciato sul mercato, o quando si apre una
nuova stagione di moda. Analogamente, un’applicazione finanziaria genera normalmente
più traffico verso la fine del mese o dell’anno fiscale, mentre un’applicazione dedicata al
turismo e ai viaggi presenta picchi di traffico prima delle vacanze. Persino un’applicazione
interna all’azienda presenta picchi di maggiore traffico in genere verso la fine del mese,
quando molteplici attività devono essere portate a termine (buste paga, consuntivo delle
ferie, ecc.)
Se un’applicazione o un sito web di un’azienda sperimenta differenti livelli di carico nel
corso del mese o dell’anno, ma questa ha optato per un modello di costi fissi, esiste un’intrinseca incongruità, dal momento che per la maggior parte del tempo l’azienda è costretta
a pagare per più di quanto effettivamente necessiti, solo per poter fronteggiare i picchi di
traffico. Questo senza voler considerare il caso peggiore, in cui l’applicazione o il sito web
della nostra ipotetica azienda si rivelino degli insuccessi, con conseguente perdita degli investimenti iniziali in hardware e licenze.
Al contrario, grazie all’impiego di soluzioni cloud, anche una piccola azienda è in grado di
iniziare la propria attività con uno sforzo contenuto e un costo minimo. Ecco quali sono i
principali vantaggi derivanti dall’utilizzo di un’infrastruttura cloud-based:
Q
Nessun costo iniziale per i web server.
Q
Nessun costo fisso per la connettività di rete.
Q
Non è richiesta alcuna abilità particolare per l’installazione dei server.
Q
Nessun costo iniziale per i cluster di database.
Q
Le competenze richieste per la configurazione di un cluster di database non sono
necessarie.
Q
Nessun router o load balancer da acquistare o configurare.
10
Windows Azure Passo per Passo
Q
Nessun firewall o software di sicurezza da comprare o configurare.
Q
Non è richiesta alcuna competenza specifica per la messa in sicurezza del sistema
sottostante.
Q
Nessun costo per l’ambiente di staging.
Q
Nessuna licenza da comprare.
Come questo elenco rivela, tutti gli sforzi iniziali solitamente richiesti da una soluzione onpremises sono bypassati completamente. Si inizia a pagare solo nel momento in cui viene
pubblicata la soluzione, e anche in quel caso è possibile aggiustare (incrementandoli o diminuendoli) la capacità computazionale e lo spazio di storage praticamente in tempo reale
per adeguarli alle effettive necessità. Inoltre, nel caso in cui il progetto si riveli improduttivo, si può smettere in qualunque momento di pagare.
Grandi opportunità per grandi aziende
I vantaggi del cloud computing appena descritti si applicano ovviamente anche alle grandi
aziende, ma con alcune differenze, quali ad esempio:
Q
Le grandi aziende generalmente dispongono di team appositamente dedicati all’IT e
che probabilmente dispongono già delle competenze richieste per installare, configurare e manutenere un sistema di livello enterprise.
Q
Questi team sono in grado di gestire i differenti aspetti di una soluzione moderna, dai
problemi di sicurezza alla performance della rete sino alle politiche di installazione.
Q
Lo stesso team può essere utilizzato in differenti progetti, riducendo il costo marginale di una soluzione.
Q
Team di grandi dimensioni dispongono in genere di procedure fault-tolerant e di persone appositamente preposte a rispondere ad eventuali avvisi di malfunzionamento.
Q
Le grandi aziende solitamente avviano un nuovo progetto di business utilizzando
macchine che già possiedono e che possono soddisfare il carico iniziale.
È importante ricordare, però, che le soluzioni on-premises comunque incorrono in costi variabili nel corso del tempo: dai costi dell’energia elettrica, agli stipendi del personale IT, fino
al noleggio della connettività.
Altre questioni riguardano tanto le grandi quanto le piccole e medie aziende:
Q
Configurare uno stesso server affinché possa soddisfare le necessità di progetti completamente diversi può rivelarsi problematico. Per esempio, un progetto potrebbe
richiedere una configurazione incompatibile con quella richiesta da un altro.
Q
Possono verificarsi problemi di scalabilità quando più applicazioni condividono gli
stessi componenti.
Da un punto di vista strettamente tecnico, usare server e infrastrutture differenti per ciascuna applicazione sarebbe la soluzione ideale, ma ciò avrebbe un impatto notevole sui
costi complessivi. In un’infrastruttura di tipo cloud, tuttavia, i responsabili IT possono tenere
separate le applicazioni e i servizi sia dal punto di vista logico che fisico, senza dover acquistare l’hardware necessario in anticipo.
Capitolo 1
Introduzione al Cloud Computing
11
Nella mia esperienza di consulente, uno dei maggiori problemi che il cloud computing
deve affrontare nelle grandi organizzazioni è dato dalla variabilità dei costi fatturati. Molte
organizzazioni preferiscono allocare una somma fissa per ciascun progetto, piuttosto che
assumersi il rischio di avere costi variabili.
Le aziende dovrebbero modificare il loro approccio al cloud computing. Questo non dovrebbe rappresentare un grosso ostacolo, poiché sono già stati compiuti salti analoghi negli
ultimi vent’anni in molti campi della vita economica e personale. Ecco alcuni esempi:
Q
Le compagnie telefoniche hanno cambiato più volte il loro sistema di fatturazione. Ricordo che nella mia infanzia esisteva una sola modalità di tariffazione, ossia
una tariffa mensile con costi fissi per ciascuna chiamata. Oggigiorno il consumatore
può scegliere tra centinaia di offerte e piani tariffari, sia personali che business. Il sistema di tariffazione del cloud è molto simile, potendo passare da un costo fisso per
funzionalità predeterminate, a una tariffa totalmente variabile.
Q
In molti paesi, un sempre maggior numero di persone vive in affitto. Acquistare
una casa può essere un buon investimento, ma a differenza degli immobili l’hardware
non acquista valore col passare del tempo. Molte compagnie non possiedono l’immobile dove hanno i loro uffici. Quando hanno un problema, possono chiedere assistenza al proprietario. Sul cloud avviene qualcosa del genere: problemi e patch ricadono
sulle spalle del proprietario dell’infrastruttura, non su colui che la usa.
Q
Molte aziende noleggiano auto per i loro impiegati, piuttosto che comprarle. Il
noleggio ha tipicamente costi fissi, almeno entro limiti ragionevoli nell’utilizzo (relativi, ad esempio, al chilometraggio). Si paga di più soltanto se si superano questi limiti.
Il cloud computing è essenzialmente la stessa cosa di un noleggio. Si paga una tariffa
fissa e si accettano alcune limitazioni (ad esempio sulla banda e sullo storage), e solo
se si eccedono queste limitazioni si pagano tariffe maggiorate.
Q
Molte aziende già noleggiano hardware come personal computer, notebook e
server. Un po’ come avviene su una piattaforma cloud, solo che questa include anche la banda, i router, i firewall e così via.
È importante sottolineare come, nel cloud, l’hardware non è sostituito solo quando si verifica un problema (come quando in casa propria si rompe improvvisamente un tubo dell’acqua), ma anche quando nuovi modelli diventano disponibili. Il servizio di fornitura elettrica
è un altro buon esempio di come il cloud funzioni. Quando nuove apparecchiature si rendono disponibili sul mercato, come ad esempio un nuovo tipo di contatore, non spetta al
consumatore sostituire il vecchio apparecchio con il nuovo. Ad esempio, nel 2004 il mio
contatore è stato sostituito con un nuovo modello dotato di connessione remota e di un
display a LED, senza che per questo abbia dovuto pagare alcunché. I relativi costi sono stati
assorbiti nelle fatture che già stavo pagando alla compagnia elettrica. Allo stesso modo,
non è necessario pagare quando Microsoft installa nuovi firewall o router in un Windows
Azure data center.
Il cloud computing incide anche sui sistemi open source, dal momento che i consumatori
non devono pagare alcuna licenza: il costo delle licenze è infatti incluso nelle tariffe di noleggio del cloud. In una soluzione on-premises, i sostenitori dell’open source asseriscono
che uno dei principali vantaggi nell’uso di sistemi operativi open source rispetto a un sistema Windows consiste nel non dover pagare i costi delle relative licenze. Nel cloud, questa
12
Windows Azure Passo per Passo
affermazione semplicemente non trova applicazione, visto che gli utenti pagano per il
sistema nel suo complesso, inclusi server e altro hardware, oltre che la connessione di rete.
Un utente può scegliere la piattaforma di cloud che preferisce e comparare i relativi prezzi
senza doversi preoccupare dei costi delle licenze.
Windows Azure e il Cloud Computing
Windows Azure è un sistema operativo per il cloud (e ospitato nel cloud) che opera una
completa astrazione rispetto ai componenti fisici del sistema: l’utente deve soltanto scegliere le caratteristiche del servizio, i componenti e i livelli di Service Level Agreement (SLA)
senza dover configurare alcun hardware o software. Per garantire la scalabilità e la faulttolerance, i dati immagazzinati in Windows Azure vengono replicati in tre nodi e il load
balancer lavora in modo del tutto trasparente. Al momento in cui scrivo queste pagine, per
quanto riguarda la capacità computazionale l’utente può scegliere tra una varietà di macchine virtuali che si differenziano sulla base dei seguenti componenti:
Q
CPU È possibile variare da un singolo processore a 1 GHz fino a un processore a 8
core, per chi intende sfruttare il parallelismo verticale.
Q
RAM Può variare da 768 MB fino a 8 GB. Non è possibile scegliere né il produttore,
né la velocità, né altre caratteristiche.
Q
Lo spazio disco locale Parte da 20 GB e può arrivare fino a 2 Terabyte per ciascuna
istanza. Non è necessario scegliere la velocità, il controller, o il tipo di ridondanza.
Q
I/O performance
elevata.
La scelta è elementare e include tre opzioni: bassa, moderata o
I costi di noleggio possono includere alcune o tutte queste caratteristiche. Quando l’utente
eccede questi limiti, il sistema di fatturazione comincia ad aggiungere costi aggiuntivi. In
cinque minuti, è possibile avere il proprio servizio o applicazione su Windows Azure perfettamente funzionante.
Se c’è bisogno di scalare verso l’alto, si può decidere di incrementare il numero di macchine
utilizzate semplicemente da un file di configurazione e nel giro di cinque minuti, le macchine aggiuntive saranno perfettamente operative. Allo stesso modo, se si vuole diminuire la
capacità computazionale, è possibile ridurre il numero di macchine in un istante e il sistema
di fatturazione cesserà di conteggiare immediatamente le macchine dismesse.
È anche possibile cambiare le dimensioni delle macchine in qualunque momento; in questo
caso, però, occorrerà attendere un po’ più a lungo prima di riavviare il servizio, perché il
sistema ha bisogno di effettuare un nuovo deploy dell’applicazione. Questo tipo di operazioni in genere richiede circa cinque minuti, trascorsi i quali l’applicazione è di nuovo in
esecuzione in nuove istanze su nuove macchine.
I costi sono dunque proporzionali alla configurazione scelta ma, e questo è importante, la
configurazione può essere cambiata in ogni momento sulla base delle esigenze.
Ogni aspetto tecnico del deployment ricade tra le responsabilità di Microsoft. Per fortuna,
nessuno conosce Microsoft Windows Server 2008 SP2 (il sistema operativo su cui Windows
Azure è al momento basato) meglio della stessa Microsoft, così come nessuno meglio di
Capitolo 1
Introduzione al Cloud Computing
13
Microsoft conosce il funzionamento interno del .NET Framework, il kernel del sistema operativo, i componenti di Internet Information Services, SQL Server, e così via.
Analogamente, nessuno può applicare patch su funzionalità o su aspetti legati alla sicurezza più rapidamente di Microsoft. Anche se un amministratore di sistema controllasse le
newsletter o i feed 24 ore al giorno, sarebbe comunque solo dopo che Microsoft li ha già
installati automaticamente sulla piattaforma Windows Azure non appena disponibili.
Su Windows Azure, il deployment di ogni applicazione avviene seguendo un modello che
descrive i bisogni dell’applicazione stessa. Lo sviluppatore può richiedere una certa quantità di spazio disco, e Windows Azure provvederà automaticamente. Ciò detto, non è però
possibile richiedere un particolare controllo SCSI (Small Computer System Interface), piuttosto che una configurazione RAID 5 (che, peraltro, sul cloud sarebbe il più delle volte inutile). L’unica cosa che occorre fare è assicurare che l’applicazione disponga di spazio disco
sufficiente. Una volta che, grazie alla scalabilità e alla ridondanza dell’ambiente cloud, hai
raggiunto i livelli di performance richiesti dalla tua applicazione, non c’è alcun bisogno di
conoscere i dettagli di funzionamento interno della piattaforma. Non c’è insomma nessun
valore aggiunto nel conoscere il tipo di dischi su cui l’applicazione gira (oltretutto, questo ci
evita i rischi derivanti dall’aver scelto i dischi sbagliati!).
Windows Azure nasconde molti dei dettagli che troviamo su una soluzione on-premises.
Ogni risorsa è esposta come servizio (ad esempio, il servizio di storage account per la gestione dei file) utilizzando protocolli standard. Tutti i dettagli dello storage sono resi completamente trasparenti agli sviluppatori, su qualunque piattaforma. Le risorse fisiche sono
esposte dall’infrastruttura come servizio, così che lo sviluppatore non abbia bisogno di scrivere codice specifico per quella risorsa in modo da dover gestire dettagli come:
Q
L’ubicazione fisica delle risorse
Q
Gli hard disk installati sulla macchina
Q
Il nome dei server
Q
Il percorso di rete
Q
IIS virtual directory
Q
Indirizzi IP delle macchine
Allo stesso modo, gli sviluppatori .NET generalmente non hanno bisogno di sapere come il
garbage collector (GC) funzioni internamente; tutto ciò di cui hanno bisogno è sapere come
rilasciare gli oggetti in un modo appropriato, così che il garbage collector possa svolgere il
proprio lavoro nel modo più efficiente possibile. Non hanno bisogno di specificare al garbage collector quando avviarsi per pulire la memoria, e nella maggior parte dei casi sarebbe controproducente lasciare allo sviluppatore un simile compito. Analogamente, nel cloud
la conoscenza dei dettagli interni del servizio di storage locale non è importante, mentre è
fondamentale sapere come aprire e chiudere i file correttamente.
Per raggiungere una risorsa remota l’applicazione deve chiamare il servizio che espone la
risorsa stessa. Dal punto di vista tecnico, si usa l’URI del servizio per inserire, aggiornare o
cancellare una risorsa, mentre si utilizza il pattern OData REST per le query al servizio aventi
per oggetto le risorse esistenti (come liste, filtri, ordinamenti, paginazione, ecc.).
14
Windows Azure Passo per Passo
Questo di solito solleva una domanda: il codice che ho scritto girerà bene su Windows
Azure? La risposta è: dipende. Se abbiamo sviluppato l’applicazione nel modo opportuno,
disaccoppiandola dalle dipendenze e separando le funzionalità in layer appropriati, è probabile che, con pochi o nessun cambiamento, l’applicazione girerà altrettanto bene (o persino meglio) sul cloud (se è necessario salvare file in uno storage condiviso, tuttavia, alcuni
adattamenti del codice saranno comunque necessari).
Al contrario, se il codice è monolitico ovvero non è stato fatto adeguato uso delle tecniche
di programmazione orientate agli oggetti (object-oriented programming techniques) o, peggio ancora, vi trovate di fronte a un caso di “spaghetti code” che mischia elementi di user
interface con logica business o di accesso ai dati, è verosimile che l’applicazione necessiti
di un pò di lavoro per funzionare con un differente tipo di storage. Comunque, in genere
quando un’applicazione funziona con SQL Server, è probabile che possa essere portata su
Windows Azure e SQL Azure con minime variazioni.
Se hai scelto di utilizzare il servizio di storage di Windows Azure piuttosto che SQL Azure
come servizio di storage per la tua applicazione, e hai ben strutturato la tua soluzione in
layer, puoi sostituire il tuo attuale livello di accesso ai dati con uno nuovo (o adattare quello
già esistente). Il servizio di storage espone le risorse come servizio OData usando lo stesso
pattern di Windows Communication Foundation (WCF) Data Services nel .NET Framework
4.0 (in precedenza conosciuto nel .NET 3.5 come ADO.NET Data Services). Se hai scelto
questo tipo di tecnica di accesso ai dati per la tua soluzione client on-premises, hai soltanto bisogno di adattare il codice in modo da utilizzare il modello di sicurezza esposto da
Windows Azure e il gioco è fatto.
Nei prossimi capitoli, esploreremo i vari servizi e le diverse caratteristiche esposte dall’intera piattaforma Windows Azure. Cominceremo con una descrizione completa delle varie
feature della piattaforma, sia di quelle rilasciate che di quelle annunciate, dopodiché cominceremo a scrivere codice nell’ambiente locale simulato, per arrivare ad effettuare il deploy
del codice su un’istanza nel cloud. Vedremo come usare il servizio di storage in modo efficiente, e come lavorare con OData e WCF Data Services. Gli ultimi capitoli sono dedicati a
SQL Azure e a Windows Azure AppFabric, che rappresentano al momento i due principali
componenti costruiti sopra Windows Azure.
L’ultimo capitolo è dedicato ad un semplice esempio che impiega tecniche di OOP e pattern
per disaccoppiare la user interface e il livello business dai componenti di accesso ai dati.
Riepilogo
In questo capitolo abbiamo visto una breve introduzione al cloud computing, a cominciare
dai principi basilari fino ad una sintetica introduzione alla strategia seguita da Microsoft per
il cloud. Abbiamo visto alcuni dei principi comuni e delle teorie dietro questa nuova ondata
nell’industria informatica.