standard - Azure App Service vs Azure Service Fabric
small app service azure (3)
¿Alguien puede dirigirme a algo que explique cuándo debo crear una aplicación Azure Service Fabric frente a una aplicación Azure App Service? Tengo una aplicación que deseo compilar pero no puedo determinar si debo compilarla utilizando Azure Service Fabric o Azure App Service.
El servicio de aplicaciones es un servicio más administrado, SF administra más el tuyo y puedes correr en tus propias instalaciones también. SF tiene un mejor soporte para desarrolladores de MS stack por ejemplo, aplicaciones nativas, etc.
Como dice ese documento, "Service Fabric es una buena opción si está creando una nueva aplicación o escribiendo de nuevo una aplicación existente para usar una arquitectura de microservicio".
Si aloja algunas aplicaciones, no debería mirar a SF. Por otro lado, si implementa más de 10 servicios, se convierte en una mejor solución.
También tenga en cuenta que SF tiene un mecanismo de almacenamiento de datos que se incluye con los servicios. Es bueno en 3 cosas 1) Cúmulos de datos masivos 2) Datos simples, a menudo en servicios de Micros Las bases de datos se vuelven una carga pesada ya que cada servicio debe tener sus propios datos y cosas como SQL son un poco exageradas cuando solo tienes 1-3 tablas. 3) Almacenamiento de estado para el modelo de programación Actor.
Creo que SF y las aplicaciones web reducirán la base de usuarios del "Servicio Cloud" en el futuro.
Lamentablemente, no hay ninguna orientación oficial sobre cuándo usar qué. Son dos plataformas separadas, que siguen diferentes paradigmas de desarrollo.
App Service le dará la funcionalidad que Service Fabric no proporciona de fábrica. Cosas como escalas automáticas, autenticación, limitación de velocidad, integración con aplicaciones SaaS, etc. Algunas o todas estas cosas pueden llegar a Service Fabric gradualmente, pero yo diría que, en el momento, están dirigidas a diferentes públicos: una un equipo menos experimentado puede encontrar más fácil trabajar con el Servicio de aplicaciones.
Service Fabric por otro lado facilita la composición de las piezas. Por ejemplo, en el enfoque "tradicional", si tuviera una API que hablara con un almacén de datos y un caché para evitar dañar el almacén de datos, tendría que manejar los diversos escenarios de tolerancia a fallas. Con Service Fabric, su caché puede ubicarse dentro del proceso de API en una colección confiable y no tendrá que lidiar con tener un componente de caché externo. Los datos comparten el servicio (¡más rápido de recuperar / editar!) Y son confiables, ya que se distribuyen en todos los nodos en los que se implementa el servicio. Algo similar con colas. Si piensa en un sistema de tipo de flujo de trabajo, donde hay una API, un servicio de trabajo y una cola entre ellos y les permite comunicarse, tendría que administrar 3 componentes diferentes y la comunicación entre ellos. Con Service Fabric, la cola entra en la aplicación. Y eso es sólo la mitad de :) también tiene el poder de usar el modelo de actor para el cálculo distribuido sin los habituales dolores de cabeza de concurrencia. Finalmente, con Service Fabric obtendrá el beneficio de tener un entorno de desarrollo más completo en su caja local; no tiene que ocuparse de crear colas, etc. en una cuenta de desarrollo de Azure ni nada por el estilo.
También vale la pena señalar que no hay nada que te impida usar ambos paradigmas: imagina dos aplicaciones con al menos una de ellas como una aplicación de tela de servicio, que exponen las API y una aplicación lógica que se encuentra encima de ellas.
Su decisión debe basarse en lo que está intentando construir, en cuánto tiempo, cuándo desea lanzar (Service Fabric actualmente solo está en vista previa privada, por lo que pasará un tiempo hasta que lleguen a GA) y qué tipo de equipo que tienes Me imagino que con el Servicio de aplicaciones será fácil comenzar de inmediato, incluso si no tienes un equipo experimentado en masa, pero Service Fabric te dará más potencia, flexibilidad y control.
Microsoft ha creado el docs.microsoft.com/en-us/azure/app-service-web/… con una comparación para Azure App Service, Virtual Machines, Service Fabric y Cloud Services.