This post is based primarily on David Chappell’s recent white paper
Windows Azure requires a DIFFERENT programming model
This is because Azure is a Paas (Platform as a Service) in the cloud, not just VMs / IaaS (Infrastructure as a Service) in the Cloud. Most of a Windows developer’s skills still apply; however, there are clear differences.
THE THREE RULES OF THE WINDOWS AZURE PROGRAMMING MODEL
To get the benefits it promises, the Windows Azure programming model imposes three rules on applications:
Rule 1: Built from one or more roles. Web roles, Worker roles and coming soon…VM roles
Rule 2: Runs multiple instances of each role.
Rule 3: Behaves correctly when any role instance fails.
Windows Azure can run applications that don’t follow any / all of these rules—it doesn’t actually enforce them. Instead, the platform simply assumes that every application obeys all three. If you do not understand and follow the model’s rules, the application may not benefit from Azure.
A role includes a specific set of code, such as a .NET assembly, and it defines the environment in which that code runs. Windows Azure today lets developers create two different kinds of roles:
- Web role: As the name suggests, Web roles are largely intended for logic that interacts with the outside world via HTTP. Code written as a Web role typically gets its input through Internet Information Services (IIS), and it can be created using various technologies, including ASP.NET, Windows Communication Foundation (WCF), PHP, and Java.
- Worker role: Logic written as a Worker role can interact with the outside world in various ways—it’s not limited to HTTP. For example, a Worker role might contain code that converts videos into a standard format or calculates the risk of an investment portfolio or performs some data analysis.
And coming soon…
- Virtual Machine (VM) role: A VM role runs an image—a virtual hard disk (VHD)—of a Windows Server 2008 R2 virtual machine. This VHD is created using an on-premises Windows Server machine, then uploaded to Windows Azure. The VHD can then be loaded on demand into a VM role and executed.
All three roles are useful. The VM role was announced at PDC2010, and not available as on date.
A typical application should use Web roles to accept HTTP requests from users, then hand off the work requested by users to a Worker role. The primary reason for this two-part breakdown is that dividing tasks in this way can make an application easier to scale. It’s also fine for a Windows Azure application to consist of just a single Web role or a single Worker role—you don’t have to use both. A single application can even contain different kinds of Web and Worker roles. For example, an application might have one Web role that implements a browser interface, perhaps built using ASP.NET, and another Web role that exposes a Web services interface implemented using WCF. Similarly, a Windows Azure application that performed two different kinds of data analysis might define a distinct Worker role for each one.
A developer can tell Windows Azure how many instances of each role to run through a service configuration file. Every instance of a particular role runs the exact same code. In fact, with most Windows Azure applications, each instance is just like all of the other instances of that role—they’re interchangeable. Windows Azure automatically load balances HTTP requests across an application’s Web role instances. This load balancing doesn’t support sticky sessions, so there’s no way to direct all of a client’s requests to the same Web role instance. Storing client-specific state, such as a shopping cart, in a particular Web role instance won’t work, because Windows Azure provides no way to guarantee that all of a client’s requests will be handled by that instance. Instead, this kind of state must be stored externally.
An application that follows the Windows Azure programming model must be built using roles, and it must run two or more instances of each of those roles. It must also behave correctly when any of those role instances fails. A role can fail if the computer it is running on fails, if the physical network connection to that machine fails etc. etc. The failure might cause the application to run more slowly, but as seen by a user, it still behaves correctly. This requirement to work correctly during partial failures is fundamental to the Windows Azure programming model. If all instances of a particular role fail, an application will stop behaving as it should—this can’t be helped. In fact, the service level agreement (SLA) for Windows Azure requires running at least two instances of each role. Applications that run only one instance of any role can’t get the guarantees this SLA provides.
One more important point to keep in mind is that all of these rules also apply to applications that use VM roles. Just like the others, every VM role must run at least two instances to qualify for the Windows Azure SLA, and the application must continue to work correctly if one of these instances fails. Even with VM roles, Window Azure still provides a form of PaaS—it’s not traditional IaaS.
THE BENEFITS: IMPROVED ADMINISTRATION, AVAILABILITY, AND SCALABILITY
Applications built using the Windows Azure programming model can be easier to administer, more available, and more scalable than those built on traditional Windows servers.
The administrative benefits of Windows Azure flow largely from the fabric controller. Like every operating system, Windows must be patched, as must other system software. In on-premises environments, doing this typically requires some human effort. In Windows Azure, however, the process is entirely automated: The fabric controller handles updates for Web and Worker role instances (although not for VM role instances). When necessary, it also updates the underlying Windows servers those VMs run on.
The Windows Azure programming model helps improve application availability in the following ways:
- Protection against hardware failures. Because every application is made up of multiple instances of each role, hardware failures—a disk crash, a network fault, or the death of a server machine—won’t take down the application.
- Protection against software failures. Along with hardware failures, the fabric controller can also detect failures caused by software. If the code in an instance crashes or the VM in which it’s running goes down, the fabric controller will start either just the code or, if necessary, a new VM for that role.
- The ability to update applications with no application downtime. An application built using the Windows Azure programming model can be updated while it’s running—there’s no need to take it down. To allow this, different instances for each of an application’s roles are placed in different update domains. When a new version of the application needs to be deployed, the fabric controller can shut down the instances in just one update domain, update the code for these, then create new instances from that new code. Once those instances are running, it can do the same thing to instances in the next update domain, and so on. While users might see different versions of the application during this process, depending on which instance they happen to interact with, the application as a whole remains continuously available.
- The ability to update Windows and other supporting software with no application downtime. The fabric controller assumes that every Windows Azure application follows the three rules listed earlier, and so it knows that it can shut down some of an application’s instances whenever it likes, update the underlying system software, then start new instances. By doing this in chunks, never shutting down all of a role’s instances at the same time, Windows and other software can be updated beneath a continuously running application.
Availability is important for most applications—software isn’t useful if it’s not running when you need it—but scalability can also matter. The Windows Azure programming model helps developers build more scalable applications in two main ways:
- Automatically creating and maintaining a specified number of role instances. As already described, a developer tells Windows Azure how many instances of each role to run, and the fabric controller creates and monitors the requested instances. This makes application scalability quite straightforward: Just tell Windows Azure what you need.
- Providing a way to modify the number of executing role instances for a running application: For applications whose load varies, scalability is more complicated. Setting the number of instances just once isn’t a good solution, since different loads can make the ideal instance count go up or down significantly. To handle this situation, Windows Azure provides both a Web portal for people and an API for applications to allow changing the desired number of instances for each role while an application is running.
Getting all of the benefits that Windows Azure offers requires conforming to the rules of its programming model. Moving existing applications from Windows Server to Windows Azure can require some work, a topic I will address in more detail in a later post. For new applications, however, the argument for using the Windows Azure model is clear. Why not build an application that costs less to administer? Why not build an application that need never go down? Why not build an application that can easily scale up and down?