Roles and Instances
Overview
In order to ensure the benefits of this post are maximized I will level set by defining what roles and instances are as well as how they relate to each other.
A role in Windows Azure is really a blueprint that describes what an individual virtual machine will look like. The blueprint includes details such as the size of the virtual machine, ports and protocols that are allowed through the firewall and whether a port is exposed publicly. In order to simplify the definition of these roles many of the elements are defined through a service definition file that adheres to a defined XML schema.
One or more virtual machines that are based on a role can run at the same time. Each of these virtual machines is known as an instance.
When designing a solution that will run on Windows Azure it is a good practice to decompose your application into a set of core services. Each of these services should be considered potential roles, but keep in mind that sometimes two of these services are so closely related in scaling characteristics you may choose to consolidate them.
A role is the smallest unit of compute scale within Windows Azure, allowing you to change the number of instances that are running.
It is important to understand that roles are not durable, meaning that changes made during execution to the local file system or machine will be rolled back if the machine is reimaged. A machine may be reimaged at your discretion or in the case where the Windows Azure Fabric Controller deems it required. The reimaging could be triggered by hardware failures, software updates or other events. There are a few options for storing data such as files that we will cover in later posts.
The instances sit behind a load balancer that leverages a round robin algorithm resulting in the inability to ensure the next query from a consumer will access the same instance it previously did. This means that any operations coming in on the public ports should ideally execute in an atomic operation, only storing session state in mechanisms that are shared between all instances. For interrole communications the load balancer is not used, providing the ability to talk directly to a specified instance.
Role Types
Web Role – this role is based on either Windows 2008 Server or Windows 2008 R2 Server and runs Internet Information Server. This role defaults to exposing a single public HTTP endpoint on port 80, but others can be opened as required. Typical uses of this include running ASP.NET, PHP and CGI applications. This role can have patching of the Operating System set to automatic reducing administrative costs of the solution. This role supports startup tasks allowing for the silent install of applications or environment changes.
Worker Role – this role is based on either Windows 2008 Server or Windows 2008 R2 Server. This is geared towards generalized computing similar in nature to an EXE or Windows Service. By default this role does not expose any endpoints, but can be set to as appropriate. Typical uses include background processing or running third party applications. This role can have patching of the Operating System set to automatic reducing administrative costs of the solution. This role supports startup tasks allowing for the silent install of applications or environment changes.
VM Role – This role is in beta at the time of writing. This role is based on a Windows 2008 R2 Enterprise image built locally and uploaded. This role is still not durable as it could be reimaged as appropriate. This role is geared at scenarios where a required install takes a long period of time, requires user input or is fragile. This role does not have the ability to automatically patch the Operating System leaving updates to be made by the developer through the creation and application of differencing disks. In general I recommend people look at the Worker and Web roles prior to falling back to the VM role.
Scaling
Although the role is the smallest unit of deployment I tend to encourage people to create what is sometimes termed as a “Scale Unit”. The concept is that before deployment you benchmark a specific configuration of instance counts providing a known configuration to capacity scenario.
For Example:
In this scenario you create an expense processing system where your company’s employees will submit expenses through an ASP.NET web site (Web Role) and processing will occur later through a background process (Worker Role). You could initially benchmark the employee count that could be supported with two ASP.NET web sites (Web Role) and a single background process (Worker Role). If this benchmark showed that 2500 employees could be supported on this configuration you could say that your “Unit of Scale” is 2 Web Roles and 1 Worker Role. This means that if I run most of the month with 2500 users but on the last 2 days spike up to 7500 users I can run a single scale unit for most of the month and on the last 2 days bring two additional scale units online. This allows for easier proactive scaling.