Amazon Web Services e Windows Azure a confronto

Nei miei post precedenti, ho esaltato le potenzialità del cloud computing ed i vantaggi derivanti ma, nel concreto, come è possibile spostare i servizi sul cloud? O meglio, quale servizio tra quelli disponibili sul mercato è più vantaggioso?
Probabilmente non esiste una sola risposta a questo quesito. Da parte mia ho scelto i servizi Microsoft Windows Azure, ma esistono delle alternative, ognuna con le proprie caratteristiche. Tra queste, ha sicuramente un ruolo importante Amazon Web Services (AWS), il servizio pionieristico di cloud computing erogato da Amazon. In questo post, vorrei approfondire quali sono le differenze principali tra Windows Azure ed Amazon Web Services e raccontarvi quali sono le ragioni per cui, tra i due, ho preferito il primo.
Ovviamente si tratta di un giudizio personale dettato, non solo dalle caratteristiche tecniche dei due servizi, ma anche da considerazioni di tipo strategico/commerciale (time to market, economicità e livello di astrazione della componente infrastrutturale).
La differenza più grande ed evidente tra i servizi di AWS ed Azure sta nel fatto che il primo è una infrastruttura (IaaS) mentre il secondo è una piattaforma (PaaS). Azure usa un approccio ad alto livello nei confronti delle macchine virtuali, queste vengono istanziate e gestite senza nessun intervento diretto dell’utente dal computing service. Amazon Elastic Compute Cloud (EC2), invece, richiede la creazione ed il deployment esplicito delle macchine virtuali, scegliendo l’AMI (Amazon Machine Image) con le caratteristiche desiderate.
Le AMI sono disponibili per i sistemi operativi Red Hat Enterprise Linux, Windows Server 2003, Oracle Enterprise Linux, OpenSolaris, openSUSE, Ubuntu, Fedora, Gentoo e Debian. Sulle macchine virtuali è possibile eseguire database server come Oracle 11g e SQL Server 2005 o server come Apache, IIS, Java Application Server o JBoss Enterprise Application Platform.
D’altro canto Azure, sebbene preveda un unico sistema operativo (Windows Azure Guest OS, basato su Windows Server 2008 a 64 bit) ed un unica tipologia di server web (IIS), permette l’utilizzo, oltre alle tecnologie ed i linguaggi dei framework .NET, di applicazioni sviluppate in PHP, Ruby, Python o Java. A tale scopo sono disponibili gli SDK per Java, PHP, e Ruby ed il plug-in per Eclipse.
La Windows Azure App Fabric offre servizi di calcolo (compute) e simple storage. Un compute service permette di eseguire su Azure applicazioni composte da Web Roles e Worker Roles. I Web Role e Worker role possono essere eseguiti da un numero configurabile di istanze di macchine virtuali scelte fra una delle dimensioni disponibili:

• Small (1 CPU core, 1,7 GB Ram, 250 GB local storage)
• Medium (2 CPU core, 3,5 GB Ram, 500 GB local storage)
• Large (4 CPU core, 7 GB Ram, 1000 GB local storage)
• ExtraLarge (8 CPU core, 14 GB Ram, 2000 GB local storage)

Il Web Role è molto simile ad una web application tradizionale e pertanto viene eseguito su una macchina virtuale che esegue IIS 7. Possono presentarsi come una aplicazione ASP.NET, con file ASPX, codebehind e servizi WCF o applicazioni web sviluppate utilizzando altre tecnologie (ad. es. Ruby). Nel caso di utilizzo di istanze multiple, Windows Azure utilizza automaticamente dei load balancers hardware per ripartire il carico tra le istanze, quindi è imperativo che le applicazioni siano stateless.
Il Worker Role ricorda i servizi Windows. Vengono eseguiti su una macchina virtuale priva di IIS e non possono accettare connessioni dall’esterno. Possono, invece, iniziare delle connessioni verso il mondo esterno per ottenere i dati di input su cui lavorare.

Analogamente ad Amazon EC2 il local storage dei servizi Azure non è persistente e va utilizzato solo per la memorizzazione di informazioni temporanee. Per memorizzare dati persistenti su Amazon, è necessario quindi agganciare all’istanza dell’AMI un volume per lo storage persistente chiamato Elastic Block Store. EBS è praticamente l’analogo del cloud drive su Azure e permette di avere unità a blocchi nelle quali è possibile memorizzare dati in un file system. Come per il CloudDrive di Azure, una unità può essere montata da una sola istanza di macchina virtuale e, di conseguenza, sia L’EBS che il CloudDrive non sono adatti alla memorizzazione di dati condivisi.
Oltre ad EBS Amazon mette a disposizione un servizio per lo storage e la pubblicazione di dati: Amazon Simple Storage Service (S3). S3 è un repository sul cloud che può essere utilizzato per memorizzare informazioni di qualunque dimensione. Così come per gli altri servizi Amazon, sono disponibili dei web service per permettere alle applicazioni di utilizzare S3. I dati sono conservati come oggetti, delle entità contenenti i dati ed i metadati che li descrivono. Un oggetto non può essere più grande di 5 GB. Gli oggetti sono contenuti in buckets, il namespace degli oggetti, e caratterizzato da una chiave, che lo identifica univocamente.

Su Windows Azure si utilizza il servizio di storage, che permette la memorizzazione di dati sotto forma di blob, tabelle e code.
Il blob permette la memorizzazione di testi e dati binari organizzati utilizzando tre risorse: lo storage account, i containers e i blob. Lo storage account è l’entry point del servizio, all’interno del quale è possibile creare dei container, che forniscono un mezzo per organizzare insiemi di blob. Ai blob ed ai container possono essere associati dei metadati sotto forma di coppie chiave/valore. Tutte le operazioni sono effettuate utilizzando una semplice interfaccia REST ed i dati sono manipolati con comuni operazioni HTTP. Ciò permette un accesso semplice, standard e indipendente dalla piattaforma e dai linguaggi utilizzati.
Le code memorizzano messaggi che possono essere letti da qualunque client che ha accesso allo storage account. Una coda può contenere un numero illimitato di messaggi con dimensione massima pari a 8 KB. I messaggi sono normalmente aggiunti alla fine della coda e recuperati dalla cima. Il comportamento FIFO (first in, first out) non è comunque garantito.
Le funzionalità delle code sono simili a quelle offerte da Amazon Simple Queue Service (SQS), il servizio per la memorizzazione affidabile di messaggi per applicazioni realizzate utilizzando EC2 ed S3. Analogamente ad i servizi di storage di Azure, SQS supporta le funzioni di base per la manipolazioni di code e messaggi accessibili con semplici interfacce HTTP GET/POST.
La tabella offre uno storage strutturato sotto forma di tabella. Le tabelle memorizzano i dati sotto forma di collezioni di entità. Le entità sono simili a righe, con una chiave primaria ed un insieme di proprietà sotto forma di coppie nome/valore simili a colonne. A differenza delle tabelle di un database, due entità nella stessa tabella possono avere insiemi differenti di proprietà.

Come si può vedere esiste una forte analogia tra Amazon S3 e lo storage service di Windows Azure, sia dal punto di vista della strutturazione delle informazioni che dal punto di vista dell’utilizzo. Un interessante confronto tra Windows Blob Storage ed Amazon S3 è disponibile su thestoragearchitect.com.

Un’altra differenza sostanziale tra Windows Azure ed Amazon Web Service sta nella disponibilità di un server RDBMS. In Amazon è possibile, ad esempio, di un server Oracle ma è necessaria una attività di amministrazione e gestione. Il servizio Amazon SimpleDB permette di memorizzare, indicizzare e utilizzare query su dati strutturati. Il modello dei dati è semplice: grandi collezioni di item organizzati in domain. Gli item sono delle hash table contenenti attributi sotto forma di coppie chiave/valore. Sebbene gli attributi possano essere ricercati utilizzando query lessicografiche simili a quelle utilizzate in un comune database relazionale (ad es.: select output_list from domain_name [where expression] [sort_instructions] [limit limit]), SimpleDB non è un database relazionale. E’ solo uno storage strutturato distribuito.
Il servizio SQL Azure è un servizio costruito sulla tecnologia su Microsoft SQL Server, che permette di ottenere istanze SQL Server altamente disponibili che possono essere connesse utilizzando le modalità usuali. Non richiede nessuna attività di carattere amministrativo, eccettuata la scelta delle dimensioni ed la configurazione degli account di accesso. L’accesso al database è protetto da un firewall configurabile dal portale http://sql.azure.com che permette di abilitare l’accesso da applicazioni on premises con ADO.NET o ODBC. Rispetto ad una istanza SQL Server 2008 ha delle limitazioni, come la mancanza di SQL Agent (e di tutte le features dipendenti) e la presenza di costrutti non supportati (ad es. SELECT INTO). Le limitazioni, però, non sono tali da rendere complesso l’utilizzo di SQL Azure da parte di applicazioni legacy. In un post futuro vi racconterò della mia esperienza nel porting di una applicazione on premises sul cloud di Azure: con un po’ di attenzione non solo può essere aggirato ogni ostacolo, ma si può approfittare dell’occasione per migliorare l’architettura dell’applicazione.

Windows Azure App Fabric, oltre a rendere disponibili le funzioni fondamentali di calcolo e storage per la costruzione di applicazioni nel cloud, offre anche il Service Bus e l’Access Control. Il Service Bus fornisce l’infrastruttura di rete per connettere le applicazioni attraverso la rete per realizzare il pattern dell’Enterprise Service Bus in modo tale da poter attraversare firewall e dispositivi NAT senza richiedere la ricalibrazione delle politiche di sicurezza. Il criterio di funzionalmento si basa sul concetto di Relay Service. L’applicazione dietro il firewal contatta il Relay Service con una connessione bidirezionale ad un indirizzo di rendezvous. A questo punto le due applicazioni possono comunicare attraverso il Relay Service. Visto che la connessione viene originata da dietro il firewall, non è necessario riconfigurare quest’ultimo. Oltre a fornire il meccanismo di connessione relayed, il Service Bus permette di passare alla connessione diretta per migliorare la velocità di comunicazione. A tale scopo viene utilizzato un algoritmo di predizione delle porte che cerca di identificare quali porte sono aperte sui firewall coinvolti. Utilizzando queste informazioni i client ed i servizi possono tentare una connessione diretta. Nel caso in cui tale connessione non vada a buon fine o non sia realizzabile viene riapplicata la connessione relayed.
L’Access Control permette di applicare in modo semplice il modello di sicurezza claims-based alle comunicazioni del Service Bus. L’approccio utilizza un token di sicurezza SWT che può essere gestito indipendentemente dall’utilizzo del framework .NET (basta poter calcolare il codice di autenticazione hash HMACSHA256. L’interfaccia, tanto per cambiare, è basata su web service REST ed utilizza il protocollo per la richiesta di token di sicurezza WRAP. In sostanza, basta effettuare il POST del nome utente e della password all’indirizzo relativo alla risorsa protetta, per ottenere il token di sicurezza. Questo viene poi passato con tutte le richieste al servizio, finchè non scade.

Per quanto mi risulta, al momento Amazon non fornisce direttamente un servizio analogo al Service Bus e all’Access Control su Amazon. Tali funzionalità sono implementabili con del lavoro aggiuntivo.

Un altro servizio interessante, disponibile sia su AWS che su Azure, è la Content Delivery Network. La CDN permette di distribuire contenuti su scala globale in modo efficiente utilizzando dei nodi che gestiscono una cache locale. Amazon CloudFront è la content delivery network offerta da Amazon che permette di erogare i dati memorizzati in S3 dal datacenter più vicino al punto di utilizzo. I server CloudFront sono presenti in Europa (Regno unito, Irlanda, Olanda e Germania), Asia (Hong Kong, Singapore e Giappone) e nelle maggiori città statunitensi.
La Content Delivery Network di Windows Azure, ultimamente espansa a 20 nodi (distribuiti tra Stati Uniti, Europa, Asia, Australia e Sud America), può essere attivata per ogni account del servizio di storage. All’attivazione viene reso disponibile l’indirizzo di accesso che permette l’accesso attraverso la cache più vicina.

Amazon Elastic MapReduce è un servizio progettato per eseguire task data intensive in un ambiente parallelo, utilizzando istanze EC2 multiple e aggregando i risultati finali che vengono memorizzati su S3. MapReduce utilizza il framework Apache Hadoop, ispirato dalle documentazioni di Google MapReduce e Google File System. Il suo funzionamento è indicato all’esecuzione di operazioni semplici su una quantità molto elevata di dati.

Su Windows Azure non è disponibile un servizio con queste caratteristiche. Per ottenere qualcosa del genere è necessario sviluppare da zero il servizio ed eseguirlo utilizzando più Worker Role.

Come dicevo all’inizio di questo post, la scelta tra AWS ed Azure è dettata da valutazioni che riguardano non solo aspetti puramente tecnici, ma anche strategici e commerciali. Da parte mia ritengo, comunque, che l’approccio ad alto livello di una PaaS sia vantaggioso, soprattutto per un ISV. Non preoccuparsi in alcun modo della componente infrastrutturale permette di focalizzare l’attenzione sul core business. L’attività di deployment si riduce all’upload del package dell’applicazione e della configurazione relativa.
La disponibilità di SQL Azure e del Service Bus permette di rilasciare delle soluzioni ibride con una porzione on premise, anche utilizzando codice legacy, ottime per un passaggio graduale sul cloud. Altro aspetto importante di Windows Azure è l’eccellente supporto fornito agli sviluppatori dai tool per Visual Studio 2010 e la facilità di conversione di una applicazione web in Web Role. L’insieme di queste caratteristiche permette la creazione ed il rilascio di una applicazione per il cloud in tempi brevissimi. In un post precedente, parlando dei vantaggi del cloud, menzionavo la rapidità di prototipazione e time to market. Beh, in questo Azure colpisce in pieno il bersaglio.