Microsoft Azure Offers Developers a Path to the Cloud
Microsoft Azure Offers Developers a Path to the Cloud
This is the first of several articles about Azure, Microsoft's cloud computing platform that was rolled out in 2008. Azure is quite large, and during the next year we're going to see several entire books written about Azure. In other words, there's far too much to fit into a single article. However, I do want give you an overview of it, and get you up and running. So for this first article, I'll present a walk-through of the basic starter sample that ships with the software development kit, while explaining the concepts.
If you want to follow along, you'll need either Vista with Service Patch 1 or Windows Server 2008, as well as Visual Studio 2008. (Or instead of Visual Studio 2008, Visual Web Developer 2008 Express Edition works, too, according to the online documentation). You'll also need either SQL Server 2005 Express or SQL Server 2008 Express. SQL Server 2008 Express is available here.
The Foundations of Azure
One of the foundations of Azure (and many other cloud platforms) is the concept of geographically distributed services. This allows users from different parts of the planet (and within regions of the United States) to be able to download or use services that are hosted on a service reasonably close to them geographically. This has many obvious benefits, such as faster response time and minimizing data transfers through an already overcrowded Internet.
When you create software for Azure, your software lives as what is called a "compute service." This is basically the portion of your software running under Azure where your server-side code (such as ASP.NET code) lives.
Microsoft uses the word "role" to mean a single code component that runs. For example, you might create an ASP.NET application, which would be a role, in this case a "Web role." Further, you might create additional modules that run in the background; these are called "worker roles." Together, one or more roles constitute a compute service.
Included with the SDK are two tools that help you develop within your own environment before uploading your software to the actual Azure cloud. These tools mimic aspects of the Azure services. The first is the Development Fabric; the second is the Development Storage.
The Development Fabric basically simulates Azure itself on your own local development box, and includes a tool that lets you manage your running services.
The Development Storage simulates the server-side storage services. Azure provides you with two areas where you can store your data, depending on your needs. First, you have access to traditional relational databases through the SQL Data Services, which is a cloud-version of SQL Server. Next, you have access to a nonrelational, flat storage system called Storage Services. On your development box, the Development Storage mimics this latter form of storage.
Trying Out the First Sample
Installing the SDK was a bit annoying, especially compared with developing under competing platforms such as Amazon.com's AWS (Amazon Web Services) and especially Google Web Applications. I had to download the rather large SDK as well as the tools for Visual Studio. (I discovered in various forums online that many people miss the second part-the tools for Visual Studio-and get frustrated when they can't try out the walk-throughs.)
In my case, even though I already have a full installation of both SQL Server 2005 and 2008, I nevertheless had to install SQL Server 2008 Express, as this is apparently a required component. (I say "apparently" because the documentation hints that although Express is required, you might be able to get it to work with a non-Express version of SQL Server. However, I was unable to do so.)
Once I installed all the software, however, everything went smoothly. The first walk-through took me through the creation of a simple site that is cloud-ready. (If you want to try this out as well, I'm referring to "How to: Build and Test a Web Role with Visual Studio" in the online documentation.)
You simply create a new project of type Web Cloud Service. But really, this creates two projects; one is a Cloud Compute project, and the other is an ASP.NET project. The Cloud Compute project contains information about the service you're creating.
Initially, the project doesn't really do much, as it's just a starter project. However, if you run it in the debugger, you'll see a few things happen. First, you'll see a message asking whether you want to create the database. Go ahead and click "Yes." Then there will be a delay as the system creates a database that runs under SQL Server Express. (Even though the Development Storage is nonrelational, behind the scenes it's actually stored in a SQL Server Express database. Go figure.) Next, the two tools I mentioned-Development Fabric and Development Storage-will start up. You won't really get much indication that they're running, except that icons for them will appear in the system tray in the lower-right area of your desktop, and a quick little message will pop up down there announcing that they have started. That message will soon disappear.
Next, Internet Explorer will open and you'll see a blank Web page. That's it. That's the Web page generated by the ASP.NET application running in your Development Fabric.
Now, if you're trying out the first walk-through in the documentation, you'll see a reference to a treeview. This early release documentation needs some editing, as it makes it sound like the treeview is supposed to be in the Web page. It's not. The docs are actually referring to the GUI for the Development Fabric. To see it, right-click the little icon in the tray (it looks like two gears) for the Development Fabric and click Show Development Fabric UI. This GUI shows you information about your running services, as well as an output of a log that your services can write to.
Since this first sample really doesn't do anything, next I'll try out one of the more complex samples. (For this first article, I'm just walking you through some samples so you can get a feel for how this all works. In the next article, I'll talk about actual coding and development.)
The Personal Web Site Sample
Included in the SDK's directory, which by default is C:\Program Files\Windows Azure SDK\v1.0, is a file called samples.zip. If you unzip this into its own directory, you'll find nine samples that demonstrate various aspects of the Azure SDK. I highly encourage you to compile and look through each sample and become familiar with what it does; doing so is an ideal hands-on approach to learning about Azure. The sample that I'll look at here is the one called Personal Web Site, found in the directory PersonalWebSite (with no spaces in the name).
The Azure SDK includes a command line that's set up with paths to all the tools in the Azure SDK. The samples can be built from this command line using batch files that accompany each sample, as well as a single batch file that will build all the samples. Although you're certainly free to use this approach, each sample also includes its own solution that you can open in Visual Studio, which I recommend you do. That way you can visually see the different parts that make up the sample.
I opened the PersonalWebSite.sln sample to try it out. (You might get a security warning when you open the project as I did; this is normal for the situation. Just click Load Project Normally.) When you run this project, it might look familiar. It's very similar to the ubiquitous ASP.NET Personal Web Site Starter Kit.
But if you look through the code, you'll see a project called AspProviders, which includes a very handy set of C# files for working with various aspects of Azure. These classes are basically wrappers around the Azure API to make it easier to use from an ASP.NET perspective. For example, there are classes for a membership provider and a role provider that make use of the storage service. These are classes that you can definitely reuse for your own cloud-based software.
One reason I draw attention to these classes in particular is that they provide something that is somewhat lacking (in my opinion) in Amazon.com's AWS. User authentication works quite differently in AWS, and much of it you have to code yourself. There is security in AWS, and it works well, but user authentication isn't built in, at least nothing on the level of the ASP.NET membership providers. If you've done much development in ASP.NET, as I have, you're probably aware of just how robust and useful the user authentication classes are that were introduced with ASP.NET 2.0. These classes include membership and role providers that work wonderfully. When I worked with AWS, I was a bit disappointed.
Of course, to be fair, AWS is very different in its architecture, and you can allocate Windows servers under AWS and run ASP.NET. From there you can use the user authentication that comes with ASP.NET. However, this authentication is separate from the requests authentication used in HTTP calls under AWS. So, personally, I welcome these classes in the Azure samples.
From here, I encourage you to explore more of the samples and look closely through the code. Pay special attention to the namespace being used, as well as the assemblies that the samples are using found in the "bin" and "ref" directories under the Azure SDK's installation. Also, don't miss the documentation found in the doc directory; included here is a .chm Window Help file that contains a good deal of information (although it's still in a prerelease state).
And then watch for my next article on Azure, where I'll walk you through some actual coding examples. It'll be fun.
Senior Editor Jeff Cogswell can be reached at jeffrey.cogswell@ZiffDavisEnterprise.com.