Azure webjobs helps us quickly develop, deploy, and run background tasks in cloud. Close integration with utility components cuts down the development time to half.
Traditionally, batch jobs are developed using 3rd party libraries like Hangfire or Quartz. Their is a lot of boilerplate coding, and heavy configurations required to implement these APIs. Creating Jobs, Schedules, Triggers, Logging, and Handling failure manually is laborious. Also, maintaining these parameters becomes a nightmare as application grows and scales.
However Azure Webjobs shifts the configuration burden from developers to the framework. For example, a batch job function can process a message from a queue with minimal specification. New messages in queue will automatically trigger delegated functions. All we have do is specify which queue to listen for. Based on the frequency and configuration (very little) – webjobs will automatically pool for the queue messages.
5 benefits of using Azure webjobs in cloud.
- Easy Setup.
- Faster Development.
- Seamless Deployment.
- Built-in Logging.
- Extensible Components.
Unlike custom batch jobs, we do not need to persist jobs and schedules in databases. The underlining webjobs framework will automatically manage for us. Any changes to these schedules, are automatically updated.
Like any other function, you can start writing your batch processing logic without the overhead of implementing any IJob or ISchedules. Infact you can write this function in any of languages Azure currently supports and upload it.
There 2 major methods to deploy webjobs.
- Zip up your code
- Upload it in the Azure app service.
- Select your schedules.
- Add Azure webjob to your project.
- Reference webjob to main project.
- Select your schedules.
Manual deploy could be used incases of smaller code bases, and functions that have a single responsibility.
Auto deploy will publish the web job everytime the project is deployed.
Azure portal actually logs all the run events of webjob functions automatically. These logs indicate important information like…
- Start, and end times when a webjob ran.
- Success or Failures status of a webjob.
- Context information like webjob id.
- Retrial attempts (incase of failures).
- Next due on (scheduled).
Extensible for components:
Webjobs in combination with each of the below components lessens boilerplate code.
- Email: Use SendGrid attributes to define your to, from, subject to send out e-mails.
- Sms: Use Twillo components on top of functions to send out sms as output as result of trigger. Like on receiving a queue message or at a schedule.
- Queues: Trigger a function listening to a queue for messages by declaring the queue name on the function. Webjob will pool according to the frequency of the data. This pooling could be adjusted in case of over-utilization.
- Blob: Trigger a function on receiving a blob or as output as blob. Blobs are serialized files. We can create blob object in any type of content we want.
- File: Trigger a function on file attribute changes or file creations.
- Timer: Run a function every often or on a schedule.
- No Automatic: Create a manual trigger function. Useful with Web API integration or with webhooks.