Sam Gentile's Blog

In last night's/early morning notes I posted, I talked about that Windows Azure itself does two main things: Compute (runs apps) and it stores their data. In this post, I discover more Running Applications and their tie to configuration, and how that manifested in the Hello Azure application that I ended up running in the cloud last night.

Running Appplications (details from Chappell's white paper)

This part is real interesting. On Windows Azure, an app typically has multiple instances, each running a copy of all or part of the app's code! Each of these instances runs in its own VM. As I said last night, these VMs run 64-bit Windows Server 2008, and they're provided by a hypervisor that's specifically designed for use in the cloud.

It's all magic as the Windows Azure app can't see the VM it's running in, you can't supply your own VM image for Azure to run and you don't care. It's all managed for you. Instead, Windows Azure lets a developer creatre .NET 3.5 applications using Web role instances and/or Worker role instances.

Each Web role instance accepts incoming HTTP (or HTTPS) requests via IIS7. A Web Role can be implemented using ASP.NET, WCF or another .NET Framework technology that works with IIS. Windows Azure also provides built-in load balancing to spread requests across Web role instances that are part of the same application.

In contrast, a Worker role instance cannot accept requests from the outside world. There os no IIS in its VM but instead it gets its input from a Web role instance, typically via a queue in Windows Azure storage. The result can be written to Windows Azure storage or sent to the outside world - outgoing network connections are allowed. Instead of starting up and shut down per web request like the Web role instance, a Worker role instance can run indefinetly - it's a batch job that you create with any .NET technology with a main method,

In either case, each VM also contains a Windows Azure agent that allows the application to interact with the Windows Azure fabric. The agent exposes a Windows Azure-maintained log, send alerts to its owner via the Windows Azure fabric, and more.

Tieing this in with Hello Azure

• Upon install of the tools, have a Cloud Services category of projects in Visual Studio
• I selected the Web Cloud Service
• VS created two projects - a standard ASP.NET project and a new Cloud Service project
• The "Configuration" file for Azure - ServiceConfiguration.cscfg - which lives in the Cloud project looks like:

<?xml version="1.0"?>
<ServiceConfiguration serviceName="HelloAzure" 
     xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole">
    <Instances count="2"/>
    <ConfigurationSettings>
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

So, you can see the Role is WebRole and I changed the Instances too run two instances of the VM.

• When I ran this (locally) it started up the Windows Azure Development Fabric
• That guy is a simulated environment for developing and testing Windows Azure apps on your machine
• IT comes up with a UI that shows my deployment
• After seeing it run locally, I wanted to deploy to the cloud
• I right-click on the solution and hit Publish
• This will compile and build the solution, also creating a new service package, essentially a zip file, with the assemblies and configuration files for the solution
• When finished, opens directories where service package created and launches Azure Services developer portal
• Log in with Live ID
• Click on New Project
• Create Hosted Services project type
• Give it a name
• Specify a sub-domian of CloudApp.net and create the project
• You see Staging and Production
• Now you specift the directory where the zip file was created by browsing to the service package we published from Visual Studio
• Also need toi browse to the ServiceConfiguration file I showed above that defines the roles and number of instances per role
• Then Start Deployment
• After a while. Deployment finishes and you hit Run and this is where the real magic happens
• At this point, Windows Azure will start up virtual machine instances for each of the roles
• Then appp - assembliies, ASPX pages, etc loaded
• Then you can access it using the temp Website URL that it generates for you
• Finally, you can move to Production and get a true URL and you have an app running in the cloud!

More coming up on the Microsoft .NET Services, especially the Service Bus, and my thoughts and comparsions with an ESB like Neuron - hey maybe like a tie-into that series........