Well, yes … sort of … and no.
It is true that Microsoft has made it pretty easy for ASP.NET developers to develop Azure applications. It is also generally true that it is relatively straightforward to port most existing ASP.NET applications to Azure with little or no modification. Of course there are some that say the process is still too painful and that additional skills are required. Also, there are others that say Azure requires a new way of thinking about applications and for providing the capability for Internet-class scalability. As usual the reality for most people trying to come to grips with new technology is somewhere between the extremes.
Let’s take, for example a simple ASP.NET web application vs. a simple Azure application. The experience for each is similar but different. In particular, let’s look at the support for application security. At the broadest level this means providing for creation of user logins and roles and providing access to resources based on those credentials.
How does the Azure application generated out-of-the-box compare with an ASP.NET Web Application? Even though the Azure project wizard creates almost the same starting point as the ASP.NET project wizard there are a few things that are different.
In an ASP.NET application the project wizard will do most of the heavy lifting for you. The ASP.NET wizard creates an empty App_Data folder in the project. By default, when the application runs and a login is requested, a SQL Express database file will be created that stores user login information. This SQL Express file can be used in the deployed application or (probably more commonly) could be upsized to a real SQL Server. This is part of the ASP Providers services Microsoft has offered since ASP.NET 2.0.
The Azure wizard also creates an empty App_Data folder. However when the Azure application is run no SQL Express database will get created. In fact, the application will throw an exception.
So what? What does this mean? Why should you care?
While it may be possible to adjust some settings and tweak things a bit to get the Azure application to work with SQL Express like the ASP.NET application does, in practice you would probably never want to do so. Using SQL Express to store application state for an Azure application would be like having training wheels on your Harley! It would seriously limit the scalability of the application and scalability is one of the main benefits of Azure. A better approach would be to use Azure table storage or SQL Azure to persist membership data. Microsoft provides sample code that shows how to do this.
The truth is that if you are looking to run a single, simple ASP.NET website, Azure may not be your most cost effective solution. If you are running multiple applications, however, which have non-trivial processing requirements and possibly share membership data, Azure may make sense. Certainly Microsoft has done a good job of extending the .NET namespaces to include first class support for Azure. Additionally the Web Role/Worker Role paradigm offers scalability far beyond what could be achieved with a simple ASP.NET application.
To help sort out all of the various details and choices which arise when evaluating architecture options Doug Rehnstrom has authored Course 2602 – Windows® Azure™ Platform Introduction: Programming Cloud-Based Applications. Programmers who attend this course will leave with an appreciation for what Azure has to offer and practical knowledge in how to leverage this platform for their organization’s business interests.