Worker Role vs Web Job

Question

From what I understand both run small repeatable tasks in the cloud.

What reasons and in what situations might I want to choose one over the other?

Pulley

Answer 1

Some basic information:

WebJobs are good for lightweight work items that don't need any customization of the environment they run in and don't consume very much resources. They are also really good for tasks that only need to be run periodically, scheduled, or triggered. They are cheap and easy to setup/run. They run in the context of your Website which means you get the same environment that your Website runs in, and any resources they use are resources that your Website can't use.

Worker Roles are good for more resource intensive workloads or if you need to modify the environment where they are running (ie. a particular .NET framework version or something installed into the OS). Worker Roles are more expensive and slightly more difficult to setup and run, but they offer significantly more power.

In general I would start with WebJobs and then move to Worker Roles if you find that your workload requires more than WebJobs can offer.

Radian

Nice to know...even if i deal with a cloud service (web role) I could begin with a webjob to do background processing (lightweight) and later switch to workerrole as needed. WorkerRole need not always be the default choice. Since worker role comes along with the cloud service template, and a web job is a different thing (from the template perspective), this may not be too obvious. Thanks! – Easterner

Answer 2

If we are to measure "power" as computational power, then in a virtual environment, this translates to how many layers are on top of the physical machine (the metal). The user code on a virtual machine runs on top of a hypervisor, which manages the physical machine. This is the thickest layer. Whenever possible the hypervisor tries to simply serve as a pass-through to the metal.

There is fundamentally little overhead for WebJobs. It is sandboxed, OS is maintained, and there are services & modules to make sure it runs. But the application code is essentially as close to the metal as in Worker Roles, since they use the same hypervisor.

If what you want to measure is "flexibility", then use Worker Roles, since it is not managed or sandboxed, it is more flexible. You are able to use more sockets, define your own environment, install more packages, etc.

If what you want is "features", then WebJobs has a full array of features. Including, virtual-networking to on-prem resources, staging environments, remote debugging, triggering, scheduling, easy connection to storage and service bus, etc...

Most people want to focus on solving their problem, and not invest time in infrastructure. For that, you use WebJobs. If you do find that you need more flexibility, or the security sandbox is preventing you from doing something that can't be accomplished any other way, then move to Worker Roles.

It is even possible to build hybrid solutions where some parts are done in WebJobs and others are done in Worker Roles, but that's out of the scope of this question. (hint: WebJobs SDK)

Aplacental

"Most people want to focus on solving their problem, and not invest time in infrastructure. For that, you use WebJobs." - that's true, but worker roles involve more cost than web jobs. That means, people select what they need and what's in their budget, which is fair! – Simms

Answer 3

Somethings to remember when choosing to use a Web Job or a Worker Role:

• A Worker Role is self hosted on a dedicated VM, a Web Job is hosted in a Web App container.

• A Worker Role will scale independently, a Web Job will scale along with the Web App container.

Web Jobs are perfect for polling RSS feeds, checking for and processing messages and for sending notifications, they are lightweight and cheaper than Worker Roles but are less powerful.

Curtsey