Migrar una aplicación de Azure Cloud Services a Azure Service Fabric

Código de ejemplo

En este artículo se explica cómo migrar una aplicación de Azure Cloud Services a Azure Service Fabric. Se centra en las decisiones arquitectónicas y los procedimientos recomendados.

Para este proyecto, empezamos con una aplicación de Cloud Services denominada Surveys y lo migramos a Service Fabric. El objetivo era migrar la aplicación con el menor número de cambios posible. Más adelante en este artículo, se muestra cómo optimizar la aplicación para Service Fabric.

Antes de leer este artículo, le resultará útil comprender los conceptos básicos de Service Fabric. Consulte Información general de Azure Service Fabric.

Acerca de la aplicación Surveys

Una empresa ficticia denominada Tailspin creó una aplicación llamada Surveys que permite a los clientes crear encuestas. Cuando un cliente se registra en la aplicación, los usuarios pueden crear y publicar encuestas, así como recopilar los resultados para el análisis. La aplicación incluye un sitio web público de donde los usuarios pueden extraer una encuesta. Obtenga más información sobre el escenario de Tailspin original aquí.

Ahora Tailspin quiere mover la aplicación Surveys a una arquitectura de microservicios, con Service Fabric ejecutándose en Azure. Dado que la aplicación ya está implementada como una aplicación de Cloud Services, Tailspin adopta un enfoque de varias fases:

1. Migre los servicios en la nube a Service Fabric y minimice los cambios en la aplicación.
2. Optimice la aplicación para Service Fabric mediante el cambio a una arquitectura de microservicios.

En un proyecto real, es probable que ambas fases se superpongan. Al realizar la migración a Service Fabric, también empezaría a rediseñar la aplicación en microservicios. Más adelante puede refinar aún más la arquitectura, quizás mediante la división de servicios generales en servicios más pequeños.

El código de la aplicación está disponible en GitHub. Este repositorio contiene la aplicación Cloud Services y la versión de Service Fabric.

¿Por qué Service Fabric?

Service Fabric es una buena opción para este proyecto, ya que la mayoría de las características necesarias en un sistema distribuido está integrada en Service Fabric, como:

• Administración de clústeres. Service Fabric controla automáticamente la conmutación por error de nodo, el seguimiento de estado y otras funciones de administración del clúster.
• Escalado horizontal. Al agregar nodos a un clúster de Service Fabric, la aplicación se escala automáticamente, a medida que los servicios se distribuyen entre los nuevos nodos.
• Detección de servicios. Service Fabric proporciona un servicio de detección que puede resolver el punto de conexión para un servicio con nombre.
• Servicios sin estado y con estado. Los servicios con estado usan colecciones confiables, que pueden ocupar el lugar de una memoria caché o una cola y pueden particionarse.
• Administración del ciclo de vida de las aplicaciones. Los servicios se pueden actualizar por separado y sin tiempo de inactividad de las aplicaciones.
• Orquestación del servicio en un clúster de máquinas.
• Mayor densidad para la optimización del consumo de recursos. Un solo nodo puede hospedar varios servicios.

Service Fabric usa varios servicios de Microsoft, incluidos Azure SQL Database, Cosmos DB, Azure Event Hubs, etc., que forman una plataforma probada para la compilación de aplicaciones en la nube distribuidas.

Comparación de Cloud Services con Service Fabric

En la tabla siguiente se resumen algunas de las principales diferencias entre las aplicaciones Cloud Services y Service Fabric. Para ver una discusión más detallada, consulte Información acerca de las diferencias entre Cloud Services y Service Fabric antes de migrar las aplicaciones.

* Los servicios con estado usan colecciones confiables para almacenar el estado entre réplicas, de modo que todas las lecturas sean locales para los nodos del clúster. Las escrituras se replican entre los nodos para mejorar la confiabilidad. Los servicios sin estado pueden tener un estado externo, bien con una base de datos u otro almacenamiento externo.

** Los roles de trabajo también pueden autohospedar ASP.NET Web API mediante OWIN.

Aplicación Surveys en Cloud Services

El siguiente diagrama muestra la arquitectura de la aplicación Surveys que se ejecuta en Cloud Services.

La aplicación consta de dos roles web y un rol de trabajo.

• El rol web Tailspin.Web hospeda un sitio web de ASP.NET que los clientes de Tailspin usan para crear y administrar encuestas. Los clientes también usan este sitio web para registrarse en la aplicación y administrar sus suscripciones. Por último, los administradores de Tailspin pueden usarlo para ver la lista de los inquilinos y administrar sus datos.

• El rol web Tailspin.Web.Survey.Public hospeda un sitio web de ASP.NET de donde los usuarios pueden extraer las encuestas que publican los clientes de Tailspin.

• El rol de trabajo Tailspin.Workers.Survey realiza el procesamiento en segundo plano. Los roles web colocan los elementos de trabajo en una cola y el rol de trabajo procesa los elementos. Se definen dos tareas en segundo plano: exportación de las respuestas de las encuestas a Azure SQL Database y cálculo de las estadísticas de las respuestas de las encuestas.

Además de Cloud Services, la aplicación Surveys usa otros servicios de Azure:

• Azure Storage para almacenar encuestas, respuestas de encuestas e información de los inquilinos.

• Azure Cache for Redis para almacenar en caché algunos de los datos que se almacenan en Azure Storage, a fin de acelerar el acceso de lectura.

• Azure Active Directory (Azure AD) para autenticar clientes y administradores de Tailspin.

• Azure SQL Database para almacenar las respuestas de las encuestas para el análisis.

Migración a Service Fabric

Como ya mencioné, el objetivo de esta fase era la migración a Service Fabric con los mínimos cambios necesarios. Con ese fin, creamos servicios sin estado correspondientes a cada rol de servicio en la nube en la aplicación original:

De forma intencionada, esta arquitectura es similar a la aplicación original. Sin embargo, el diagrama oculta algunas diferencias importantes. En el resto de este artículo, exploraremos esas diferencias.

Conversión de roles de servicio en la nube en servicios

Para la migración inicial, Tailspin siguió los pasos descritos en Guía de conversión de roles web y de trabajo a servicios sin estado de Service Fabric.

Creación de servicios front-end web

En Service Fabric, un servicio se ejecuta dentro de un proceso creado por el tiempo de ejecución de Service Fabric. Para un front-end web, eso significa que el servicio no se está ejecutando en IIS. En su lugar, el servicio debe hospedar un servidor web. Este enfoque se denomina autohospedaje, porque el código que se ejecuta en el proceso actúa como el host del servidor web.

La aplicación Surveys original usa ASP.NET MVC. Dado que ASP.NET MVC no se puede autohospedar en Service Fabric, Tailspin consideró las siguientes opciones de migración:

• Migre los roles web a ASP.NET Core, que puede autohospedarse.
• Convierta el sitio web en una aplicación de una sola página (SPA) que llame a una API web implementada mediante ASP.NET Web API. Esto habría requerido volver a diseñar completamente el front-end web.
• Mantenga el código existente de ASP.NET MVC e implemente IIS en un contenedor de Windows Server para Service Fabric. Este enfoque requeriría pocos cambios en el código o ninguno.

La primera opción, trasladar a ASP.NET Core, permitió a Tailspin sacar provecho de las características más recientes en ASP.NET Core. Para realizar la conversión, seguimos los pasos descritos en Migración de ASP.NET MVC a ASP.NET Core MVC.

Agentes de escucha HTTP

En Cloud Services, un rol web o de trabajo expone un punto de conexión HTTP declarándolo en el archivo de definición de servicio. El rol web de tener, al menos, un punto de conexión.

<!-- Cloud service endpoint -->
<Endpoints>
    <InputEndpoint name="HttpIn" protocol="http" port="80" />
</Endpoints>

De igual forma, los puntos de conexión de Service Fabric se declaran en un manifiesto de servicio:

<!-- Service Fabric endpoint -->
<Endpoints>
    <Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8002" />
</Endpoints>

Sin embargo, a diferencia de un rol de servicio en la nube, los servicios de Service Fabric pueden colocarse en el mismo nodo. Por lo tanto, cada servicio debe escuchar en un puerto distinto. Más adelante en este artículo, analizaremos cómo se enrutan las solicitudes de cliente en el puerto 80 o el puerto 443 al puerto correcto del servicio.

Un servicio debe crear explícitamente los agentes de escucha para cada punto de conexión. La razón es que Service Fabric es agnóstico en cuanto a las pilas de comunicación. Para obtener más información, consulte Creación de un front-end de servicio web para una aplicación mediante ASP.NET Core.

Empaquetado y configuración

Un servicio en la nube contiene los archivos de paquete y de configuración siguientes:

Hay un archivo .csdef para toda la aplicación. Puede tener varios archivos .cscfg para diferentes entornos, como local, de prueba y de producción. Cuando el servicio se está ejecutando, puede actualizar el archivo .cscfg, pero no el archivo .csdef. Para obtener más información, consulte ¿Qué es el modelo de servicio en la nube y cómo se empaqueta?

Service Fabric tiene una división similar entre la definición de servicio y la configuración de servicio, pero la estructura más granular. Para entender el modelo de configuración de Service Fabric, resulta útil comprender cómo se empaqueta una aplicación de Service Fabric. La estructura es la siguiente:

Application package
  - Service packages
    - Code package
    - Configuration package
    - Data package (optional)

El paquete de aplicación es lo que se implementa. Contiene uno o varios paquetes de servicio. Un paquete de servicio contiene paquetes de código, configuración y datos. El paquete de código contiene los archivos binarios de los servicios y el paquete de configuración contiene las opciones de configuración. Este modelo permite actualizar servicios individuales sin tener que volver a implementar toda la aplicación. También permite actualizar solo los valores de configuración, sin tener que volver a implementar el código o reiniciar el servicio.

Una aplicación de Service Fabric contiene los archivos de configuración siguientes:

Para más información, consulte Modelo de una aplicación en Service Fabric.

Para admitir distintas opciones de configuración para varios entornos, emplee el siguiente enfoque, que se describe en Administración de los parámetros de la aplicación en varios entornos:

1. Defina el valor de configuración en el archivo Setting.xml del servicio.
2. En el manifiesto de la aplicación, defina una invalidación para el valor de configuración.
3. Coloque los valores de configuración específicos del entorno en archivos de parámetros de la aplicación.

Implementación de la aplicación

Mientras que Azure Cloud Services es un servicio administrado, Service Fabric es un motor en tiempo de ejecución. Puede crear clústeres de Service Fabric en muchos entornos, incluido Azure y entornos locales. En el diagrama siguiente se muestra una implementación recomendada para Azure:

Se implementa un clúster de Service Fabric en un conjunto de escalado de máquinas virtuales. Los conjuntos de escalado de máquinas virtuales son un recurso de Azure Compute que se usa para implementar y administrar un conjunto de máquinas virtuales idénticas.

Como ya se ha mencionado, se recomienda colocar el servidor web Kestrel detrás de un proxy inverso por motivos de seguridad. Este diagrama muestra Azure Application Gateway, que es un servicio de Azure que ofrece distintas funcionalidades de equilibrio de carga de capa 7. Actúa como un servicio de proxy inverso, que termina la conexión de cliente y reenvía las solicitudes de vuelta a los puntos de conexión de back-end. Puede usar una solución de proxy inverso diferente, como nginx.

Enrutamiento de capa 7

En la aplicación Surveys original, un rol web escuchaba en el puerto 80 y el otro, en el puerto 443.

Otra opción es usar el enrutamiento de capa 7. En este enfoque, las distintas rutas de dirección URL se enrutan a números de puerto diferentes en el back-end. Por ejemplo, el sitio público podría usar rutas de dirección URL que empiecen por /public/.

Las opciones para el enrutamiento de capa 7 incluyen:

• Usar Application Gateway.
• Usar un dispositivo virtual de red (NVA), como nginx.
• Escribir una puerta de enlace personalizada como un servicio sin estado.

Tenga en cuenta este enfoque si tiene dos o más servicios con puntos de conexión HTTP públicos, pero quiere que aparezcan como un sitio con un nombre de dominio único.

Un enfoque que no se recomienda es permitir que los clientes externos envíen solicitudes a través del proxy inverso de Service Fabric. Aunque esto es posible, el proxy inverso está destinado a la comunicación entre servicios. Abrirlo a clientes externos expondría cualquier servicio que se ejecute en el clúster con un punto de conexión HTTP.

Restricciones de colocación y tipos de nodo

En la implementación anterior, todos los servicios se ejecutan en todos los nodos. Sin embargo, también puede agrupar los servicios, para que determinados servicios se ejecuten solo en determinados nodos en el clúster. Los motivos para usar este enfoque incluyen:

• Ejecutar algunos servicios en distintos tipos de máquina virtual. Por ejemplo, algunos servicios podrían ejecutar procesos intensivos o requerir unidades GPU. Puede tener una combinación de tipos de máquinas virtuales en el clúster de Service Fabric.
• Aislar servicios front-end de servicios back-end por motivos de seguridad. Todos los servicios front-end se ejecutarán en un conjunto de nodos y los servicios back-end se ejecutarán en nodos diferentes del mismo clúster.
• Requisitos de escala diferentes. Es posible que algunos servicios tengan que ejecutarse en más nodos que otros. Por ejemplo, si define nodos front-end y nodos back-end, cada conjunto se puede escalar de manera independiente.

El siguiente diagrama muestra un clúster que separa los servicios front-end y back-end:

Para implementar este enfoque:

1. Al crear el clúster, defina dos o más tipos de nodo.
2. Para cada servicio, use restricciones de colocación para asignar el servicio a un tipo de nodo.

Al realizar la implementación en Azure, cada tipo de nodo se implementa en un conjunto de escalado de máquinas virtuales independiente. El clúster de Service Fabric abarca todos los tipos de nodo. Para obtener más información, consulte Relación entre los tipos de nodos de Service Fabric y los conjuntos de escalado de máquinas virtuales.

Si un clúster tiene varios tipos de nodo, un tipo de nodo se designa como el tipo de nodo principal. Los servicios de tiempo de ejecución de Service Fabric, como el servicio de administración del clúster, se ejecutan en el tipo de nodo principal. Aprovisione al menos 5 nodos para el tipo de nodo principal en un entorno de producción. El otro tipo de nodo debe tener al menos 2 nodos.

Configuración y administración del clúster

Para evitar que usuarios no autorizados se conecten a su clúster, los clústeres deben protegerse. Se recomienda usar Azure AD para autenticar clientes y certificados X.509 para la seguridad entre nodos. Para más información, consulte Escenarios de seguridad de los clústeres de Service Fabric.

Para configurar un punto de conexión HTTPS público, consulte Especificación de recursos en un manifiesto de servicio.

Puede escalar horizontalmente la aplicación mediante la adición de máquinas virtuales al clúster. Los conjuntos de escalado de máquinas virtuales admiten el escalado automático mediante la aplicación de reglas de escalado automático basadas en contadores de rendimiento. Para más información, consulte Escalado o reducción horizontal de un clúster de Service Fabric usando reglas de escalado automático.

Mientras el clúster está en ejecución, debe recopilar registros de todos los nodos en una ubicación central. Para más información, consulte Recopilación de registros con Diagnósticos de Azure.

Refactorización de la aplicación

Después de migrar la aplicación a Service Fabric, el paso siguiente consiste en refactorizarla en una arquitectura más pormenorizarla. El objetivo de Tailspin al refactorizar es facilitar el desarrollo, la compilación y la implementación de la aplicación Surveys. Al descomponer los roles web y de trabajo existentes en una arquitectura más pormenorizada, Tailspin busca eliminar las dependencias de comunicación y datos estrechamente acopladas existentes entre estos roles.

Tailspin encuentra otras ventajas al trasladar la aplicación Surveys a una arquitectura más pormenorizada:

• Cada servicio se puede empaquetar en proyectos independientes con un ámbito lo suficientemente pequeño como para que un equipo reducido pueda administrarlo.
• El control de versiones y la implementación de cada servicio pueden realizarse de manera independiente.
• Cada servicio puede implementarse mediante la tecnología óptima para ese servicio. Por ejemplo, un clúster de Service Fabric puede incluir servicios creados con distintas versiones de .Net Framework, Java u otros lenguajes como C o C++.
• Cada servicio se puede escalar independientemente para responder a aumentos y disminuciones de carga.

El código fuente de la versión refactorizada de la aplicación está disponible en GitHub.

Consideraciones de diseño

El siguiente diagrama muestra la arquitectura de la aplicación Surveys refactorizada para obtener una arquitectura más pormenorizada:

Tailspin.Web es un servicio sin estado que autohospeda una aplicación de ASP.NET MVC que los clientes de Tailspin visitan para crear encuestas y ver resultados de encuestas. Este servicio comparte la mayor parte de su código con el servicio Tailspin.Web de la aplicación de Service Fabric portada. Como se mencionó anteriormente, este servicio utiliza ASP.NET Core y pasa de utilizar Kestrel como front-end web a implementar WebListener.

Tailspin.Web.Survey.Public es un servicio sin estado que también autohospeda un sitio de ASP.NET MVC. Los usuarios visitan este sitio para seleccionar encuestas de una lista y completarlas. Este servicio comparte la mayor parte de su código con el servicio Tailspin.Web.Survey.Public de la aplicación de Service Fabric portada. Este servicio también utiliza ASP.NET Core y pasa de utilizar Kestrel como front-end web a implementar WebListener.

Tailspin.SurveyResponseService es un servicio con estado que almacena las respuestas de las encuestas en Azure Blob Storage. También combina respuestas en los datos de análisis de encuestas. El servicio se implementa como un servicio con estado porque utiliza ReliableConcurrentQueue para procesar respuestas de encuesta en lotes. Esta funcionalidad estaba implementada originalmente en el servicio Tailspin.AnswerAnalysisService en la aplicación de Service Fabric portada.

Tailspin.SurveyManagementService es un servicio sin estado que almacena y recupera encuestas y preguntas de encuesta. El servicio utiliza Azure Blob Storage. Esta funcionalidad estaba también implementada originalmente en los componentes de acceso a datos de los servicios Tailspin.Web y Tailspin.Web.Survey.Public en la aplicación de Service Fabric portada. Tailspin refactorizó la funcionalidad original en este servicio para que pueda escalarse de forma independiente.

Tailspin.SurveyAnswerService es un servicio sin estado que recupera respuestas y análisis de encuestas. El servicio también utiliza Azure Blob Storage. Esta funcionalidad estaba también implementada originalmente en los componentes de acceso a datos del servicio Tailspin.Web en la aplicación de Service Fabric portada. Tailspin refactorizó la funcionalidad original en este servicio porque espera menos carga y desea usar menos instancias para conservar recursos.

Tailspin.SurveyAnalysisService es un servicio sin estado que conserva datos de resumen de respuestas de encuestas en una instancia de Redis Cache para recuperarlos rápidamente. Mediante Tailspin.SurveyResponseService, se llama a este servicio cada vez que se responde una encuesta y los nuevos datos de respuesta de la encuesta se combinan en los datos de resumen. Este servicio incluye la funcionalidad implementada originalmente en el servicio Tailspin.AnswerAnalysisService en la aplicación de Service Fabric portada.

Servicios sin estado y con estado

Azure Service Fabric admite los siguientes modelos de programación:

• El modelo de ejecutable invitado permite que cualquier ejecutable se empaquete como un servicio y se implemente en un clúster de Service Fabric. Service Fabric organiza y administra la ejecución del ejecutable invitado.
• El modelo de contenedor permite la implementación de servicios en imágenes de contenedor. Service Fabric permite crear y administrar contenedores sobre contenedores del kernel de Linux, así como sobre contenedores de Windows Server.
• El modelo de programación de Reliable Services permite crear servicios con o sin estado que se integran con todas las características de la plataforma de Service Fabric. Los servicios con estado permiten almacenar el estado replicado en el clúster de Service Fabric, mientras que los servicios sin estado no lo permiten.
• El modelo de programación de Reliable Actors permite crear servicios que implementan el patrón de actor virtual.

Todos los servicios de la aplicación Surveys son servicios confiables sin estado, excepto el servicio Tailspin.SurveyResponseService. Este servicio implementa ReliableConcurrentQueue para procesar respuestas de encuesta al recibirlas. Las respuestas en ReliableConcurrentQueue se guardan en Azure Blob Storage y se transfieren a Tailspin.SurveyAnalysisService para su análisis. Tailspin elige ReliableConcurrentQueue porque las respuestas no requieren el orden estricto "primero en entrar, primero en salir" que proporciona una cola, como Azure Service Bus. ReliableConcurrentQueue también está diseñado para ofrecer un alto rendimiento y una baja latencia para las operaciones de puesta en cola y eliminación de cola.

Idealmente, las operaciones para conservar elementos quitados de la cola de ReliableConcurrentQueue deberían ser idempotentes. Si se produce una excepción durante el procesamiento de un elemento de la cola, el mismo elemento se puede procesar más de una vez. En la aplicación Surveys, la operación para combinar respuestas de encuesta en el servicio Tailspin.SurveyAnalysisService no es idempotente, ya que Tailspin decidió que los datos de análisis de encuestas sean únicamente una instantánea actual de los datos de análisis y no es necesario que sean coherentes. Las respuestas de encuesta que se guardan en Azure Blob Storage son coherentes en última instancia, por lo que el análisis de encuestas final siempre se puede recalcular correctamente a partir de estos datos.

Marco de comunicación

Cada servicio de la aplicación Surveys se comunica mediante una API web de RESTful. Las API de RESTful proporcionan las siguientes ventajas:

• Facilidad de uso: cada servicio se basa en ASP.Net Core MVC, que admite de forma nativa la creación de API web.
• Seguridad: aunque los servicios no requieren capa de sockets seguros, Tailspin podría determinar que cada servicio lo requiera.
• Control de versiones: los clientes se pueden escribir y probar en una versión específica de una API web.

Los servicios de la aplicación Surveys usan el proxy inverso implementado por Service Fabric. El proxy inverso es un servicio que se ejecuta en cada nodo del clúster de Service Fabric y gestiona la resolución de puntos de conexión, el reintento automático y otros tipos de errores de conexión. Para usar al proxy inverso, cada llamada de API de RESTful a un servicio específico se realiza mediante un puerto de proxy inverso predefinido. Por ejemplo, si se ha establecido el puerto de proxy inverso en 19081, una llamada a Tailspin.SurveyAnswerService puede realizarse de la siguiente manera:

static SurveyAnswerService()
{
    httpClient = new HttpClient
    {
        BaseAddress = new Uri("http://localhost:19081/Tailspin/SurveyAnswerService/")
    };
}

Para habilitar el proxy inverso, especifique un puerto de proxy inverso durante la creación del clúster de Service Fabric. Para más información, consulte Proxy inverso de Azure Service Fabric.

Consideraciones de rendimiento

Tailspin creó servicios de ASP.NET Core para Tailspin.Web y Tailspin.Web.Surveys.Public mediante plantillas de Visual Studio. De forma predeterminada, estas plantillas incluyen el registro en la consola. El registro en la consola puede realizarse durante el desarrollo y la depuración, pero todos los registros de la consola deben eliminarse cuando la aplicación se implementa en producción.

Por ejemplo, las siguientes líneas en startup.cs para cada uno de los servicios front-end web deben convertirse en comentarios:

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    //loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    //loggerFactory.AddDebug();

    app.UseMvc();
}

Por último, cuando Tailspin implementa la aplicación Tailspin en producción, cambia el modo de Visual Studio a Liberar.

Consideraciones de la implementación

La aplicación Surveys refactorizada se compone de cinco servicios sin estado y un servicio con estado, por lo que el planeamiento de clústeres se limita a determinar el tamaño correcto de la máquina virtual y el número de nodos. En el archivo applicationmanifest.xml que describe el clúster, Tailspin establece el atributo InstanceCount de la etiqueta StatelessService en -1 para cada uno de los servicios. Un valor de -1 indica a Service Fabric que cree una instancia del servicio en cada nodo del clúster.

Tailspin implementa el clúster mediante Azure Portal. El tipo de recurso de clúster de Service Fabric implementa toda la infraestructura necesaria, incluidos los conjuntos de escalado de la máquina virtual y un equilibrador de carga. Los tamaños de máquina virtual recomendados se muestran en Azure Portal durante el proceso de aprovisionamiento para el clúster de Service Fabric. Dado que las máquinas virtuales se implementan en un conjunto de escalado de máquina virtual, se pueden escalar tanto vertical como horizontalmente a medida que aumente la carga de usuarios.

Pasos siguientes

El código de la aplicación Surveys está disponible en GitHub.

Si es la primera vez que usa Azure Service Fabric, primero configure el entorno de desarrollo y, a continuación, descargue la versión más reciente del SDK de Azure y del SDK de Azure Service Fabric. El SDK incluye el administrador de clústeres OneBox, de forma que puede implementar y probar la aplicación Surveys localmente con depuración de F5 completa.