Azure Webjobs vs Azure Functions: comment choisir

J'ai créé des emplois Web Azure qui utilisent des déclencheurs et je viens de découvrir Azure Functions .

D'après ce que je comprends, les fonctions Azure semblent chevaucher les fonctionnalités d'Azure Webjobs et j'ai du mal à comprendre quand choisir entre Function et Webjob:

• Contrairement aux Webjobs, les fonctions ne peuvent être 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 tâches Web et des fonctions en utilisant de nombreux langages (C #, node.js, python ...) mais vous pouvez écrire votre fonction à partir du portail Azure afin qu'il soit plus facile et plus rapide de développer des tests et de 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 de service d'application 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 vous pouvez mettre à l'échelle une seule fonction, tandis que pour un travail Web, vous devez mettre à l'échelle l'ensemble de l'application Web.

Donc, bien sûr, il y a une différence de prix, si vous avez une application Web existante en cours d'exécution, vous pouvez l'utiliser pour exécuter un travail Web sans aucun 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 à garder à l'esprit lorsque vous devez choisir?

Il existe quelques options ici dans App Service. Je ne parlerai pas des applications logiques 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 aka. WebJobs programmés aka. WebJobs déclenchés

Les WebJobs déclenchés sont des WebJobs qui sont exécutés une fois lorsqu'une URL est appelée ou lorsque la propriété de planification est présente dans schedule.job . Les WebJobs planifiés ne sont que des WebJobs pour lesquels un travail Azure Scheduler a été créé pour appeler notre URL selon une planification, mais nous prenons également en charge la propriété de planification, comme mentionné précédemment.

Résumé:

• + Exécutable / Script à la demande
• + Exécutions programmées
• - Doit déclencher via le point de terminaison .scm
• - La mise à l'échelle est manuelle
• - La VM est toujours requise

WebJobs continus (non SDK)

Ces emplois durent indéfiniment et nous les réveillerons en cas de panne. Vous devez activer Always On pour que ceux-ci fonctionnent, ce qui signifie les exécuter au niveau de base et au-dessus.

Résumé:

• + Exécutable / Script toujours en cours d'exécution
• - Nécessite toujours activé - Niveau de base et supérieur
• - La VM est toujours requise

WebJobs en continu avec le SDK WebJobs

Ce n'est rien du point de vue "WebJobs the feature". Essentiellement, nous avons ce doux SDK que nous avons écrit pour cibler les WebJobs qui vous permet d'exécuter du code basé sur de simples déclencheurs. J'en parlerai plus tard.

Résumé:

• + Exécutable / Script toujours en cours d'exécution
• + Journalisation / tableau de bord plus riches
• + Déclencheurs pris en charge avec des tâches de longue durée
• - Nécessite toujours activé - Niveau de base et supérieur
• - La mise à l'échelle est manuelle à configurer
• - La mise en route peut être un peu fatigante
• - La VM est toujours requise

Kit de développement logiciel (SDK) Azure WebJobs

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

Le SDK vise simplement à faciliter l'exécution du code en réaction à un événement et à créer une liaison aux services / etc. facile. C'est honnêtement mieux couvert dans certains documents , mais le cœur de celui-ci est cette nature «événement» + «code». Nous avons également fait un travail d'extensiblité sympa, mais c'est secondaire 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. Controle total.
• - Le truc HTTP est un peu bancal, mais ça marche

Fonctions Azure

Azure Functions consiste à prendre cet objectif principal du SDK WebJobs, à l'héberger en tant que service et à faciliter la mise en route avec d'autres langues. Nous introduisons également le concept «sans serveur» ici car cela avait beaucoup de sens - nous savons comment notre SDK évolue, afin que nous puissions faire des choses intelligentes pour vous.

Azure Functions est une expérience très fortement gérée. Nous ne soutenons pas la venue de votre propre hôte. Actuellement, nous ne prenons pas en charge les extensions personnalisées, mais c'est quelque chose que nous étudions. Nous avons des opinions sur ce que vous pouvez et ne pouvez pas faire, mais pour les choses que nous activons, elles sont astucieuses et faciles à utiliser et à gérer.

La plupart des choses que nous avons faites pour améliorer les fonctions passent par le SDK WebJobs. Par exemple, nous allons télécharger un nouveau NuGet pour WebJobs qui augmente vraiment considérablement la vitesse de journalisation, ce qui présente d'énormes avantages pour les utilisateurs du SDK WebJobs. Dans les fonctions d'expédition comme "WebJobs SDK as a Service", nous avons vraiment amélioré de nombreux problèmes liés à l'expérience.

• + Beaucoup de langues prises en charge
• + Mise à l'échelle dynamique entièrement gérée
• + Portail facile à utiliser avec UX pour la gestion des connexions / etc.
• - L'hôte n'est pas (encore) personnalisable
• ~ S'exécute dans une «application» distincte qui nécessite une configuration dans votre dépôt, mais facilite grandement la maintenance à long terme.
• ~ Aucun outil (encore) Certains outils sont maintenant en version alpha ou en préversion - https://www.npmjs.com/package/azurefunctions (mise à jour de février 2017: Visual Studio Tools pour Azure Functions maintenant disponible en préversion : https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-functions / )

Je suis probablement biaisé car Functions est notre dernier et meilleur, mais n'hésitez pas à tirer plus de contre pour Functions à ma façon.

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

Étant Azure Functions basées sur le SDK WebJobs, elles fournissent la plupart des fonctionnalités déjà disponibles dans WebJobs, mais avec de nouvelles fonctionnalités intéressantes.

En termes de déclencheurs , en plus de ceux déjà disponibles pour WebJobs (par exemple, Service Bus, files d'attente de stockage, objets blob de stockage, planifications CRON, WebHooks, EventHub et fournisseurs de stockage de fichiers en nuage), les fonctions Azure peuvent être déclenchées en tant qu'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 les extrants , la seule différence est que les fonctions peuvent renvoyer une réponse lorsqu'elles sont appelées via HTTP.

Les deux prennent en charge une grande variété de langues , notamment: bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell et Python.

Étant des fonctions actuellement en aperçu, l' outillage n'est toujours pas idéal. Mais Microsoft y travaille. Espérons que nous obtenons la même flexibilité de développement et de test de fonctions localement que nous le faisons actuellement pour WebJobs avec Visual Studio.

Les avantages les plus significatifs et les plus intéressants apportés par Functions sont l'alternative d'avoir un plan de service dynamique avec un modèle «sans serveur» , dans lequel nous n'avons pas besoin de gérer les instances de VM ou la mise à l'échelle; tout est géré pour nous. De plus, en ne disposant 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 :)

Selon la documentation, Azure Functions présente les éléments suivants, contrairement à WebJobs:

• Mise à l'échelle automatique (le processeur et la mémoire sont mis à l'échelle en fonction des besoins déterminés lors de l'exécution)
• Tarification à l'utilisation (plan de consommation à la place du plan App Service)
• Plus d'événements déclencheurs (comme les WebHooks)
• Développement dans le navigateur (Visual Studio toujours possible)
• Prise en charge F #

En termes simples: Azure Functions est le nouvel animal. Si vous n'avez pas encore de plan App Service, j'irais avec Functions car pour le long terme, je ne vois aucune raison pour laquelle commencer avec WebJobs serait mieux (les outils Functions pourraient ne pas être déjà aussi stables cependant).

Je voudrais ajouter deux points supplémentaires aux messages longs et peu anciens ci-dessus. si vous choisissez un plan de consommation dans les fonctions Azure, voici les limitations

Si vous souhaitez exécuter des travaux pendant plus de 10 minutes, choisissez Webjobs. Fonctions Azure, ne s'exécute que pendant 5 minutes par défaut, si votre processus dépasse 5 minutes, la fonction azure lève une exception de délai d'expiration. Vous pouvez augmenter le délai d'expiration à 10 minutes dans host.json .

Remarque: il n'y a pas de problème de délai d'expiration si vous utilisez les fonctions Azure du plan de service d'application.

Une autre raison de distinguer est. si vous utilisez la fonction azure, votre heure de début initiale sera lente car les machines (conteneurs) sont créées à la volée et détruites une fois utilisées.

Pour éviter le démarrage à froid, l'application de fonction azure a publié un plan premium, dans lequel une instance sera exécutée tout le temps et en fonction de la charge, l'application de fonction commencera à évoluer et vous serez facturé pour une instance et d'autres instances en fonction de la consommation.

Je me rends compte que je suis très en retard dans le jeu avec cette réponse, mais comme il s'agit toujours d'un résultat de recherche de premier plan sur Google, je voulais donner quelques conseils sur ce sujet strictement du point de vue des coûts car il semble que l'OP ait des préoccupations concernant le coût. . Il y a déjà de bonnes réponses ici qui parlent des limites techniques et des détails du fonctionnement de chaque service, donc je ne vais pas répéter ces réponses.

Si vous avez absolument besoin de quelque chose qui fonctionne "gratuitement" (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é avec 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 certaines limitations, comme déjà mentionné, peuvent entraîner des coûts de performance sur votre application Web.
2. Fonctions - Lorsque vous utilisez le plan de consommation, vous disposez d'un certain nombre d'exécutions gratuites. Le nombre au moment de la rédaction de cet article est en fait assez élevé, 1 million d'exécutions gratuites. Cependant, la limite d'exécution de 1 million n'est pas la limite susceptible de vous causer des problèmes; ce sont les 400K Go-s (gigaoctets 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 qu'elle s'exécute (voir le calcul officiel sur la page de tarification 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 , alors vous avez plus d'options disponibles.

1. Fonctions - Vous pouvez exécuter dans le plan de consommation ou dans le plan de service de l'application pour un prix relativement bon marché. Gardez cependant à l'esprit le modèle de facturation du GB. Si vous utilisez le plan de consommation et effectuez un travail fréquent et «lourd», vous pourriez être surpris par une grosse facture.
2. Services cloud - Cette option n'a pas été discutée comme une alternative, principalement parce que l'OP ne l'a pas posée. Mais c'est aussi une option viable. Les services cloud ne sont en fin de compte que des machines virtuelles s'exécutant dans le cloud, vous pouvez donc exécuter les tâches d'arrière-plan dont vous avez besoin et ils évoluent assez bien (bien que vous deviez câbler vos propres déclencheurs pour l'exécution, un léger inconvénient par rapport aux tâches / fonctions Web ). Ils ont un coût initial plus élevé (car 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 que vous faites beaucoup de «gros» travaux, les services cloud peuvent être un meilleur choix car il est plus facile de gérer / surveiller une VM à prix fixe que les exécutions et gigaoctets secondes, à mon avis.

Si vous souhaitez lire certains scénarios spécifiques et pourquoi je choisirais l'un (emplois Web, fonctions, services cloud) par rapport à l'autre, j'ai récemment écrit un article de blog sur les emplois Web vs les fonctions vs les services cloud .

Une considération majeure est qu'Azure Functions cesse de prendre en charge le .NET Framework complet après la version 1, qui a été abandonnée avec la v2.0, et qui ne changera pas dans la version actuelle de l'aperçu v3.0. 😔

• La documentation le précise ici ,

• tout comme cette réponse ,

• ainsi que ce problème / réponse github .

Pendant ce temps, cette approche armée forte n'a heureusement pas été appliquée - encore - à Azure WebJobs :

La version 3.x du SDK WebJobs prend en charge les applications console .NET Core et .NET Framework.

Je voudrais donner quels sont les points communs et les différences expliquer entre les deux fonctions Azure qui reposent sur AppService et WebJobs SDK. Le SDK WebJobs vous donnera plus de liberté de jeu tandis que les fonctions Azure sont plus structurées avec moins de responsabilités pour les développeurs.

Lorsque vous examinez les points communs, Both utilise le mode de programmation orienté fonction, des liaisons pour le déclencheur / entrée / sortie, prend en charge les bibliothèques externes et peut exécuter et déboguer localement les articles de toilette Supportruntime.

Différences

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------