Nel 2008 Microsoft fa il suo ingresso nel mondo del Cloud Computing, ma invece di presentare una infrastruttura cloud, come ci si poteva aspettare all'epoca, rilascia una piattaforma (PaaS - Platform as a Service) composta da diversi componenti.
Windows Azure è il primo componente di questa piattaforma, il sistema operativo, che governa il runtime delle applicazioni, ne cura il deployment sulle macchine, reagisce a eventuali problemi hardware e, soprattutto espone potenza di calcolo (intesa come istanze di macchine virtuali e fisiche) e spazio di memorizzazione (storage) per tabelle, blob, messaggi in code e dischi virtuali.
L'idea è fornire il supporto per per ospitare applicazioni di qualunque livello, da semplici siti web ospitati sui loro server (vedremo più avanti che il termine server è riduttivo), fino ad applicazioni enterprise ad altrà affidabilità e scalabilità, che possono sfruttare meccanismi di queueing per disaccopiare il front-end dal back-end.
La definizione di Cloud Computing riportata da Wikipedia è la seguente:
«In informatica, con il termine cloud computing si intende un insieme di tecnologie informatiche che permettono l'utilizzo di risorse (storage, CPU) distribuite. La caratteristica principale di tale approccio è di rendere disponibili all'utilizzatore tali risorse come se fossero implementate da sistemi (server o periferiche personali) "standard". L'implementazione effettiva delle risorse non è definita in modo dettagliato; anzi l'idea è proprio che l'implementazione sia un insieme eterogeneo e distribuito - the cloud, in inglese nuvola - di risorse le cui caratteristiche non sono note all'utilizzatore»
Questa definizione, anche se non chiarissima ad una prima lettura, mette in luce due aspetti importanti:
- Utilizzo di risorse distribuite, si riferisce alle possibilità offerte dalla piattaforma di distribuire le risorse su dispositivi virtuali al fine di garantire alta affidabilità e alta scalabilità.
- Risorse le cui caratteristiche non sono note all'utilizzatore, questo concetto si riferisce a caratteristiche fisiche che non solo non sono note all'utilizzatore finale della soluzione (di norma anche con sistemi on-premises l'utente finale ignora le caratteristiche fisiche dei server su cui è ospitata l'applicazione), ma non sono note neanche allo sviluppatore della soluzione stessa.
L'aspetto più interessante del cloud computing e in particolare della piattaforma Microsoft, è proprio l'indipendenza dalle risorse fisiche.
Ad esempio, possiamo descrivere l'applicazione tramite un apposito modello e chiedere alla piattaforma dello spazio disco locale per eseguire delle elaborazioni temporanee, ma senza preoccuparci di dove la piattaforma decide di creare questo spazio: tramite le API di sistema potremmo domandare a Windows Azure dove ha creato questo spazio per recuperare la root del nostro file system.
Allo stesso modo possiamo creare uno store condiviso ed esposto via REST/HTTP (prende il nome di Storage Account e sarà analizzato all'interno di questa guida dal punto di vista dei vari linguaggi utilizzabili) ricevendo dalla piattaforma un URI a cui effettuare le richieste: non è importante sapere che dietro le quinte i dati vengano poi salvati in un disco a stato solido di una particolare marca, piuttosto che organizzati su due dischi in RAID 1, oppure ancora replicati su due macchine, l'importante, per l'applicazione e per lo sviluppatore della soluzione è che lo storage sia performante, scalabile e fault-tolerant. Ci liberiamo di tutti i "problemi fisici" e l'astrazione consente di dedicarci a quello che sappiamo fare meglio: lo sviluppo dell'applicazione.
Possiamo fare un parallelo fra lo sviluppo tradizionale rispetto lo sviluppo cloud e lo sviluppo degli anni 80/90 rispetto all'era dei servizi del 90/2000. Nel tempo si è passati da uno sviluppo "locale" e monolitico ad uno sviluppo a componenti per poi passare esposizione di funzionalità tramite servizi. L'acronimo oggi in voga è SOA (Service Oriented Architecture), che già definisce un ecosistema di servizi interconnessi tra loro e fruibili anche da applicazioni che interagiscono con un utente finale. Questo tipo di architetture definisce un concetto di interoperabilità tra sistemi anche diversi(1).
Ciascun servizio, però, al suo interno è implementato su un sistema specifico, in un certo linguaggio, con un particolare hardware e sistema operativo. I componenti al suo interno comunicano tra loro utilizzando, il più delle volte, uno standard che non è lo stesso usato per l'infrastruttura "SOA". Per fare un esempio, il modo in cui i componenti .NET dialogano tra loro all'interno di un'applicazione è diverso da ciò che avviene tra componenti scritti in Java o usando COM. Tutti, però, possono aderire a dei contratti di comunicazione che ne garantiscano la reciproca interoperabilità.
L'evoluzione dei linguaggi, dei sistemi operativi e dei framework nel tempo ha reso sempre meno importanti molti dettagli della piattaforma necessaria all'esecuzione di un programma:
- I compilatori di linguaggi evoluti permettono di non conoscere la specificità del codice macchina di ciascun processore.
- I sistemi operativi consentono di generalizzare, condividere e semplificare l'accesso alle risorse logiche e fisiche.
- Grazie ai runtime (come JVM e CLR) possiamo "ignorare" i sistemi operativi sottostanti.
- Il cloud rappresenta l'indipendenza dalla locazione fisica delle risorse.
A cosa porta tutto questo? All'idea di avere un sistema operativo distribuito su cui eseguire le proprie applicazioni. Con il termine distribuito non si intende solo l'idea di avere un'esecuzione di codice divisa tra più processori, magari su server diversi.
Il concetto di sistema operativo distribuito è applicabile a tutte le risorse tipicamente controllate dal sistema operativo (CPU, memoria, I/O e quindi storage e comunicazione con altri processi).
Attenzione, perché non è così importante che dal punto di vista implementativo si scelga la strada di avere un unico sistema monolitico (che utilizza contemporaneamente tante CPU e tanti dischi su tanti server fisicamente dislocati in posti diversi) piuttosto che quella di creare un sistema distribuito in una logica "peer-to-peer", dove ogni nodo partecipa al sistema complessivo ma senza una struttura gerarchica predefinita. Queste scelte sono dettagli implementativi.
Dal punto di vista del fruitore di un sistema simile (il nostro programma o servizio) l'importante è poter richiedere l'esecuzione di una certa operazione richiedendo determinati livelli di servizio (utenti concorrenti, tempi di risposta, spazio di memorizzazione, ecc.). Se queste richieste sono soddisfatte, il fatto che siano ottenute con l'uso di un unico enorme mainframe o con una rete di piccoli server può essere irrilevante.
Il Cloud Computing e Windows Azure
Il cloud computing, in questi ultimi anni, sta prendendo sempre più piede non solo nelle grandi realtà che possono usufruire di un abbattimento dei costi a volte "esponenziale", ma anche nelle piccole realtà dove il costo di tenere un server, ad esempio in uno studio di un commercialista, è elevato, non tanto per l'acquisto iniziale, quanto nella sua manutenzione nel tempo, senza contare le probabili interruzioni del servizi per problemi software/hardware, il rinnovo del parco macchine, l'ammortamento in contabilità delle stesse, le licenze e così via.
Windows Azure è invece un sistema operativo nato per il cloud che rende la scelta delle caratteristiche necessarie a garantire un determinato livello di servizio qualcosa di molto più semplice.
Rispetto all'esempio precedente, per un servizio è necessario scegliere il numero di istanze parallele di cui si ha bisogno: il numero delle istanze è configurabile nel tempo, adattando le prestazioni al crescere o dimunuire delle richieste o dei dati. Stesso discorso si applica allo spazio sullo storage: lo spazio disponibile (sono, per default, 100 TB...avete letto bene...100 TB per ogni storage account) viene ripartito su diversi nodi per garantire contemporaneamente scalabilità e fault-tolerance in modo completamene trasparente per lo sviluppatore e l'applicazione e, cosa più importante in scenari piccoli, si paga solo per l'effettivo utilizzo.
SQL Azure
Esiste poi una versione cloud di SQL Server, denominata SQL Azure, che espone sul cloud il mondo relazionale del motore di SQL Server. SQL Azure è accessibile in modo tradizionale utilizzando ADO.NET oppure ODBC sia da applicazioni ospitate su Windows Azure, sia da applicazioni che, per qualunque ragione, restano in casa dell'utente finale, sia da applicazioni mobile in giro per il pianeta.
Anche nel caso di SQL Server non dobbiamo preoccuparci della manutenzione ordinaria (aggiornamenti e patch) e straordinaria (riavvio dei servizi, sostituzione hardware, ecc.) in quanto il tutto ci viene offerto sotto forma di servizi che comprendono il ciclo di vita completo del prodotto.
Non ci dobbiamo neanche preoccupare delle licenze: sulla piattaforma Microsoft, paghiamo un canone mensile in base all'utilizzo del servizio senza preoccuparci delle licenze, ne del sistema operativo (che tra l'altro nel caso di SQL Azure è completamente nascosto dietro le quinte), ne dello stesso SQL Server.
Nell'aprile 2012, periodo in cui scriviamo queste pagine, con poco più di 3 Euro al mese si può utilizzare un database da 100MB sulla piattaforma cloud che, internamente replica i dati su tre nodi per garantire fault-tolerance: in pratica con 40 Euro l'anno otteniamo un servizio per ospitare i nostri dati relazionali su un cluster a 3 nodi senza nessuna necessità di tenere sotto controllo ne l'hardware ne il sistema operativo, ne lo stesso SQL dal punto di vista del funzionamento, dell'aggiornamento delle componenti: il tutto è "always on" e sempre disponbile.
Come avremo modo di vedere nelle sezioni dedicate ai vari linguaggi è possibile utilizzare l'ambiente di sviluppo a noi più vicino sia per creare il codice delle applicazioni da ospitare su Windows Azure, sia per accedere ai database ospitati su SQL Azure.
Lo stesso discorso si applica ai servizi esposti da AppFabric che avremo modo di analizzare nel corso della guida.
Gli Autori
Roberto Brunetti e Daniele Midi fanno parte dello staff di ThinkAhead, azienda del gruppo DevLeap specializzata nello sviluppo Web e Cloud. Roberto ha scritto due libri su Windows Azure di cui uno direttamente per Microsoft Press. Daniele ha all'attivo numerose applicazioni Web 2.0 che sfruttano la piattaforma cloud di Microsoft. Entrambi tengono seminari e conferenze sull'argomento e hanno realizzato il sito www.dotnetcampus.it, conferenza su .NET, interamente basato su Windows Azure.
