Azure Webjobs vs Azure Functions : comment choisir ?

Question

J'ai créé quelques Emplois web d'Azure qui utilisent des déclencheurs et je viens d'apprendre que Fonctions Azure .

D'après ce que j'ai compris, Azure Functions semble chevaucher les fonctionnalités d'Azure Webjobs et j'ai quelques difficultés à comprendre quand choisir entre Function et Webjob :

• Contrairement aux Webjobs, les fonctions ne peuvent être que déclenchées, elles n'ont pas été conçues pour exécuter un processus continu (mais vous pouvez écrire du code pour créer une fonction continue).

• Vous pouvez écrire des Webjobs et des fonctions en utilisant de nombreux langages (C#, node.js, python ...) mais vous pouvez écrire votre fonction à partir du portail Azure. Il est donc plus facile et plus rapide de développer, tester et déployer une fonction.

• Les Webjobs s'exécutent en tant que processus d'arrière-plan dans le contexte d'une application web App Service, d'une application API ou d'une application mobile, tandis que les fonctions s'exécutent à l'aide d'un plan App Service classique/dynamique.

• En ce qui concerne la mise à l'échelle, Functions semble offrir plus de possibilités puisque vous pouvez utiliser un plan de service d'application dynamique et mettre à l'échelle une seule fonction alors que pour un webjob, vous devez mettre à l'échelle toute l'application web.

Si vous avez une application web existante, vous pouvez l'utiliser pour exécuter un webjob sans coût supplémentaire, mais si je n'ai pas d'application web existante et que je dois écrire du code pour déclencher une file d'attente, dois-je utiliser un webjob ou une fonction ?

Y a-t-il d'autres considérations à prendre en compte lorsque vous devez choisir ?

Answer 1

Il y a plusieurs options ici dans App Service. Je ne parlerai pas de Logic Apps ou d'Azure Automation, qui touchent également cet espace.

Azure WebJobs

Cet article est honnêtement la meilleure explication, mais je vais résumer ici.

WebJobs à la demande ou WebJobs planifiés ou WebJobs déclenchés

Les WebJobs déclenchés sont des WebJobs qui sont exécutés une seule fois lorsqu'une URL est appelée ou lorsque la fonction la propriété schedule est présente dans schedule.job . Les WebJobs programmés sont simplement des WebJobs pour lesquels un job Azure Scheduler a été créé pour appeler notre URL selon un calendrier, mais nous supportons également la propriété schedule, comme mentionné précédemment.

Résumé :

• + Exécutable/script sur demande
• + Exécutions programmées
• - Il faut déclencher via le point de terminaison .scm
• - La mise à l'échelle est manuelle
• - VM est toujours nécessaire

WebJobs en continu (non SDK)

Ces emplois sont éternels et nous les réveillerons quand ils s'effondreront. Vous devez activer l'option Always On pour qu'ils fonctionnent, ce qui signifie que vous devez les exécuter à partir du niveau de base.

Résumé :

• + Exécutable/script toujours en cours d'exécution
• - Nécessite d'être toujours en marche - Niveau de base et supérieur
• - VM est toujours nécessaire

WebJobs en continu avec le WebJobs SDK

Ce n'est pas du tout un point de vue "WebJobs la fonctionnalité". En fait, nous disposons d'un kit de développement logiciel (SDK) que nous avons écrit pour les WebJobs et qui vous permet d'exécuter du code en fonction de simples déclencheurs. J'en parlerai plus tard.

Résumé :

• + Exécutable/script toujours en cours d'exécution
• + Journaux et tableaux de bord plus riches
• + Prise en charge des déclencheurs et des tâches à long terme
• - Nécessite d'être toujours en marche - Niveau de base et supérieur
• - La mise à l'échelle est manuelle
• - La mise en route peut être un peu fastidieuse
• - VM est toujours nécessaire

Azure WebJobs SDK

Azure WebJobs SDK est un SDK complètement séparé de WebJobs, la fonctionnalité de la plateforme. Il est conçu pour être exécuté dans un WebJob, mais peut être exécuté n'importe où. Nous avons des clients qui les exécutent sur des rôles de travailleur et même sur prem ou d'autres nuages, bien que le soutien ne soit que le meilleur effort.

Le SDK a pour but de faciliter l'exécution d'un code en réaction à un événement et de faciliter la liaison avec les services, etc. Ce sujet est honnêtement mieux couvert dans un docs mais le cœur de tout cela est la nature "événement" + "code". Nous avons également réalisé des travaux d'extension intéressants, mais ils sont secondaires par rapport à l'objectif principal.

Résumé :

• La plupart d'entre eux sont mentionnés ci-dessus
• + Vous pouvez étendre et exécuter ce que vous voulez. Contrôle total.
• - Le truc HTTP est un peu bancal, mais il fonctionne.

Fonctions Azure

Azure Functions a pour but de reprendre l'objectif principal du SDK WebJobs, de l'héberger en tant que service et de faciliter la mise en œuvre avec d'autres langages. Nous avons également introduit le concept de "Serverless" ici parce que cela avait beaucoup de sens de le faire - nous savons comment notre SDK évolue, donc nous pouvons faire des choses intelligentes pour vous.

Azure Functions est une expérience très lourdement gérée. Nous ne prenons pas en charge l'apport de votre propre hôte. Actuellement, nous ne prenons pas en charge les extensions personnalisées, mais c'est un sujet que nous étudions. Nous avons une opinion bien arrêtée sur ce que vous pouvez et ne pouvez pas faire, mais pour les choses que nous permettons, elles sont astucieuses, faciles à utiliser et à gérer.

La plupart des choses que nous avons faites pour améliorer les fonctions passent par le SDK WebJobs, cependant. Par exemple, nous allons télécharger un nouveau NuGet pour WebJobs qui augmente considérablement la vitesse de journalisation, ce qui a des avantages énormes pour les utilisateurs de WebJobs SDK. En livrant Functions en tant que "WebJobs SDK as a Service", nous avons vraiment amélioré un grand nombre de problèmes d'expérience.

• + De nombreuses langues sont prises en charge
• + Entièrement géré, mise à l'échelle dynamique
• + Portail facile à utiliser avec une interface utilisateur pour gérer les connexions, etc.
• - Hôte non personnalisable (pour l'instant)
• ~ Fonctionne dans une "application" distincte, ce qui nécessite une certaine configuration dans votre dépôt, mais facilite grandement la maintenance à long terme.
• ~ Pas d'outillage (encore) Certains outils sont maintenant en version alpha ou en version préliminaire. https://www.npmjs.com/package/azurefunctions (mise à jour février 2017 : Les outils Visual Studio pour Azure Functions sont désormais disponibles en avant-première : https://blogs.msdn.microsoft.com/webdev/2016/12/01/visual-studio-tools-for-azure-functions/ )

Je suis probablement partial puisque Functions est notre dernier et meilleur produit, mais n'hésitez pas à m'envoyer d'autres contre pour Functions.

Je finirai probablement par publier un blog qui en dira un peu plus, mais j'ai essayé de rester aussi succinct que possible pour ce forum.

Answer 2

Comme il s'agit de fonctions Azure basées sur le SDK de WebJobs, elles offrent la plupart des fonctionnalités déjà disponibles dans WebJobs, mais avec quelques nouvelles capacités intéressantes.

En termes de déclencheurs En plus de ceux déjà disponibles pour les WebJobs (par exemple, Service Bus, Storage Queues, Storage Blobs, CRON schedules, WebHooks, EventHub et File Cloud Storage providers), Azure Functions peut être déclenché comme API. Et les appels HTTP ne nécessitent pas d'informations d'identification Kudu, mais peuvent être authentifiés via Azure AD et des fournisseurs d'identité tiers.

En ce qui concerne sorties La seule différence est que les fonctions peuvent renvoyer une réponse lorsqu'elles sont appelées via HTTP.

Les deux supportent un large variété de langues Vous pouvez utiliser les logiciels suivants : bash (.sh), batch (.bat / .cmd), C#, F#, Node.Js, PHP, PowerShell et Python.

Fonctions de l'être actuellement en avant-première, outillage n'est toujours pas idéal. Mais Microsoft y travaille. Espérons que nous obtiendrons la même flexibilité pour développer et tester les fonctions localement que celle dont nous disposons actuellement pour les WebJobs avec Visual Studio.

Les avantages les plus significatifs et les plus cool apportés par les fonctions sont l'alternative d'avoir une Plan de service dynamique avec un "Modèle "sans serveur En effet, nous n'avons pas besoin de gérer les instances de machines virtuelles ou la mise à l'échelle, tout est géré pour nous. De plus, en n'ayant pas d'instances dédiées, nous ne payons que pour les ressources que nous utilisons réellement.

Une comparaison plus détaillée entre les deux ici : https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

Answer 3

J'aimerais ajouter deux points supplémentaires à ces longs et un peu anciens messages. Si vous choisissez un plan de consommation dans les fonctions azur, voici les limitations.

Si vous voulez exécuter des tâches de plus de 10 minutes, choisissez webjobs. Les fonctions Azure, qui ne fonctionnent que pendant 5 minutes par défaut, si votre processus dépasse 5 minutes, alors la fonction azur lance une exception de timeout. Vous pouvez augmentation de le délai d'attente à 10 minutes dans host.json .

Note : Il n'y a pas de problème de délai d'attente si vous utilisez les fonctions d'App Service Plan Azure.

Une autre raison de faire la distinction est que si vous utilisez la fonction azur, votre temps de démarrage initial sera lent car les machines (conteneurs) sont créées à la volée et détruites une fois qu'elles sont utilisées.

Pour éviter le démarrage à froid, azure function app a lancé un plan premium, dans lequel une instance fonctionnera en permanence et, en fonction de la charge, l'application de fonction commencera à s'adapter et vous serez facturé pour une instance et d'autres instances en fonction de la consommation.

Answer 4

Selon le docs Azure Functions a ce que WebJobs n'a pas :

• Mise à l'échelle automatique (le processeur et la mémoire sont mis à l'échelle en fonction des besoins déterminés au moment de l'exécution).
• Tarification à l'usage (plan de consommation au lieu du plan de service)
• Plus d'événements déclencheurs (comme les WebHooks)
• Développement dans le navigateur (Visual Studio toujours possible)
• Support F#

Pour faire simple : Azure Functions est l'animal le plus récent. Si vous n'avez pas déjà un plan App Service, j'opterais pour Functions car, à long terme, je ne vois pas pourquoi il serait préférable de commencer par WebJobs (les outils Functions ne sont peut-être pas aussi stables).

Answer 5

Je me rends compte que je suis très en retard pour répondre à cette question, mais comme il s'agit toujours d'un des premiers résultats de recherche sur Google, je voulais donner quelques conseils sur ce sujet de manière stricte. du point de vue des coûts puisqu'il semble que le PO s'inquiète du coût. Il y a déjà d'excellentes réponses ici qui parlent des limitations techniques et des détails du fonctionnement de chaque service, donc je ne vais pas les répéter.

Si vous avez absolument besoin de quelque chose qui court pour "libre". (c'est-à-dire sans coût supplémentaire par rapport à ce que vous avez déjà payé pour votre application web), vous avez deux options :

1. Webjobs - déployé à côté de votre application web existante et utilise les mêmes ressources que votre application web. Il n'y a pas de coût monétaire supplémentaire pour utiliser les webjobs mais il y a quelques limitations comme déjà mentionné qui peuvent mener à des coûts de performance sur votre application web.
2. Fonctions - Lorsque vous utilisez le plan de consommation, un certain nombre d'exécutions gratuites vous est alloué. Au moment où nous écrivons ces lignes, ce nombre est en fait assez élevé : 1 million d'exécutions gratuites. Cependant, la limite d'un million d'exécutions n'est pas celle qui risque de vous poser problème ; c'est la limite de 400K Go-s (gigabytes secondes). Il s'agit essentiellement d'un calcul de la quantité de mémoire utilisée par votre fonction multipliée par le nombre de secondes d'exécution (voir le calcul officiel sur le site de l page des prix ici ). Vous serez surpris de la rapidité avec laquelle cette allocation gratuite s'épuise.

Si vous êtes préoccupé par les coûts mais pas limité à aucun coût du tout, alors vous avez plus d'options disponibles.

1. Fonctions - Vous pouvez utiliser soit le plan de consommation, soit le plan de service d'applications pour un prix relativement peu élevé. Gardez cependant à l'esprit le modèle de facturation du GB-s. Si vous utilisez le plan de consommation et que vous effectuez des travaux fréquents et "lourds", vous pourriez être surpris par une facture élevée.
2. Services en nuage - Cette option n'a pas été discutée comme alternative, principalement parce que le PO n'a pas posé de question à ce sujet. Mais c'est aussi une option viable. Les services en nuage sont en fin de compte juste des VMs fonctionnant dans le nuage, vous pouvez donc exécuter n'importe quel travail d'arrière-plan dont vous avez besoin sur eux et ils s'adaptent assez bien (bien que vous deviez câbler vos propres déclencheurs pour l'exécution, un léger inconvénient par rapport aux webjobs/fonctions). Ils ont un coût initial plus élevé (parce que vous payez par instance, que vous l'utilisiez ou non), mais si vous avez des tâches qui doivent être exécutées en permanence et qui font beaucoup de travail "lourd", les services en nuage peuvent être un meilleur choix parce qu'il est plus facile de gérer/surveiller une VM à prix fixe que des exécutions et des secondes en gigaoctets, à mon avis. L'autre avantage des services en nuage est que vous n'avez jamais à vous soucier des délais d'attente ou de certaines des autres limitations mentionnées dans les réponses précédentes.

Si vous souhaitez lire des scénarios spécifiques et savoir pourquoi je choisirais l'un (webjobs, fonctions, services en nuage) plutôt que l'autre, j'ai récemment rédigé un article de blog sur le thème suivant webjobs vs fonctions vs services en nuage .