Windows Azure: Getting to Know the Runtime Environment

There’s a lot to learn in developing apps for a new platform like Windows Azure. Here’s a step-by-step tale of one developer’s experience.

Jose Barreto

I recently learned how to develop, test and deploy a Windows Azure application. I had heard a lot about Windows Azure and saw many experiences reported by others, but I wanted to get my own hands-on experience and validate what I’d been told. The release of Visual Studio 2010 was the final push I needed to get started.

In this article I will describe how I created and deployed a sample application. This is always a nice way to get your feet wet with a new technology and it forced me to experience the entire lifecycle of an application in Windows Azure.

My experimentation was made easier by the fact that I had previously developed ASP.NET applications, because a Windows Azure application follows the same architecture, with Web roles (Web front ends) and worker roles (back-end services). The main tool to develop Windows Azure applications and regular ASP.NET applications is also the same: Visual Studio. I had already installed the final version of Visual Studio 2010 on my Windows 7 computer and had also added IIS as an optional Windows 7 component.

In addition to Visual Studio 2010 and IIS, I also downloaded the Windows Azure tools, which added extra templates for Windows Azure development. I was interested in understanding more about the environment where Windows Azure applications run. I know in general that these are virtual machines and that they should work well for your applications regardless of their specific configuration details, but I was curious about how Windows Azure deployed them. As someone with some IT infrastructure background, I’m always interested in learning what this type of deployment looks like under the covers.

To get there, I decided to write an application that would report information about the file system of the machine where it runs—simple things such as what drives exist and what their characteristics are (type, file system, total size and available space). I also added the ability to query folders and files, so I could understand what existed where. Figure 1 shows what I ended up with.

Figure 1 A sample file system report application created in Windows Azure.

Nothing fancy, as you can tell, just enough to understand the development experience, go through the deployment process and have the tools to understand the Windows Azure runtime environment.

C# for the Cloud

Creating the application was fairly straightforward. I created a new project using C# and selected the cloud project. To keep it simple, I used a single ASP.NET Web Role for my Cloud Service Project.

Then I dragged some controls, added some code and started testing it. The whole development process runs locally, so there’s no need to even have a Windows Azure account at that point. I was also not using any Windows Azure Storage, so it was simply one Web Role that had no external dependencies. Not typically a very useful application, but I my goal was to create somewhat of a glorified “Hello, World” to get started.

Because I had the entire Microsoft .NET Framework available, writing the code was not hard at all. To get the drive information, for instance, I used the System.IO namespace.

protected void btnDrives_Click(object sender, EventArgs e)
 {
   DriveInfo[] diAll = DriveInfo.GetDrives();
   string strDrive = "";
   foreach (DriveInfo diOne in diAll)
    {
       strDrive = "Drive " + diOne.Name + " Type:" + diOne.DriveType.ToString();
      if (diOne.IsReady)
       {
          strDrive = strDrive + " Volume:" + diOne.VolumeLabel + " FS:" + diOne.DriveFormat.ToString() + " Total:" + diOne.TotalSize.ToString() + " Free:" + diOne.AvailableFreeSpace.ToString();
       }
       txtAdd(strDrive);
    }
 }

Aside from the fact that I had to run Visual Studio as an Administrator, everything else was fairly uneventful in terms of development and local debugging of the application. Visual Studio automatically started the local Windows Azure Simulation Environment when I ran my application (see Figure 2). I was able to set breakpoints, watch my code run step by step and so on. No surprises there.

Figure 2 Here’s how my application looked when it ran through the Windows Azure Simulation Environment.

Deploying Azure Apps

Perhaps the hardest part for me, being new to Windows Azure, was knowing exactly what I needed to deploy my application. Once you create your service in the Windows Azure Web UI, you reach a point where you can deploy the application.

When you click on the Deploy button, you are then prompted to provide two files (an application package file and a configuration settings file) along with a Service Deployment Name. There was little else in terms of tips on how to generate those.

After spending some time in the Visual Studio environment, I was unable to find the right way to create those files or even what the file extensions would be. That was when I had to look up the Windows Azure documentation for the first time. Up to this point, I was just winging it. It turns out you need to right-click the Cloud project to find the “Publish …” option to generate a package for Windows Azure.

This will create the two required files, one Cloud Service Package (.cspkg) and one Cloud Service Configuration (.cscfg). The “Publish …” option opens a Windows Explorer window with the right folder (see Figure 3) as well as an Internet Explorer window with the right Windows Azure URL.

Figure 3 The Windows Explorer window opened from the “Publish …” option.

Once I provided everything, the service was published within seconds. After that, clicking on “Run” deployed the application. That’s when the virtual machine (VM) containing the running application actually becomes provisioned and started. That step takes a few minutes.

Running the Service

The status of the service went from “Initializing” to “Busy” to “Ready.” After that, the deployment was completed and running the service meant simply hitting the Web site URL at https://servicename.cloudapp.net.

I was finally ready to inspect some of the characteristics of the Windows Azure VM running my service. First, I listed the drives on the system. It turns out that the VM had three drives (C:, D: and E:) as I showed in Figure 1. I then used the application to look into specific folders and files on each drive. After further investigation, I came to a conclusion about the three different drives, shown in Figure 4.

Figure 4 Here’s how the storage was parsed out over three drives.

I did find documentation pertaining to the amount of storage that can be specified per VM. The default size (small) gives you 250GB of local storage. That was the size of my VM. You can choose bigger ones with 500GB, 1000GB and 2000GB of local storage.

However, I did not find documentation of this breakdown between the three drives (nor even any documentation about the three drives, period). I can only tell you that the numbers in Figure 4 were true for my specific application deployment at that time.

If you are planning to use local temporary storage in your application, you should look into the documentation for Local Storage Resources. These local storage resources apparently live on the C: drive, but you should use the API to find the exact local path to use.

If you need permanent storage, you should look into the many options Windows Azure offers, including Blobs, Tables, Queues, Drivesand SQL Azure Databases. These are accessed via APIs and are not stored as part of your Windows Azure VM local storage.

Staging Essentials

One last thing I found interesting was the process to deploy additional versions of the application. Windows Azure allows you to place the new version in a separate “Staging” area. This makes it possible to run and test the new staged version with a temporary URL while the older version is still running with the main URL.

When you are confident that the version is fine, you can simply switch the production and staged environments. This is done quickly, because both environments are fully deployed at that point and you’re effectively just switching the two URLs. If your new version turns out to have any issues, you can also quickly switch back to the old version.

Packaging for the Cloud

If you’re familiar with ASP.NET, creating Windows Azure applications is not a big stretch, once you grasp a few extra concepts. I learned a lot about the way Windows Azure applications are packaged and also understood the deployment steps in greater detail.

I was happy with my experiment, having deployed my first Windows Azure application and learned more about the Windows Azure runtime in the process.  I understood more about the different drives used by Windows Azure VMs and was able to understand the details of the VM deployment in greater detail. Not that you need to understand these details to deploy your applications, but a developer is always more comfortable after understanding more about what’s inside.

Jose Barreto* is a principal program manager with the File Server Team, part of the Microsoft Server and Cloud Division. He graduated in Computer Science at the Universidade Federal do Ceara in Brazil in 1989 and moved to the United States in 2000. Barreto joined Microsoft in 2002 in California and moved to the Redmond campus in 2007.*

Related Content

• Providing Scalability for ASP.NET Applications
• Automating Virtual Machine Host Deployment
• Scaling ASP.NET Applications: Lessons Learned