So, why would there be a need for different architectural patterns in Windows Azure?
One reason is for scalability. While it is still important to separate storage, presentation and business logic as in n-Tier architecture, we must adopt a slightly different approach if we want to achieve the scalability available to us on the cloud platform. Achieving this same level of scalability on-premises would often require a large capital investment in hardware as well as sometimes complex application enhancements. Further, if demand is not constant over time, much of the additional on-premises capacity goes unused.
On the other hand, a well architected Windows Azure app can easily scale based on requirements. It is this “elastic scaling” (both scale out and scale in) which allows an application to be right-sized depending upon the level of demand it sees. Elastic scalability – from small department sized apps to Internet class applications such as Facebook – is one of the key benefits of cloud computing.
Enter the “Asynchronous Web Role/Worker Role” Pattern
Arguably the simplest architectural pattern in Azure is the asynchronous web role/worker role. In this basic pattern there are one or more “web roles” and one or more “worker roles”. Azure provides a “Load Balancer” which distributes incoming Internet traffic for us transparently. The storage service provides persistence for our data and also provides a special type of storage (called “queues”) which can be used for communication between the different roles in our application.
Figure 1 The Asynchronous Web Role/Worker Role Pattern
The “web role” communicates with the outside world via the Internet. The web role is the client-facing part of our application. Sometimes (but not always) there is a user interface associated with a web role.
A “worker role”, on the other hand, typically operates behind the scenes. As the name suggests this is code which carries out some task asynchronously. This task may involve processing business logic, writing data to storage or carrying out a long running computation.
Web roles and worker roles communicate with one another via “queues”. A queue is a first-in first-out (FIFO) data structure that allows us to pass messages back and forth between different roles in our application.
It is a bit of an oversimplification, perhaps, but do you notice how web roles, worker roles and storage services can be somewhat similar in purpose to presentation, business and storage tiers?
(Note: Microsoft has enhanced Azure to allow for a greater variety of communication options between roles internally and with the outside world. This basic pattern still is very important, however, and will continue to be the foundation for many real-world systems deployed on Azure.)
Learning Tree’s Windows Azure course will explore web roles, worker roles, queues, storage and more! Doug Rhenstrom, the course author, is developing a hands-on exercise where attendees will build an application that exploits the web/worker role pattern described here. For a short demo of that application please check out this brief video:
You’ll want to attend our Windows Azure course, though, to really dive into the details of how this stuff actually works!