La piattaforma Microsoft per il cloud computing: Windows Azure

Windows Azure: Blob

I Blob sono strutturati in container che a loro volta contengono blob: file binari. Con una normale richiesta HTTP GET si possono scaricare dall'indirizzo http://<StorageAccount>.blob.core.windows.net/<Container>/<BlobName> attraverso qualsiasi client. Ogni contenitore può essere pubblico o privato; nel primo caso può essere acceduto da chiunque, mentre nel secondo solo dal detentore dell'account tramite autenticazione e URI speciali che contengono il token al blob. In questo modo si possono sia avere contenitori per ospitare immagini o video accessibili da chiunque, sia file al solo scopo di essere sfruttati dalle proprie applicazioni.

I blob possono essere di tipo page o block e a loro volta possono contenere dei metadati aggiuntivi. I primi sono ottimizzati per un accesso randomico di scrittura e lettura e possono raggiungere la dimensione di un terabyte, mentre i secondi sono ideali per lo streaming, organizzati appunto a blocchi di massimo 4MB per un totale di 200GB o 50000 blocchi. Esistono tool di terze parti che permettono di gestire facilmente gli storage tra cui il migliore, secondo l'autore dell'articolo, attualmente è CloudBerry Explorer.

Windows Azure: Table

Le Table invece sono adatte per la memorizzazione di informazioni, ma non bisogna confonderle con le tabelle dei normali database relazionali. Non sono infatti un RDBMS, non esistono relazioni, non vi è un controllo dello schema, ne è possibile fare query come lo sviluppatore è abituato a fare. E' uno storage le cui tabelle sono di fatto delle entità fatte di proprietà che possono raggiungere la dimensione massima di 1MB. Vi è la possibilità di usare un PartitionKey per suddividere le informazioni e bilanciare i carichi tra i nodi, una RowKey che identifica un'entità all'interno di una partizione e il Timestamp: una proprietà di tipo data che mantiene l'ora dell'ultima modifica.

L'accesso, anch'esso disponibile via REST, può essere effettuato, per chi usa il .NET Framework, mediante gli ADO.NET Data Services e quindi facilmente interrogabile con LINQ. L'URI di accesso generalmente è http://<StorageAccount>.table.core.windows.net/<TableName>.

La concorrenza dei dati è di tipo ottimistico, perciò nel caso vi siano più update solo il primo tra questi avrà successo, scatenando invece un errore per i successivi. Questa semplificazione insieme alle altre permette di alleggerire il sistema di storage e di facilitare la possibilità di scalare semplicemente lavorando sulla PartitionKey trattando le Tables come se fossero semplicemente un posto dove depositare le informazioni.

Windows Azure: Queue

Le Queue sono un repository di messaggi con un ordine FIFO nelle quali possiamo inserire messaggi e poi recuperarli. I messaggi sono in XML e non possono superare gli 8KB e una volta depositati "vivono" per un massimo di 7 giorni (se non diversamente specificato). Come le normali code è possibile fare la peek del messaggio o farselo restituire. In questo caso però il messaggio non viene automaticamente eliminato ma resta invisibile per un tempo determinato (in genere 30 secondi). In questo lasso di tempo chi ha preso in carico il messaggio deve eliminarlo esplicitamente, altrimenti verrà reso di nuovo visibile e potenzialmente processato da qualcun altro o più di una volta.

Le Queue, come per tutto Windows Azure, sono accessibili tramite REST per le operazioni prima citate e hanno solitamente l'indirizzo http://<StorageAccount>.queue.core.windows.net/<QueueName>. Sono ideali per essere utilizzate in congiunta tra i web role e i worker role. I primi infatti possono ricevere le richieste da parte degli utenti e accodarle nella Queue. I secondi invece recuperano i messaggi e li processano favorendo moltissimo la possibilità di scalare dato che è possibile incrementare i worker role se il processamento di un messaggio richiede molto tempo, o incrementare le istanze di web role se è lento il processo di accodamento o si vogliono accettare più richieste possibili da parte dell'utente.