Azure Webjobs vs Azure-Funktionen: So wählen Sie aus

162

Ich habe einige Azure-Webjobs erstellt , die Trigger verwenden, und ich habe gerade etwas über Azure-Funktionen gelernt .

Soweit ich weiß, scheinen sich Azure-Funktionen mit Azure Webjobs-Funktionen zu überschneiden, und ich habe einige Schwierigkeiten zu verstehen, wann ich zwischen Funktion und Webjob wählen soll:

Im Gegensatz zu Webjobs können Funktionen nur ausgelöst werden. Sie wurden nicht für die Ausführung eines kontinuierlichen Prozesses entwickelt (Sie können jedoch Code schreiben, um eine kontinuierliche Funktion zu erstellen).
Sie können Webjobs und Funktionen in vielen Sprachen (C #, node.js, python ...) schreiben, aber Sie können Ihre Funktion über das Azure-Portal schreiben, damit das Testen und Bereitstellen einer Funktion einfacher und schneller entwickelt werden kann.
Webjobs werden als Hintergrundprozesse im Kontext einer App Service-Webanwendung, API-App oder mobilen App ausgeführt, während Funktionen mithilfe eines klassischen / dynamischen App Service-Plans ausgeführt werden.
In Bezug auf die Skalierung scheinen Funktionen mehr Möglichkeiten zu bieten, da Sie einen dynamischen App-Serviceplan verwenden und eine einzelne Funktion skalieren können, während Sie für einen Webjob die gesamte Web-App skalieren müssen.

Es gibt also sicher einen Preisunterschied. Wenn eine vorhandene Web-App ausgeführt wird, können Sie damit einen Webjob ohne zusätzliche Kosten ausführen. Wenn ich jedoch keine vorhandene Web-App habe und Code schreiben muss, um eine Warteschlange auszulösen soll ich einen Webjob oder eine Funktion verwenden?

Gibt es weitere Überlegungen, die Sie berücksichtigen müssen, wenn Sie eine Auswahl treffen müssen?

azure azure-webjobs azure-functions

— Thomas
quelle

6

Dies ist ein Blog-Beitrag, den ich schulde. :) Ich werde versuchen, eine Antwort vorzubereiten, aber dies kann für Stack Overflow etwas offen sein, daher müssen Sie dies möglicherweise auf MSDN fragen, wenn es geschlossen wird.

— Chris Anderson-MSFT

Schöner (kurzer) Blog-Beitrag zu diesem Thema geekswithblogs.net/tmurphy/archive/2016/06/02/…

— Todd Menier

Hey Todd, zögern Sie nicht, meine Frage zu bearbeiten, um den Link hinzuzufügen. Interessanter Artikel ^^

— Thomas

@ chris-anderson-msft Können wir PowerShell als Webjob ausführen? Können wir das PowerShell-Paket auf Webjob installieren?

— Anomepani

170

Hier im App Service gibt es einige Optionen. Ich werde Logic Apps oder Azure Automation nicht berühren, die auch diesen Bereich berühren.

Azure WebJobs

Dieser Artikel ist ehrlich gesagt die beste Erklärung, aber ich werde hier zusammenfassen.

On Demand WebJobs aka. Geplante WebJobs aka. Ausgelöste WebJobs

Ausgelöste WebJobs sind WebJobs, die einmal ausgeführt werden, wenn eine URL aufgerufen wird oder wenn die Schedule-Eigenschaft in Schedule.job vorhanden ist . Geplante WebJobs sind nur WebJobs, für die ein Azure Scheduler-Job erstellt wurde, um unsere URL nach einem Zeitplan aufzurufen. Wir unterstützen jedoch auch die Schedule-Eigenschaft, wie bereits erwähnt.

Zusammenfassung:

+ Ausführbare Datei / Skript auf Anfrage
+ Geplante Ausführungen
- Müssen über .scm Endpunkt auslösen
- Die Skalierung erfolgt manuell
- VM ist immer erforderlich

Kontinuierliche WebJobs (kein SDK)

Diese Jobs laufen für immer und wir werden sie wecken, wenn sie abstürzen. Sie müssen Always On aktivieren, damit diese funktionieren. Dies bedeutet, dass Sie sie in der Basisstufe und höher ausführen.

Zusammenfassung:

+ Ausführbare Datei / Skript wird immer ausgeführt
- Benötigt immer auf - Basisstufe und höher
- VM ist immer erforderlich

Kontinuierliche WebJobs mit dem WebJobs SDK

Dies ist aus Sicht von "WebJobs the feature" nichts. Im Wesentlichen haben wir dieses süße SDK, das wir für WebJobs geschrieben haben und mit dem Sie Code basierend auf einfachen Triggern ausführen können. Ich werde später mehr darüber sprechen.

Zusammenfassung:

+ Ausführbare Datei / Skript wird immer ausgeführt
+ Reichhaltigere Protokollierung / Dashboard
+ Auslöser werden zusammen mit lang laufenden Aufgaben unterstützt
- Benötigt immer auf - Basisstufe und höher
- Die Skalierung erfolgt manuell
- Der Einstieg kann etwas lästig sein
- VM ist immer erforderlich

Azure WebJobs SDK

Das Azure WebJobs SDK ist ein vollständig von der Plattformfunktion WebJobs getrenntes SDK. Es ist für die Ausführung in einem WebJob konzipiert, kann aber wirklich überall ausgeführt werden. Wir haben Kunden, die sie in Worker-Rollen und sogar in Prem- oder anderen Clouds ausführen, obwohl Support nur die beste Anstrengung ist.

Das SDK soll es einfach machen, Code als Reaktion auf ein Ereignis auszuführen und eine Bindung an Dienste / etc. einfach. Dies wird ehrlich gesagt am besten in einigen Dokumenten behandelt , aber das Herzstück ist das "Ereignis" + "Code". Wir haben auch einige coole Erweiterungsarbeiten durchgeführt, aber das ist dem Hauptzweck untergeordnet.

Zusammenfassung:

Die meisten davon sind oben erwähnt
+Sie können erweitern und ausführen, was Sie wollen. Volle Kontrolle.
- HTTP-Zeug ist ein wenig wackelig, aber es funktioniert

Azure-Funktionen

Bei Azure-Funktionen geht es darum, den Hauptzweck des WebJobs SDK zu nutzen, es als Dienst zu hosten und den Einstieg in andere Sprachen zu vereinfachen. Wir führen hier auch das "Serverless" -Konzept ein, weil es sehr sinnvoll war - wir wissen, wie unser SDK skaliert, damit wir intelligente Dinge für Sie tun können.

Azure-Funktionen sind eine sehr stark verwaltete Erfahrung. Wir unterstützen es nicht, Ihren eigenen Gastgeber mitzubringen. Derzeit unterstützen wir keine benutzerdefinierten Erweiterungen, aber wir untersuchen dies. Wir sind der Meinung, was Sie tun können und was nicht, aber für die Dinge, die wir ermöglichen, sind sie geschickt und einfach zu bedienen und zu verwalten.

Die meisten "Framework" -Dinge, die wir zur Verbesserung der Funktionen getan haben, werden jedoch über das WebJobs SDK durchgeführt. Zum Beispiel werden wir ein neues NuGet für WebJobs hochladen, das die Protokollierungsgeschwindigkeit drastisch erhöht, was für WebJobs SDK-Benutzer enorme Perf-Vorteile bietet. Bei den Versandfunktionen als "WebJobs SDK as a Service" haben wir viele Erfahrungsprobleme wirklich verbessert.

+ Viele Sprachen werden unterstützt
+ Vollständig verwaltete, dynamische Skalierung
+ Einfach zu bedienendes Portal mit UX zum Verwalten von Verbindungen / etc.
- Host (noch) nicht anpassbar
~ Läuft in einer separaten "App", die einige Konfigurationen in Ihrem Repo erfordert, aber die langfristige Wartung erheblich vereinfacht.
~ ~~(Noch) keine Werkzeuge~~ Einige Werkzeuge sind jetzt in Alpha oder Vorschau verfügbar - https://www.npmjs.com/package/azurefunctions (Update Februar 2017: Visual Studio-Tools für Azure-Funktionen jetzt in der Vorschau verfügbar: https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / Visual-Studio-Tools-für-Azure-Funktionen / )

Ich bin wahrscheinlich voreingenommen, da Funktionen unsere neueste und beste ist, aber ich kann gerne mehr Nachteile für Funktionen auf meine Weise erzielen.

Ich werde wahrscheinlich einen Blog veröffentlichen, der etwas ausführlicher ist, aber ich habe versucht, dies für dieses Forum so kurz wie möglich zu halten.

— Chris Anderson-MSFT
quelle

1

Klingt großartig. DM mich auf Twitter (@crandycodes), wenn Sie Fragen haben. Ich kann Ihnen helfen, Ihre Beispiele auf Azure.com zu bewerben, wenn Sie dies auch möchten, wenn Sie sie freigeben möchten.

— Chris Anderson-MSFT

1

Ich konnte sehen, dass das nützlich war. Ich weiß, dass es viel Raum gibt, um zu diskutieren, wie man vom Server zu serverlosen Anwendungsmustern übergeht. Diese Art von scheint mit dem zu tun zu haben, was Sie gerade beschrieben haben.

— Chris Anderson-MSFT

1

Grundsätzlich nehmen wir Ihren Code und Ihre Konfiguration und erstellen eine WebJob SDK-Funktion (daher der Name Azure-Funktionen) unter dem Deckmantel. Ihr Code wird also in einer WebJob SDK-Funktion ausgeführt, die wir für Sie verwalten.

— Chris Anderson-MSFT

1

Jede Funktions-App hat 1 Host (den Sie sich als WebJob vorstellen können). Ihre Funktionen in einer Funktions-App teilen sich ein Dateisystem, App-Einstellungen, Speicher, CPU usw. Sie können gerne eine neue Frage stellen.

— Chris Anderson-MSFT

2

Ja. Der Timer-Trigger. Cron-Ausdruck von {0 * / 30 * * * *} azure.microsoft.com/en-us/documentation/articles/…

— Chris Anderson-MSFT

17

Als Azure-Funktionen, die auf dem WebJobs SDK basieren, bieten sie die meisten Funktionen, die bereits in WebJobs verfügbar sind, jedoch einige neue coole Funktionen.

In Bezug auf Trigger können Azure-Funktionen zusätzlich zu den bereits für WebJobs verfügbaren (z. B. Service Bus, Speicherwarteschlangen, Speicher-Blobs, CRON-Zeitpläne, WebHooks, EventHub und File Cloud-Speicheranbieter) als APIs ausgelöst werden. Für HTTP-Aufrufe sind keine Kudu-Anmeldeinformationen erforderlich, sie können jedoch über Azure AD und Identitätsanbieter von Drittanbietern authentifiziert werden.

In Bezug auf die Ausgaben besteht der einzige Unterschied darin, dass Funktionen eine Antwort zurückgeben können, wenn sie über HTTP aufgerufen werden.

Beide unterstützen eine Vielzahl von Sprachen , darunter: Bash (.sh), Batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell und Python.

Da die Funktionen derzeit in der Vorschau angezeigt werden, sind die Werkzeuge immer noch nicht ideal. Aber Microsoft arbeitet daran. Hoffentlich erhalten wir die gleiche Flexibilität beim Entwickeln und Testen von Funktionen vor Ort wie derzeit für WebJobs mit Visual Studio.

Die wichtigsten und coolsten Vorteile von Funktionen sind die Alternative zu einem dynamischen Serviceplan mit einem "serverlosen" Modell , bei dem keine VM-Instanzen oder keine Skalierung verwaltet werden müssen. es ist alles für uns verwaltet. Da wir keine dedizierten Instanzen haben, zahlen wir nur für die Ressourcen, die wir tatsächlich verwenden.

Ein detaillierterer Vergleich zwischen den beiden hier: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

— Paco de la Cruz
quelle

Danke für deine Antwort Paco! Dieser Vergleich kann viele Menschen interessieren :-) Aber ich habe nicht nach einem Vergleich gesucht, sondern nur versucht zu verstehen, wann ich eher mit Funktionen als mit Webjobs arbeiten sollte!

— Thomas

6

Es ist schwer, eine klare Anleitung zu haben, ohne den Kontext zu kennen. Deshalb habe ich geglaubt, dass ein Vergleich für die Leute hilfreich sein könnte :) Ich würde das sagen:

if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else  { continueWIthWebJobs(); }

:)

— Paco de la Cruz

Funktionen können eine Antwort zurückgeben, wenn sie über HTTP aufgerufen werden. Funktionen basieren jedoch auf dem WebJobs SDK. Seltsam, nicht wahr?

— RudyCo

Wahrscheinlich ist es besser zu sagen , dass sie wurden auf dem WebJobs SDK basiert, aber sie haben ziemlich viel entwickelte sich von dort :)

— Paco de la Cruz

14

Laut den Dokumenten hat Azure Functions Folgendes, was WebJobs nicht tut:

Automatische Skalierung (CPU und Speicher werden entsprechend den zur Laufzeit ermittelten Anforderungen skaliert)
Pay-per-Use-Preise (Verbrauchsplan statt App-Service-Plan)
Weitere Triggerereignisse (wie WebHooks)
In-Browser-Entwicklung (Visual Studio noch möglich)
F # Unterstützung

Einfach ausgedrückt: Azure Functions ist das neuere Tier. Wenn Sie noch keinen App Service-Plan haben, würde ich mich für Funktionen entscheiden, da ich langfristig keine Gründe sehe, warum es besser wäre, mit WebJobs zu beginnen (das Funktionswerkzeug ist jedoch möglicherweise noch nicht so stabil).

— user764754
quelle

14

Ich möchte den obigen langen und etwas alten Beiträgen noch zwei weitere Punkte hinzufügen. Wenn Sie in Azure-Funktionen den Verbrauchsplan auswählen, sind die folgenden Einschränkungen aufgeführt

Wenn Sie Jobs länger als 10 Minuten ausführen möchten, wählen Sie Webjobs. Azure-Funktionen werden standardmäßig nur 5 Minuten lang ausgeführt . Wenn Ihr Prozess 5 Minuten überschreitet, löst die Azure-Funktion eine Timeout-Ausnahme aus. Sie können erhöhen das Timeout auf 10 Minuten in host.json .

Hinweis: Wenn Sie die Azure-Funktionen des App Service Plan verwenden, tritt kein Timeout-Problem auf.

Ein weiterer Grund zur Unterscheidung ist. Wenn Sie die Azure-Funktion verwenden, ist Ihre anfängliche Startzeit langsam, da die Maschinen (Container) im laufenden Betrieb erstellt und nach ihrer Verwendung zerstört werden.

Um einen Kaltstart zu vermeiden, hat die Azure-Funktions-App einen Premium-Plan veröffentlicht, bei dem eine Instanz ständig ausgeführt wird. Basierend auf der Last beginnt die Funktions-App mit der Skalierung, und Ihnen werden eine Instanz und andere Instanzen basierend auf dem Verbrauch in Rechnung gestellt.

— Karthikeyan VK
quelle

Ihr erster Punkt gilt nur, wenn Sie den Verbrauchsplan verwenden. Mit einem bezahlten Sku haben Sie kein Timeout-Limit. Ich stimme dem zweiten Punkt zu.

— Thomas

Ich denke, beide Punkte gelten für den Verbrauchsplan. Vielen Dank für den Hinweis

— Karthikeyan VK

4

Große Erwähnung von Timeouts. Für uns ist dies ein wichtiger Faktor

— Niels Filter

1

Sie können jedoch beim Erstellen von Azure-Funktionen einen Appservice-Plan auswählen. Aber es besiegt den ganzen Zweck

— Karthikeyan VK

1

@KarthikeyanVK, ich bin nicht sicher, ob es noch genau ist, da die Funktion Laufzeit v2 mehr als 10 Minuten erlaubt?

— Thomas

6

Mir ist klar, dass ich mit dieser Antwort sehr spät zum Spiel komme, aber da dies immer noch ein Top-Suchergebnis bei Google ist, wollte ich aus Kostengründen einige Hinweise zu diesem Thema geben, da das OP anscheinend Bedenken hinsichtlich der Kosten hat . Es gibt hier bereits einige großartige Antworten, die über die technischen Einschränkungen und Details der Funktionsweise der einzelnen Dienste sprechen. Daher werde ich diese Antworten nicht erneut aufbereiten.

Wenn Sie unbedingt etwas benötigen, das "kostenlos" läuft (da keine zusätzlichen Kosten zu dem anfallen, was Sie bereits für Ihre Web-App bezahlt haben), haben Sie zwei Möglichkeiten:

Webjobs - werden zusammen mit Ihrer vorhandenen Web-App bereitgestellt und verwenden dieselben Ressourcen wie Ihre Web-App. Die Verwendung von Webjobs verursacht keine zusätzlichen finanziellen Kosten. Wie bereits erwähnt, gibt es jedoch einige Einschränkungen, die zu Leistungskosten für Ihre Web-App führen können.
Funktionen - Bei Verwendung des Verbrauchsplans wird Ihnen eine bestimmte Anzahl freier Ausführungen zugewiesen. Die Zahl zum Zeitpunkt dieses Schreibens ist tatsächlich ziemlich hoch, 1 Million freie Hinrichtungen. Das Ausführungslimit von 1 Million ist jedoch nicht das Limit, das Ihnen wahrscheinlich Probleme bereiten wird. Es sind die 400K GB-s (Gigabyte Sekunden). Dies ist im Grunde eine Berechnung der Speichermenge, die Ihre Funktion verwendet, multipliziert mit der Anzahl der Sekunden, die sie ausgeführt wird (siehe die offizielle Berechnung auf der Preisseite hier ). Sie werden überrascht sein, wie schnell diese kostenlose Zuteilung aufgebraucht ist.

Wenn Sie sich Gedanken über die Kosten machen, aber nicht auf keine Kosten beschränkt sind , stehen Ihnen mehr Optionen zur Verfügung.

Funktionen - Sie können entweder im Verbrauchsplan oder im App-Serviceplan zu einem relativ günstigen Preis ausgeführt werden. Beachten Sie jedoch das Abrechnungsmodell des GB. Wenn Sie den Verbrauchsplan verwenden und häufig "schwere" Arbeiten ausführen, werden Sie möglicherweise von einer hohen Rechnung überrascht.
Cloud-Dienste - Diese Option wurde nicht als Alternative erörtert, hauptsächlich weil das OP nicht danach gefragt hat. Dies ist aber auch eine praktikable Option. Cloud-Dienste sind letztendlich nur VMs, die in der Cloud ausgeführt werden, sodass Sie alle Hintergrundjobs ausführen können, die Sie für sie benötigen, und sie lassen sich ziemlich gut skalieren (obwohl Sie Ihre eigenen Trigger für die Ausführung verkabeln müssen, was im Vergleich zu Webjobs / Funktionen eine leichte Unannehmlichkeit darstellt ). Mit ihnen sind höhere Anfangskosten verbunden (weil Sie pro Instanz zahlen, unabhängig davon, ob Sie sie verwenden oder nicht). Wenn Sie jedoch Jobs haben, die ständig ausgeführt werden müssen und viel "schweres" Heben ausführen, sind Cloud-Dienste möglicherweise die bessere Wahl weil es meiner Meinung nach einfacher ist, eine VM mit festem Preis zu verwalten / zu überwachen als Ausführungen und Gigabyte-Sekunden.

Wenn Sie daran interessiert sind, einige spezifische Szenarien durchzulesen und warum ich eines (Webjobs, Funktionen, Cloud-Dienste) dem anderen vorziehen würde, habe ich kürzlich einen Blog-Beitrag über Webjobs vs. Funktionen vs. Cloud-Dienste geschrieben .

— Dan
quelle

1

Vielen Dank für die Antwort @Dan :-) Ich würde sagen, der Cloud-Service ist immer noch nett, aber ich habe darüber nachgedacht, Webjob und Funktionen zu vergleichen, da sie dasselbe Kern-SDK und zweieinhalb Jahre zuvor verwenden. Ich habe den Zweck von Serverless nicht wirklich verstanden :-)

— Thomas

3

Eine wichtige Überlegung ist, dass Azure Functions nach Version 1, die mit Version 2.0 eingestellt wurde und die sich in der jetzt in der Vorschau Version 3.0 nicht ändern wird, die Unterstützung von .NET Framework beendet. 😔

Die Dokumentation macht dies hier deutlich ,
wie auch diese Rückmeldung ,
sowie dieses Github-Problem / diese Antwort .

In der Zwischenzeit wurde dieser stark bewaffnete Ansatz glücklicherweise noch nicht auf Azure WebJobs angewendet :

Version 3.x des WebJobs SDK unterstützt sowohl .NET Core- als auch .NET Framework-Konsolen-Apps.

— Nicholas Petersen
quelle

Ja, guter Punkt. Trotzdem sollten die Leute von nun an versuchen, den Netzkern so oft wie möglich zu verwenden.

— Thomas

0

Ich möchte die Gemeinsamkeiten und Unterschiede zwischen den beiden Azure-Funktionen erläutern, die auf AppService und WebJobs SDK aufbauen. Mit dem WebJobs SDK haben Sie mehr Freiheit beim Spielen, während die Azure-Funktionen strukturierter sind und weniger Verantwortung für die Entwickler übernehmen.

Wenn Sie sich die Gemeinsamkeiten ansehen Beide verwenden den funktionsorientierten Programmiermodus, Bindungen für Trigger / Input / Output, unterstützen externe Bibliotheken und können Supportruntime-Toilettenartikel lokal ausführen und debuggen.

Unterschiede

|-----------------------|------------------|
|      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|
--------------------------------------------

— Sajeetharan
quelle