Llegamos a ustedes gracias a:



Reportajes y análisis

Reseña: Microservicios maestros de Microsoft

Azure Service Fabric

[20/06/2016] Muchas empresas han implementado -o pretenden hacerlo- arquitecturas de microservicios, para bien o para mal. Las arquitecturas de multiservicios le dan fuertes límites de módulos, despliegue independiente y ampliación independiente de piezas ligeras, aislamiento de las preocupaciones, y la oportunidad de usar cualquier tecnología que sea apropiada para cada pequeño servicio. Por otro lado, los sistemas distribuidos tienen inherentemente una mayor latencia y más oportunidades para el fracaso que los sistemas monolíticos, así como una mayor complejidad operativa, por lo que la aplicación tiene que ser "suficientemente grande" para justificar la sobrecarga de ser distribuida.

Supongamos que tiene una aplicación que justifica la sobrecarga de ser distribuida, y desea implementarla como un conjunto de microservicios. Las siguientes preguntas a plantear son dónde y cómo debe implementar y mantener sus microservicios.

La respuesta de Microsoft a estas dos preguntas:

  • En Azure Service Fabric
  • Donde quiera

Como verá, Azure Service Fabric ofrece muchos beneficios, a costa de cierta complejidad.

Middleware para microservicios

Azure Service Fabric es un middleware diseñado para ayudarle a construir y gestionar aplicaciones de microservicios escalables y confiables que funcionan a muy alta densidad en un conjunto compartido de máquinas virtuales o físicas (es decir, un clúster). Para fines de producción, cada nodo de un clúster reside en una máquina separada. Para los propósitos de desarrollo y pruebas, muchos nodos pueden residir en una sola máquina.

Service Fabric de Azure es middleware para microservicios. Puede alojarlo en Azure, en las nubes privadas, y en las nubes alojadas.
Azure Service Fabric

De acuerdo con Microsoft, mediante el uso de Service Fabric, los desarrolladores y administradores pueden evitar tener que resolver problemas complejos de infraestructura y centrarse en la implementación de las cargas de trabajo exigentes y de misión crítica con el conocimiento de que son escalables, fiables, manejables, y comprobables. Service Fabric acoge microservicios dentro de contenedores que se implementan y activan a través del clúster. Un clúster de base de datos SQL Azure único, construido sobre Service Fabric, se compone de cientos de máquinas que ejecutan decenas de miles de contenedores que alojan un total de cientos de miles de bases de datos. Microsoft llama a esto "hiper escala."

Si el servicio Azure Fabric va a ayuda realmente puede depender de dos factores: si su aplicación de forma sencilla se puede descomponer en microservicios, y si esos microservicios pueden expresarse en una forma soportada por Azure Service Fabric. Afortunadamente hay más flexibilidad en los escenarios de Service Fabric de lo que inicialmente esperaba. Como verá, si bien Microsoft hace hincapié en Azure, la pila .Net, y hosts de Windows Server, permite alternativas a todo lo anterior.

Escenarios de Service Fabric

Los escenarios de Service Fabric incluyen microservicios de estado y sin estado, el actor fiable y aplicaciones de servicios fiables y huéspedes ejecutables. Todos menos los huéspedes ejecutables son aplicaciones .Net que llaman a la API de Service Fabric.

Aplicaciones de servicios fiables, que son los servicios de larga duración que suelen tener oyentes y varias réplicas, pueden ser con o sin estado. En una aplicación de servicio sin estado, no existe un estado almacenado, por lo que la aplicación es más o menos un controlador para las peticiones entrantes, de forma similar a un sitio web sin cookies, excepto que las aplicaciones de servicios no se limitan a los protocolos HTTP -puede llamar a una API a través de una variedad de protocolos conectables. En algunas arquitecturas, una aplicación de servicio sin estado actúa como interfaz para un servicio con estado, como un frente Web o una capa de lógica de negocio.

Los servicios sin estado son relativamente simples. Más allá del servicio en sí es un oyente de comunicaciones enchufable.
Azure Serice Fabric

Es posible tener una aplicación parcial de estado que mantiene un estado en una base de datos externa, por ejemplo, pero que no utiliza las API con estado de Service Fabric. Por otro lado, una aplicación de servicio plenamente confiable con estado, puede almacenar su estado internamente con las APIs Reliable Queu y Reliable Dictionary. Reliable Queues y Reliable Dictionary son tipos de Reliable Collections, que son proporcionadas por Service Fabric y, por lo tanto, son muy confiables, así como dispuestas y consistentes. El almacenamiento de su estado interno tiene ventajas claras de rendimiento: Cada lectura y escritura es local, no una petición a una base de datos remota.

Los servicios con estado aprovechan el gestor de estado fiable y el replicador transaccional. Pueden llamar colecciones fiables para mantener el estado en el servicio de forma confiable.
Azure Service Fabric

Si necesita un servicio sin estado llamado solamente por las peticiones HTTP, puede crear una API Web sin estado. Esto es básicamente una API Web ASP.Net con auto alojamiento OWIN, que se ejecuta en un proceso de servicio de host, conectado a un host Olin como el Proyecto Katana, en lugar de ejecutarse en una instancia de IIS.

Aplicaciones de actores confiables

El patrón de actor virtual fue desarrollado en Microsoft Research, en Project Orleans y probado en el campo, mediante la implementación de los servicios de back-end para Halo. Las aplicaciones de actores confiables son una implementación a disposición del público del patrón de actor virtual. Básicamente, un actor es una unidad aislada, independiente de la computación y el estado con la ejecución de un único subproceso. El patrón de actor es un modelo computacional para sistemas concurrentes o distribuidos en el que un gran número de estas unidades de cómputo pueden ejecutarse simultáneamente y de forma independiente una de otra. Los actores pueden comunicarse con otros actores, y pueden crear más actores. Si eso le recuerda a Erlang, está en lo correcto. Los actores virtuales son una generalización de las ideas de actores consagrados en Erlang.

La confiable implementación de actor en Service Fabric es en realidad una especialización de los servicios fiables con estado, con una implementación destinada a distribuir la carga de los actores y proporcionar la conmutación por error automática. Los actores tienen concurrencia basada en turnos. A pesar de que las API de actores son asíncronas, un actor puede procesar solo una solicitud a la vez; esto es exigido por una cerradura por actor mientras dura el giro. Mientras que el "giro" es más significativo en el contexto de un juego, se puede pensar en él como la respuesta completa a una sola solicitud.

¿Cuándo utilizar actores fiables, que no sean para un juego? Los siguientes son los tres criterios principales sugeridas por Microsoft:

  • Su espacio del problema implica un gran número (miles o más) de unidades pequeñas, independientes y aislados de estado y de lógica.
  • Querrá trabajar con objetos de un único subproceso que no requieren interacción significativa de componentes externos, incluyendo la consulta de estado a través de un conjunto de actores.
  • Sus instancias de actor no bloquearán las llamadas con retrasos impredecibles mediante la emisión de operaciones I/O.

Sobre la base de estos criterios y el cuerpo de experiencia de Erlang, una aplicación obvia sería para las telecomunicaciones. Otras posibles aplicaciones podrían incluir simulaciones de elementos finitos, problemas de optimización global, simulaciones de dinámica molecular, modelado genético y solucionadores de ecuaciones en derivados parciales con restricciones tales como la dinámica de fluidos y simulaciones de transferencia de calor. ¿Serán puestas en práctica en los actores de estas aplicaciones que resulten ser más simples, o mejor aún, más rápidas o más fáciles de mantener que las implementaciones tradicionales? Es difícil de decir.

El servicio actor es un tipo especializado de servicio con estado. Como tal, puede utilizar proveedores estatales y eliminar los oyentes, al igual que con los servicios ordinarios con estado.
Azure Service Fabric

Arquitectura de Service Fabric

La arquitectura de Service Fabric involucra nueve subsistemas, proporcionando funcionalidad como canal de comunicación punto a punto de datagramas, servicios de federación, replicación, recuperación de fallas, gestión de recursos, gestión de clúster, gestión de la salud, almacén de imágenes, interfaz de hosting, nombres, comunicaciones confiables y capacidad de prueba.

La arquitectura de Fabric Service de Azure incluye nueve subsistemas, como se muestra en el diagrama.
Azure Service Fabric

La mayor parte de esa funcionalidad es obvia a partir de los nombres. La capacidad de prueba le da formas fáciles de simular fallas de hardware y software, ya sea con acciones individuales, tales como el reinicio de un nodo, o escenarios complejos tales como "conmutación por error" (generar fallas en una partición específica del servicio), y el "caos" (generar fallas en todo el clúster de Service Fabric, y dejar que todo el infierno se desate).

"OK", puede decir: "Me encanta la idea de ejecutar una aplicación en Fabric Service, pero tengo una aplicación existente que quiero escalar sin hacer el trabajo de volver a escribirla como servicio. ¿Fabric Service puede ayudar?"

De hecho, puede. Service Fabric puede ejecutar archivos ejecutables de los huéspedes una vez que escribe (o utiliza una herramienta para generar) aplicaciones y archivos de manifiesto del servicio que especifican los nombres de archivo en clave y configuración, y los puntos de entrada y fin del servicio. Básicamente, cualquier aplicación que se pueda ejecutar en el host subyacente (por lo general, pero no siempre de Windows) puede funcionar como un ejecutable invitado. Service Fabric entonces la tratará como un servicio sin estado, proporcionando alta disponibilidad, vigilancia de la salud, gestión del ciclo de vida de la aplicación, y alta densidad de aplicación.

En el último párrafo mencioné que los hosts de Service Fabric son generalmente, aunque no siempre, de Windows. Para una configuración de desarrollo y prueba, puede utilizar Windows 7, Windows 8/8.1, Windows Server 2012 R2 o Windows 10, además de Visual Studio, el tiempo de ejecución de Service Fabric y Service Fabric SDK. Para la producción, se puede utilizar Azure, Windows Server 2012 R2, Windows Server 2016, o Linux, concretamente Ubuntu Server 15.10 en la vista previa limitada actual. Las instancias de Windows y Linux pueden ejecutarse en servidores físicos, máquinas virtuales, o cualquier nube. Service Fabric está bien soportado, pero no asegurado, en Azure.

Construir y desplegar aplicaciones de Service Fabric

Puede construir, desplegar y gestionar aplicaciones de Service Fabric de tela de varias maneras, usando una variedad de herramientas: Visual Studio, la consola Azure, PowerShell, Service Fabric Explorer y Visual Studio Team Services. Con Team Services, puede configurar un proceso de integración continuo y automatizado.

Yo configuré dos entornos de desarrollo en máquinas con Windows 10, una usando Visual Studio 2015 Actualización 2 y la otra con la vista previa de Visual Studio "15". La primera era una actualización de una instalación existente; la última fue una instalación limpia en una instancia de Visual Studio que no había visto antes.

Uno pensaría que la actualización podría haber ido más rápido, pero podría estar equivocado. Después de cinco intentos fallidos para reparar Visual Studio 2015, me di por vencido y volví a instalar Windows 10 a partir de trozos desnudos, así como un Visual Studio 2015 recién descargado con la actualización 2 y finalmente Service Fabric SDK y tiempo de ejecución. Tiempo transcurrido: más de 24 horas.

Una vez que todo se ha instalado, la creación de una aplicación de Service Fabric fue bastante dócil. La implementación de la aplicación en un clúster local fue más "interesante" porque encender un racimo de cinco nodos en una caja de desarrollo modesta con 8GB de RAM involucraba un poco de ruido metálico de maquinaria, un recuerdo de los días en que llegué a trabajar, iniciaba Visual Studio 2010, hervía agua, me preparaba un té, y traía mi taza a mi escritorio al tiempo que mi curso de proyecto de desarrollo C ++ terminaba de subir. Tenga en cuenta que la creación de un clúster es mucho más rápida en los SSD que en los discos duros.

Si tiene una máquina de desarrollo con suficientes recursos de RAM y CPU, puede dejar que su Service Fabric local se ejecute todo el tiempo. Yo no tuve ese lujo, así que tuve que parar el clúster para hacer otras tareas en esa caja de desarrollo. La siguiente vez que necesitaba desplegar mi aplicación, era también hora de hervir agua y preparar té.

Aquí estamos creando un servicio de estado en Visual Studio y esperando a que el clúster local lo ponga en marcha para el despliegue y la depuración. El agua hirvió, el té se preparó.
Azure Service Fabric

La gestión de clusters y el escalado de aplicación son acciones bastante sencillas en la máquina local. No debería ser mucho más complicado en Azure, pero por desgracia se vio seriamente complicado. La configuración de un clúster desde cero en Azure mediante la consola Azure implicaba una larga lista de lavandería de opciones y pasos de configuración. La configuración de Azure necesita ser mejor automatizada -ni ejecutar un clúster de Service fabric Azure de cualquier capacidad especialmente barato. Es necesario un mínimo de cinco máquinas virtuales para un clúster legítimo de producción, por lo que debe multiplicar el costo mensual de máquina virtual, MV, en la figura de abajo por al menos cinco.

La creación de un clúster de Service Fabric en el portal de Azure requiere tomar algunas decisiones difíciles. Idealmente, usted debe modelar los requisitos de capacidad de cluster antes de tiempo.
Azure Service Fabric

Service Fabric de Azure, mientras sea "de middleware," es más de lo que parece. Le puede dar a su aplicación basada en microservicios la clase de fiabilidad, manejabilidad y escalabilidad que una vez requirió una PaaS en toda regla. Aunque Service Fabric todavía necesita trabajar en la portabilidad y facilidad de instalación, sus beneficios para aplicaciones con un número masivo de usuarios son significativos.

Martin Heller, InfoWorld (EE.UU.)