Azure App Service vs Azure Service Fabric
Quelqu'un peut-il m'indiquer quelque chose qui explique pourquoi je dois créer une application Azure Service Fabric par rapport à une application Azure App Service? Je souhaite créer une application, mais je ne peux pas déterminer si je devrais la créer à l'aide de Azure Service Fabric ou Azure App Service.
Microsoft a créé le document avec une comparaison entre Azure App Service, les ordinateurs virtuels, Service Fabric et les services Cloud.
Malheureusement, il n'y a aucune indication officielle sur le moment d'utiliser quoi. Ce sont deux plates-formes distinctes, qui suivent différents paradigmes de développement.
App Service vous fournira des fonctionnalités que Service Fabric ne fournit pas directement. Des éléments tels que l’échelle automatique, l’authentification, la limitation de débit, l’intégration avec des applications SaaS, etc. Tout ou partie de ces choses peuvent arriver à Service Fabric progressivement, mais je dirais qu’à la minute, elles sont ciblées différents publics - une équipe moins expérimentée peut trouver plus facile de travailler avec App Service.
En revanche, Service Fabric facilite la composition des pièces. Par exemple, dans l'approche "traditionnelle", si vous aviez une API qui parle à un magasin de données et un cache pour éviter de taper sur le magasin de données, vous auriez à gérer les différents scénarios de tolérance aux pannes. Avec Service Fabric, votre cache peut s’intégrer au processus d’API dans une collection fiable et vous n’aurez plus à vous soucier de la présence d’un composant de cache externe. Les données sont co-localisées avec le service (plus rapide à récupérer/modifier!) Et sont fiables car elles sont réparties sur tous les nœuds dans lesquels le service est déployé. Chose similaire avec les files d'attente. Si vous pensez à un système de type flux de travail, où il existe une API, un service de travail et une file d'attente entre eux et leur permettant de communiquer, vous devez gérer 3 composants différents et la communication entre eux. Avec Service Fabric, la file d'attente entre dans l'application. Et ce n'est que la moitié :) vous bénéficiez également du pouvoir d'utiliser le modèle d'acteur pour le calcul distribué sans les problèmes habituels de concurrence. Enfin, avec Service Fabric, vous bénéficiez d'un environnement de développement plus complet sur votre poste local: vous n'avez pas à créer de files d'attente, etc. sur un compte Azure dev ou quoi que ce soit du genre.
Il convient également de noter que rien ne vous empêche d'utiliser les deux paradigmes: imaginez deux applications, dont l'une au moins est une application de service fabric, qui expose des API et une application logique qui s'ajoute à celles-ci.
Votre décision doit être basée sur ce que vous essayez de créer, en combien de temps, lorsque vous souhaitez publier (Service Fabric n’est actuellement qu’en mode de prévisualisation privée, de sorte qu’il faudra un certain temps avant qu’ils arrivent à l’AG) et quel type de l'équipe que vous avez. J'imagine qu'avec App Service, il sera facile de prendre les devants même si vous n'avez pas une équipe très expérimentée, mais Service Fabric vous apportera plus de puissance, de flexibilité et de contrôle.
Le service d'application est un service plus géré, SF vous permet de gérer vous-même et vous pouvez également l'exécuter dans vos propres locaux. SF prend mieux en charge les développeurs de piles non MS, par exemple les applications natives, etc.
Comme le dit ce document "Service Fabric est un bon choix si vous créez une nouvelle application ou ré-écrivez une application existante pour utiliser une architecture de microservice."
Si vous hébergez quelques applications, vous ne devriez pas regarder SF, mais si vous déployez plus de 10 services, cela devient une meilleure solution.
Notez également que SF possède un mécanisme de stockage de données inclus avec les services. Il est bon pour 3 choses 1) Grappes de données massives 2) Données simples, souvent dans les bases de données de services Micros, un lourd fardeau puisque chaque service doit avoir ses propres données avoir 1-3 tables. 3) Stockage d’état pour le modèle de programmation Actor.
Je pense que SF et les applications Web vont diviser la base d'utilisateurs du "Service Cloud" à l'avenir.
Utilisez Service Fabric lorsque vous avez besoin de davantage de contrôle sur l'infrastructure sous-jacente ou d'un accès direct à celle-ci.
Utilisez App Service lorsque vous avez besoin d'une plate-forme d'hébergement entièrement gérée pour vos applications Web.
-as par documentation
Si (il est possible que l’application évolue à l’avenir || souhaite construire une application avec une architecture de service micro) optez pour Azure Service Fabric
autre Azure App Service est ok