Chapter 15. Processing with worker roles

In Azure there are two roles that run your code. The first, the web role, has already been discussed. It plays the role of the web server, communicating with the outside world. The second role is the worker role. Worker roles act as backend servers—you might use one to run asynchronous or long-running tasks. Worker roles are usually message based and will usually receive these messages by polling a queue or some other shared storage. Like web roles, you can have multiple deployments of code running in different worker roles. Each deployment can have as many instances as you would like running your code (within your Azure subscription limits).

It’s important to remember that a worker role is a template for a server in your application. The service model for your application defines how many instances of that role need to be started in the cloud. The role definition is similar to a class definition, and the instances are like objects.

If your system has Windows services or batch jobs, they can easily be ported to a worker role. For example, many systems have a series of regularly scheduled backend tasks. These might process all the new orders each night at 11 p.m. Or perhaps you have a positive pay system for banking, and it needs to connect to your bank each day before 3 p.m., except for banking holidays.

15.1. A simple worker role service

15.2. Communicating with a worker role

15.3. Common uses for worker roles

15.4. Working with local storage

15.5. Summary