Azure Webjobs a Azure Functions: jak wybrać

Utworzyłem kilka zadań Webjobs platformy Azure, które używają wyzwalaczy, i właśnie dowiedziałem się o usłudze Azure Functions .

Z tego, co rozumiem, usługi Azure Functions wydają się nakładać na funkcje usługi Azure Webjobs i mam pewne trudności ze zrozumieniem, kiedy wybrać między funkcją a pracą w sieci Web:

• W przeciwieństwie do zadań Webjob, funkcje mogą być wyzwalane tylko, nie zostały zaprojektowane do uruchamiania ciągłego procesu (ale możesz napisać kod, aby utworzyć ciągłą funkcję).

• Możesz pisać zadania Webjobs i funkcje przy użyciu wielu języków (C #, node.js, python ...), ale możesz napisać swoją funkcję z Azure Portal, aby łatwiej i szybciej opracować test i wdrożyć funkcję.

• Zadania Webjob działają jako procesy w tle w kontekście aplikacji internetowej App Service, aplikacji interfejsu API lub aplikacji mobilnej, podczas gdy funkcje działają przy użyciu planu klasycznej / dynamicznej usługi aplikacji.

• Jeśli chodzi o skalowanie, Functions wydaje się dawać więcej możliwości, ponieważ możesz użyć dynamicznego planu usługi aplikacji i możesz skalować pojedynczą funkcję, podczas gdy w przypadku pracy sieciowej musisz skalować całą aplikację internetową.

Więc na pewno istnieje różnica cenowa, jeśli masz już uruchomioną aplikację internetową, możesz jej użyć do uruchomienia webjob bez żadnych dodatkowych kosztów, ale jeśli nie mam istniejącej aplikacji internetowej i muszę napisać kod, aby uruchomić kolejkę czy powinienem używać pracy internetowej czy funkcji?

Czy są jakieś inne kwestie, o których należy pamiętać przy wyborze?

W ramach usługi App Service jest kilka opcji. Nie będę dotykać Logic Apps ani Azure Automation, które również dotykają tego miejsca.

Azure WebJobs

Ten artykuł jest szczerze najlepszym wyjaśnieniem, ale podsumuję tutaj.

On Demand WebJobs aka. Zaplanowane WebJobs aka. Wyzwalane zadania internetowe

Wyzwalane zadania WebJob to zadania WebJob uruchamiane jednorazowo po wywołaniu adresu URL lub gdy właściwość schedule jest obecna w schedule.job . Zaplanowane zadania WebJobs to po prostu zadania WebJobs, dla których utworzono zadanie Azure Scheduler w celu wywołania naszego adresu URL zgodnie z harmonogramem, ale obsługujemy również właściwość harmonogramu, jak wspomniano wcześniej.

Podsumowanie:

• + Plik wykonywalny / skrypt na żądanie
• + Zaplanowane egzekucje
• - Muszę wywołać za pośrednictwem punktu końcowego .scm
• - Skalowanie jest ręczne
• - Maszyna wirtualna jest zawsze wymagana

Continuous WebJobs (non SDK)

Te prace trwają wiecznie, a my obudzimy je, gdy się zawieszą. Musisz włączyć opcję Zawsze włączone, aby działały, co oznacza uruchamianie ich w warstwie Podstawowa i nowszych.

Podsumowanie:

• + Plik wykonywalny / skrypt zawsze działa
• - Wymagane zawsze włączone - poziom podstawowy i wyższy
• - Maszyna wirtualna jest zawsze wymagana

Ciągłe zadania WebJobs za pomocą zestawu SDK zadań WebJobs

To nie jest nic z punktu widzenia „WebJobs funkcja”. Zasadniczo mamy ten słodki zestaw SDK, który napisaliśmy dla WebJobs, który umożliwia wykonywanie kodu w oparciu o proste wyzwalacze. Porozmawiam o tym później.

Podsumowanie:

• + Plik wykonywalny / skrypt zawsze działa
• + Bogatsze logowanie / pulpit nawigacyjny
• + Wyzwalacze obsługiwane wraz z długotrwałymi zadaniami
• - Wymagane zawsze włączone - poziom podstawowy i wyższy
• - Skalowanie jest konfigurowane ręcznie
• - Rozpoczęcie pracy może być trochę męczące
• - Maszyna wirtualna jest zawsze wymagana

Zestaw SDK Azure WebJobs

Azure WebJobs SDK to całkowicie oddzielny zestaw SDK z funkcji platformy WebJobs. Został zaprojektowany do uruchamiania w WebJob, ale naprawdę można go uruchomić wszędzie. Mamy klientów, którzy uruchamiają je w rolach roboczych, a nawet w chmurze stacjonarnej lub w innych chmurach, chociaż wsparcie to tylko najlepszy wysiłek.

SDK ma po prostu ułatwić uruchamianie kodu w reakcji na jakieś zdarzenie i tworzenie powiązań z usługami / itp. łatwo. Szczerze mówiąc, najlepiej jest to omówione w niektórych dokumentach , ale sednem tego jest natura „zdarzenia” + „kod”. Wykonaliśmy również kilka fajnych prac związanych z ekstensywnością, ale to jest drugorzędne w stosunku do podstawowego celu.

Podsumowanie:

• Większość z nich została wymieniona powyżej
• +Możesz przedłużyć i uruchomić, co chcesz. Pełna kontrola.
• - Rzeczy związane z HTTP są trochę dziwne, ale działają

Azure Functions

Azure Functions polega na wykorzystaniu tego podstawowego celu zestawu SDK WebJobs, hostowaniu go jako usługi i ułatwianiu rozpoczynania pracy z innymi językami. Przedstawiamy tutaj również koncepcję „bezserwerowego”, ponieważ miało to duży sens - wiemy, jak skaluje się nasze SDK, więc możemy robić za Ciebie inteligentne rzeczy.

Azure Functions to bardzo mocno zarządzane środowisko. Nie wspieramy przyprowadzania własnego hosta. Obecnie nie obsługujemy rozszerzeń niestandardowych, ale właśnie to badamy. Zastanawiamy się, co możesz, a czego nie możesz zrobić, ale rzeczy, które umożliwiamy, są sprytne i łatwe w obsłudze i zarządzaniu.

Jednak większość „frameworkowych” rzeczy, które zrobiliśmy w celu ulepszenia funkcji, przechodzi przez pakiet SDK WebJobs. Na przykład będziemy przekazywać nowy pakiet NuGet dla zadań WebJobs, który naprawdę drastycznie zwiększa szybkość rejestrowania, co daje ogromne korzyści w zakresie perf dla użytkowników zestawu SDK zadań WebJobs. W funkcjach wysyłkowych, takich jak „WebJobs SDK jako usługa”, naprawdę poprawiliśmy wiele problemów związanych z obsługą.

• + Obsługiwanych jest wiele języków
• + W pełni zarządzane, dynamiczne skalowanie
• + Łatwy w użyciu portal z UX do zarządzania połączeniami / itp.
• - Nie można dostosować hosta (jeszcze)
• ~ Działa w oddzielnej „aplikacji”, która wymaga pewnej konfiguracji w repozytorium, ale znacznie ułatwia długoterminową konserwację.
• ~ Brak narzędzi (jeszcze) Niektóre narzędzia są teraz w wersji alfa lub w wersji zapoznawczej - https://www.npmjs.com/package/azurefunctions (aktualizacja z lutego 2017 r .: Visual Studio Tools for Azure Functions jest teraz dostępna w wersji zapoznawczej : https: //blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-functions / )

Prawdopodobnie jestem stronniczy, ponieważ Functions jest naszym najnowszym i najlepszym, ale nie krępuj się strzelać więcej wad dla funkcji na swój sposób.

Prawdopodobnie skończę na opublikowaniu bloga, który omawia nieco więcej, ale starałem się, aby to było jak najbardziej zwięzłe na tym forum.

Będąc Azure Functions opartymi na zestawie SDK zadań WebJobs, zapewniają większość funkcji już dostępnych w zadaniach WebJobs, ale z kilkoma nowymi, ciekawymi możliwościami.

Jeśli chodzi o wyzwalacze , oprócz tych, które są już dostępne dla zadań WebJob (np. Service Bus, kolejki magazynu, obiekty BLOB magazynu, harmonogramy CRON, elementy WebHooks, EventHub i dostawcy magazynu w chmurze plików), Azure Functions można wyzwalać jako interfejsy API. A wywołania HTTP nie wymagają poświadczeń Kudu, ale mogą być uwierzytelniane za pośrednictwem usługi Azure AD i dostawców tożsamości innych firm.

Jeśli chodzi o dane wyjściowe , jedyną różnicą jest to, że funkcje mogą zwracać odpowiedź, gdy są wywoływane przez HTTP.

Obie obsługują szeroki gamę języków , w tym: bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell i Python.

Będąc funkcjami w podglądzie, narzędzia nadal nie są idealne. Ale Microsoft nad tym pracuje. Mamy nadzieję, że uzyskamy taką samą elastyczność w tworzeniu i testowaniu funkcji lokalnie, jak obecnie w przypadku zadań WebJobs w programie Visual Studio.

Najbardziej znaczące i fajne korzyści, jakie przynosi Functions, to alternatywa posiadania dynamicznego planu serwisowego z rozszerzeniem modelem „bezserwerowym” , w którym nie musimy zarządzać maszynami wirtualnymi ani skalować; wszystko jest dla nas zarządzane. Dodatkowo, nie mając dedykowanych instancji, płacimy tylko za zasoby, z których faktycznie korzystamy.

Bardziej szczegółowe porównanie między tymi dwoma tutaj: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

Zgodnie z dokumentacją Azure Functions ma następujące elementy, których nie ma WebJobs:

• Automatyczne skalowanie (procesor i pamięć są skalowane zgodnie z potrzebami określonymi w czasie wykonywania)
• Cennik płatności za użycie (plan zużycia zamiast planu usługi App Service)
• Więcej zdarzeń wyzwalających (takich jak WebHooks)
• Programowanie w przeglądarce (nadal możliwe Visual Studio)
• Obsługa języka F #

Mówiąc najprościej: Azure Functions to nowsze zwierzę. Jeśli nie masz jeszcze planu usługi App Service, wybrałbym Functions, ponieważ w dłuższej perspektywie nie widzę żadnych powodów, dla których rozpoczęcie pracy z WebJobs byłoby lepsze (chociaż narzędzia funkcji mogą nie być już tak stabilne).

Chciałbym dodać jeszcze dwa punkty do powyższych długich i trochę starych postów. Jeśli wybierzesz plan zużycia w Azure Functions, poniżej znajdują się ograniczenia

Jeśli chcesz wykonywać zadania dłużej niż 10 minut, wybierz webjobs. Azure functions, domyślnie działa tylko przez 5 minut , jeśli proces przekracza 5 minut, funkcja Azure zgłasza wyjątek limitu czasu. Możesz zwiększyć limit czasu do 10 minut w host.json .

Uwaga: nie ma problemu z przekroczeniem limitu czasu, jeśli używasz funkcji Azure Service planu usługi aplikacji.

Innym powodem do rozróżnienia jest. Jeśli używasz funkcji Azure, początkowy czas rozpoczęcia będzie długi, ponieważ maszyny (kontenery) są tworzone w locie i niszczone po ich użyciu.

Aby uniknąć zimnego startu, Azure Function App wydało plan premium, w którym jedno wystąpienie będzie działało przez cały czas i na podstawie obciążenia aplikacja funkcji rozpocznie skalowanie, a opłaty za jedno wystąpienie i inne wystąpienia będą naliczane na podstawie zużycia.

Zdaję sobie sprawę, że z tą odpowiedzią jestem bardzo spóźniony, ale ponieważ jest to nadal najlepszy wynik wyszukiwania w Google, chciałem udzielić wskazówek na ten temat ściśle z punktu widzenia kosztów, ponieważ wydaje się, że OP ma pewne obawy dotyczące kosztów . Jest już tutaj kilka świetnych odpowiedzi, które mówią o ograniczeniach technicznych i szczegółach działania każdej usługi, więc nie zamierzam ich ponownie mieszać.

Jeśli absolutnie potrzebujesz czegoś, co działa „za darmo” (bez dodatkowych kosztów w stosunku do tego, co już zapłaciłeś za swoją aplikację internetową), masz dwie możliwości:

1. Zadania internetowe - wdrażane wraz z istniejącą aplikacją internetową i wykorzystujące te same zasoby, co Twoja aplikacja internetowa. Korzystanie z zadań webjobs nie wiąże się z żadnymi dodatkowymi kosztami, ale jak już wspomniano, istnieją pewne ograniczenia, które mogą prowadzić do obniżenia wydajności aplikacji internetowej.
2. Funkcje - Korzystając z planu zużycia, przydzielana jest określona liczba bezpłatnych wykonań. Liczba w chwili pisania tego tekstu jest w rzeczywistości dość wysoka, 1 milion bezpłatnych egzekucji. Jednak limit 1 miliona realizacji nie jest limitem, który może sprawić Ci kłopoty; to 400K GB-s (gigabajtowe sekundy). Jest to po prostu obliczenie ilości pamięci używanej przez funkcję pomnożoną przez liczbę sekund, przez które działa (zobacz oficjalne obliczenia na stronie z cenami tutaj ). Będziesz zaskoczony, jak szybko ten darmowy przydział się wyczerpuje.

Jeśli obawiasz się kosztów, ale nie ograniczasz się do żadnych kosztów , masz więcej dostępnych opcji.

1. Funkcje - możesz uruchomić w planie zużycia lub planie usługi aplikacji za stosunkowo niedrogą cenę. Pamiętaj jednak o modelu rozliczeniowym GB-s. Jeśli korzystasz z planu zużycia i wykonujesz częste, „ciężkie” prace - możesz być zaskoczony dużym rachunkiem.
2. Usługi w chmurze - ta opcja nie została omówiona jako alternatywa, głównie dlatego, że OP nie pytał o to. Ale jest to również realna opcja. Usługi w chmurze to ostatecznie tylko maszyny wirtualne działające w chmurze, więc możesz uruchamiać na nich dowolne zadania w tle, których potrzebujesz, i całkiem dobrze skalują się w górę / w dół (chociaż musisz podłączyć własne wyzwalacze do wykonania, niewielka niedogodność w porównaniu do zadań / funkcji internetowych) ). Mają z nimi większy koszt początkowy (ponieważ płacisz za wystąpienie, niezależnie od tego, czy go używasz, czy nie), ale jeśli masz zadania, które muszą być wykonywane w sposób ciągły i wykonują dużo „ciężkich” prac, wówczas usługi w chmurze mogą być lepszym wyborem ponieważ moim zdaniem łatwiej jest zarządzać / monitorować maszynę wirtualną o stałej cenie niż wykonywanie i gigabajtowe sekundy.

Jeśli jesteś zainteresowany przeczytaniem niektórych konkretnych scenariuszy i dlaczego wybrałbym jeden (zadania internetowe, funkcje, usługi w chmurze) zamiast drugiego, niedawno napisałem wpis na blogu na temat zadań internetowych, funkcji i usług w chmurze .

Ważną kwestią jest to, że usługa Azure Functions przestała obsługiwać pełną platformę .NET Framework po wersji 1, która została wycofana z wersją 2.0 i która nie zostanie zmieniona w wersji zapoznawczej 3.0. 😔

• Dokumentacja wyjaśnia to tutaj ,

• podobnie jak ta odpowiedź zwrotna ,

• a także ten problem / odpowiedź na githubie .

W międzyczasie to silnie uzbrojone podejście nie zostało na szczęście zastosowane - jeszcze - do Azure WebJobs :

Wersja 3.x zestawu WebJobs SDK obsługuje zarówno aplikacje konsolowe .NET Core, jak i .NET Framework.

Chciałbym podać jakie są podobieństwa i różnice między dwiema funkcjami platformy Azure, które są zbudowane w oparciu o AppService i WebJobs SDK. Pakiet WebJobs SDK zapewnia większą swobodę podczas zabawy, podczas gdy funkcje platformy Azure są bardziej ustrukturyzowane i mają mniej obowiązków dla programistów.

Patrząc na podobieństwa Obydwa używają trybu programowania zorientowanego na funkcje, powiązań dla wyzwalacza / wejścia / wyjścia, obsługują biblioteki zewnętrzne i mogą uruchamiać i debugować lokalnie przybory toaletowe Supportruntime.

Różnice

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