Background jobs in cloud-native applicaties
04.04Maarten Ghijsens is één van onze Azure cloud-native architecten die klanten helpt met het moderniseren van hun applicaties. Voor een van die klanten bouwden we in de afgelopen maanden een applicatie die een overzicht geeft van alle Office 365 workspaces. Denk bijvoorbeeld aan SharePoint–sites en teams in Microsoft Teams. Maarten deed daarom onderzoek naar de mogelijkheden om zogenaamde background jobs (of long-running operations) te doen draaien binnen cloud-native applications op Azure. Hieronder leggen we uit hoe dit proces in z’n werk ging, en hoe je er zelf mee aan de slag kan.
De belangrijkste features van de nieuwe applicatie zijn lifecycle management en ledenbeheer van de workspaces. De applicatie zelf heeft verschillende voordelen: hij laat toe om een persoonlijk overzicht te behouden en ondersteunt het bouwen van verschillende workspaces. Verder uniformiseert en centraliseert de applicatie de creatie van SharePoint-sites en Teams, monitort het op inactiviteit in de workspaces, herinnert het gebruikers om zaken te archiveren, enzovoort.
Omdat SharePoint-sites en Teams nog steeds buiten de applicatie kunnen worden gecreëerd of gewijzigd was het noodzakelijk om een synchronisatie van de workspaces te voorzien. Enkele keren per uur worden de workspaces gesynchroniseerd tussen Office 365 en een SQL-database van de applicatie.
Onderstaande tabel mag je zien als een samenvatting van het onderzoek, met de verschillende mogelijkheden en de kenmerken die een invloed hebben op je beslissing. Deze lijst is uiteraard niet volledig, maar kan voor mede-architecten en developers een leidraad bieden in hun beslissingsproces voor background jobs in cloud-native applicaties.
Note: Maarten heeft bewust Azure Batch uit de lijst met mogelijkheden gelaten. Het focust zich namelijk op virtual machines en niet op containers om het werk uit te voeren. Aangezien we hier kiezen voor een serverless, cloud-native oplossing, is Azure Batch dus minder relevant.
Azure Web Jobs | Azure App Service + Hangfire | Azure Functions | Azure Logic Apps | Azure Container Instances | ||||
Regular | Durable | Premium | ||||||
Serverless | Nee | Nee | Ja | Ja | Nee | Ja | Ja | |
Duurtijdslimiet | 230 seconden | 230 seconden | Max. 10 minuten | Ja | Max. 60 minuten | Nee | Nee | |
Kost | Hoog | Hoog | Laag | Laag | Hoog | Laag | Laag | |
Schaalbaarheid | Scale-up | Manueel | Manueel | Auto | Auto | Auto | Auto | Auto / Manueel |
Scale-out | ||||||||
Doel | Bestaande achtergrondprocessen die snel naar de cloud verhuisd worden in een lift-and-shift scenario. | Kleine/korte taken die door acties in de user interface van de webapplicatie worden getriggerd, maar die asynchroon uitgevoerd worden om de user experience te versnellen. | Kleine/korte taken die door een gebeurtenis of een andere applicatie getriggerd worden. | Langdurige taken die opgesplitst en parallel uitgevoerd kunnen worden in meerdere kleine taken. | Langdurige taken die door een gebeurtenis of een andere applicatie getriggerd worden. | Low-code oplossingen om te integreren met andere applicaties of werkstromen te ondersteunen die zonder (veel) maatwerk uitgevoerd kunnen worden. | Voer op gebeurtenisgebaseerde taken uit, implementeer snel vanuit uw containers m.b.v. ontwikkelpijplijnen en voer taken voor gegevensverwerking en -compilatie uit. | |
Aandachtspunten | Wordt best niet gebruikt voor greenfield-applicaties. | Hou rekening met time-outs van de Azure App Service en eventuele opslag of databanken bij fire-and-forget taken. Terugkerende achtergrondtaken kunnen falen als de Azure App Service niet “Altijd aan” is. | Koude starten na lange inactiviteit beïnvloeden antwoordtijden. | Instrumentatie van taken is verplicht. Moeilijk te debuggen door parallele taakuitvoering. | Niet geschikt voor intensieve of complexe werkvolumes. |
We kozen ervoor een .NET 6 C# console application te bouwen en te verpakken in een Linux-based Docker container image. Deze Docker container image werd geüpload in een Azure Container Registry, waardoor we manueel nieuwe instanties kunnen starten met Azure Container Instances. Eenmaal de background job goed draaide en volledig correct werkte in een Azure Container Instance, besloten we een Azure Logic App te gebruiken met een recurrence trigger om de Azure Container Group met een interval op te starten.
Dankzij het serverless model en het pay-as-you-go plan is onze background job relatief goedkoop. Onze oplossing is platform- en OS-onafhankelijk, want de .NET 6 C# console application kan perfect draaien op andere besturingssystemen. De Azure Container Instance zorgt daarbij ook nog eens voor extra mogelijkheden om te schalen en voorkomt afhankelijkheden van pakketten zoals Hangfire. Dit wordt namelijk vaak gebruikt als alternatief om snel en eenvoudig “fire-and-forget” background jobs te draaien in .NET-applicaties.
Wil je graag zelf een background job laten draaien in een container? Download dan zeker ons handig stappenplan, of neem contact op om samen de mogelijkheden samen te bekijken!