Azure Webjobs vs Azure Functions : How to choose

192
votes

I've created some Azure Webjobs that use triggers and I've just learnt about Azure Functions.

From what I understand Azure Functions seem to overlap with Azure Webjobs features and I have some difficulty to understand when to choose between Function and Webjob:

  • Unlike Webjobs, Functions can only be triggered, it hasn't been designed to run continuous process (but you can write code to create a continuous function).

  • You can write Webjobs and Functions using many languages (C#, node.js, python ...) but you can write your function from the Azure portal so it is easier and quicker to develop test and deploy a Function.

  • Webjobs run as background processes in the context of an App Service web app, API app, or mobile app whereas Functions run using a Classic/Dynamic App Service Plan.

  • Regarding the scaling, Functions seems to give more possibilities since you can use a dynamic app service plan and you can scale a single function whereas for a webjob you have to scale the whole web app.

So for sure there is a pricing difference, if you have an existing web app running you can use it to run a webjob without any additional cost but if I don't have an existing web app and I have to write code to trigger a queue should I use a webjob or a Function ?

Is there any other considerations to keep in mind when you need to choose ?

8
azureazure-webjobsazure-functions
This is a blog post I owe. :) I'll try to prepare a response, but this may be a bit open ended for Stack Overflow, so you may need to ask this on MSDN if it gets closed. – Chris Anderson-MSFT
Nice (short) blog post on this topic geekswithblogs.net/tmurphy/archive/2016/06/02/… – Todd Menier
@chris-anderson-msft Can we run PowerShell as webjob? Can we install PowerShell package on Webjob? – anomepani

8 Answers

186
votes

There are a couple options here within App Service. I won't touch on Logic Apps or Azure Automation, which also touch this space.

Azure WebJobs

This article is honestly the best explanation, but I'll summarize here.

On Demand WebJobs aka. Scheduled WebJobs aka. Triggered WebJobs

Triggered WebJobs are WebJobs which are run once when a URL is called or when the schedule property is present in schedule.job. Scheduled WebJobs are just WebJobs which have had an Azure Scheduler Job created to call our URL on a schedule, but we also support the schedule property, as mentioned previously.

Summary:

  • + Executable/Script on demand
  • + Scheduled executions
  • - Have to trigger via .scm endpoint
  • - Scaling is manual
  • - VM is always required

Continuous WebJobs (non SDK)

These jobs run forever and we will wake them up when they crash. You need to enable Always On for these to work, which means running them in Basic tier and above.

Summary:

  • + Executable/Script always running
  • - Requires always on - Basic tier and above
  • - VM is always required

Continuous WebJobs with the WebJobs SDK

These aren't anything from a "WebJobs the feature" point of view. Essentially, we have this sweet SDK we wrote targeting WebJobs which lets you execute code based on simple triggers. I'll talk about this more later on.

Summary:

  • + Executable/Script always running
  • + Richer logging/dashboard
  • + Triggers supported along with long running tasks
  • - Requires always on - Basic tier and above
  • - Scaling is manual to set up
  • - Getting started can be a bit tiresome
  • - VM is always required

Azure WebJobs SDK

Azure WebJobs SDK is a completely separate SDK from WebJobs the platform feature. It's designed to be run in a WebJob, but can really be run anywhere. We have customers who run them on worker roles and even on prem or other clouds, though support is only best effort.

The SDK is just about making it easy to run some code in reaction to some event and make binding to services/etc. easy. This is honestly best covered in some docs, but the heart of it is that "event" + "code" nature. We've also done some cool extensiblity work, but that's secondary to the core purpose.

Summary:

  • Most of these are mentioned above
  • + You can extend and run whatever you want. Full control.
  • - HTTP stuff is a little wonky, but it works

Azure Functions

Azure Functions is all about taking that core purpose of the WebJobs SDK, hosting it as a service, and making it easy to get started with other languages. We also introduce the "Serverless" concept here because it made a lot of sense to do so - we know how our SDK scales, so we can do intelligent things for you.

Azure Functions is a very heavily managed experience. We aren't supporting bringing your own host. Currently, we don't support custom extensions but its something we're investigating. We're opinionated about what you can and can't do, but for the things we enable, they are slick, and easy to use and manage.

Most of the "framework" things we've done to improve Functions go through the WebJobs SDK, though. For instance, we'll be uploading a new NuGet for WebJobs which really drastically increases the speed of logging, which has huge perf benefits for WebJobs SDK users. In shipping Functions as "WebJobs SDK as a Service" we've really improved a lot of experience issues.

I'm probably biased since Functions is our latest and greatest, but feel free to shoot more cons for Functions my way.

I'll probably end up publishing a blog which elaborates a bit more, but I tried to keep this as succinct as possible for this forum.

17
votes

Being Azure Functions based on the WebJobs SDK, they provide most of the functionality already available in WebJobs, but with some new cool capabilities.

In terms of triggers, in addition to those already available for WebJobs (e.g. Service Bus, Storage Queues, Storage Blobs, CRON schedules, WebHooks, EventHub, and File Cloud Storage providers), Azure Functions can be triggered as APIs. And HTTP calls don't require kudu credentials, but can be authenticated via Azure AD and third-party identity providers.

In regard to outputs, the only difference is that Functions can return a response when called via HTTP.

Both support a wide variety of languages, including: bash (.sh), batch (.bat / .cmd), C#, F#, Node.Js, PHP, PowerShell, and Python.

Being Functions currently in Preview, tooling is still not ideal. But Microsoft is working on it. Hopefully we get the same flexibility of developing and testing Functions locally as we currently do for WebJobs with Visual Studio.

The most significant and cool advantages brought by Functions is the alternative of having a Dynamic Service Plan with a "Serverless" model, in which we don't need to manage VM instances or scaling; it's all managed for us. Additionally, by not having dedicated instances, we only pay for the resources we actually use.

A more detailed comparison between the two here: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

16
votes

I would like to add two more point to the above long & little bit old posts. if you choose consumption plan in azure functions, below are the limitations

If you want to run any jobs more than 10 minutes choose webjobs. Azure functions, runs only for 5 minutes by default, if your process exceeds 5 minutes, then azure function throws timeout exception. You can increase the timeout to 10 minutes in host.json.

Note: There is no timeout problem if you are using app service plan azure functions.

Another reason to distinguish is. if you use azure function, then your initial start time will be slow because the machines(containers) are created on the fly and destroyed once it is used.

To avoid cold start, azure function app have released premium plan, where one instance will be running all the time and based on the load the function app will start scaling and you will be billed for one instance and other instances based on consumption.

14
votes

According to the docs Azure Functions has the following that WebJobs doesn't:

  • Automatic scaling (CPU and memory is scaled according to needs determined at runtime)
  • Pay-per-use pricing (Consumption plan instead App Service plan)
  • More trigger events (like WebHooks)
  • In-browser development (Visual Studio still possible)
  • F# support

Simply put: Azure Functions is the newer animal. If you don't already have an App Service plan I'd go with Functions because for the long-term I don't see any reasons why starting with WebJobs would be better (Functions tooling might not be already as stable though).

7
votes

I realize I'm very late to the game with this answer but since this is still a top search result on Google, I wanted to give some guidance on this topic strictly from a cost perspective since it seems that the OP has some concerns about cost. There are already some great answers here that talk about the technical limitations and details of how each service works, so I am not going to rehash those answers.

If you absolutely need something that runs for "free" (as in no additional cost to what you've already paid for your web app) then you have two options:

  1. Webjobs - deployed alongside your existing web app and uses the same resources as your web app. There is no additional monetary cost to use webjobs but there are some limitations as already mentioned that can lead to performance costs on your web app.
  2. Functions - When using the consumption plan, you are allotted a certain amount of free executions. The number at the time of this writing is actually quite high, 1 million free executions. However, the 1 million execution limit is not the limit that is likely to give you trouble; it's the 400K GB-s (gigabyte seconds). This is basically a calculation of the amount of memory your function uses multiplied by the number of seconds it runs (see the official calculation on the pricing page here). You will be surprised how quickly this free allotment gets used up.

If you are concerned about costs but not limited to no costs at all, then you have more options available.

  1. Functions - You can run either in the consumption plan or the app service plan for a relatively inexpensive price. Keep in mind though, the GB-s billing model. If you are using the consumption plan and are doing frequent, "heavy" work - you might be surprised with a big bill.
  2. Cloud Services - This options hasn't been discussed as an alternative, mainly because the OP didn't ask about it. But this is also a viable option. Cloud services are ultimately just VMs running in the cloud so you can run whatever background jobs you need on them and they scale up/down pretty well (although you have to wire up your own triggers for execution, a slight inconvenience compared to webjobs/functions). They have more initial cost associated with them (because you pay per instance whether you use it or not) but if you have jobs that need to run constantly and are doing a lot of "heavy" lifting, then cloud services might be a better choice because it is easier to manage/monitor a fixed priced VM than executions and gigabyte seconds, in my opinion. The other nice thing about cloud services is that you never have to worry about timeouts or some of the other limitations mentioned in previous answers.

If you are interested in reading through some specific scenarios and why I would choose one (webjobs, functions, cloud services) over the other, I just recently wrote a blog post on webjobs vs functions vs cloud services.

3
votes

A major consideration is that Azure Functions quit supporting the full .NET Framework after version 1, which was discontinued with v2.0, and which will not be changing in the now in preview v3.0. 😔

Meanwhile, this strong armed approach was thankfully not applied -- yet -- to Azure WebJobs:

Version 3.x of the WebJobs SDK supports both .NET Core and .NET Framework console apps.

2
votes

I would like to give what are the commonalities and differences between the two Azure functions are built on top of AppService and WebJobs SDK. WebJobs SDK will give you more freedom to play with while Azure functions are more structured with fewer responsibilities for the developers.

When you look at the commonalities Both uses the function-oriented programming mode, bindings for trigger/input/output, support external libraries and can run and debug locally Supportruntime toiletries.

Differences

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------

enter image description here

1
votes

One answer I always found for this question was You can Customize Host in Azure WebJobs but you cant Customize the host of Azure Functions,

An example for this is "In a WebJob, you can create a custom retry policy for calls to external systems."

This kind of policy can't be configured in an Azure Function.