Azure Webjobs and functions explained

Recently I had questions from my customers asking the differences between Azure web jobs VS Functions. At Prometix we have developed numerous Azure based applications and here is my thought.

In the early days, Azure was a thin veneer over virtual machines, and since then it has grown to the point where,  you need to choose which service to use to host your code. From virtual machines to Azure Functions, we can tune just how much abstraction there is between our application code and the hardware. This article is about picking between two of the abstractions that run furthest from the hardware: WebJobs and Azure Functions.

App Service

Let’s start by talking about App Service, which is the technology that underlies both of these offerings. App Service started its life as a way of hosting applications inside of IIS (Internet Information Services) on Windows. The separation between the applications was provided by IIS and, as such, the configurability and isolation of these services were pretty limited.

However, the cost of those hosting sites was very low. At first, the capabilities were limited to hosting applications in IIS, but this soon changed.

One of the more common requirements for web applications is to be able to run background tasks. Batch processing, scheduled tasks, and long-running processes are all common in modern applications. The issue with running these on IIS is that it consumes one of the precious threads dedicated to serving content and the process may be interrupted by an app pool recycle. There are, of course, some tricks to push off app pool recycles until your task has completed, but ideally, we’d like to run the task outside of IIS. WebJobs were created to provide this capability. Developers can call out to a WebJob via a messaging system such as Storage Queues or Azure Service Bus and have it complete the task while the main application continues on.

WebJobs

WebJobs were the first attempt to solve this problem. WebJobs have built-in triggers for a number of different events inside of Azure: storage queues, blobs, service bus queues, topics and schedule triggers. This means that it is possible, even easy, to set up a WebJob that monitors a blob storage account for new items. Upon discovering a new item, it will be launched to process it.

Deploying WebJobs is quite easy since they deploy using the same infrastructure as any App Service. This allows deploying from source control, FTP, or even Dropbox (but please don’t do that). Deploying from Visual Studio is also possible (again, please don’t do that), although you’re much better off deploying from a continuous build tool such as TeamCity or Visual Studio Team Services (VSTS).

Azure Functions

Azure Functions take the concepts from WebJobs and expand on them. First, Functions enable a whole raft of new trigger types. It is now possible to trigger on such things as Cosmos DB’s change feed, Event Hubs, and WebHooks. As a web developer, the HTTP trigger is one of the most interesting. HTTP triggers enable building an entire website or web application entirely with triggers.

More interesting than the triggers is the change in hosting model. WebJobs are tightly coupled with the App Service plan that hosts them. This means that if you have one WebJob of 20 in a plan that requires additional resources, your only option is to scale the entire App Service plan.

This brings a lot of overhead since now each instance of the App Service is running all the WebJobs. Functions can be deployed using this same model, which may be desirable if you have few to deploy and an existing App Service, or they can be deployed in a pay-per-use model that some refer call Functions as a Service (FaaS) or serverless.

It is paramount that choosing right technology for the correct requirements. Otherwise the model will not cost effective and not serve the purpose.

If you are interested in developing solutions as part Azure environment using. Please contact Prometix for any assistance – enquires@prometix.com.au