asp.net - studio - ¿Azure Service Fabric hace lo mismo que Docker?

dotnet architecture

Question

Mi opinión es que la gente usa Docker para asegurarse de que el entorno local sea el mismo que el de la producción y que pueda dejar de pensar en dónde se ejecutan físicamente sus aplicaciones y los mecanismos de equilibrio deberían asignar aplicaciones en los mejores lugares para ese momento.

Estoy 100% basado en la web y me voy a mover a la nube junto con nuestras bases de datos, y lo que no se puede mover se unirá sin problemas para que el material corporativo y la nube se conviertan en una subred.

Y entonces me pregunto, tal vez Service Fabric ya hace lo mismo que hace Docker y da como servicio de traducción de direcciones (fabric: // que actúa un poco como DNS para los procesos en el espacio de tela) más (importante para algunos) anima asignación de trabajadores a demanda: gran beneficio de escalabilidad.

1. ¿Puede Service Fabric reemplazar con éxito a Docker?
2. ¿Está ganando audiencia y aceptación? Porque de lo contrario, incluso la invención más grande puede fallar.

Answer 1

Es confuso ya que Docker (la compañía) está tratando de replantear reclamos en todas las nubes.

• Docker Engine (lo que la mayoría de la gente llama "Docker") es una tecnología de contenedorización. Puede darte
  • Aislamiento del proceso
  • Aislamiento de red
  • Entorno de aplicación consistente
• Docker Hub es un registro de imágenes. Almacena imágenes de Docker para que pueda descargarlas como parte de su implementación.
• Docker Cloud es un sistema de orquestación para Docker. Puede darte
  • Escala tus aplicaciones hacia arriba y hacia abajo
  • Conecte sus aplicaciones entre sí
  • Prueba de CI, integrada con Docker Hub (esto no forma parte de la orquestación, solo otra cosa más)

Service Fabric es un sistema de orquestación. Puede organizar contenedores Docker, pero también puede integrarse más estrechamente con sus servicios si compila específicamente para Fabric. (Docker es completamente agnóstico sobre lo que se ejecuta dentro de un contenedor).

Así que Service Fabric es en su mayoría comparable a Docker Cloud, aunque no es una coincidencia exacta. Hay algunas otras soluciones de orquestación basadas en Docker (Kubernetes es probablemente la más grande) y hay otras soluciones de micro-servicio basadas en la nube (Heroku es probablemente el más conocido).

La principal desventaja de Service Fabric es que se trata de una tecnología de Microsoft, por lo que estará vinculado a Azure en mayor medida que si ejecutara Docker. La otra es que Docker tiene una gama más amplia de opciones para construir su stack: las tres Docker-cosas que mencioné anteriormente tienen al menos una alternativa de código abierto (esto también es una gran desventaja de Docker, ya que nadie está presentando una sola Best Practices Para tu documento).

Si amas a Microsoft y si juntar los sistemas no es algo importante para ti, entonces Service Fabric debería ser una buena alternativa al ecosistema de Docker. (Y aún puede ejecutar contenedores Docker debajo de él).

Answer 2

Las similitudes clave entre Service Fabric y la contenedorización de Docker:

1. Tanto Dockers como SF, son capaces de crear una imagen inmutable de su implementación de micro-servicios, en ambas plataformas: Linux y Windows.
2. Tanto Dockers como SF son capaces de orquestar su aplicación contenedorizada dentro de un grupo de máquinas virtuales. Estas máquinas virtuales pueden estar en cualquier lugar: nube pública, nube privada o su propio centro de datos. Tenga en cuenta que ambos son independientes de la plataforma en la nube, es decir, no tienen una gran afinidad con ninguno de los servicios en la nube. Por lo tanto, siempre que no esté utilizando ninguna característica específica de la nube dentro de su micro-servicio, esto debería estar bien.
3. Tanto Dockers como SF son capaces de exhibir las capacidades esenciales de una plataforma de orquestación: detección de servicios, equilibrio de carga de nivel de servicio, aislamiento de nivel de red entre servicios, manejo de fallas y control de replicación, etc.

Las diferencias clave entre Service Fabric y la contenedorización de Docker:

1. El contenedor Docker es esencialmente una construcción de implementación / empaquetado. Dicho esto, Docker no dicta sobre lo que está empaquetando dentro de un contenedor como parte de la implementación de su servicio. Tampoco proporciona ninguna construcción de programación para implementar su tipo de servicio . Mientras que, Service Fabric proporciona construcciones de programación en forma de tipos de base / interfaces desde las cuales la implementación de su servicio puede comenzar con un determinado tipo de servicio declarado: servicio con estado, servicio sin estado, actor virtual.
2. En el mundo de Docker, todo es un contenedor, es decir, su unidad de despliegue / orquestación mínima es un contenedor. Por lo tanto, no reconoce ni admite un proceso individual. Mientras que, en SF, tenemos una disposición en la cual, su micro-servicio derivado del servicio stateless / stateful puede ser orquestado y gobernado como un proceso. Sin embargo, SF también admite la organización de contenedores como lo hace Docker. Además, la última versión de SF permite empacar su servicio con estado / sin estado dentro de un contenedor.

Teniendo en cuenta los hechos anteriores, tenga en cuenta que SF no tiene una gran afinidad con ningún proveedor de la nube. Puede ejecutarse por igual en cualquier nube pública: Azure, AWS o GCP, siempre que pueda crear las máquinas virtuales con la plataforma deseada.