Ejecutando serverless tasks utilizando Azure WebJobs

Introducción

Una necesidad que emerge mucho cuando trabajamos en soluciones en la nube es el ejecutar background tasks. Quiero decir, tareas que son realizadas sin la intervención del usuario. Este tipo de tareas puede involucrar parseo y conversión de archivos, algo de procesamiento por lotes de datos, etc.

Para ello y como parte de su oferta en serverless computing, Azure nos permite desplegar WebJobs. Los Azure WebJobs se despliegan dentro del servicio AppService y pueden ser desarrolladas en .NET por lote de archivos, PowerShell, PHP, Python, Java y JavaScript.

Comenzando con WebJobs

Todo lo que necesitamos para tener un WebJob corriendo en Azure es seguir estos pasos:

• Crear un AppService
• Subir el artefacto de uno de los tipos soportados por WebJobs en la pestaña dentro de AppService

En el portal de Azure podemos especificar si el WebJob será ejecutado continuamente, programado (esto se puede especificar utilizando una expresión crontab) o si será realizado manualmente.

Otra de las opciones soportadas es ejecutar el WebJob utilizando un WebHook. Para esto, podemos enviar una llamada a HTTP POST con una URL provista, incluyendo en nuestra solicitud el usuario y contraseña. Esta información puede ser obtenida desde el popup de Propiedades en el portal de WebJob en Azure.

La posibilidad de ejecutar un WebJob utilizando WebHooks es útil cuando integramos con otro WebJob u otra función de Azure, en caso de procesos más complejos.

La página que utilizamos para desplegar un WebJob en el portal de Azure se ve así:

Usando el SDK de Azure WebJobs

Cuando desarrollamos en .NET Core utilizando WebJobs podemos aprovechar las características de Azure WebJobs SDK. El SDK facilita comenzar con WebJobs y nos permite declarar métodos a ser llamados en respuesta a eventos. Para ello, el SDK provee diferentes clases de ejecución que pueden ser utilizadas para decorar los métodos que queremos llamar.

Por ejemplo podemos declarar un método a ser ejecutado cada vez que un nuevo mensaje es recibido en la cola y llamarlo “testqueue“. El contenido del mensaje enviado a la cola será disponibilizado por medio del método por medio del parámetro “mensaje”. El código para este método se vería así:

public static void ProcessQueueMessage([QueueTrigger("testqueue")] string message, ILogger logger)
{
    logger.LogInformation(message);
}

También podemos declarar un método a ser ejecutado periódicamente, o en un intervalo que podemos definir utilizando una expresión crontab. El código para este método se vería así:

public static void ProcessTrigger([TimerTrigger("0 * * * * *")] TimerInfo timer)
{
    Console.WriteLine("Timer: " + DateTime.Now);
}

Las clases que están disponibles en Azure WebJobs SDK son las siguientes:

• BlobTrigger
• FileTrigger
• NoAutomaticTrigger
• QueueTrigger
• TimerTrigger

Además de declarar los distintos métodos decorados con clases de ejecución, tenemos que sumar código al método Main para así inicializar la infraestructura provista en el SDK. En este caso, estamos sumando servicios core de Almacenamiento en Azure Storage, este será para soportar el primer ejemplo de un método usando QueueTrigger y temporizadores Timers para soportar el segundo ejemplo de un método utilizando TimeTrigger.

<!-- wp:code -->
<pre class="wp-block-code"><code>static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =&gt;
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage();
        b.AddTimers();
    });
    builder.ConfigureLogging(b =&gt;
    {
        b.AddConsole();
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}</code></pre>
<!-- /wp:code -->

Para que este código corra correctamente necesitaremos sumar un setting que llamaremos “AzureWebJobsStorage” en nuestro archivo appsettings.json.

Otra cosa que vale la pena señalar es que el proyecto principal que tenemos que crear es una consola .NET. De todos modos en esa aplicación podemos referenciar todas las librerías y proyectos que queramos.

Esto implica tres cosas:

• Podemos diseñar nuestro WebJobs como hacemos usualmente para diseñar otra solución .NET, definiendo todas las capas que necesitemos así como también los componentes.
• Es posible compartir componentes entre diferentes aplicaciones WebJobs.
• No tenemos que decidir de antemano si queremos desarrollar un WebJob. Podemos desarrollar nuestra lógica e incluso los accesos a datos y llamadas a servicios con cada test unitario correspondiente sin tener que atar codigo relacionado al WebJob.

Para más información pueden dirigirse a:

https://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-get-started
https://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to

Testeando nuestro WebJobs con Azurite

Como fué señalado anteriormente, necesitamos tener una cuenta de almacenamiento provisionada en nuestra suscripción Azure para poder correr el WebJob. Adicionalmente, para WebJobs programados o continuos necesitamos setear AlwaysOn en el AppService. Esta opción no está disponible en la versión gratis de AppServices.

Esto significa que hay costos asociados a testear y desarrollar un WebJob.

De todos modos hay un emulador para Azure Storage llamado Azurite (https://github.com/Azure/Azurite) que podemos utilizar para testear nuestros WebJobs localmente sin requerir la provisión de una cuenta de almacenamiento o un AppService de pago.

Podemos correr este emulador de diferentes maneras. Por ejemplo podemos correrlo en un contenedor Docker solamente siguiendo este comando:

(https://github.com/Azure/Azurite)

Una vez ejecutado el comando, deberíamos recibir un resultado como este:

Para poder utilizar Azurite en nuestro WebJob debemos cambiar el valor de “AzureWebJobsStorage” en nuestro archivo appsettings.json. La cadena de conexión que tenemos que setear está disponible en Cloud Explorer en Visual Studio:

Conclusión

Azure WebJobs ofrece una manera de ejecutar background tasks mientras valoramos el poder y conveniencia del serverless computing en la nube, evitando el provisionamiento y mantenimiento de una máquina virtual.

WebJobs puede ser utilizado para tareas que llevan mucho tiempo, dado que el SDK y WebHoooks facilitan la ejecución de WebJobs. Podemos diseñar nuestros procesos compuestos con varios WebJobs y Azure Functions. Esto significa que podemos comunicar mediante colas de mensajes y utilizar arquitectura impulsada por el diseño.