One of the banes of the computer industry is its “not good enough” syndrome. One minute you’re gazing lovingly at your freshly deployed Web applications, proud as a new father. The next moment, your manager is saying, “It looks okay, but are you using the cloud? I read that the ‘cloud’ is a killer technology and I think we should be taking advantage of it.’” So you hang your head, trudge back to your cubicle, and start looking into how to graft “cloud” technology onto your beautiful masterwork.
There are plenty of good reasons to develop applications for the cloud, of course. One of them is that if you need to update web applications originally written for IE6, you might as well adopt the platform for which the software is most suited — and that easily could be the cloud.
The nice thing is that, at least in the case of Windows Azure, the ”grafting” process is not nearly as horrific as you might expect. So rather than beating your head against your cubicle wall, at least in this instance, I suggest continuing to read, as I show you the steps involved in moving an existing ASP.NET Web site to become a Web role in the Windows Azure platform.
The Components of Windows Azure
While there are a number of moving pieces that make up Windows Azure, really only a couple apply to our goal of migrating an ASP.NET application to Azure. The basic architecture of an Azure application utilizes discrete components named roles. As of its initial release, Azure supports two types of roles: Web roles and Worker roles.
The Web role provides Web application functionality such as that which is supported by ASP.NET. The Worker role is used for general application components that are typically used to provide background processing for a Web role. To put it in application migration terms, the Web role listens for incoming HTTP requests. When one is received, the request is routed to a Worker role for processing. The results are then sent back to the initial requestor by the Web role. Within a particular Azure application, there must be at least one role of either type defined, although it is possible for one or more instances of any of the defined roles to be running.
So now that we know that two roles will be involved, what does that mean for our application migration? From the perspective of the migration process, the answer is “not as much as you might think.” If you are using Visual Studio 2010 to create the Azure application, the primary difference occurs as you create and deploy the application onto the Azure platform. That said, a number of criteria need to be met as you create the Web role; these criteria can have an impact on how you deploy your application.
The migration of an ASP.NET site to Azure involves the creation of Web and Worker roles. While the process is relatively straightforward, it is important to be aware of the differences between traditional ASP.NET and a Web role. In general, there are four areas of distinction. Web roles must have:
- References to a number of Windows Azure specific assemblies. If you care about the details, they are Microsoft.WindowsAzure.Diagnostics, Microsoft.WindowsAzure.ServiceRuntime, and Microsoft.WindowsAzure.StorageClient.
- Code in the WebRole.cs/vb file that bootstraps the DiagnosticMonitor. One of the other functions of this code is to indicate that the role will recycle when a configuration setting change occurs (to mirror the ASP.NET default behavior).
- The addition of an Azure-aware trace listener in the web.config file. (The specific listener is Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener.)
- Any third-party assemblies that are normally found in the GAC of the ASP.NET Web server.
That last requirement might seem a little odd. But consider, as an example, the case of an MVC web application. As part of the application, there is a reference to the System.Web.Mvc assembly. This assembly is normally found in the GAC, which also means that the Copy Local property of the reference in your projects is probably set to “False”. However the Virtual Machines on which Azure runs only contains the assemblies which are part of the .NET Framework 3.5 SP1 redistributable. This does not include System.Web.Mvc (or any of the other GAC-ed third party assemblies). So to ensure that the System.Web.Mvc assembly is available in the cloud, you need to set Copy Local to True. This ensures that the assembly is added to the package that gets uploaded to the cloud.
And Now, the Details…
To show the steps in detail, I’ll use as an example a one-page Web site that displays the contents of the Products table from the AdventureWorks database. (If you’re interested, you can download the Web site and the AdventureWorks database.)
The first step to convert the Web application project into a Web role recognized by Azure. To do this, we add an Azure Cloud service to the current solution and add the existing Web application to it. At the solution level, add a new project, and select a project template of Azure Cloud Service. You don’t need to add any roles to the service at this point.
Once the Azure Cloud project has been created, locate the Roles node in the Solution Explorer and select Add | Web Role Project in solution… from the right-click context menu. This option allows you to add an existing Web Application project from the solution as a Web role for the Cloud service.
Just so you know: The other option is to create a brand new solution containing the new Azure Cloud service project, and then add the existing Web Application project to the solution. Once this is done, the Web project can be added as a Web role to the cloud service in exactly the same manner. Functionally, there is no difference between these two techniques, so it’s really just a matter of preference.
At this point, you can test the application.
Make sure that you set the Azure Cloud Service as the start-up project for the solution. Also, since you need to run the AppFabric development version, you need to run Visual Studio as an administrator. Once you ensure both of these criteria are met, you should be able to launch the process as you would any other development project (pressing F5, for example). The application should work precisely as if the AppFabric were not involved.
The only remaining step to publish this application to the cloud is to push configuration files to the Azure portal. You could do so at this point, but you immediately will run into a problem: There is no database to access. So let’s address this problem before publishing the application.
Moving Data to the Cloud
As has been previously mentioned, the sampleWeb application uses the AdventureWorks database to hold the information. The default server is a local instance named SQLEXPRESS. While this setup is quite feasible when running on terra firma, its use not a valid assumption in the cloud. The virtual machines which host Azure do not include SQL Express. In addition, whatever database solution you use needs to be able to span multiple role instances. In either case, something other than SQL Express is required. For Windows Azure, the options are to use SQL Azure or to migrate to Windows Azure Storage.
The differences between these two options are worth a separate article all on its own. At a minimum, cost factors into the decision. But for this example, using SQL Azure is the “least resistance” option for a simple example.
For more about databases, see Optimizing SQL Server for Windows 7.
The starting point for a conversion to SQL Azure is to establish an account at sql.azure.com and to create a database. To make the management of the SQL Azure database easier, use SQL Management Studio 2008 R2. While this tools is available in CTP form at the moment, I’m sure that remote access of SQL Azure will continue to be available even after it goes live. You also need to define a couple of Firewall rules so that you can access the data, but we’ll cover that in more detail in a moment.
Now that all the tools are in place, the migration process is relative simple:
- Generate SQL Azure scripts to create the database
- Execute the scripts on the SQL Azure database
- Change the connection strings in the application to refer to the new database
Sounds almost too easy, doesn’t it?
The generation of SQL Azure scripts is accomplished using SQL Management Studio. Select Tasks | Generate Scripts from the right-click context menu for the database. The dialog box that pops up (see Figure 1) allows you to configure the script generation process and also to specify the target database engine. Specifically, click on the Advanced button and change the Script for the Database Engine Type value to SQL Azure Database. For the purpose of this sample, I also modified the Types of data to script value to include both the schema and the data.
Once the script is generated, it needs to be executed against the SQL Azure database. Again using SQL Management Studio, connect to a different database engine. For the server name, provide the full domain name that you received when you registered your database at sql.azure.com. The credential provided in the dialog must match those provided to you by the SQL Azure Web site. Figure 2 indicates both the SQL portal view and the corresponding server names.
Your database is now set up, but it is not accessible either from the Azure application or your own systems. Before you can do so, you must modify the Firewall settings .
From the Firewall Settings tab, click the Add Rule button and specify the IP address range that is allowed access to your database. As a convenience, this dialog includes the IP address from which you are accessing the Web site. To allow the Azure application access to the database, make sure that the Allow Microsoft Services access to this server value is checked. Figure 3 illustrates an appropriately configured SQL Azure database.
Once you establish a connection, open the script that you generated in the first step. Then connect to the database you created and execute the script using the F5 button. If this is successful, you will see a message at the bottom on the query output window saying so.
The final step is to modify the connection strings in your Web application. For this application, the connection strings are found in the <connectionStrings> element in the web.config file. So from Visual Studio, open web.config and locate the connectionStrings section. Locate the AdventureWorksConnectionString and replace the value of the connection string with the value for your SQL Azure database. (Go to the SQL Azure page displayed in Figure 1 and click on the ConnectionStrings button. The appropriate connection string appears and can easily be copied into the clipboard.)
At this point, your application is ready to run. Give it a try by using the F5 button from within Visual Studio. If all works as it should, you will see the Web site and be able to interact with the data.
Keep in mind that you are not yet running on the Windows Azure proper. Instead, you are running within the Developer Fabric. You are using SQL Azure for data access and the Developer Fabric is a local approximation of the cloud. Before it can be considered a true cloud application, you need to deploy it to Windows Azure. Fortunately, that too is not a challenging proposition.
Moving the Completed Application to the Cloud
Two files need to be uploaded to the Windows Azure site in order to deploy your Azure application. To create the files, right-click on the Azure Cloud Service project in the Solution Explorer and select the Publish option. While this builds the projects, it really (at least by default) doesn’t do much other that create the two necessary files (an Azure Service package containing the deployed application and a service configuration file). It is possible to configure your project to publish directly to the cloud, but for this sample, we’ll push the application manually.
Once the files are created, take note of where they are located. Then go on-line to the Windows Azure portal and select the project that is to be the target of the deployment. Depending on whether this is the first time deploying the project, you will either see a Deploy button or an Update button. Click the appropriate button, and upload the two files created when you Published your project. Figure 4 shows the deployment screen prior to the filling in of the values.
Enter the necessary path information and click on the Deploy button. After a period of time (and it could be a couple of minutes), your Azure application’s status will should as being Ready.
Now you can navigate to the home page for your Azure application and you should be rewarded with a brand, spanking new Web application that includes the originally required cloud technology.
Feel free to show it off to your manager. Collect admiration. You’ll have earned it.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!