Sorry for the delay. Between the demands of family and a dead hard-drive, I’ve been a bit busy. Last time we did a high level overview of the components of Azure Services. This time I want to look a bit more closely at just Windows Azure, the operating system used by customer applications.
While development for Windows Azure is .NET development, it is not the same as development targeting any other Microsoft platform. Neither is the way in which these applications are hosted. In a nutshell, each application that is deployed into Windows Azure is given its own dedicated virtual machine instance. This VM instance is in turn bound to a single processor core that only handles processing for that VM. These VM’s are managed by the Azure’s Fabric.
The Fabric is not only a glue for Windows Azure, its also a baby sitter and mechanic. It watches over all the VM’s and makes sure they’re running well. Azure Fabric also handles deployment of applications and upgrades to the VM’s. When a new application is deployed into Windows Azure, the Fabric will look an available VM, upgrade/patch it if necessary, configure it based on the type of application, install the application, and start it running. Think of the Fabric as your own personal SCM team. Only the Fabric doesn’t need smoke breaks or a coffee machine.
Now, for obvious security reason, you can’t attach a debugger to an application that is running in the cloud. So when doing your development and debugging, you’re going to want to do as much of it locally as you can. To do this, your of course going to need a local version of the Fabric to run your applications in. The Azure Development Fabric is where local applications will be deployed, spun up by Visual Studio when you press the debug button. Just keep in mind that this local “emulator” (for lack of a better term) may not always behave exactly like the real thing. So while local debugging is helpful, final testing should still be performed once the application has been deployed into the cloud.
Last topic for today is something I touched on a a couple paragraphs ago… The Fabric will configure the the virtual machines based on the type of application you are deploying. In Windows Azure, there are currently two applications types, called roles, that are supported. The Web Role is an ASP.NET based application. It can be a web service or public facing web page. An application built on the Worker Role is more like an NT Service. It runs continually, great for long running processes. A key difference between these two roles is that the web role can accept inbound communications whereas the Worker Role cannot. The Worker Role can call out, but can’t be called too. Communications to a Worker Role application can be done via the topic of our my next post, Azure Storage.