Con i template di Visual Studio 2010 possiamo creare una applicazione web che si possa distribuire su Azure con pochi click. In particolare dopo aver creato un Cloud Project, viene chiesto quali “ruoli” vogliamo aggiungere al progetto e subito possiamo scegliere (almeno per quanto riguarda il web) tra:

  • Web Role <= Applicazione Web Forms
  • MVC 2 Role <= Applicazione ASP.NET MVC 2 (l’altro giorno al MIX hanno annunciato i templates per MVC3, quindi probabilmente i tools si allineeranno presto a questa novità)
  • WCF Service Role <= Servizi/o WCF
  • CGI Role <= Tutto ciò che gira in FastCGI

image

Tutto questo è possibile sia in C# che in VB.NET e ovviamente, una volta aggiunto il ruolo, Visual Studio genererà il codice di esempio del template esattamente come se stessimo creando la corrispettiva applicazione web svincolata da Azure.

Qualcosa però cambia:

  • Le references dichiarate e importate sono le solite + quelle di Windows Azure (per la diagnostica, lo storage e il RoleEnvironment)
  • C’è un file in più nel progetto che di solito si chiama WorkerRole.cs o WebRole.cs (in cui abbiamo per l’appunto il ciclo di vita del ruolo)
  • Nel Web.Config c’è una sezione dedicata al logging/tracing che va a puntare sull’Azure Storage (di default quello locale di sviluppo definito nel cscfg)

Best practices

Sviluppare sul Cloud è come sviluppare per Web Farms. Non sappiamo che server prenderà la richiesta web “dietro” il load balancer, non sappiamo se richieste successive colpiranno lo stesso server e quindi dobbiamo sempre e solo supporre il worst case. Fosse il web di oggi solo ASPX (o risorse scaricate in modo monilitico) non sarebbe un problema; con AJAX però la cosa si complica.

Infatti il codice client potrebbe invocare partial rendering ottenuto da una istanza diversa da quella della macchina che ha erogato la pagina. Motivo per cui dobbiamo, oltre che scrivere AJAX assolutamente stateless, assicurarci di avere la MachineKey identica su tutti i server della farm per evitare che il ViewState vada in errore.

La sessione: nei contesti web farms MAI tenerla sulla singola istanza. Perchè se due richieste successive della stessa sessione logica colpiscono due istanze diverse, la sessione si duplicherà su due macchine (risiedendo in memoria) producendo effetti non controllabili. A questo c’è una soluzione ben rodata e abbastanza stabile che è trasferire la gestione della sessione su storage persistente (tipo SQL Azure, in questo caso), così da creare un singolo entry point per le multiple istanze (anche il TempData di MVC sta in sessione).

La cache: inutile fare local cache sull’istanza in un contesto farm; o meglio non ottimale. Infatti così facendo si “cacha” potenzialmente N volte (dove N è il numero delle istanze) una risorsa che potrebbe essere cachata a monte del load balancer. E su questo ci aiuta AppFabric Caching che fa appunto, proprio così. Inoltre AppFabric Caching non fa solo output cache ma anche Sessione State Cache: il che ci rende finalmente indipendenti da SQL Server per la gestione della sessione (e decisamente più performanti).