Azure Webjobs vs Azure Functions: comment choisir
J'ai créé des Azure Webjobs qui utilisent des déclencheurs et je viens tout juste d'en apprendre plus sur Azure Functions .
D'après ce que je comprends, Azure Functions semble se chevaucher avec les fonctionnalités Azure Webjobs et j'ai du mal à comprendre quand choisir entre Function et Webjob:
À la différence des Webjobs, les fonctions ne peuvent être déclenchées que par un logiciel, il n'a pas été conçu pour exécuter un processus continu (mais vous pouvez écrire du code pour créer une fonction continue).
Vous pouvez écrire des fonctions Web et des fonctions dans 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 et de déployer une fonction. .
Les tâches Web s'exécutent en tant que processus d'arrière-plan dans le contexte d'une application Web, d'une API ou d'une application mobile App Service, alors que les fonctions s'exécutent à l'aide d'un plan de service Classic/Dynamic App.
En ce qui concerne la mise à l'échelle, Functions semble offrir davantage de possibilités, car vous pouvez utiliser un plan de services d'application dynamique et vous pouvez redimensionner une seule fonction, tandis que pour un travail Web, vous devez redimensionner l'ensemble de l'application Web.
Donc, bien sûr, il y a une différence de prix. Si une application Web existante est en cours d'exécution, vous pouvez l'utiliser pour exécuter une tâche 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. devrais-je utiliser un webjob ou une fonction?
Y a-t-il d'autres considérations à garder à l'esprit lorsque vous devez choisir?
Il y a 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.
Sur demande WebJobs aka. WebJobs programmés aka. WebJobs déclenchés
Les WebJobs déclenchés sont des WebJobs qui ne sont exécutés qu'une fois qu'une URL est appelée ou que la propriété schedule est présente dans schedule.job . Les tâches Web planifiées ne sont que des tâches Web pour lesquelles un travail de planificateur Azure a été créé pour appeler notre URL sur une planification, mais nous prenons également en charge la propriété de planification, comme mentionné précédemment.
Sommaire:
+Exécutable/Script à la demande+Exécutions planifiées-Doit se déclencher via un noeud final .scm-La mise à l'échelle est manuelle-VM est toujours requis
Continu WebJobs (non SDK)
Ces emplois durent éternellement et nous les réveillerons quand ils tomberont en panne. Vous devez activer Always On pour que ces éléments fonctionnent, ce qui signifie qu'ils doivent être exécutés au niveau de base et supérieur.
Sommaire:
+Exécutable/Script toujours actif-Requiert toujours activé - Niveau de base et supérieur-VM est toujours requis
WebJobs en continu avec le SDK WebJobs
Ce ne sont pas du point de vue "WebJobs the feature". Pour résumer, nous avons écrit ce kit de développement logiciel ciblant WebJobs qui vous permet d’exécuter du code basé sur des déclencheurs simples. J'en reparlerai plus tard.
Sommaire:
+Exécutable/Script toujours actif+Enregistrement plus riche/tableau de bord+Déclencheurs pris en charge avec des tâches longues-Requiert toujours activé - Niveau de base et supérieur-La mise à l'échelle est manuelle à configurer-Se lancer peut être un peu fastidieux-VM est toujours requis
SDK Azure WebJobs
Azure WebJobs SDK est un SDK complètement distinct de WebJobs, la fonctionnalité de plate-forme. 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 gèrent sur des rôles de travail et même sur des prems ou d'autres clouds, bien que l'assistance ne soit qu'un effort maximum.
Le Kit de développement logiciel (SDK) facilite l’exécution de code en réaction à un événement et permet de lier les services/etc. facile. C’est honnêtement ce qui est le mieux traité dans certains docs , mais le cœur de celui-ci est cette nature "événement" + "code". Nous avons également effectué des travaux d’extensibilité intéressants, mais c’est un objectif secondaire.
Sommaire:
- La plupart d'entre eux sont mentionnés ci-dessus
+Vous pouvez étendre et exécuter ce que vous voulez. Controle total.-Les trucs HTTP sont un peu débiles, mais ça marche
Fonctions Azure
Azure Functions consiste à exploiter cet objectif principal du kit de développement WebJobs SDK, à l'héberger en tant que service et à faciliter la mise en route pour d'autres langues. Nous présentons également ici le concept "Serverless", car il était tout à fait logique de le faire. Nous savons comment notre SDK évolue pour pouvoir faire des choses intelligentes pour vous.
Azure Functions est une expérience très lourdement gérée. Nous ne soutenons pas le fait d’apporter votre propre hôte. Actuellement, nous ne prenons pas en charge les extensions personnalisées, mais nous en enquêtons. Nous avons des opinions sur ce que vous pouvez et ne pouvez pas faire, mais pour les choses que nous activons, elles sont lisses, faciles à utiliser et à gérer.
La plupart des choses "framework" que nous avons faites pour améliorer les fonctions passent par WebJobs SDK. Par exemple, nous allons télécharger un nouveau NuGet pour WebJobs, ce qui augmente considérablement la vitesse de journalisation, ce qui offre d’énormes avantages pour les utilisateurs du kit de développement WebJobs. Dans les fonctions d’expédition "WebJobs SDK as a Service", nous avons vraiment amélioré de nombreux problèmes d’expérience.
+Beaucoup de langues supportées+Mise à l'échelle dynamique entièrement gérée+Portail facile à utiliser avec UX pour la gestion des connexions/etc.-Hôte non personnalisable~S'exécute dans une "application" distincte nécessitant une certaine configuration dans votre référentiel, mais simplifiant considérablement la maintenance à long terme.~Pas d'outillage (encore)Certains outils sont maintenant en alpha ou en aperçu - https://www.npmjs.com/package/azurefunctions (mise à jour février 2017: les fonctions de Visual Studio Tools pour Azure sont désormais disponibles en aperçu: https : //blogs.msdn.Microsoft.com/webdev/2016/12/01/visual-studio-tools-for-Azure-functions/ )
Je suis probablement biaisé puisque Functions est notre dernier et meilleur, mais n'hésitez pas à tirer plus de inconvénients pour Functions my way.
Je vais probablement finir par publier un blog qui en explique un peu plus, mais j'ai essayé de le garder le plus succinct possible pour ce forum.
Les fonctions Azure reposant sur le kit de développement WebJobs SDK fournissent la plupart des fonctionnalités déjà disponibles dans WebJobs, mais avec quelques 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, Blobs de stockage, Planifications CRON, WebHooks, EventHub, etc.). File Cloud Storage), 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 sorties , 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.
Être Fonctions actuellement dans Aperçu, l'outillage n'est toujours pas idéal. Mais Microsoft y travaille. Espérons que nous aurons la même flexibilité de développement et de test des fonctions localement que nous le faisons actuellement pour WebJobs avec Visual Studio.
L’un des avantages les plus importants et les plus intéressants apportés par Functions est la possibilité d’avoir un plan de service dynamique avec un "= Server (sans serveur)" . model , dans lequel il n'est pas nécessaire de gérer VM instances 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 docs , Azure Functions contient les éléments suivants que WebJobs n'a pas:
- Mise à l'échelle automatique (la CPU et la mémoire sont mises à l'échelle en fonction des besoins déterminés lors de l'exécution)
- Tarification à l'utilisation (plan de consommation au lieu du plan de service d'application)
- Plus d'événements déclencheurs (comme WebHooks)
- Développement dans le navigateur (Visual Studio toujours possible)
- Support F #
Autrement dit: Azure Functions est l'animal le plus récent. Si vous ne possédez pas déjà de plan App Service, je choisirais Fonctions, car pour le long terme, je ne vois aucune raison pour laquelle commencer avec WebJobs serait préférable (les outils de Fonctions ne sont peut-être pas encore aussi stables).
Je voudrais ajouter deux autres points aux anciens et longs messages ci-dessus. si vous choisissez un plan de consommation dans les fonctions Azure, voici les limitations.
Si vous souhaitez exécuter des tâches de plus de 10 minutes, choisissez Webjobs. Azure fonctionne uniquement 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'attente jusqu'à 10 minutes dans Host.json.
Remarque: Il n'y a pas de problème de délai si vous utilisez les fonctions Azure du plan de services de l'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 tout démarrage à froid, Azure Function Application propose un plan premium dans lequel une instance fonctionnera à tout moment et en fonction du chargement. L'application fonctionnelle démarrera la mise à l'échelle et vous serez facturé pour une instance et d'autres instances basées sur la consommation.
Je me rends compte que je suis très en retard pour le jeu avec cette réponse, mais comme il s’agit toujours d’un excellent résultat de recherche sur Google, je souhaitais donner des indications précises sur ce sujet du point de vue des coûts car il semble que le PO ait des inquiétudes concernant les coûts. Il y a déjà quelques bonnes réponses ici qui parlent des limitations techniques et des détails sur le fonctionnement de chaque service, alors je ne vais pas les reformuler.
Si vous avez absolument besoin de quelque chose qui fonctionne pour "gratuitement" (sans aucun coût supplémentaire à ce que vous avez déjà payé pour votre application Web), alors vous avez deux options:
- Webjobs - déployé avec votre application Web existante et utilise les mêmes ressources que votre application Web. L'utilisation de WebJobs n'entraîne pas de coût monétaire supplémentaire, mais il existe certaines limitations pouvant entraîner des coûts de performance pour votre application Web.
- Fonctions - Lors de l’utilisation du plan de consommation, un certain nombre d’exécutions gratuites vous sont attribuées. Le nombre au moment d'écrire ces lignes est en fait assez élevé, 1 million d'exécutions gratuites. Cependant, la limite d'exécution d'un million n'est pas la limite susceptible de vous causer des problèmes; c'est le 400K GB-s (gigaoctet secondes). Il s’agit en gros 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 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 non limité à aucun coût , vous avez plus d'options disponibles.
- Fonctions - Vous pouvez exécuter le plan de consommation ou le plan de services de l’application à un prix relativement avantageux. Gardez toutefois à l’esprit le modèle de facturation de la Grande-Bretagne. Si vous utilisez le plan de consommation et effectuez des travaux "lourds" fréquents, vous risquez d'être surpris par une facture importante.
- Services en nuage - Cette option n'a pas été discutée, principalement parce que le PO n'a pas posé de question. Mais c'est aussi une option viable. Les services en nuage ne sont finalement que des ordinateurs virtuels exécutés dans le nuage. Vous pouvez donc exécuter tous les travaux d'arrière-plan dont vous avez besoin. Ils évoluent assez bien (bien que vous deviez câbler vos propres déclencheurs pour l'exécution, un léger inconvénient comparé aux tâches/fonctions web. ). Ils ont un coût initial plus élevé qui leur est associé (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 que vous faites beaucoup de travail "lourd", les services en nuage pourraient être un meilleur choix. car il est plus facile de gérer/surveiller un VM à prix fixe que des exécutions et des gigaoctets secondes, à mon avis. L'autre avantage des services de cloud computing 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 êtes intéressé par la lecture de certains scénarios spécifiques et par la raison pour laquelle je choisirais l'un (Webjobs, fonctions, services cloud) plutôt que l'autre, j'ai récemment écrit un article de blog sur webjobs vs fonctions vs services cloud .