Sono un Trainer MCT e Consulente IT freelancer; particolarmente sensibile alle tematiche Mobile e Cloud, sono attivo nel mondo Community soprattutto su Windows Azure e Windows Phone. Mi è stato riconosciuto l’MVP per due anni consecutivi e sono pluricertificato su diversi vendor (MS, Sun, Apple, Cisco, IBM).
Windows Azure è un platform-as-a-service e, in quanto tale, fornisce allo sviluppatore una piattaforma per poggiare le applicazioni esistenti. Quando però si distribuiscono applicazioni (web soprattutto), è sempre necessario avere una giusta politica per lo storage delle informazioni. Facciamo un esempio.
Quando Azure era in CTP, la piattaforma era molto più restrittiva di adesso (cosa che apprezzo molto) costringendo lo sviluppatore ad alcuni accorgimenti in nome della scalabilità e della stabilità della soluzione to-be. Se per esempio avessimo voluto, da una applicazione web, salvare dei file sul “disco”, semplicemente non avremmo potuto. Certo c’è e c’era il LocalStorage; ai tempi però non era possibile preservarne il contenuto tra recycle successivi, per cui era necessario trovare una soluzione alternativa.
La soluzione maxima era quella di affidarsi all’Azure Storage, cioè l’insieme di quattro (allora tre) servizi (Blobs, Tables, Queues, Drives) per salvare lo stato della nostra applicazione. L’idea portante era: “Azure Compute serve per fornire risorse computazionali e la piattaforma web per l’esecuzione di ASP.NET; Azure Storage serve per tutto ciò che invece necessita di memorizzazione, inclusi I dati strutturati”. Perciò la best practice era (e sotto alcuni aspetti rimane tutt’ora) utilizzare i Blob per salvare files sull’Azure Storage. Vedremo poi l’eleganza dell’Azure Storage nei post successivi.
Azure Storage
I punti da discutere sono molti anche possiamo riassumerli in questi tre principali:
Avere un Azure Storage significa creare un account di storage nella propria subscription Windows Azure. Dopodichè si avranno due chiavi da 512 bit da utilizzare per le comunicazioni protette (scritture ovunque e letture su container non pubblici) e un url sul quale saranno esposti i nostri dati (max 100TB per account), con la forma: http(s)://accountName.[blob,table,queue].core.windows.net.
Poi sebbene sia tutto accessibile in modo estremamente elegante in REST, dal codice .NET abbiamo a disposizione dei wrapper (namespace Microsoft.WindowsAzure.StorageClient) che ci permettono di fare le GET, POST, PUT, DELETE da C# e VB.NET in modo fortemente tipizzato.
La sicurezza è di canale (basta anteporre agli url sopra un https); la crittografia sul messaggio non si fa perchè spesso non c’è alcun messaggio .
Vedremo nei prossimi post le quattro astrazioni di storage che sono attuabili in Azure:
Development Fabric
Per sviluppare in locale ed effettuare i test sullo storage esiste il Development Fabric, un mock del vero Azure per testare il comportamento più velocemente e/o quando non si ha connettività internet a disposizione.