Running Windows Services in Azure: introducing WebJobs

in Software Engineering, DevOps

Context

Azure WebJobs allow you to create the equivalent of a continuously running Windows Service or a one off/scheduled task (depending on how you configure it), hosted in Azure using its main strength, the Web Apps.
Each Web App can contain one or many WebJobs - even if it doesn't have an actual Web App on it. In our case for example we needed a quick way of deploying a tiny RabbitMQ Listener on Azure (something we'd normally do as a Windows Service), and WebJobs answered our need perfectly.

Prerequisites

Assuming you work with Visual Studio, you should download the Azure SDK for .NET - this will allow you to create a project of type “Azure WebJob” which will make your life easier. Although this is not necessary, you could just create a simple console app, and download the NuGet package “Microsoft.Azure.WebJobs”.

Azure WebJob project in Visual Studio

You also - obviously - need an Azure Subscription that allows you to create a Web App plan, and a Web App inside of it. You don't need a big pricing plan, the free one is more than enough for a Micro Service.

Analysis of the project

Once you've created the Azure WebJob project, here's what it should look like:

Project layout in VS

It is essentially a Console App: you'll recognise the classic Program.cs file, and you'll also notice the new Functions.cs file. Let's have a deeper look at them.

Program.cs:
using Microsoft.Azure.WebJobs;

namespace WebJobProject  
{
    // To learn more about Microsoft Azure WebJobs SDK, please see http://go.microsoft.com/fwlink/?LinkID=320976
    class Program
    {
        // Please set the following connection strings in app.config for this WebJob to run:
        // AzureWebJobsDashboard and AzureWebJobsStorage
        static void Main()
        {
            var host = new JobHost();
            // The following code ensures that the WebJob will be running continuously
            host.RunAndBlock();
        }
    }
}

Nothing fantastic here. static Main method, called as an entry point to the executable produced as an output when building the project.

The JobHost class comes from the Microsoft.Azure.WebJobs package, and basically means that you're creating a container for your job in memory. Then there's a call to RunAndBlock(); which is an instruction for the container to run all the registered jobs, and block (loop indefinitely) until further instructions are received.
The question now is, how do we register jobs?

Functions.cs
using System.IO;  
using Microsoft.Azure.WebJobs;

namespace WebJobProject  
{
    public class Functions
    {
        // This function will get triggered/executed when a new message is written 
        // on an Azure Queue called queue.
        public static void ProcessQueueMessage([QueueTrigger("queue")] string message, TextWriter log)
        {
            log.WriteLine(message);
        }
    }
}

To put it simply: the file and the name of the class don't matter, what matters is having a public class with a public static method containing the [QueueTrigger] attribute in its parameters. This attribute is what will flag your method as a Job, nothing else.
WebJobs come with a lot of different triggers other than [QueueTrigger]. We're not going to address these in this article, but they're all fairly well documented.

Simple "click" deployment

The Azure SDK for Visual Studio allows you to do very simple "click" deployment to Azure. You can do so by right-clicking on your project, a "Publish as Azure WebJob" button appears, opening the following menu when you click on it:

Publish as Azure WebJob

The "Run Continuously" default option is what we want here so we'll leave it as is. You can of course configure your WebJob to run on a specific schedule, as if you were configuring a Windows Scheduled Task, for example.

Clicking "Ok" opens a menu with 2 options : "Microsoft Azure App Service" or "Import". We want to select "Microsoft Azure App Service", which opens the following menu:

Azure Publish Menu

Here you should be able to select your subscription, and find the Web App you want to publish to, opening another menu that will let you enter information for the website on the web app. Which doesn't matter, since we're not interested in the web app itself, so I'd just leave the default values.

And that's it, your WebJob is deployed, you should be able to see it via the Azure Portal in your Web App => Settings => WebJobs:

Azure Web App Menu

Laurent Humbert's Picture

Laurent Humbert

Professional Software Developer. Also french guy lost in Manchester, mostly doing back end stuff and playing games.
@LaurentHbt