Rôle du travailleur vs travail Web
D'après ce que je comprends, les deux exécutent de petites tâches reproductibles dans le cloud.
Quelles raisons et dans quelles situations pourrais-je vouloir choisir l'une plutôt que l'autre?
Quelques informations de base:
WebJobs sont bons pour les éléments de travail légers qui ne nécessitent aucune personnalisation de l'environnement dans lequel ils s'exécutent et ne consomment pas beaucoup de ressources. Ils sont également très utiles pour les tâches qui doivent uniquement être exécutées périodiquement, planifiées ou déclenchées. Ils sont bon marché et faciles à installer/exécuter. Ils s'exécutent dans le contexte de votre site Web, ce qui signifie que vous obtenez le même environnement dans lequel votre site Web s'exécute, et toutes les ressources qu'ils utilisent sont des ressources que votre site Web ne peut pas utiliser.
Worker Roles sont adaptés aux charges de travail plus gourmandes en ressources ou si vous devez modifier l'environnement dans lequel ils s'exécutent (par exemple, une version particulière du framework .NET ou quelque chose installé dans le système d'exploitation). Les rôles de travail sont plus chers et légèrement plus difficiles à configurer et à exécuter, mais ils offrent beaucoup plus de puissance.
En général, je commencerais par WebJobs, puis je passerais aux rôles de travail si vous trouvez que votre charge de travail nécessite plus que ce que WebJobs peut offrir.
Si nous devons mesurer la "puissance" comme puissance de calcul, alors dans un environnement virtuel, cela se traduit par le nombre de couches au-dessus de la machine physique (le métal). Le code utilisateur sur une machine virtuelle s'exécute au-dessus d'un hyperviseur, qui gère la machine physique. Il s'agit de la couche la plus épaisse. Dans la mesure du possible, l'hyperviseur essaie simplement de servir d'intermédiaire avec le métal.
Il y a fondamentalement peu de frais généraux pour les WebJobs. Il est en bac à sable, le système d'exploitation est maintenu et il existe des services et des modules pour s'assurer qu'il fonctionne. Mais le code d'application est essentiellement aussi proche du métal que dans les rôles de travail, car ils utilisent le même hyperviseur.
Si ce que vous voulez mesurer est la "flexibilité", utilisez des rôles de travail, car il n'est pas géré ou mis en sandbox, il est plus flexible. Vous pouvez utiliser plus de sockets, définir votre propre environnement, installer plus de packages, etc.
Si vous voulez des "fonctionnalités", alors WebJobs a une gamme complète de fonctionnalités. Y compris, mise en réseau virtuelle vers des ressources sur site, environnements intermédiaires, débogage à distance, déclenchement, planification, connexion facile au stockage et au bus de service, etc.
La plupart des gens veulent se concentrer sur la résolution de leur problème et ne pas investir de temps dans l'infrastructure. Pour cela, vous utilisez WebJobs. Si vous trouvez que vous avez besoin de plus de flexibilité ou que le sandbox de sécurité vous empêche de faire quelque chose qui ne peut être accompli autrement, passez aux rôles de travail.
Il est même possible de créer des solutions hybrides où certaines parties sont effectuées dans des WebJobs et d'autres dans des rôles de travail, mais cela sort du cadre de cette question. (indice: WebJobs SDK)
Choses à retenir lors du choix d'utiliser un travail Web ou un rôle de travailleur:
Un rôle de travailleur est auto-hébergé sur une machine virtuelle dédiée, un travail Web est hébergé dans un conteneur Web App.
Un rôle de travailleur évoluera indépendamment, un travail Web évoluera avec le conteneur Web App.
Les travaux Web sont parfaits pour interroger des flux RSS, rechercher et traiter des messages et pour envoyer des notifications, ils sont légers et moins chers que les rôles de travail mais sont moins puissants.