24

Feb

Windows Azure – Compute pt.2 – Tools, SDK e strumenti di sviluppo

Gli strumenti di sviluppo per Azure sono usciti già nel lontano 2008, ma oggi si sono evoluti parecchio, permettendo il deploy diretto da Visual Studio sull’ambiente Azure di produzione. La bontà dell’SDK sta nell’aver riprodotto l’ambiente Azure anche in versione “locale”, in modo da poter debuggare e testare l’applicazione esattamente come se fosse realmente distribuita su Azure. Si può fare direttamente da Visual Studio o anche da linea di comando.

Una volta installati i tools infatti (necessario su VS2008), verrà installato automaticamente il development fabric (che ha necessità di privilegi admin per partire, per cui in tal caso avviate VS in modalità elevata) e il development storage, che è la controparte virtualizzata del Windows Azure Storage che si può trovare online. Per far funzionare il tutto basta una macchina decentemente aggiornata, SQL Server 2005 (anche express) e il .NET 3.5 SP1.

Modello di sviluppo

Ma come si sviluppa su Azure? Abbiamo detto che la più piccola unità funzionale è il ruolo, partiamo da lì. Il ruolo ha necessariamente un modulo di codice che implementi RoleEntryPoint, nel quale vengano definiti i metodi per potersi avviare. Nel caso di applicazioni Web tale classe è data per scontata, e quindi omessa, ma si può reintegrare a piacimento nel progetto. Il ciclo di vita di un ruolo mappa bene i metodi che dovremo sovrascrivere nel RoleEntryPoint:

  • OnStart: si descrive da sè ed è un metodo al cui ritorno corrisponde generalmente, salvo problemi, il passaggio in stato Run.
  • Run: è l’esecuzione del ruolo, non dovrebbe mai tornare. Il tipico scenario di utilizzo prevede di scrivere la logica del Run all’interno di un loop infinito o condizionato da condizioni application wide.
  • OnStop: viene chiamato quando si vuole interrompere il servizio:
    • Dall’Azure Management web portal
    • Quando ri-effettuiamo il deploy della soluzione

Per chiarire le idee su cosa accade al ruolo Azure, questa immagine dovrebbe chiarificare tutto il workflow:

image

Quali sono i ruoli principali di una applicazione per Azure? Il ruolo web e il ruolo worker.

Il ruolo worker è un classico esempio di processo batch che esegue in continuazione a pause di N secondi (nel famoso loop all’interno del metodo Run), esattamente come un servizio Windows. I pattern più tipici di utilizzo del worker role sono:

  • Worker che processi i messaggi di una coda asincrona (che può essere una coda Azure oppure una qualsiasi altra coda remota)
  • Worker che si metta in ascolto TCP/IP su una particolare porta
  • Worker che avvi un processo sul server virtuale di destinazione (pratica ad oggi utilizzata per fare girare un pò di tutto su Azure, da Tomcat a MySQL e via dicendo).

Reputo l’ultimo pattern di utilizzo assolutamente fuorviante e sbagliato: benchè di fatto sia un workaround per fare del ruolo worker una manna universale per far girare tutto su Azure, l’idea di base è sbagliata. Azure è un PaaS e come tale deve funzionare da platform. Fare girare MySQL su Azure oggi è sostanzialmente un exploit (anche nella forma) di Azure stesso: infatti perdiamo qualsiasi beneficio di scalabilità e assenza di manutenibilità dell’infrastruttura.

Il ruolo web è come il ruolo worker, nella struttura, ma può fare da host per applicazioni web, quali ASP.NET (WebForms o MVC), PHP o FastCGI. E’ ad oggi il ruolo più facile da implementare poichè prevede che basti prendere una nostra applicazione ASP.NET (creata con un minimo di astrazione infrastrutturale) e con due click farne il deploy su Azure. Sui server di Azure la cosa equivale a impostare un server IIS sull’applicazione web. Da poco è possibile indicare in fase di configurazione, di avere più websites all’interno dello stesso ruolo, specificando ovviamente i bindings su cui IIS dovrà rispondere per indirizzare il giusto sito.

by Roberto Freato on 2/24/2011
Post archive