2015-12-29

Diciembre 2015

Volumen 30, número 13

Microsoft Azure: Azure Service Fabric y la arquitectura de microservicios

Por Cesar de la Torre, Kunal Deep Singh, Vaclav Turecek | Diciembre de 2015

Microservicios es una palabra que está muy de moda hoy en día. Aunque existen numerosas presentaciones y ponencias sobre el tema, sigue habiendo confusión entre muchos desarrolladores. Una pregunta que suele repetirse es: "¿no se trata tan solo de otro enfoque de arquitectura orientada a servicios (SOA) o diseño guiado por el dominio (DDD)?".

Por supuesto, muchas de las técnicas utilizadas en el enfoque de microservicios proceden de las experiencias de los desarrolladores en SOA y DDD. Puede considerar que los microservicios son "SOA aplicada correctamente", donde los principios y patrones como los servicios autónomos, el patrón de contexto enlazado y el control por dominios tienen sus raíces en SOA y DDD.

En este artículo se analizará la teoría y la implementación de microservicios. Comenzaremos con una breve introducción a los microservicios y después pasaremos al lado más práctico, donde le enseñaré a crear e implementar microservicios con Azure Service Fabric. Por último, mostraré por qué esta plataforma es una opción ideal para crear microservicios.

Como el nombre sugiere, la arquitectura de microservicios es un enfoque para crear una aplicación de servidor como un conjunto de servicios pequeños, cada uno de los cuales se ejecuta en su propio proceso y con una comunicación entre ellos mediante protocolos como HTTP y WebSockets. Cada microservicio implementa capacidades de negocio y de dominio de un extremo a otro dentro de un determinado contexto enlazado por servicio, se debe desarrollar de forma autónoma y debe implementarse de manera independiente con mecanismos automatizados. Por último, cada servicio debería ser propietario de la lógica de dominio y el modelo de datos de dominio relacionados, y puede utilizar distintas tecnologías de almacenamiento de datos (SQL, No-SQL) y lenguajes de programación diferentes en cada microservicio.

Algunos ejemplos de microservicios son las puertas de enlace de protocolos, los perfiles de usuario, las cestas de la compra, el procesamiento del inventario, el subsistema de compra, el proceso de pago y las colas y memorias cachés.

¿Por qué microservicios? En una sola palabra: agilidad. A largo plazo, los microservicios permiten un mejor mantenimiento en sistemas grandes, complejos y altamente escalables, mediante la designación de aplicaciones basadas en muchos servicios que se pueden implementar de forma independiente y permiten una planificación pormenorizada de versiones.

Como una ventaja adicional, los microservicios se pueden escalar horizontalmente de forma inmediata. En lugar de disponer de enormes bloques de aplicación monolíticos que se deben escalar horizontalmente de forma completa, puede escalar horizontalmente microservicios concretos. De esa forma, es posible escalar solo el área funcional que necesita más potencia de procesamiento o ancho de banda para admitir la demanda, en lugar de escalar horizontalmente otras partes de la aplicación donde no es necesario.

El diseño de aplicaciones de microservicios específicas permite prácticas de desarrollo continuo y una integración también continua, y acelera la incorporación de nuevas funciones a la aplicación. La jerarquía específica de aplicaciones también permite ejecutar y probar microservicios de forma aislada, y evolucionar los microservicios de forma independiente a la vez que se mantienen los estrictos contratos entre ellos. Si no interrumpe los contratos ni las interfaces, puede cambiar la implementación de cualquier microservicio de forma interna y agregar una nueva funcionalidad sin interrumpir el resto de microservicios que dependen de él.

Como se muestra en la Figura 1, el enfoque de microservicios se centra en la eficacia de cambios ágiles y la rápida iteración, ya que podrá cambiar pequeñas partes concretas de aplicaciones grandes, complejas y escalables.

Figura 1. El enfoque de microservicios comparado con el tradicional de aplicaciones de servidor

Propiedad de los datos por microservicio

Una regla importante de este enfoque es que cada microservicio debe ser propietario de su lógica y sus datos de dominio en un ciclo de vida autónomo, con una implementación independiente por microservicio. No es diferente de la forma en que una aplicación completa es propietaria de su lógica y sus datos.

Este enfoque implica que el modelo conceptual del dominio variará entre subsistemas o microservicios. Piense en las aplicaciones empresariales, donde cada una de las aplicaciones de administración de las relaciones con el cliente (CRM), los subsistemas de compras transaccionales y los subsistemas de asistencia al cliente llama a datos y atributos de entidades de cliente únicos y utiliza un contexto enlazado diferente.

Este principio es similar a DDD cuando cada contexto enlazado, que es un patrón comparable a un subsistema o servicio, debe ser propietario de su modelo de domino (datos y lógica). Cada contexto enlazado a DDD estaría relacionado con un microservicio distinto.

Por otra parte, el enfoque tradicional (o monolítico) que utilizan muchas aplicaciones consiste en tener una base de datos única centralizada (a menudo una base de datos SQL normalizada) para toda la aplicación y sus subsistemas internos, como se muestra en la Figura 2. Este enfoque tiene un aspecto a priori más simple y parece que permite la reutilización de entidades en subsistemas distintos para garantizar la coherencia. Pero la realidad es que al final se acaban teniendo tablas enormes que sirven a muchos subsistemas distintos e incluyen atributos y columnas que simplemente no se necesitan en la mayoría de casos. Es como intentar usar el mismo mapa físico para ir de excursión un par de horas, para hacer un viaje en coche que dure todo un día y para aprender geografía.

Figura 2. Comparación de propiedad de datos: microservicios frente a enfoque monolítico

¿Microservicios con o sin estados?

Como se mencionó anteriormente, cada microservicio debe ser propietario de su modelo de dominio. En el caso de los microservicios sin estado, las bases de datos serán externas y se utilizarán opciones relacionales, como SQL Server, u opciones de NoSQL, como MongoDB o Azure Document DB. Profundizando aún más, los propios servicios pueden ser con estado, lo que significa que los datos están dentro del mismo microservicio. Estos datos pueden existir no solo dentro del mismo servidor, sino dentro del proceso del mismo microservicio, en memoria, conservados en disco duro y replicados en otros nodos.

El enfoque sin estado es perfectamente válido y más fácil de implementar que los microservicios con estado, ya que es muy similar a los patrones tradicionales conocidos. Sin embargo, los microservicios sin estado provocan latencia entre el proceso y los orígenes de datos, pero a la vez presentan más piezas que se pueden mover cuando se mejora el rendimiento mediante colas y memoria caché adicionales. El resultado: puede acabar con arquitecturas complejas que tengan demasiados niveles.

Los microservicios con estado, por otra parte, pueden destacar en escenarios avanzados, ya que no hay latencia entre los datos y la lógica del dominio. El procesamiento intenso de datos, los back-ends de juegos, las bases de datos como servicio y otros escenarios con baja latencia se benefician de los servicios con estado, que habilitan el estado local para un acceso más rápido.

El inconveniente: los servicios con estado conllevan un nivel de complejidad para escalarse horizontalmente. La funcionalidad que normalmente se implementaría dentro de los límites de las bases de datos externas se debe abordar en cosas como la replicación de datos entre réplicas de microservicios con estado, la creación de particiones de datos, etc. Pero esta es precisamente una de las áreas en las que Service Fabric puede ayudar más, mediante la simplificación del desarrollo y el ciclo de vida de los microservicios con estado.

Ventajas de Azure Service Fabric

Junto con todas las ventajas que aporta el enfoque de microservicios se incluye un inconveniente. Las implementaciones de microservicios complejos y computación distribuida pueden ser difíciles de administrar si usted mismo se ocupa de ello. Service Fabric ofrece los cimientos necesarios para crear, implementar, ejecutar y administrar microservicios de una forma eficaz y eficiente.

¿Qué es Service Fabric? Es una plataforma de sistemas distribuidos que se utiliza para crear aplicaciones hiperescalables, confiables y fáciles de administrar para la nube. Service Fabric aborda los importantes retos del desarrollo y la administración de aplicaciones en la nube. Con Service Fabric, los desarrolladores y administradores puede evitar tener que solucionar problemas de infraestructura complejos, y en su lugar se pueden centrar en implementar exigentes cargas de trabajo críticas, con la seguridad de que son escalables, confiables y administrables. Service Fabric representa la plataforma de middleware de Microsoft de última generación para crear y administrar estos servicios de escala en la nube de primer nivel y clase empresarial.

Service Fabric es un entorno de implementación universal; podrá implementar cualquier archivo ejecutable basado en cualquier lenguaje (Microsoft .NET Framework, Node.js, Java, C++) o incluso tiempos de ejecución de bases de datos como MongoDB.

Por tanto, es importante dejar claro que Azure Service Fabric no solo está limitado a aplicaciones orientadas a microservicios. También se puede utilizar para hospedar e implementar aplicaciones tradicionales (servicios o aplicaciones web) y obtener muchos beneficios relacionados con la escalabilidad, el equilibrio de carga y la rápida implementación. Sin embargo, Azure Service Fabric es una nueva plataforma creada desde cero y especialmente diseñada para sistemas basados en microservicios e hiperescala, como se muestra en la Figura 3.

Figura 3. Microsoft Azure Service Fabric

A continuación se muestran algunas ventajas de Service Fabric:

Se ejecuta en Azure, de forma local y en cualquier nube. Una característica muy importante de Service Fabric es que puede ejecutarlo en Azure, pero también de forma local, en sus propios servidores sin sistema operativo o máquinas virtuales (MV), e incluso en otras nubles hospedadas de terceros. No está limitado a una nube concreta. Incluso podría ejecutar un clúster de Service Fabric en Amazon Web Services (AWS).
Admite Windows o Linux. Actualmente (a finales de 2015), Service Fabric admite Windows, pero también admitirá Linux y contenedores (imágenes de Windows y de Docker).
Completamente probado. Microsoft ha utilizado Service Fabric durante años para ofrecer muchos de sus productos en la nube.

Service Fabric nació por la necesidad de crear servicios de gran escala dentro de Microsoft. Para crear productos como SQL Server como servicios disponibles en la nube (Base de datos SQL de Azure) mientras se mantenían ágiles, confiables, escalables y rentables, era necesaria una tecnología distribuida que pudiera cubrir todos esos requisitos de forma eficaz. Mientras se creaba la tecnología base que solucionase estos complejos escenarios, resultó evidente que SQL Server no era el único producto que estaba dando el salto. Sucedía lo mismo con otros productos, como Skype Empresarial, que tuvo que solucionar problemas similares para convertirse en una aplicación basada en microservicios. Service Fabric es la plataforma de aplicaciones que surgió de esos retos y se ha utilizado en muchos servicios a gran escala en Microsoft, con arquitecturas y requisitos cambiantes para ejecutarse a escala. InTune, DocumentDB y los back-end de Cortana y Skype Empresarial son servicios que se ejecutan con Service Fabric.

La experiencia de admitir sistemas críticos ha permitido a Microsoft diseñar una plataforma que comprende intrínsecamente los recursos de infraestructura disponibles y las necesidades de las aplicaciones escalables. Habilita la actualización automática, un comportamiento de recuperación automática que es esencial para ofrecer servicios duraderos y altamente disponibles en hiperescala. Microsoft ofrece esta tecnología curtida en batalla para todo el mundo.

Modelos de programación de Azure Service Fabric

Service Fabric ofrece dos marcos de alto nivel para crear servicios: las API Reliable Services y las API Reliable Actors. Aunque los dos se basan en el mismo núcleo de Service Fabric, tienen distintos equilibrios entre simplicidad y flexibilidad en lo que respecta a simultaneidad, creación de particiones y comunicación, como se muestra en la Figura 4. Resulta útil comprender cómo funcionan los dos modelos para poder elegir el marco más apropiado para el servicio. En muchos escenarios de aplicaciones, puede adoptar un enfoque híbrido y usar actores para microservicios determinados, y servicios confiables para agregar datos generados por varios actores. Por lo tanto, un servicio confiable podría orquestar servicios de actores en muchos escenarios habituales.

Figura 4. Comparación de modelos de programación de Service Fabric

API Reliable Actor	API Reliable Services
El escenario implica muchos pequeños objetos o unidades independientes de estado y lógica (algunos ejemplos son los objetos activos de Internet de las cosas o los escenarios de back-end de juegos)	Debe mantener la lógica y las consultas en varios componentes y tipos de entidades
Trabaja con una enorme cantidad de objetos uniproceso mientras sigue pudiendo escalar y mantener la coherencia	Utiliza colecciones confiables (como la cola y el diccionario confiables de .NET) para almacenar los estados o entidades
Quiere que el marco administre la simultaneidad y la granularidad del estado	Quiere controlar la granularidad y la simultaneidad del estado
Quiere que Service Fabric se ocupe de administrar la implementación de la comunicación	Quiere tomar decisiones, administrar e implementar los protocolos de comunicación (Web API, WebSockets, Windows Communication Foundation, etc.)
Quiere que Service Fabric administre el esquema de creación de particiones de los servicios de actores con estado para que sea transparente para usted	Quiere controlar el esquema de creación de particiones del servicio con estado

Creación de microservicios sin estado con Azure Service Fabric

Un microservicio en Azure Service Fabric puede ser casi cualquier proceso del servidor que quiera crear, ya sea de .NET Framework, Node.js, Java o C++. Actualmente, solo están disponibles las bibliotecas de .NET y C++ de la API de Service Fabric. Por tanto, debe implementar los microservicios en .NET Framework o en C++ para las implementaciones de bajo nivel.

Como se mencionó, un microservicio sin estado es aquel en el que hay un proceso (como un servicio de front-end o un servicio de lógica de negocios), pero no hay literalmente ningún estado almacenado dentro del servicio, o el estado que hay se pierde cuando finaliza el proceso y no requiere sincronización, replicación, persistencia ni alta disponibilidad. Podría tener un estado externo relacionado, pero conservado en almacenamiento externo, como una Base de datos SQL de Azure, Almacenamiento de Azure, Azure DocumentDB o cualquier otro motor de almacenamiento de terceros (relacional o NoSQL). En consecuencia, cualquier servicio existente, como el servicio ASP.NET Web API ejecutándose en Servicios en la nube, un rol de trabajo o una aplicación web de Azure, se podría migrar fácilmente a servicios sin estado de Service Fabric.

Para configurar el entorno de desarrollo, debe disponer del SDK de Service Fabric, que le permite ejecutar un clúster de desarrollo local que no sea un emulador, pero ejecuta las mismas partes que en Azure. Además, la integración de herramientas de Visual Studio 2015 hace que la implementación y la depuración sean más sencillas.

Antes de implementar y depurar servicios en la máquina local, debe crear el clúster de nodos. Puede hacerlo mediante la ejecución de un script de Windows PowerShell denominado DevClusterSetup.ps1, como se explica en la sección "Instalar e iniciar un clúster local" de la página de documentación "Preparación del entorno de desarrollo" que puede encontrar en bit.ly/1Mfi0LB. Consulte esta página para obtener un tutorial completo sobre el proceso de configuración.

Clase base de servicio sin estado Cualquier clase de servicio sin estado de Service Fabric debe derivarse de la clase Microsoft.ServiceFabric.Services.StatelessService. Esta clase ofrece contexto y métodos de API relacionados con el clúster de Service Fabric y el entorno de ejecución, y se conecta con el ciclo de vida del servicio.

Tanto si el servicio es con estado como sin él, Reliable Services ofrece un ciclo de vida simple que le permite acoplar rápidamente el código y comenzar a trabajar. Tan solo hay uno o dos métodos que debe implementar para que el servicio de Service Fabric esté listo y en funcionamiento, normalmente RunAsync y CreateServiceReplicaListeners, que se explicarán cuando se detallen los protocolos de comunicación.

Observe RunAsync como se muestra en la Figura 5. Ahí es donde el servicio puede "realizar trabajo" en segundo plano. El token de cancelación que se ofrece es una señal de cuándo debería parar ese trabajo.

Figura 5. Estructura base de un servicio sin estado en Azure Service Fabric

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Protocolos de comunicación de Reliable Services de Azure Service Fabric Reliable Services de Azure Service Fabric ofrece un modelo de comunicación acoplable. Puede usar el transporte que prefiera, como HTTP con ASP.NET Web API, WebSockets, Windows Communication Foundation, protocolos TCP personalizados, etc.

Puede implementar su propio código para el protocolo de comunicación elegido en el servicio o usar cualquier pila de comunicación que se ofrezca con Service Fabric, como ServiceCommunicationListener/ServiceProxy, que es la pila de comunicación predeterminada que ofrece el marco Reliable Services en Service Fabric. También habrá paquetes NuGet independientes con pilas de comunicación adicionales que puede acoplar a Service Fabric.

Uso de ASP.NET Web API en microservicios de Service Fabric Como se mencionó antes, Service Fabric le permite decidir cómo quiere que se comuniquen sus servicios, pero una de las formas más habituales de crear servicios HTTP en .NET Framework es con ASP.NET Web API.

Web API en Service Fabric es exactamente igual que ASP.NET Web API, que ya conoce y disfruta. Utilice controladores, HttpRoutes y podrá crear servicios REST de la misma forma mediante MapHttpRoute o atributos en los métodos que quiere asignar a las rutas HTTP. La diferencia cuando se utiliza Service Fabric es la forma de hospedar una aplicación de Web API. Lo primero que debe tener en cuenta es que no es posible usar IIS en Azure Service Fabric, ya que utiliza procesos normales replicados en el clúster, de forma que tendrá que autohospedar la escucha HTTP en el código. Para hacerlo con los servicios de Web API, tiene dos opciones:

Use ASP.NET 5 Web API (nombre en clave "Project K") para autohospedar la escucha HTTP dentro del proceso de microservicios de Service Fabric.
Use OWIN o Katana y ASP.NET 4.x Web API para autohospedar la escucha HTTP dentro del proceso de microservicios de Service Fabric.

La ejecución de ASP.NET 5 basado en Azure Service Fabric es la mejor opción para crear microservicios porque, como se mencionó antes, Service Fabric permite implementar un número cualquiera de servicios en cada nodo o máquina virtual, lo que se traduce en una alta densidad de microservicios por clúster. Además, esa alta densidad mejorará aún más cuando finalmente se ofrezca compatibilidad con .NET Core 5 y CoreCLR en el futuro (con ASP.NET 5). Será "la mejor opción" para conseguir densidades muy altas de microservicios, ya que .NET Core 5 es un marco ligero con una superficie de memoria muy pequeña en comparación con .NET 4.x Framework completo.

Uso de microservicios de Service Fabric y aplicaciones web "de tipo MVC" ASP.NET MVC es un marco muy conocido para sitios web tradicionales, pero no puede usar el marco MVC "antiguo" (MVC5 o una versión anterior) con Service Fabric. Esto se debe a que en Service Fabric debe autohospedar la escucha HTTP en el proceso y a que ni OWIN ni Katana se admiten en ASP.NET 4.x MVC (solo se admiten en ASP.NET 4.x Web API.) Por tanto, las opciones que tiene para implementar una aplicación web "de tipo MVC" en servicios de Service Fabric son las siguientes:

Usar MVC 6 en ASP.NET 5 para autohospedar la escucha HTTP dentro del proceso de microservicios de Service Fabric. Admite MVC porque en ASP.NET 5, Web API y MVC se han consolidado y de hecho son el mismo marco con los mismos controladores sin dependencia con IIS. Esta será la opción preferida cuando ASP.NET 5 se publique para producción.
Usar ASP.NET 4.x Web API con OWIN o Katana para hospedar automáticamente la escucha HTTP dentro del proceso de microservicios de Service Fabric, simular controladores MVC con controladores Web API y utilizar resultados de HTML o JavaScript en lugar de contenido normal de Web API (JSON o XML). En la página de documentación que se encuentra en bit.ly/1UMdKIf se muestra cómo implementar esta técnica.

Implementar autohospedaje con ASP.NET 4.x Web API y OWIN o Katana

Para este enfoque, la aplicación de Web API con la que está acostumbrado a trabajar no cambia. No es distinta de las aplicaciones de Web API que haya podido escribir en el pasado y debería poder simplemente mover el código de la aplicación de un sitio a otro. El hospedaje de la aplicación podría ser algo distinto de lo que está acostumbrado si ha estado hospedando en IIS.

Método CreateServiceReplicaListeners de la clase del servicio Aquí es donde el servicio define las pilas de comunicación que quiere usar. La pila de comunicación, como Web API, es lo que define los puntos de conexión de escucha para el servicio, así como la forma en que esos mensajes que aparecen interactuarán con el resto del código del servicio.

Volviendo a la clase del servicio que se mencionó anteriormente en la Figura 4, ahora solo debo agregar un nuevo método llamado CreateServiceReplicaListeners, que especifique al menos una pila de comunicación que quiera usar. En este caso, es el elemento OwinCommunicationListener que utiliza Web API, como se muestra en la Figura 6.

Figura 6. Se agrega el método CreateServiceReplicaListeners a la clase del servicio sin estado

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

Es importante destacar que puede tener varias escuchas de comunicación agregadas al servicio.

La clase OwinCommunicationListener es código reutilizable que volvería a usar en todos los microservicios. De manera similar, podría acoplar otros protocolos (WCF, WebSockets, etc.).

Si está creando un microservicio de Web API, seguirá teniendo controladores con código habitual que no difiere del tipo al que está habituado cuando se implementan servicios de Web API, como el código siguiente:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

Como este artículo es una introducción de extremo a extremo de Azure Service Fabric y los microservicios, no se llevarán a cabo más pasos para implementar OWIN en el microservicio de Service Fabric. Hay un ejemplo simple disponible en GitHub que puede descargar y analizar (bit.ly/1OW5Bmj): Ejemplo HelloWorld de Web API y Service Fabric (ASP.NET 4.x).

Implementar el autohospedaje con ASP.NET 5 Web API

La ejecución de ASP.NET 5 basado en Azure Service Fabric es la mejor opción para crear microservicios porque Service Fabric permite implementar un número cualquiera de servicios en cada nodo o máquina virtual, lo que se traduce en una alta densidad de microservicios por clúster. ASP.NET 5 también ofrece características interesantes como las siguientes:

Hospedaje flexible: ahora puede hospedar la aplicación ASP.NET 5 en IIS o en su propio proceso. El hospedaje en su propio proceso es fundamental en Azure Service Fabric.
Web API, MVC y páginas web: se han unificado, lo que simplifica el número de conceptos.
Compatibilidad completa: ahora, las aplicaciones de ASP.NET 5 se pueden instalar en una máquina, sin que ello afecte a las demás aplicaciones que puedan estar usando una versión distinta de .NET Framework. Se trata de una característica muy valiosa para la administración de TI.
Compatibilidad entre plataformas: ASP.NET 5 se ejecuta y se admite en Windows, Mac OS X y Linux.
Listo para la nube: las características como el diagnóstico, el estado de la sesión, la memoria caché y la configuración están diseñadas para el trabajo tanto local como en la nube (por ejemplo, Azure) sin cambios.

En el futuro, la capacidad de alta densidad mejorará aún más cuando finalmente se ofrezca compatibilidad con .NET Core 5 y CoreCLR.

Aunque se sigue trabajando en la compatibilidad con .NET Core y CoreCLR de Service Fabric, las ventajas cuando la compatibilidad esté en línea son evidentes. La ejecución de ASP.NET 5 basado en .NET Core 5 ofrece un .NET Framework ligero y un tiempo de ejecución de CoreCLR con una superficie de memoria muy pequeña en comparación con .NET 4.x tradicional. Esa combinación permitirá una densidad de microservicios increíble, como se muestra en el panel "Microservice B" de la Figura 7.

Figura 7. Comparación de ASP.NET 5 ejecutándose en CLR frente a CoreCLR dentro del contexto de Service Fabric

Aunque la compatibilidad con .NET Core 5 y CoreCLR es una opción futura, las empresas pueden prepararse ya para ello mediante el desarrollo de servicios de ASP.NET 5 basados en .NET 4.x en Service Fabric. Si lo hace así, en el futuro la migración a CoreCLR será más fácil.

Funcionamiento e implementación de microservicios de hiperescala

La administración de la implementación y las operaciones que ofrece Service Fabric son otros motivos de por qué es ideal para la creación y ejecución en microservicios de hiperescala de producción. Puede centrarse en el desarrollo de microservicios y dejar que Service Fabric proporcione los complejos cimientos necesarios de forma interna.

La alta densidad de los microservicios es una gran ventaja si le interesa reducir el costo de la infraestructura. Un clúster de Service Fabric está compuesto de un grupo de varios servidores o máquinas virtuales (y contenedores en el futuro) llamados nodos del clúster. En cada nodo, Service Fabric implementa automáticamente varios servicios, por lo que dependiendo de la potencia de cada uno de los servidores o máquinas virtuales, puede tener una densidad altísima de microservicios en el clúster.

En Azure Service Fabric, tiene la posibilidad de ejecutar cientos de instancias de servicio en cada máquina o máquina virtual. Eso ofrece un gran ahorro en el costo total de propiedad (TCO). Para la misma cantidad de servicios, necesitará menos hardware. Por ello, la alta densidad es un aspecto claramente diferenciador al comparar Azure Service Fabric con Servicios en la nube de Azure, donde hay una limitación de una máquina virtual por servicio. Si estuviera implementando microservicios como un rol web o un rol de trabajo, probablemente tendría demasiados recursos asignados a un único microservicio, lo que provocaría ralentizaciones al implementar y administrar. Por ejemplo, en la Figura 8 se puede ver una máquina virtual por instancia de servicio, con la forma de un rol web de Azure o un rol de trabajo (el color indica el tipo de servicio y cada forma o cuadro indica una instancia distinta de máquina virtual y servicio). Este enfoque no ayuda si lo que busca es tener alta densidad de microservicios, a menos que use máquinas virtuales pequeñas. Aun así, hay un límite y con ninguna de las implementaciones podrá alcanzar el mismo nivel de alta densidad que con Azure Service Fabric.

Figura 8. Comparación de densidades de servicio: Servicios en la nube de Azure frente a Service Fabric

Por contra, en Service Fabric puede implementar un número cualquiera de microservicios por nodo, de forma que la densidad de los servicios sea mucho más eficiente y se reduzca el costo. Puede disponer de decenas, cientos o incluso miles de servidores o máquinas virtuales por clúster, con decenas de miles de instancias de microservicios y réplicas por nodo o máquina virtual. Y como cada microservicio es simplemente un proceso, el desarrollo y el escalado son mucho más rápidos que la creación de una nueva máquina virtual por servicio, como es el caso con los Servicios en la nube de Azure.

Creación de un clúster en la nube de Azure Antes de implementar microservicios, debe crear el clúster de nodos en Azure o en servidores locales. Al crear el clúster en la nube de Azure (como el entorno de ensayo o de producción), puede trabajar directamente desde el Portal de Azure o mediante el Administrador de recursos de Azure (ARM). En la Figura 9, verá un clúster de Service Fabric que creamos en nuestra suscripción de Azure mediante el Portal de Azure. Internamente, el proceso de creación del clúster se basa en el ARM de Azure y en los grupos de recursos de Azure. En este caso, creamos un clúster con cinco nodos o máquinas virtuales que también se colocan dentro de un grupo de recursos de Azure.

Figura 9. Clúster de Service Fabric en el Portal de Azure

Implementación de aplicaciones o servicios en el clúster Cuando el clúster de los nodos o máquinas virtuales esté listo y en ejecución, podrá implementar servicios. Cuando se implementa en clústeres de producción, normalmente usará un script de Windows PowerShell para implementar los servicios o aplicaciones en el clúster de Azure, aunque en los entornos de ensayo o pruebas también puede implementar directamente desde Visual Studio.

Cuando se implementa en un clúster local en el equipo de desarrollo con Visual Studio 2015, normalmente implementaría directamente desde el IDE haciendo doble clic con el botón derecho en el proyecto de la aplicación de Service Fabric y seleccionando Implementar. También puede usar Windows PowerShell para implementar en el clúster de desarrollo del portátil, ya que las mismas partes de Service Fabric se ejecutan en clústeres de desarrollo y en clústeres basados en la nube de Azure.

Las operaciones cotidianas y la manejabilidad de las implementaciones son necesarias para mantener los servicios con una ejecución correcta a largo plazo; además, las características de administración del ciclo de vida de las aplicaciones se han integrado en Service Fabric, en concordancia con el enfoque basado en microservicios. Las características de administración y las operaciones disponibles en Service Fabric incluyen implementaciones rápidas, actualizaciones de aplicaciones sin tiempo de inactividad, supervisión del estado de los servicios y escalado vertical y horizontal de clúster. Las actualizaciones sin tiempo de inactividad son posibles porque la tecnología de actualización de Service Fabric ofrece una combinación integrada de actualizaciones graduales y comprobaciones de estado automáticas que detectan y revierten los cambios de la actualización si desestabilizan la aplicación. La administración de los clústeres y aplicaciones de Service Fabric se puede realizar mediante comandos de Windows Powershell, que ofrecen toda la potencia de CLI y los scripts, a la vez que también se admiten herramientas visuales como Visual Studio, para una mayor facilidad de uso.

Las actualizaciones graduales se realizan por fases. En cada fase, la actualización se aplica a un subconjunto de nodos del clúster, que se conoce como un dominio de actualización. Como resultado, la aplicación permanece disponible durante toda la actualización. También puede tener compatibilidad en paralelo y control de versiones seguras para poder implementar las versiones v1 y v2 del mismo microservicio, y Service Fabric redirigirá una u otra, según las solicitudes del cliente. Consulte la documentación que se encuentra en bit.ly/1kSupz8 para obtener información detallada.

Al depurar servicios dentro del clúster de desarrollo local del equipo, Visual Studio facilita el proceso incluso aunque los procesos de los servicios ya estuvieran en ejecución antes de comenzar la depuración El IDE se adjunta automáticamente a todos los procesos de microservicios relacionados con el proyecto, lo que facilita comenzar a trabajar y usar los puntos de interrupción normales en el código de microservicios de Service Fabric. Simplemente, establezca los puntos de interrupción en el código y presione F5. No es necesario averiguar los procesos a los que debe adjuntar Visual Studio.

Explorador de Service Fabric El Explorador de Service Fabric, que se muestra en la Figura 10, es una herramienta basada en web que el clúster ofrece para visualizar el estado de las aplicaciones implementadas, inspeccionar el contenido de nodos individuales y realizar varias acciones administrativas. La herramienta de explorador se sirve desde el mismo servicio de puerta de enlace HTTP que admite las API REST de Service Fabric y puede acceder a ella en http://<punto-de-conexión-del-clúster>:19007/Explorer. En el caso de un clúster local, la dirección URL sería http://localhost:19007/Explorer.

Figura 10. El Explorador de Service Fabric

Para conocer más detalles sobre el Explorador de Service Fabric, lea la página de documentación "Visualización del clúster mediante el Explorador de Service Fabric" (bit.ly/1MUNyad).

La plataforma de Service Fabric permite una serie de características que le permiten centrarse en el desarrollo de la aplicación en lugar de tener que preocuparse por la implementación de complejos sistemas actualizables y de estado. Entre ellas se encuentran:

Escala horizontal de servicios sin estado El motor de orquestación de Service Fabric puede escalar automáticamente la aplicación web en más máquinas cada vez que se agreguen nuevos nodos a un clúster. Al crear instancias de un servicio sin estado, puede especificar el número de instancias que quiere crear. Service Fabric colocará ese número de instancias en los nodos del clúster de forma adecuada, asegurándose de que no se crea más de una instancia en ningún nodo. También puede indicar a Service Fabric que siempre cree una instancia en todos los nodos mediante la especificación de "-1" como el número de instancias. Esto garantiza que cada vez que se agreguen nodos para escalar horizontalmente el clúster, se creará una instancia del servicio sin estado en los nuevos nodos.

Equilibro automático de recursos Service Fabric ofrece equilibro de recursos de servicio (u orquestación de servicios), que conoce los recursos totales disponibles en el clúster (como el proceso de las máquinas virtuales). Mueve automáticamente los microservicios en función de las restricciones y directivas definidas para optimizar mejor cómo se colocan los servicios creados en las máquinas virtuales (consulte la Figura 11). Esto se centra en la optimización de costos y rendimiento.

Figura 11. Clúster donde se muestra la distribución de servicios en los nodos y el equilibrio automático de recursos

Conmutación por error y replicación integradas Las máquinas de los centros de datos o nubes públicas son propensas a errores de hardware no previstos. Para protegerse frente a esos escenarios, Service Fabric ofrece conmutación por error y replicación integradas, lo que significa que aunque se produzcan problemas de hardware, la disponibilidad de los servicios no se verá afectada. Esto es posible porque Service Fabric puede ejecutar y administrar varias instancias de cada servicio en las máquinas y los dominios de error.

Restricciones de ubicación Puede indicar al clúster que haga cosas como no colocar los microservicios de front-end en las mismas máquinas o los mismos nodos que los microservicios de nivel intermedio, y que evite colocar tipos determinados de microservicios en los mismos nodos. Esto se puede hacer para minimizar los conflictos conocidos o para garantizar el acceso prioritario de microservicios determinados a los recursos.

Equilibro de carga de las solicitudes No debe confundirse con el equilibrio automático de recursos; el equilibrio de carga de las solicitudes no lo controla Service Fabric, sino los equilibradores de carga de Azure u otra plataforma externa a Service Fabric.

Estado Le permite supervisar y diagnosticar los sistemas. También se utiliza durante las actualizaciones de la aplicación para ofrecer comprobaciones de seguridad, de forma que las actualizaciones se puedan revertir si tienen un efecto desestabilizante. Para más información, consulte la página de documentación "Introducción a la supervisión del estado de Service Fabric" (bit.ly/1jSvmHB).

Microservicios con estado en Azure Service Fabric

La compatibilidad con los servicios con estado es un componente importante e interesante de Azure Service Fabric. También es un tema lo suficientemente complejo y amplio como para que el análisis de los servicios con estado se escape del alcance de este artículo, pero se explicará brevemente de qué se trata. Permanezca atento a un artículo de continuación que se centre en esta área de Service Fabric en una columna futura.

Un microservicio con estado de Service Fabric coloca el proceso y los datos, con el estado situado dentro del propio microservicio (tanto en memoria como almacenados en el disco local). La confiabilidad del estado se consigue mediante la persistencia local y la replicación de datos en otros nodos o máquinas virtuales. Básicamente, cada partición de datos tiene varios servicios de réplica asociados a ella. Cada réplica se puede implementar en un nodo o una máquina virtual distintos para ofrecer alta disponibilidad si la réplica principal deja de funcionar. Es similar a la forma en que la Base de datos SQL de Azure trabaja con réplicas de bases de datos, ya que se basa en Azure Service Fabric.

En aplicaciones complejas y escalables, los servicios con estado simplifican la arquitectura y reducen el número de componentes, en comparación con una arquitectura tradicional de tres niveles que necesita utilizar colas y memoria caché externas. Al usar servicios con estado, las ventajas de una memoria caché externa tradicional son ahora intrínsecas al servicio con estado. Además, las colas externas no son necesarias, ya que es posible implementar colas internas dentro de los microservicios de Service Fabric.

Al usar servicios con estado, se crean automáticamente elementos secundarios de copia de seguridad en caliente que pueden retomar las operaciones desde el mismo punto donde un elemento principal lo dejó tras un fallo de hardware. Muchas veces los servicios tienen que escalarse para continuar cubriendo las exigencias de una base de usuarios en crecimiento, lo que requiere que se agregue hardware al entorno en ejecución. Service Fabric usa características como la creación de particiones, para que los servicios se puedan crear de forma que se extiendan automáticamente al nuevo hardware sin necesidad de que los usuarios intervengan.

Reliable Services de Azure con estado ofrece un host de capacidades, entre las que se incluyen la compatibilidad con la creación de particiones de datos, la compatibilidad con réplicas y la elección de líder, la nomenclatura de servicios de réplica y la detección de direcciones de servicio del servicio de puerta de enlace. También ofrece administración de la simultaneidad y la granularidad de los cambios de estado mediante transacciones, la capacidad de mantener una replicación de estados coherente y el uso de colecciones de clave y valor distribuidas y confiables (diccionario y cola confiables). La buena noticia es que Service Fabric se ocupa de la complejidad y los detalles de estos temas, lo que le permite centrarse en crear aplicaciones.

Servicios de Reliable Actors en Azure Service Fabric

Reliable Actors de Azure Service Fabric es un modelo de programación de actores para Service Fabric. Ofrece un modelo de actores uniproceso y asincrónico. Un actor representa una unidad de estado y proceso. En parte es similar al proyecto de software de código abierto "Orleans" que creó Microsoft Research. El aspecto importante es que la API Reliable Actors de Service Fabric se basa en la infraestructura subyacente que ofrece Service Fabric.

La implementación de instancias de actores para dispositivos de Internet de las cosas (IoT) es un buen ejemplo del uso de servicios de actores. Un tipo Vehicle-Actor con la forma de una clase de C# encapsularía la lógica de dominio del vehículo de IoT además de sus estados activos (como las coordenadas GPS) y otros datos. Después, tendríamos potencialmente millones de instancias u objetos de actores de esa clase mencionada, distribuidos en muchos nodos del clúster.

Los actores por supuesto no están limitados a objetos de IoT activos, se podrían usar para cualquier otra cuestión, pero los "objetos de IoT activos" conforman un excelente escenario didáctico.

Los actores se distribuyen a lo largo del clúster para conseguir una escalabilidad y disponibilidad elevadas, y se tratan como objetos en memoria en todas las máquinas virtuales del clúster. También se conservan en el disco local y se replican a lo largo del clúster.

Los actores son objetos uniproceso aislados que encapsulan el estado y el comportamiento. Todos los actores son una instancia de un tipo de actor, de forma similar al código de .NET que se muestra aquí:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

A continuación, en el código siguiente se muestra código de cliente para utilizar el actor mediante un objeto proxy:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

El marco Reliable Actors de Service Fabric se ocupa de toda la infraestructura de comunicación de forma interna.

Podría disponer de millones de objetos VehicleActor ejecutándose en el clúster en muchos nodos o máquinas virtuales diferentes y Service Fabric se ocuparía de crear los cimientos necesarios, incluidas las particiones y las réplicas donde los millones de actores se extienden y se equilibran.

La API de cliente Actors ofrece comunicación entre una instancia de actor y un cliente de actor. Para comunicarse con un actor, un cliente crea un objeto de proxy de actor que implementa la interfaz de actor. El cliente interactúa con el actor mediante la invocación de métodos en el objeto proxy.

En los escenarios donde encajan los actores, se simplifica enormemente la implementación de microservicios, especialmente si se compara con los servicios confiables con estado en los que tiene más control, pero debe implementar mucha base relacionada con la creación de particiones de datos, direccionamiento de particiones, réplicas, etc. Si no necesita un control pormenorizado, puede evitar el trabajo adicional si usa Reliable Actors.

Resumen

Las arquitecturas de microservicios requieren un compromiso con los enfoques descentralizados, la arquitectura disciplinada y los procesos de diseño, las nuevas tecnologías como Azure Service Fabric y un cambio en las dinámicas de equipo hacia equipos de desarrollo más pequeños y principios de Agile aplicados por microservicio.

Cesar de la Torrees jefe de programas senior en Microsoft y vive en Redmond, Wash. Entre sus intereses se encuentran Microsoft Azure y el desarrollo en .NET con enfoques como las arquitecturas de microservicios y el diseño dirigido por dominios, así como el desarrollo de aplicaciones móviles que sacan lo mejor de los servicios.

Kunal Deep Singhes jefe de programas senior en el equipo de Microsoft Azure Service Fabric. Antes de Azure, trabajó en varias versiones de Windows Phone, Silverlight y como desarrollador de juegos para títulos de Xbox. Vive en Seattle, Wash.

Vaclav Turecekes jefe de programas senior en Microsoft. Trabaja sin descanso con un grupo de personas con mucho talento para convertir Azure Service Fabric en la mejor Plataforma como servicio de última generación.

Gracias al siguiente experto técnico de Microsoft por colaborar en la redacción y revisión de este artículo: Mark Fussell
Mark Fussell es un apasionado de la creación de aplicaciones de escala en la nube, que lleva muchos años en Microsoft creando productos que van desde tecnologías de acceso a datos y comunicaciones a otras tecnologías de lado servidor. Está entusiasmado de que Microsoft haya permitido que Service Fabric esté disponible para todo el mundo para la creación de aplicaciones con un enfoque de microservicios.

Compartir a través de