I Quaderni del Cloud : Cosa è la piattaforma Windows Azure

Artikkeli
09/13/2010

Dopo alcuni post introduttivi dei Quaderni del Cloud sul Cloud Computing oggi ci soffermiamo sulla piattaforma Windows Azure.

Azure Services Platform, è la piattaforma di Public cloud computing con cui le aziende possono realizzare soluzioni applicative e servizi “in the cloud” ad uso interno o verso clienti e business partners. La realizzazione delle applicazioni avviene tramite gli stessi strumenti e framework utilizzati per lo sviluppo del software on-premises sfruttando quindi il know-how già presente in azienda e garantendo un’ integrazione completa con i processi di software factory già implementati e testati da anni.

Ma vediamo nel dettaglio di cosa si tratta :

Cosa è Windows Azure Platform?

Ripartendo dalla tassonomia (IaaS, PaaS e SaaS) riassunta nel mio post precedente Cloud Mini-serie : Cosa è il Cloud Computing la piattaforma Windows Azure rappresenta il layer PaaS (Platform as a Service) all’interno della strategia di Cloud Computing di Microsoft.

Windows Azure Platform, essendo una Platform as a Service rappresenta l’ambiente ideale per sviluppare, eseguire e gestire le proprie applicazioni o servizi in the cloud indipendentemente dalla tecnologia e dai framework di sviluppo. Su Windows Azure Platform è infatti possibile sviluppare in .NET, JAVA, PHP, Ruby, e persino in C++ come scrissi anche sul mio post sull’interoperabilità nel cloud.Sul sito Interoperability Bridge potete scaricare gli SDK e le estensioni per gli ambienti di svuluppo diversi da .NET).

La piattaforma Windows Azure è a sua volta composta da 3 elementi :

Windows Azure : il sistema operativo per il Cloud che permette alle applicazioni di girare e fornisce potenza computazionale, storage, hosting e funzioni di management.
Microsoft SQL Azure : il database relazionale per il Cloud.
Windows Azure AppFabric : l’insieme di servizi di infrastruttura applicativa per l’Identity Management e la connettività.

Quindi, con Windows Azure Platform, siamo in grado di gestire cloud storage (relazionali e flat) e di sviluppare applicazioni nel cloud facilmente integrabili con altri servizi e/o applicazioni sia on-premises che in the cloud.

Ma quali sono le differenze con il modello tradizionale (on-premises)?

Per rispondere a questa domanda ripensiamo a cosa abbiamo fatto per decenni (e stiamo ancora facendo) :

Abbiamo acquistato hardware e software per far girare le nostre applicazioni occupandoci di tutti gli aspetti di manutenzione e gestione della nostra server farm. Ci siamo fatti carico di tutti quegli aspetti di configurazione a basso valore aggiunto quali networking, routing, scalabilità, reliability e manageability che i nostri committenti danno SEMPRE per scontato e che incidono pesantemente sia nel budget sia nel lavoro quotidiano dei tecnici IT.

Ecco, questo è l’ambito (o meglio uno degli ambiti) in cui Window Azure Platform entra in gioco :

fornire una piattaforma per l’esecuzione delle nostre applicazioni che ci garantisca una corretta esecuzione di tutte quelle operazioni a basso valore aggiunto permettendoci di concentrarci maggiormente sulle questioni legate al nostro business.

In questo modo, avremo un ambiente, completamente gestito da esperti in ogni singolo aspetto (dalla sicurezza al networking alle operations) che lavorerà per noi. Bello no? Vediamo come...

Windows Azure

Windows Azure è un sistema operativo per il Cloud e come ogni sistema operativo che si rispetti fornisce potenza computazionale, sistemi di comunicazioni (asincroni), storage di base, management e servizi avanzati di virtualizzazione. Infatti questi le macro aree di Windows Azure :

Compute
Storage
Management
Hosting

Compute

Ambiente virtualizzato basato su Windows Server che permette l’esecuzione delle applicazioni (hosted services). Gli Hosted Services a loro volta possono essere composti da 1 o più roles. Attualmente Windows Azure gestisce due tipi di roles : Worker Role e Web Role.

Il Worker Role è il ruolo dedicato alla business logic, all’esecuzione dei così detti long-running tasks ma soprattutto è il ruolo non visibile all’esterno, dove non è richiesta interazione con l’utente.
Tecnicamente il worker role è un’istanza virtuale che Windows Azure può usare per far girare qualsiasi componente di piattaforma come ad esempio IIS o Apache TomCat. E’ su questo componente che si interviene quando si vuole avere un Web Server diverso da IIS.

Il Web Role, viceversa, è il ruolo dedicato all’interazione con l’esterno dove potrà girare la nostra user interface e Web Services esposti verso Internet/Intranet.

Tecnicamente può essere considerato un caso particolare del worker Role dove IIS è attivato di default.

Ogni VM role è fisicamente una macchina virtuale (scusate il gioco di parole :-)). Esistono diversi “tagli” di VM disponibilie tra cui scegliere (con costi diversi):

maggiori info qui.

Storage

Ad oggiè l’insieme di 4 servizi fault-tolerance e high-availability per lo storage di dati strutturati e destrutturati: Table, Blob, Code, Drives. I servizi di storage sono indipendenti dagli hosted services ed accedibili tramite REST-based API permettendo quindi l’accesso da parte di qualsiasi client HTTP (.NET, JAVA, PHP, Ruby, ...). Per accedere ai servizi di storage è necessario avere uno storage account (sempre tramite il portale di Windwos Azure) il quale permette di gestire fino a 100 Terabytes di dati. Ad ogni modo è possibile creare quanti storage account si vuole. Ma vediamo nel dettaglio i 4 elementi:

Table : storage a tabelle-proprietà-entità. In questa modalità non viene implementato nessun tipo di struttura relazionale e schema. La particolarità di questa struttura di storage è la scalabilità .Con questo modello si possono raggiungere volumi di dati enormi senza perdere in performance; volumi che i modelli relazionali non sono in grado di supportare.
L’accesso alle tabelle può avvenire tramite i WCF Data Services (sviluppatori .NET) oppure tramite endpoint REST. Ogni SDK fornisce varie API più ad alto livello di REST.

Blob : I blob rappresentano lo storage per dati binari quali immagini, video, documenti. Uno storage account può contenere n containers all’interno dei quali possono essere salvati un numero arbitrario di blob. La struttura dei blob è flat anche se in alcuni casi può sembrare l’opposto. Ad esempio la risorsa

https://myaccount.blob.core.windows.net/Brescia/Laghi/LagodiGarda.jpg

può sembrare che la risorsa LagodiGarda.jpg sia all’interno di folder o sottostrutture Brescia e Laghi mentre in realtà Brescia è il nome del container e Laghi/LagodiGarda.jpg è il nome della risorsa. Inoltre, i Blob (e i container) possono contenere anche i metadati per le risorse ospitate.

Windows Azure fornisce la tecnologia CDN (Content Delivery Network) per una efficace distribuzione geografica dei blob in relazione alla posizione delle applicazioni. Ad esempio se una certa risorsa viene acceduta primariamente in ASIA e in US tale risorsa viene automaticamente spostata nelle due aree geografiche. Le funzioni di CDN devono però essere abilitate appositamente ed hanno una fee a parte. Maggiori informazioni sulle CDN a breve tramite i prossimi annunci che faremo.

Queue : A differenze dei sistemi precedenti orientati allo store di dati le Queue hanno il compito di fornire pattern asincroni per la comunicazione tra web role e worker role. Le Queue forniscono un meccanismo di persistenza asincrona per messaggi che possono arrivare fino a 8K.

Anche in questo caso lo sviluppo lo si può fare tramite le API REST a basso livello oppure tramite delle API che forniscono un certo livello di astrazione fornite dagli SDK.

Drives : I Windows Azure Drives sono dei virtual HD creati come particolari blob (page blob) formattati in NTFS. Il pattern più comune nell’uso dei Drives è il caricamento in read-write da parte di un role (Web o Worker role) che può creare dei snapshot che possono essere caricati simultaneamente da altri role.

I Drives tornano molto utili, ad esempio, nella prima migrazione su Windows Azure di quelle applicazioni che fanno largo uso di accesso al file system locale.

Management

Le funzioni di Management di Windows Azure permettono ai programmatori e agli architetti di infrastruttura di definire e monitorare lo stato di salute della propria applicazione. Una volta installata l’applicazione (scusate, ma scrivere deployare proprio non mi piace J) e propriamente configurata Windows Azure fornisce un Web Portal o delle API REST-based per controllare gli aspetti di monitoring delle applicazioni, gestione degli store accounts, hosted services, i profili di deployment (compresi gli affinity groups). Tutte queste caratteristiche di management sono accedibili da client web o da applicazioni custom preventivamente profilate tramite lo scambio di un certificato X509 che permette di autenticare l’utente.

Hosting

Prossimamente Microsoft aggiungerrà a Windows Azure la possibilità di gestire direttamente le Virtual Machine come se fosse in modalità Hosting. Dal mio punto di vista questa è una feature per creare un piano tattico di avvicinamento al Cloud Computing e non strategico. L’Hosting di macchine virtuali se da un lato è molto comodo perchè senza particolare sforzo posso iniziare a spostare le applicazioni nel cloud è altresì vero che non sfrutto tutte quelle caratteristiche che fanno del Cloud un sistema di business e tecnologico innovativo. Per capire meglio questa mia affermazione vi invito a leggere il mio precedente post della mini-serie : Cosa è il Cloud Computing quando parlo di differenze tra Cloud Computing e Hosting.

Ad ogni modo a breve ci saranno importanti annunci a riguardo mentre per ora, se interessati, potete trovare maggiori informazioni sul Blog del mio collega Murray: https://blogs.msdn.com/b/usisvde/archive/2010/03/29/vm-support-in-windows-azure.aspx

e per i più curiosi…

provo a schematizzare il dietro le quinte di Windows Azure!!

Windows Azure di per sè è stato creato da zero come sistema operativo per il cloud utilizzando però delle tecnologie Microsoft ben consolidate come ad esempio Windows Server 2008 r2 e Windows Server Hyper-V virtualization layer.

Potremmo quindi dire che Windows Azure è di fatto un “Cloud Layer” su varie tecnologie Microosft. Infatti, il cuore pulsante di Windows Azure è basato su una specializzazione di Hyper-V chiamata Windows Azure Fabric Controller (da non confondersi con Windows Azure AppFabric) che rappresenta il così detto cloud fabric layer. Il fabric layer da un lato astrae dall’ hardware sottostante e dall’altro gestisce dinamicamente delle VM con Windows Server 2008 R2 a 64-bit .

Di cosa si occupa il Windows Azure Fabric Controller?

Essenzialmente di gestire array di istanze di Windows Server e fornire dinamicamente risorse, funzioni di load balancing, fault-tolerance, geo-replication e application lifecycle permettendo il così detto Cloud elasticity.

Lavorare con Windows Azure

Windows Azure, tramite i propri meccanismi di provisioning e gestione delle applicazioni, permette agli sviluppatori di concentrarsi solo sullo sviluppo applicativo demandando al sistema tutti gli aspetti di fault tolerance, di controllo e di management. Inoltre , in modalità self-service è possibile scalare on-demand, chiedendo, ad esempio, di aumentare lo storage allocato, oppure aggiungere una nuova istanza all’applicazione il tutto tramite semplici attività di configurazione.
Il pagamento dei servizi avviene attraverso una fatturazione basata sull’effettivo utilizzo delle risorse (storage, Cpu, banda).

Con Windows Azure cosa rimane a nostro carico e cosa viene gestito automaticamente ?

Ovviamente resta nostro compito sviluppare e deployare le applicazioni integrandole con i sistemi di management che già utilizziamo per controllare lo stato di salute dei nostri asset mentre
tutto il resto ci viene fornito dalla piattaforma di Windows Azure!!

Questo , tradotto nel day-by-day, significa non dover più richiedere l’acquisto di HW e SW (licenze comprese) per l’esercizio, non doversi più occupare dell’installazione dei sistemi e dei relativi aggiornamenti, delle configurazioni di rete, dei load balancer, del clustering e di tutte le tecniche di scalabilità e di ridondanza per l’alta affidabilità ... Windows Azure gestisce il tutto dietro le quinte ... e non è certo poca cosa J!!

Inoltre, tramite la famiglia System Center è possibile governare tutte le risorse fisiche, virtuali e cloud-based in un unico ambiente o cruscotto.

SQL Azure

SQL Azure è un DB relazionale (SQL Server) fornito come servizio su piattaforma Cloud! SQL Azure supporta indici, views, triggers e store procedure.

Attenzione : non confondere SQL Azure con lo storage di Windows Azure presentato precedentemente!! SQL Azure è una database relazionale mentre lo storage di Windows Azure no !!

Ad oggi non è ancora disponibile una versione per il reporting interamente cloud-based ma è possibile utilizzare SQL Server Reporting services on-premises collegato a delle istanze di SQL Azure.

E’ possibile connettersi a SQL Azure via ADO.NET, PHP e ODBC. Essenzialmente quello che è richiesto al programmatore o al gestore dell’infrastruttura è la modifica della connections string.

Ogni account creato per accedere a SQL Azure può avere uno o più server logici da gestire che però sono implementati da Windows Azure come istanze isolate residenti in una particolare area geografica.

Infine, SQL Azure è disponibile in 3 differenti dimensioni : 1GB, 10 GB e 50GB. Il modello di pagamento del servizio è basato sulla dimensione e non sulla quantità di dati salvati nel DB.

La domanda più ricorrente che ricevo quando parlo di architetture con SQL Azure è : che differenza c’è tra SQL Server e SQL Azure? Provo a rispondere con una breve tabella comparativa (Il documento intero lo potete trovare qui ):

Feature	SQL Server (On-premise)	SQL Azure	Mitigation
Data Storage	No size limits as such	· Web Edition · Business Edition Exact size and pricing information can be obtained at Pricing Overview. Note: When you reach the allocated level (1 GB or 10 GB), only SELECTs and DELETEs will be supported. UPDATEs and INSERTs will throw an error.	· An archival process can be created where older data can be migrated to another database in SQL Azure or on premise. · Because of above size constraints, one of the recommendations is to partition the data across databases. Creating multiple databases will allow you take maximum advantage of the computing power of multiple nodes. The biggest value in the Azure model is the elasticity of being able to create as many databases as you need, when your demand peaks and delete/drop the databases as your demand subsides. The biggest challenge is writing the application to scale across multiple databases. Once this is achieved, the logic can be extended to scale across N number of databases.
Edition	· Express · Workgroup · Standard · Enterprise	· Enterprise Edition
Connectivity	· SQL Server Management Studio · SQLCMD	· SQL Server 2008 R2 Management Studio provides complete connectivity to SQL azure. Prior versions have limited support. · SQLCMD
Data Migration		· SQL Server Integration Services, BCP and SqlBulkCopyAPI are supported
Authentication	· SQL Authentication · Windows Authentication	· SQL Server Authentication only	Use SQL Server authentication
Schema	No such limitation	SQL Azure does not support heaps. ALL tables must have a clustered index before data can be inserted.	Check all scripts to make sure all table creation scripts include clustered index.
TSQL Supportability		Certain TSQL commands are fully supported; some are partially supported while others are unsupported. · Supported TSQL: https://msdn.microsoft.com/en-us/library/ee336270.aspx · Partially Supported TSQL: https://msdn.microsoft.com/en-us/library/ee336267.aspx · Unsupported TSQL: https://msdn.microsoft.com/en-us/library/ee336253.aspx
“USE” command	Supported	Not supported	USE command is not supported because each of the databases created by the user may not be on the same physical server. So the application has to retrieve data separately from multiple databases and consolidate at the application level.
Transactional Replication	Supported	Not supported	You can use BCP or SSIS to get the data out on-demand into an on premise SQL Server. You can also use the SQL Data Sync tool to keep on-premise SQL Server and SQL Azure in sync.
Log Shipping	Supported	Not supported
Database Mirroring	Supported	Not supported
SQL Agent	Supported	Cannot run SQL agent/jobs on SQL Azure	You can run SQL agent on on-premise SQL Server and connect to SQL Azure
Server options	Supported	· Some system views are supported (https://msdn.microsoft.com/en-us/library/ee336238.aspx)	The idea is most system level metadata is disabled as it does not make sense in a cloud model to expose server level information
Connection Limitations	N/A	To provide fair usage experience to all tenants on the nodes, connections to service may be closed due to one of the following situations: · Excessive resource usage · Long running queries – (over 5 minutes) · Long running single transactions between BEGIN TRAN and END TRAN – (over 5 minutes) · Idle Connections – (over 30 minutes)
SSIS	Can run SSIS on-premise	Cannot run SSIS in SQL Azure	Run SSIS on site and connect to SQL Azure with ADO.NET provider

Windows Azure AppFabric

Sopra le funzionalità di base messe a disposizione da Windows Azure abbiamo dei servizi applicativi più ad alto livello forniti dal Windows Azure AppFabric erogati in modalità as a service.

Ad oggi, i servizi presenti in Windows Azure AppFabric sono il Service Bus per la connettività e l’ Access Control Service (ACS) per la sicurezza.

Attenzione : Non confondere il Windows Azure Fabric Controller con il Windows Azure AppFabric. Il primo è il meccanismo interno a Windows Azure per gestire il provisioning, monitoring e la gestione dei servizi di Windows Azure stesso, mentre il secondo sono dei servizi per le applicazioni utenti : connettività e autenticazione/autorizzazione.

Service Bus

Il Service Bus è un message bus equivalente da un punto di vista concettuale all’ Enterprise Service Bus aziendale per collegare componenti di sistemi informativi in house con applicazioni e servizi sul Cloud garantendo all’IT il pieno controllo delle applicazioni indipendentemente dalla loro locazione geografica.

Non solo per il mondo B2B ! IL Service Bus è un servizio che permette di far colloquiare applicazioni Cloud-to-Cloud, Cloud-Web e Cloud-Intranet ! Il tutto senza inserire questa logica all’interno dell’applicazione e senza modificare gli accessi di rete o le regole di routing!

Pensiamo alle implicazioni che abbiamo oggi quando ci viene chiesto di far colloquiare due applicazioni che girano in due intranet diverse. Significa modificare gli accessi, duplicazione dei servizi in DMZ, duplicazione delle utenze, adeguamento delle policy di accesso e di routing e così via...

Il Service Bus di AppFabric ci permette di realizzare questo scenario in modo molto più trasparente bypassando tutte quelle difficoltà tecnologiche come firewalls, NATs e dynamic IPs .

In questo esempio :

1) registrazione dell’ endpoint

2) Esposizione dell’endpoint tramite il service bus

3) Lato client avviene il discovery del servizio/endpoint tramite il bus

4) Invocazione delle operation del servizio tramite il bus

5) Invocazione delle operation sul servizio target (on-premises).

Access Control Service (Ovvero, come gestiamo le utenze in Azure?)

Il secondo servizio presente in WIndows Azure AppFabric è ACS (Access Control Service).

L’ Access Control è la componente di sicurezza per garantire i meccanismi di autenticazione, autorizzazione e identity flow basati sulla Claims-Based Security per tutti i servizi applicativi REST-based. Tramite questo servizio di sicurezza le applicazioni e i servizi che risiedono su Windows Azure possono garantire un meccanismo di Single-Sign On con le applicazioni on-premises.

Siamo arrivati alla fine di questa primissima overview del mondo di Windows Azure. Sperando di aver stuzzicato il vostro interesse, nei prossimi capitoli affronteremo nel dettaglio molti degli aspetti introdotti in questo post.

--Mario

PS: Se volete vedere alcuni di questi disegni in formato animato questo è un brevissimo video di presentazione : https://www.microsoft.com/windowsazure/videoPlayer/videoPlayer.aspx?w=720&h=480&vid=WinAzPlatform_720x480_FINAL_101609.wmv

Comments

Anonymous
September 13, 2010
Bel post, un riepilogo così esaustivo ci voleva. Semplici e chiari gli schemi.
Anonymous
October 11, 2010
Ciao Mario, se ho ben capito, mentre ora sul mio pc ho sistema operativo, programmi e dati, con questa soluzione avrei solo bisogno di un collegamento internet poiché starebbe tutto su web? In cosa consiste precisamente il pagare per quanto si utilizza? Grazie e buon lavoro! Benedetto

Jaa