5

Mar

Windows Azure – Storage pt.1 – Introduzione

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:

  • Necessità di avere uno storage con alti SLA, scalabile e accessibile da ovunque
  • Necessità di potervi accedere via REST
  • Necessità di avere diverse astrazioni per salvare/utilizzare i dati

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 Winking smile.

Vedremo nei prossimi post le quattro astrazioni di storage che sono attuabili in Azure:

  • Blobs: semplici files + metadati
  • Drives: dischi VHD da montare sul cloud per accedere ai dati via NTFS
  • Tables: dati strutturati accessibili via Data Services
  • Queues: code di messaggi, utili al disaccoppiamento di applicazioni

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.

by Roberto Freato on 3/5/2011
Post archive