Background business – Azure Worker role Vs Web Job

Importance of asynchronous work loads

Background processes play a key role in enabling distributed asynchronous computing. Background tasks have been used in the past to handle secondary workloads like logging, monitoring, scheduling and notifications, but today’s systems use background processing to improve user experience by decoupling User Interfaces from heavier tasks. Microsoft Azure provides two ways to host background tasks:

• Worker Roles (PaaS)
• Web Jobs (API apps. SaaS)

Worker Roles are dedicated virtual machines which can be pictured as an executable unit of work, unlike Web Jobs. Making a choice between these two technologies to host your background processes is an important design task.

Key differences

The key differences between Worker Roles and Web Jobs are shown below.

	Worker Role	Web Job
Hosting	Self-Hosted – Hosted on a dedicated virtual machine.	Web App hosted – hosted within a Web App container.
Coupling	Decoupled from frontends and middle tiers.	Coupled with Web App which is possibly hosting a web front end or middle tier.
Scalability	Independently scalable.	Scalable along with the Web App hosting it.
Remote Access	Supports remoting into the host VM.	Does not support remoting.
Deployment	Complicated deployment.	Simple deployment.
Configurability	High.	Low.
Triggers	All triggers have to be programmatically introduced.	Supports on-demand, scheduled and continuous triggers.
Management	Logging and diagnostics need to be coded in	Natively support detailed logging and diagnostics
Debugging	Difficult to attach Visual Studio debugger.	Easily attachable to Visual Studio debugger.
Pricing	Comparatively more expensive.	Comparatively cheaper.
Excepting handling	Unexpected shutdowns have to be programmatically handled.	Supports graceful shutdown.
Tenancy	Natively single-tenant.	Supports shared (multi-tenant) deployment.

Making your selection

Web Jobs are best suited for running lightweight tasks which require minimum environment customisation. Web Jobs supports Windows executables (cmd, bat, exe), PowerShell, Linux Shell Script, PHP, Python, JavaScript or Java files to be executed as background tasks.

Natively, Web Jobs support three types of triggers:

• On-Demand – Triggered externally. The Web Job SDK supports listening to Azure Storage tables, queues, blobs and Azure Service Bus queues for triggering a Job. An on-demand Job can also be manually triggered from the portal.
• Scheduled – Triggered based on a configured schedule. The scheduler used to trigger the job is decoupled from the Web Job itself.
• Continuous – Runs continuously. Starts when the Web Job starts. An endless loop needs to be explicitly written to keep the Job running infinitely.

Deploying a Web Job requires minimal plumbing and they are also easily managed.

The following scenarios are where Web Jobs can be a perfect fit:

• Polling RSS feeds
• Sending SMS notifications
• Asynchronous logging
• Archiving.

Worker Roles on the other hand are meant for heavier tasks which require a higher level of customisation. These are best suited for executing jobs which have dependencies on the Windows registry, environment variables or similar Windows infrastructure services.

A key advantage of using Worker Roles is the ability to execute start up tasks. Startup tasks can be used to prepare the execution environment to suit specific requirements. Worker Roles are hosted on a standalone virtual machine which offers more control to the operating environment. Because of this, a Worker Role may be a good choice where there is a requirement to remote in to the host virtual machine. However, making any change to the application image deployed on a worker role using remote desktop is not advisable as the change will not persist after role recycling. The deployment of a Worker Role takes more time compared to a Web Job.

Following are the scenarios where a Worker Role may be a better fit than a Web Job:

• Locked down environment which requires strong security boundaries to be set up before executing the task. Banks and other financial institutions usually have such requirements.
• Legacy workloads using COM components which require registration during start up.
• Completely decoupled task layer where the background tasks need to be scaled independently.

I hope you find this reference useful – feel free to share your own experiences in the comments section below.

Reference

https://azure.microsoft.com/en-us/documentation/articles/app-service-how-works-readme/