Azure Webjobs vs Azure Functions：選択方法
トリガーを使用する Azure Webjobs を作成し、 Azure Functions について学習しました。
私が理解していることから、Azure FunctionsはAzure Webjobs機能と重複しているように見え、FunctionとWebjobのどちらを選択するかを理解するのが少し困難です：
Webjobsとは異なり、Functionsはトリガーのみ可能です。連続プロセスを実行するようには設計されていません（ただし、連続関数を作成するコードを作成できます）。
多くの言語（C＃、node.js、python ...）を使用してWebjobと関数を記述できますが、Azureポータルから関数を記述できるため、関数のテストとデプロイをより簡単かつ迅速に開発できます。
WebjobsはApp Service Webアプリ、APIアプリ、またはモバイルアプリのコンテキストでバックグラウンドプロセスとして実行されますが、関数はClassic/Dynamic App Serviceプランを使用して実行されます。
スケーリングに関しては、動的アプリサービスプランを使用でき、単一の関数をスケーリングできるので、Functionsはより多くの可能性を提供するようです。
確かに価格に違いがあります。既存のWebアプリを実行している場合は、追加費用なしでWebジョブを実行できますが、既存のWebアプリがなく、キューをトリガーするコードを記述する必要がある場合webjobまたはFunctionを使用する必要がありますか？
選択する必要があるときに留意すべきその他の考慮事項はありますか？
App Serviceには、いくつかのオプションがあります。このスペースに触れるLogic AppsやAzure Automationには触れません。
Azure WebJobs
この記事 は正直なところ最良の説明ですが、ここで要約します。
オンデマンドWebJobs別名。スケジュールされたWebJobs別名。トリガーされたWebジョブ
トリガーされたWebジョブは、URLが呼び出されたとき、または scheduleプロパティがschedule.job に存在するときに1回実行されるWebジョブです。スケジュールされたWebジョブは、スケジュールでURLを呼び出すためにAzure Schedulerジョブが作成されたWebジョブだけですが、前述のように、スケジュールプロパティもサポートします。
概要：
+Executable/Script on demand+スケジュールされた実行-.scmエンドポイント経由でトリガーする必要があります-スケーリングは手動です-VMは常に必要です
連続Webジョブ（非SDK）
これらのジョブは永遠に実行され、クラッシュしたときにそれらを起動します。これらを機能させるには、Always Onを有効にする必要があります。つまり、Basicティア以上で実行する必要があります。
概要：
+実行可能ファイル/スクリプトは常に実行中-常時オンが必要-基本層以上-VMは常に必要です
WebJobs SDKを使用した継続的なWebジョブ
これらは「WebJobs the feature」の観点からは何もありません。基本的に、シンプルなトリガーに基づいてコードを実行できるWebJobsをターゲットに作成したこの甘いSDKがあります。これについては後で詳しく説明します。
概要：
+実行可能ファイル/スクリプトは常に実行中+より豊富なロギング/ダッシュボード+トリガーは長時間実行されるタスクとともにサポートされます-常時オンが必要-基本層以上-スケーリングはセットアップが手動です-始めるのは少し面倒です-VMは常に必要です
Azure WebJobs SDK
Azure WebJobs SDKは、WebJobsのプラットフォーム機能とは完全に独立したSDKです。 WebJobで実行するように設計されていますが、実際にはどこでも実行できます。サポートはベストエフォートに過ぎませんが、ワーカーロールで、さらにはpremやその他のクラウドで実行する顧客がいます。
SDKは、イベントに反応してコードを簡単に実行し、サービスなどにバインドできるようにすることを目的としています。簡単です。これは正直なところいくつかの docs でカバーされていますが、その中心は「イベント」+「コード」の性質です。また、いくつかのクールな拡張性の作業を行いましたが、それはコアの目的に二次的です。
概要：
- これらのほとんどは上記のとおりです
+好きなものを拡張して実行できます。フルコントロール。-HTTPのものは少し不安定ですが、動作します
Azure関数
Azure Functionsは、WebJobs SDKの中心的な目的を実現し、それをサービスとしてホストし、他の言語で簡単に使い始めることができるようにすることです。また、ここでは「サーバーレス」の概念を紹介します。これは非常に理にかなっているためです。SDKのスケーリング方法を知っているため、インテリジェントなことを行うことができます。
Azure Functionsは非常に厳しく管理されたエクスペリエンスです。独自のホストの持参はサポートしていません。現在、カスタム拡張機能はサポートしていませんが、調査中です。私たちはあなたができることとできないことについて意見を述べていますが、私たちが可能にすることに関しては、それらは滑らかで、使いやすく、管理しやすいです。
ただし、関数を改善するために行った「フレームワーク」のほとんどは、WebJobs SDKを使用します。たとえば、WebJobs用の新しいNuGetをアップロードします。これにより、ロギングの速度が大幅に向上します。これにより、WebJobs SDKのユーザーにとってパフォーマンスが大幅に向上します。 「WebJobs SDK as a Service」として機能を出荷する際に、多くの経験の問題を本当に改善しました。
+サポートされている多くの言語+完全に管理された動的スケーリング+接続を管理するためのUXを使用した使いやすいポータルなど。-ホストはカスタマイズできません（まだ）~別の「アプリ」で実行します。これは、リポジトリでの設定が必要ですが、長期的なメンテナンスがはるかに簡単になります。~ツーリングなし（まだ）一部のツールはアルファ版またはプレビュー版になりました- https://www.npmjs.com/package/azurefunctions （2017年2月更新：Visual Studio Tools for Azureプレビューで使用可能な機能： https://blogs.msdn.Microsoft.com/webdev/2016/12/01/visual-studio-tools-for-Azure-functions/ ））
Functionsは最新かつ最高の機能なので、私はおそらく偏見がありますが、Functionsについては自分のやり方でもっと短所を考えてください。
おそらくもう少し詳しく説明するブログを公開することになるでしょうが、このフォーラムではできる限り簡潔にするようにしました。
WebJobs SDKに基づくAzure Functionsであるため、WebJobsで既に利用可能なほとんどの機能を提供しますが、いくつかの新しいクールな機能を備えています。
triggersの観点から、WebJobsですでに利用可能なもの（サービスバス、ストレージキュー、ストレージBLOB、CRONスケジュール、WebHooks、EventHubなど）に加えて、 File Cloud Storageプロバイダー）、Azure FunctionsはAPIとしてトリガーできます。また、HTTP呼び出しにはkuduの資格情報は必要ありませんが、Azure ADおよびサードパーティのIDプロバイダーを介して認証できます。
outputsに関しては、唯一の違いは、関数がHTTP経由で呼び出されたときに応答を返すことができることです。
両方とも、bash（.sh）、batch（.bat/.cmd）、C＃、F＃、Node.Jsなど、幅広いさまざまな言語をサポートしています、PHP、PowerShell、Python。
現在プレビュー中の関数であるため、toolingはまだ理想的ではありません。しかし、マイクロソフトはそれに取り組んでいます。現在、Visual StudioでWebJobsを使用している場合と同じように、ローカルで関数を開発およびテストする柔軟性が得られることを願っています。
Functionsによってもたらされる最も重要でクールな利点は、Dynamic Service Planと "Serverless" model。VMインスタンスやスケーリングを管理する必要はありません。すべて管理されています。さらに、専用のインスタンスを持たないことにより、実際に使用したリソースに対してのみ支払います。
ここの2つの詳細な比較： https://blog.kloud.com.au/2016/09/14/Azure-functions-or-webjobs/
HTH :)
docs によると、Azure FunctionsにはWebJobsにはない次の機能があります。
- 自動スケーリング（CPUおよびメモリは、実行時に決定されたニーズに従ってスケーリングされます）
- 従量課金制（App Serviceプランではなく消費プラン）
- より多くのトリガーイベント（WebHooksなど）
- ブラウザー内開発（Visual Studioは引き続き可能）
- F＃サポート
簡単に言えば、Azure Functionsは新しい動物です。 App Serviceプランをまだお持ちでない場合は、長期的にはWebJobsから始める方が良い理由がわからないので、Functionsを使用します（ただし、Functionsツールはまだ安定していません）。
上記の長くて少し古い投稿にさらに2点追加したいと思います。 Azure機能で消費計画を選択した場合、以下の制限があります
10分以上ジョブを実行する場合は、webjobsを選択します。 Azure関数は、デフォルトで5分でのみ実行されます。プロセスが5分を超えると、Azure関数はタイムアウト例外をスローします。 increaseのタイムアウトをHost.jsonで10分にできます。
注：アプリサービスプランのAzure機能を使用している場合、タイムアウトの問題はありません。
区別するもう1つの理由は次のとおりです。 Azure機能を使用する場合、マシン（コンテナー）はオンザフライで作成され、使用されると破棄されるため、初期開始時間が遅くなります。
私はこの答えでゲームに非常に遅れていることに気付きますが、これはまだGoogleのトップの検索結果なので、コストの観点からこのトピックに関するいくつかのガイダンスを厳密に与えたいと思いましたOPにはコストに関する懸念があるようです。技術的な制限と各サービスの仕組みの詳細について説明するいくつかの素晴らしい回答が既にありますので、それらの回答を再ハッシュするつもりはありません。
「無料」で実行するものが絶対に必要な場合（Webアプリの料金を追加費用なしで） 2つのオプション：
- Webjobs-既存のWebアプリと一緒にデプロイされ、Webアプリと同じリソースを使用します。ウェブジョブを使用するための追加の金銭的費用はありませんが、ウェブアプリのパフォーマンスコストにつながる可能性のある前述の制限がいくつかあります。
- 機能-消費計画を使用すると、一定量の無料実行が割り当てられます。この記事の執筆時点での数は実際には非常に多く、100万回の無料実行です。ただし、100万件の実行制限は、問題を引き起こす可能性のある制限ではありません。 400K GB-s（ギガバイト秒）です。これは基本的に、関数が使用するメモリ量に実行秒数を掛けた計算です（ 価格設定ページ の公式計算を参照）。この無料の割り当てがすぐに使い果たされることに驚くでしょう。
コストを心配しているが、コストに制限されていない場合は、さらに多くのオプションを利用できます。
- 機能-比較的安価な価格で消費プランまたはアプリサービスプランのいずれかで実行できます。ただし、GB-s課金モデルに留意してください。消費計画を使用していて、頻繁に「重い」作業をしている場合、大きな請求書に驚くかもしれません。
- クラウドサービス-このオプションは、主にOPがそれについて尋ねなかったため、代替手段として議論されていませんしかし、これも実行可能なオプションです。クラウドサービスは最終的にはクラウドで実行される単なるVMであるため、必要なバックグラウンドジョブを実行でき、スケールアップ/スケールダウンは非常にうまく行えます（ただし、実行のために独自のトリガーをワイヤリングする必要がありますが、Webジョブ/機能と比べると少し不便です） ）。関連付けられている初期コストは高くなります（使用するかどうかに関係なくインスタンスごとに支払うため）私の意見では、固定価格のVMの管理/監視は、実行とギガバイト秒よりも簡単だからです。クラウドサービスのもう1つの良い点は、タイムアウトや以前の回答で言及した他の制限について心配する必要がないことです。
いくつかの特定のシナリオを読み、なぜ他のシナリオ（webjobs、functions、cloud services）を選択することに興味がある場合、最近 webjobs vs functions vs cloud services に関するブログ記事を書きました。