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 ?
There are a couple options here within App Service. I won't touch on Logic Apps or Azure Automation, which also touch this space.
This article is honestly the best explanation, but I'll summarize here.
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:
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:
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:
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-premises or other cloud environments, 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 extensibility work, but that's secondary to the core purpose.
Summary:
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 performance 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.