Azure workshop at the Microsoft p&p Symposium 2010

Today I followed the Windows Azure workshop on the Microsoft patterns & practices Symposium 2010. And the first thing I have to say is that I am impressed how easily an existing ASP.NET web application can be migrated to the cloud. One reason for this is that a web role on Windows Azure is implemented in the cloud using IIS on a Windows Server 2008. An eyeopener for me was that anything that runs on IIS also runs on a Windows Azure web role. Thus, not only ASP.NET but PHP and Java applications as well. (The same goes for worker roles. An executable that runs on Windows Server 2008 should run on a Windows Azure worker role as long as no UI is used.)

For development only two steps are needed to test your web application in a local Azure develoment environment. First the DevFabric environment should be installed, which comes with the Windows Azure SDK. Optionally, the Cerebrata Cloud Storage Studio can also be installed, which is a great tool to manage Azure storage data. Second create a new Windows Azure Cloud Service for an ASP.NET Web Role and make a reference to the existing ASP.NET web application. That is basically it. You are ready to run your application in the local DevFabric environment. Of course, this is not the whole story.

The biggest part of the workshop focussed on the parts of an existing application that needs special attention when you bring them to the cloud. Parts that were addressed are: identify and access control, data storage handling and logging.

Identity control could still work the same if you have your own database with user names and passwords. But in case Active Directory is used, it must be adapted for the cloud. To address this is the cloud, claims-based identity can be used. Windows Identity Foundation (WIF) is available to implement this in a generic way that both works on-premise and in the cloud. A separate guide from the patterns & practices team is available to describe this extensively (see Claims–based Identity and Access Control). The cool thing about the fundamental design pattern used for claims-based identity is that no communication is needed between the web server application and the Security Token Service (STS) which is the provider of security tokens. A trust relation from the web server application to the STS will suffice. And as long as the STS can supply a token with the required claims, it can be used. Be it Active Directory, Facebook, Twitter or whatever you need.

Data stored in databases or local files need to be migrated to the cloud. Azure includes SQL Azure as a cloud alternative for SQL Server and Azure Storage for blobs, tables and queues. Theoretically, an on-premise database can still be used from an Azure cloud service, but most of the time the preferred way is to bring the data to the cloud as well. Switching to a cloud database is easy. An SQL Azure database can be accessed from any location by simply changing the connection string. For simple relational data you have a choice between SQL Azure and Azure Storage for tables. One aspect of this choice is pricing. Depending on the data usage scenarios it may be cheaper to choose one instead of the other. During the workshop also a spreadsheet was presented, which can be used to calculate prices for your scenarios (see How Much Will It Cost?).

When logging is implemented using Enterprise Library, the only thing you need to do to migrate the output to Azure storage, is to replace the listener in de configuration for an Azure specific listener.

The guides made by the patterns & practices team are very useful. I am especially looking forward to the announced next guide about developing Windows Phone 7 applications in the cloud.