Understanding Windows Azure Runtime: Part II

Monday March 05, 2012 , 5 min Read

In part I of the article, I introduced the concepts and terminology of Windows Azure runtime. In this part, we will take a closer look at the Roles and the way to control the lifecycle of the Roles.

Most of the modern applications are logically partitioned into individual layers. Each layer is responsible for a specific function. UI rendering, business logic, data access and database are the common layers of these applications. These layers may or may not be running on dedicated machines. For maximum scalability, each layer can run on a cluster of machines or all these layers can be running on the same machine. Windows Azure Roles are modeled around these application layers or tiers. Each role instance is actually a dedicated Azure VM. Based on the role, the VM is customized for specific tasks.

Let’s understand more about Windows Azure Roles.

Web Role– This is a VM that is designed to primarily host web applications. Whatever layer you host on IIS can be easily moved into the Web Role. Earlier, Web Role ran the Hosted Web Core (HWC) to host web applications. That’s the reason why you couldn't host multiple websites within one Web Role. Now with Web Role supporting IIS 7.x, it brings parity with the on-premise deployment scenarios. Web Role can also host WCF services and CGI applications like PHP and Perl. They only support HTTP/S based communication.
Worker Role – This Role is typically mapped to the application tier or the business logic layer of the application. Though Worker Roles can expose TCP, HTTP/S endpoints, they are mostly reached via the Web Role. Worker Role will never have any UI and does the ‘heavy lifting’ required by the application. They can execute external processes and act as a surrogate process for legacy executables. Worker Roles are used to bootstrap other runtimes like Java and Python. They can also host databases like MySQL or MongoDB and expose the ports of these database servers as external endpoints.
VM Role – This is the new Role that got announced at PDC 2010. This is used to host legacy applications that do not fit into Web Role or Worker Role. We will get more details once the VM Roles go into the CTP mode. Since it is too early to include this in the discussion, I am not going to discuss this in detail.

The lifecycle of the role is managed by the Windows Azure runtime. There are certain implicit and explicit factors that may force the runtime to reboot or re-launch the role instances. Implicit factors are internal to Azure environment and explicit factors are those that are initiated through the change in configuration files or by performing an in-place upgrade. As developers, it is important for us to know when the instance is going to be recycled and how to gracefully handle these changes.

Worker Roles implement an abstract class called RoleEntryPoint. This is optional for Web Roles but is mandatory for Worker Roles. RoleEntryPoint is the prescriptive interface between the Windows Azure Runtime and the Role instances. This interface has three methods – 1) OnStart(), 2) Run() and 3) OnStop(). During the initialization of a Role, the OnStart() method is called. To ensure that the Role is ‘awake’ all the time, there is a while(true) construct in the Run() method. This is comparable to the static void main() method in a classic C# program. After exiting from the Run() method, the Windows Azure environment calls the OnStop() method. This is where the cleanup code will be placed.

Implementing RoleEntryPoint class is optional in a Web Role because of a few reasons. Web Roles function in a typical Request/Response pattern and may not long running processes. Web Roles also rely on ASP.NET lifecycle management methods for initialization and clean up. Technically, Web Roles can be forced to act like Worker Roles by implementing the RoleEntryPoint class and overriding the required methods. This is particularly useful in scenarios where an extra Worker Role is not required and the Web Role can easily manage few other tasks including processing messages. Steve Marx has written an excellent post discussing the scenario for combining roles.

By overriding the methods of RoleEntryPoint we can make Worker Roles very efficient and intelligent. Within the OnStop() method, the state of the Role can be dumped into a Azure Table. During the startup phase of the Worker Role, we can read the previous state of the application from an Azure Table and continue from the same point where the last execution was left. It is entirely possible to externalize the tasks of Worker Role to Azure Storage and every time the Worker Role boots, it will learn what it is supposed to execute by querying an external state machine. This will be the basis of building efficient Map/Reduce scenarios on Windows Azure.

Windows Azure Runtime also offers mechanism to intercept and control the reboot of the Roles. This done by subscribing to the RoleEnvironment.Changing, RoleEnvironment.Changed and RoleEnvironment.Stopping events. By detecting the factor that forced the event to take place, we can either reboot and cancel the reboot and continue with the process. I will cover the factors and conditions that typically force a reboot in a separate article.

I want to summarize this article with a few tips on leveraging the RoleEntryPoint and RoleEnvironment classes –

OnStart()Wire-up event handlers in the OnStart() method
Initialize Azure storage and perform mandatory check of resources
Initialize Windows Azure Diagnostics
Run()Never exit the Run() method as the OnStop() method is called immediately and the Role will be terminated
Try to parallelize and multithread the operations in the Run() method
OnStop()Only perform quick cleanup in OnStop() that doesn’t take too long
The method must return within 30 sec. or there will be a forced shutdown