What is Azure WebJobs?

Azure WebJobs is a service that is located within an Azure Web App Service suite and which will allow us to carry out scheduled or continuous tasks. We could compare it to an old Windows service.

 


You can create two types of Web Job, continuous execution or scheduled. The latter in turn can be one-time execution (triggered), run periodically until an expiration date or run periodically indefinitely. Triggered Web Jobs are those that are executed once when a URL is called or when the programming property is present in schedule.job.
Scheduled WebJobs are only WebJobs that have created an Azure work planner to call our URL according to a schedule. It has as advantages, that it can be executed through a request with a script, or executed in a programmed way, and its disadvantages is that it has to be triggered through an endpoint, the scaling is manual, it can not be remotely debugged and it always requires a VM or WebApp.

Continuous webjobs starts immediately when the WebJob is created. To prevent the work from ending, the program or script usually works within an endless loop. If the work is finished, it is possible to restart it, as, this type of Webjob, if it can be debugged then one of its disadvantages is that a VM or WebApp is always necessary.
Another disadvantage, which its possible to solve over time, is its null compatibility with .Net Core, which means that we have to “cheat” in order to simulate a WebJob.

What is Azure Functions?

Azure Functions is a solution to easily execute small code fragments, or “functions”, in the cloud. You can simply write the code you need for the problem in question, without worrying about the entire application or the infrastructure to run it. Azure Functions are server less, that is, they don’t have a server. The costs incurred are always due to the time taken to execute the programmed functions.

Azure Functions is an excellent solution to process data and integrate systems, as well as to work with the Internet of Things (IoT) and generate simple APIs and microservices. You can use Functions for tasks such as image processing or orders, file maintenance or for tasks that you want to run according to a schedule.

The best features of Azure Functions, are the following:

• Language option: write functions using the C#, F# or Javascript language.
• Pay per use: only pay for the time you have spent executing the code
• Bring your own dependencies: Azure features supports NuGet and NPM, so you can use your favourite libraries.
• Integrated security: protect the functions triggered by HTTP with OAuth providers such as Azure Active Directory, Facebook, Google, Twitter and Microsoft account.
• Flexible development: code functions directly in the portal or configure continuous integration and implement the code through GitHub, Visual Studio Team Services and other compatible development tools.

Azure functions has great facility for integrating with Azures ecosystem, currently, the following integrations exist:
• Azure Cosmos DB
• Azure Event Hubs
• Azure Event Grid
• Azure Mobile Apps (tables)
• Azure Notification Hubs
• Azure Service Bus (queues and themes)
• Azure Storage (blob, queues and tables)
• GitHub (webhooks)
• Local (through Service Bus)
• Twilio (SMS messages)

Very good, but which one do I choose?

We already know what both services are, but which one is more suited to our needs?

Lets start from the premise, you need to have a WebApp to host a Webjob, which means fixed monthly expenses, but you might think, I already have a WebApp, where I host my WebJob, and you’ll be right, but that means that the scaling of your WebApp is associated with your WebJob, and that can lead to uncontrolled expenses or consume your WebApp resources.

On the other hand, Azure Functions is Server less, that is, it doesn’t have a server, and we would only pay for the time it takes to process the Azure function, up to a processing limit of 4 minutes.

Why do I start here? Because the way I see it, there’s no other choice today, than to use Azure Functions instead of Webjobs. Let me explain. Imagine that you have processing, which runs every 5 minutes, and that your processing time is 2 minutes each time it runs. This implies that, if we used an Azure Function, the billing would be very high, due to the processing time of our logic, with which we would be more interested in a WebJob, hosted in an independent WebApp, in order to scale without influencing other services, because we would know its monthly cost and we wouldn’t get a nasty surprise at the end of the month.

Because if we look at the rest of the features, nothing attracts us to WebJobs over Azure Functions. In Azure Functions you pay for use (and you can usually perform functions, so they run quickly), Azure Functions scales independently, since it is completely decoupled from your infrastructure, we can remotely debug in both, we can create our Functions/WebJobs in Our Local IDE and then deploy it in Azure, Azure Functions is fully compatible with Net Core, which WebJobs is not. Azure Funtions inherits all of Webjobs functions, which will be compatible with everything we would like to do with WebJobs. If our infrastructure is Azure, Azure Funtions quickly integrates with most of Azures services.

In conclusion, I believe that up until now it wasn’t a fair battle, so we offer Azure functions in comparison to Webjobs.

Written by: Alberto Picazo