Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Azure Webjobs vs Azure Functions : comment choisir

ayi

ayi_2

Il y a quelques options ici au sein d’App Service. Je n’aborderai pas Logic Apps ou Azure Automation, qui touchent également à ce domaine.
Azure WebJobs
<a href="https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/">Cet article</a> est honnêtement la meilleure explication, mais je vais résumer ici.
WebJobs à la demande, aussi appelés WebJobs planifiés ou WebJobs déclenchés
Les WebJobs déclenchés sont des WebJobs qui s’exécutent une seule fois lorsqu’une URL est appelée ou lorsque la <a href="https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/#CreateScheduledCRON">propriété schedule est présente dans schedule.job</a>. Les WebJobs planifiés sont simplement des WebJobs pour lesquels un job Azure Scheduler a été créé pour appeler notre URL selon un planning, mais nous prenons également en charge la propriété schedule, comme mentionné précédemment.
Résumé :
<ul>
<li>
<ul>
<li>Exécutable/Script à la demande</li>
</ul>
</li>
<li>
<ul>
<li>Exécutions planifiées</li>
</ul>
</li>
<li>
<ul>
<li>Doivent être déclenchés via le point de terminaison .scm</li>
</ul>
</li>
<li>
<ul>
<li>La mise à l’échelle est manuelle</li>
</ul>
</li>
<li>
<ul>
<li>Une VM est toujours nécessaire</li>
</ul>
</li>
</ul>
WebJobs continus (sans SDK)
Ces jobs s’exécutent en permanence et nous les relançons quand ils plantent. Vous devez activer Always On pour que ceux-ci fonctionnent, ce qui signifie les exécuter au minimum dans le niveau Basic et au-dessus.
Résumé :
<ul>
<li>
<ul>
<li>Exécutable/Script toujours en cours d’exécution</li>
</ul>
</li>
<li>
<ul>
<li>Nécessite Always On - niveau Basic et au-dessus</li>
</ul>
</li>
<li>
<ul>
<li>Une VM est toujours nécessaire</li>
</ul>
</li>
</ul>
WebJobs continus avec le SDK WebJobs
Ce ne sont rien de particulier du point de vue de la fonctionnalité “WebJobs”. Essentiellement, nous avons écrit ce SDK génial ciblant les WebJobs qui vous permet d’exécuter du code basé sur des déclencheurs simples. J’en parlerai davantage plus tard.
Résumé :
<ul>
<li>
<ul>
<li>Exécutable/Script toujours en cours d’exécution</li>
</ul>
</li>
<li>
<ul>
<li>Journalisation/tableau de bord plus riches</li>
</ul>
</li>
<li>
<ul>
<li>Déclencheurs pris en charge avec les tâches de longue durée</li>
</ul>
</li>
<li>
<ul>
<li>Nécessite Always On - niveau Basic et au-dessus</li>
</ul>
</li>
<li>
<ul>
<li>La mise à l’échelle nécessite une configuration manuelle</li>
</ul>
</li>
<li>
<ul>
<li>Le démarrage peut être un peu fastidieux</li>
</ul>
</li>
<li>
<ul>
<li>Une VM est toujours nécessaire</li>
</ul>
</li>
</ul>
SDK Azure WebJobs
Le SDK Azure WebJobs est un SDK complètement séparé de la fonctionnalité plateforme WebJobs. Il est conçu pour être exécuté dans un WebJob, mais peut en réalité être exécuté n’importe où. Nous avons des clients qui l’exécutent
(Réponse tronquée)

AyiNEDJIMI

Bonjour,
Le choix entre Azure WebJobs et Azure Functions est une question que beaucoup d’architectes et développeurs se posent lors de la conception d’une solution Azure. Ces deux services permettent d’exécuter du code en arrière-plan, mais ils répondent à des besoins différents. Je vais vous fournir une analyse complète pour vous aider à faire le bon choix.
<h2><a name="p-34582-vue-densemble-des-deux-services-1" class="anchor" href="#p-34582-vue-densemble-des-deux-services-1" aria-label="Heading link"></a>Vue d’ensemble des deux services</h2>
<h3><a name="p-34582-azure-webjobs-2" class="anchor" href="#p-34582-azure-webjobs-2" aria-label="Heading link"></a>Azure WebJobs</h3>
Les WebJobs sont une fonctionnalité d’Azure App Service qui permet d’exécuter des programmes ou des scripts en arrière-plan dans le même contexte qu’une application web App Service. Ils partagent les ressources de l’App Service Plan associé.
Caractéristiques principales :
<ul>
<li>Intégrés à App Service (même plan, même VM)</li>
<li>Peuvent être continus (s’exécutent en permanence) ou déclenchés (à la demande ou selon un planning)</li>
<li>Supportent de nombreux types de fichiers : <code>.exe</code>, <code>.cmd</code>, <code>.bat</code>, <code>.sh</code>, <code>.php</code>, <code>.py</code>, <code>.js</code>, <code>.jar</code></li>
<li>Peuvent utiliser le SDK WebJobs pour une intégration avancée avec Azure Storage</li>
</ul>
<h3><a name="p-34582-azure-functions-3" class="anchor" href="#p-34582-azure-functions-3" aria-label="Heading link"></a>Azure Functions</h3>
Azure Functions est un service de calcul serverless indépendant qui exécute du code en réponse à des événements, sans gestion de serveur. Il facture uniquement le temps d’exécution effectif (en mode Consumption).
Caractéristiques principales :
<ul>
<li>Modèle serverless ou dédié (Elastic Premium, Dedicated Plan)</li>
<li>Large éventail de déclencheurs (HTTP, Timer, Queue, Blob, Event Hub, Service Bus, Cosmos DB, etc.)</li>
<li>Plusieurs langages supportés : C#, JavaScript/TypeScript, Python, Java, PowerShell, Go (custom handler)</li>
<li>Mise à l’échelle automatique et élastique</li>
<li>Modèle de facturation à l’exécution (Consumption Plan)</li>
</ul>
<h2><a name="p-34582-tableau-comparatif-dtaill-4" class="anchor" href="#p-34582-tableau-comparatif-dtaill-4" aria-label="Heading link"></a>Tableau comparatif détaillé</h2>
<div class="md-table">
<table>
<thead>
<tr>
<th>Critère</th>
<th>Azure WebJobs</th>
<th>Azure Functions</th>
</tr>
</thead>
<tbody>
<tr>
<td>Modèle d’hébergement</td>
<td>Intégré à App Service</td>
<td>Indépendant (serverless ou plan dédié)</td>
</tr>
<tr>
<td>Facturation</td>
<td>Inclus dans l’App Service Plan</td>
<td>À l’exécution (Consumption) ou plan dédié</td>
</tr>
<tr>
<td>Mise à l’échelle</td>
<td>Manuelle (scale out App Service)</td>
<td>Automatique et élastique</td>
</tr>
<tr>
<td>Déclencheurs</td>
<td>Timer, continu, manuel</td>
<td>20+ déclencheurs natifs</td>
</tr>
<tr>
<td>Langages</td>
<td>Tout exécutable, SDK C#/Node</td>
<td>C#, JS/TS, Python, Java, PowerShell, Go</td>
</tr>
<tr>
<td>Durée max d’exécution</td>
<td>Illimitée</td>
<td>5 min (Consumption), 10 min extensible, illimité (Premium/Dedicated)</td>
</tr>
<tr>
<td>Accès au système de fichiers</td>
<td>Oui (partage App Service)</td>
<td>Limité (temporaire)</td>
</tr>
<tr>
<td>Monitoring</td>
<td>Application Insights (basique)</td>
<td>Application Insights (avancé, intégré)</td>
</tr>
<tr>
<td>CI/CD</td>
<td>Via App Service deployment</td>
<td>Via Azure DevOps, GitHub Actions natif</td>
</tr>
<tr>
<td>Local development</td>
<td>Via WebJobs SDK</td>
<td>Via Azure Functions Core Tools</td>
</tr>
<tr>
<td>Orchestration</td>
<td>Non</td>
<td>Oui (Durable Functions)</td>
</tr>
<tr>
<td>Cold start</td>
<td>Non (si App Service actif)</td>
<td>Oui (Consumption Plan)</td>
</tr>
<tr>
<td>Maturité</td>
<td>Stable, maintenance uniquement</td>
<td>Actif, nouvelles fonctionnalités régulières</td>
</tr>
</tbody>
</table>
</div><h2><a name="p-34582-quand-choisir-azure-webjobs-5" class="anchor" href="#p-34582-quand-choisir-azure-webjobs-5" aria-label="Heading link"></a>Quand choisir Azure WebJobs ?</h2>
<h3><a name="p-34582-cas-dusage-favorables-aux-webjobs-6" class="anchor" href="#p-34582-cas-dusage-favorables-aux-webjobs-6" aria-label="Heading link"></a>Cas d’usage favorables aux WebJobs</h3>
1. Vous avez déjà une App Service existante
Si votre application web tourne sur un App Service Plan, les WebJobs sont une extension naturelle sans coût supplémentaire :
<pre data-code-wrap="csharp"><code class="lang-csharp">// Exemple de WebJob avec SDK - traitement de messages Queue
public class Functions
{
public static async Task ProcessQueueMessage(
[QueueTrigger("maqueue")] string message,
ILogger logger)
{
logger.LogInformation($"Message reçu : {message}");
// Traitement du message
await TraiterMessage(message);
}
}
</code></pre>
2. Tâches de longue durée nécessitant une exécution continue
Les WebJobs continus s’exécutent en permanence sans limite de temps, idéal pour :
<ul>
<li>Les listeners de files d’attente avec faible latence</li>
<li>Les processus de synchronisation permanents</li>
<li>Les tâches de monitoring continu</li>
</ul>
3. Accès nécessaire au système de fichiers de l’App Service
Les WebJobs partagent le système de fichiers avec l’application web parente, permettant d’accéder aux mêmes fichiers et répertoires.
4. Migration d’applications existantes
Si vous migrez une application .NET Framework legacy avec des traitements en arrière-plan, les WebJobs offrent une voie de migration simple.
<h2><a name="p-34582-quand-choisir-azure-functions-7" class="anchor" href="#p-34582-quand-choisir-azure-functions-7" aria-label="Heading link"></a>Quand choisir Azure Functions ?</h2>
<h3><a name="p-34582-cas-dusage-favorables-aux-functions-8" class="anchor" href="#p-34582-cas-dusage-favorables-aux-functions-8" aria-label="Heading link"></a>Cas d’usage favorables aux Functions</h3>
1. Architecture serverless et microservices
Pour des architectures découplées et event-driven :
<pre data-code-wrap="csharp"><code class="lang-csharp">// Azure Function avec Timer Trigger
[FunctionName("TraitementNocturne")]
public static async Task Run(
[TimerTrigger("0 0 2 * * *")] TimerInfo myTimer,
ILogger log,
[CosmosDB(
databaseName: "MaBDD",
collectionName: "Commandes",
ConnectionStringSetting = "CosmosDBConnection")] IAsyncCollector<dynamic> outputDocument)
{
log.LogInformation($"Traitement nocturne démarré : {DateTime.Now}");

var commandes = await RecupererCommandesNonTraitees();
foreach (var commande in commandes)
{
    await outputDocument.AddAsync(new { id = commande.Id, statut = "Traité" });
}

}
</code></pre>
2. Réponse à des événements multiples et variés
Azure Functions supporte nativement plus de 20 types de déclencheurs :
<pre data-code-wrap="csharp"><code class="lang-csharp">// Function déclenchée par un message Service Bus
[FunctionName("TraiterCommande")]
public static async Task Run(
[ServiceBusTrigger("commandes", Connection = "ServiceBusConnection")] string message,
[Table("CommandesTable", Connection = "StorageConnection")] CloudTable table,
ILogger log)
{
var commande = JsonConvert.DeserializeObject<Commande>(message);
// Traitement...
}
</code></pre>
3. Optimisation des coûts avec une charge variable
Le Consumption Plan d’Azure Functions inclut 1 million d’exécutions gratuites par mois et ne facture que ce qui est consommé :
<pre><code class="lang-auto">Coût = (Nombre d'exécutions × 0,20 €/million) + (GB-secondes × 0,000016 €/GB-s)
</code></pre>
4. Orchestration de workflows complexes avec Durable Functions
<pre data-code-wrap="csharp"><code class="lang-csharp">// Orchestrateur Durable Functions
[FunctionName("OrchestrateurCommande")]
public static async Task<List<string>> RunOrchestrator(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
var outputs = new List<string>();

// Exécution parallèle
var tache1 = context.CallActivityAsync<string>("ValiderPaiement", "commande-123");
var tache2 = context.CallActivityAsync<string>("VerifierStock", "commande-123");

await Task.WhenAll(tache1, tache2);

outputs.Add(await tache1);
outputs.Add(await tache2);

// Puis exécution séquentielle
outputs.Add(await context.CallActivityAsync<string>("ExpedierCommande", "commande-123"));

return outputs;

}
</code></pre>
5. Exposition d’API légères
<pre data-code-wrap="csharp"><code class="lang-csharp">// HTTP Trigger pour une API simple
[FunctionName("GetProduit")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = "produits/{id}")] HttpRequest req,
string id,
ILogger log)
{
var produit = await _repository.GetProduitAsync(id);
return produit != null
? new OkObjectResult(produit)
: new NotFoundResult();
}
</code></pre>
<h2><a name="p-34582-arbre-de-dcision-9" class="anchor" href="#p-34582-arbre-de-dcision-9" aria-label="Heading link"></a>Arbre de décision</h2>
Pour vous aider à choisir rapidement, voici un arbre de décision :
<pre><code class="lang-auto">Avez-vous déjà un App Service Plan ?
├── OUI → Votre tâche dure plus de 10 minutes ou est continue ?
│ ├── OUI → WebJobs
│ └── NON → Les deux conviennent, préférez Functions pour l'évolutivité
└── NON → Vous avez besoin de serverless (pas de gestion serveur) ?
├── OUI → Azure Functions (Consumption Plan)
└── NON → Votre charge est imprévisible ?
├── OUI → Azure Functions (Elastic Premium)
└── NON → Évaluez App Service + WebJobs vs Functions Dedicated
</code></pre>
<h2><a name="p-34582-migration-de-webjobs-vers-azure-functions-10" class="anchor" href="#p-34582-migration-de-webjobs-vers-azure-functions-10" aria-label="Heading link"></a>Migration de WebJobs vers Azure Functions</h2>
Si vous souhaitez migrer des WebJobs existants vers Functions :
<pre data-code-wrap="bash"><code class="lang-bash"># Installer Azure Functions Core Tools
npm install -g azure-functions-core-tools@4

Créer un nouveau projet Functions

func init MonProjetFunctions --dotnet

Ajouter une fonction depuis un template

func new --name MonTraitement --template "Timer trigger"

Tester localement

func start
</code></pre>
Le WebJobs SDK est d’ailleurs la base sur laquelle Azure Functions a été construit, ce qui facilite la migration du code métier.
<h2><a name="p-34582-recommandation-finale-11" class="anchor" href="#p-34582-recommandation-finale-11" aria-label="Heading link"></a>Recommandation finale</h2>
<ul>
<li>Choisissez WebJobs si vous avez un App Service existant, besoin d’exécution continue, ou contraintes de migration legacy.</li>
<li>Choisissez Azure Functions pour tout nouveau développement, les architectures event-driven, la mise à l’échelle automatique et l’optimisation des coûts.</li>
</ul>
Dans la majorité des projets nouveaux, Azure Functions est le choix recommandé par Microsoft et offre une feuille de route produit plus active.
<hr>
Si vous nous donnez plus de détails sur votre cas d’usage spécifique (type de traitement, fréquence, durée, contraintes d’infrastructure), je pourrai affiner cette recommandation et vous aider à concevoir l’architecture optimale.