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
Comments
Post a Comment