Elección de una opción de proceso de Azure para los microservicios

  • Artículo

El término proceso hace referencia al modelo de hospedaje para los recursos informáticos donde se ejecutan las aplicaciones. Para una arquitectura de microservicios, hay dos enfoques especialmente populares:

  • Un orquestador de servicios que administra los servicios que se ejecutan en nodos dedicados (máquinas virtuales).
  • Una arquitectura sin servidor mediante funciones como un servicio (FaaS).

Aunque estas no son las únicas opciones, ambas son métodos probados para generar microservicios. Una aplicación puede incluir ambos enfoques.

Orquestadores de servicios

Un orquestador controla las tareas relacionadas con la implementación y administración de un conjunto de servicios. Estas tareas incluyen colocar servicios en los nodos, supervisar el estado de los servicios, reiniciar los servicios en mal estado, equilibrar la carga del tráfico de red en todas las instancias de servicio, detectar servicios, escalar el número de instancias de un servicio y aplicar actualizaciones de configuración. Entre los orquestadores más conocidos se encuentran Kubernetes, Service Fabric, DC/OS y Docker Swarm

En la plataforma Azure, tenga en cuenta las siguientes opciones:

  • Azure Kubernetes Service (AKS) es un servicio administrado de Kubernetes. AKS aprovisiona Kubernetes y expone los puntos de conexión de la API de Kubernetes, pero hospeda y administra el plano de control de Kubernetes, realizando actualizaciones automatizadas, correcciones automatizadas, autoescala y otras tareas de administración. Se puede considerar AKS como "API de Kubernetes como servicio".

  • Azure Container Apps es un servicio administrado basado en Kubernetes que abstrae las complejidades de la orquestación de contenedores y otras tareas de administración. Container Apps simplifica la implementación y administración de aplicaciones y microservicios contenedorizados en un entorno sin servidor, a la vez que proporciona las características de Kubernetes.

  • Service Fabric es una plataforma de sistemas distribuidos para empaquetar, implementar y administrar microservicios. Los microservicios pueden implementarse en Service Fabric como contenedores, como archivos ejecutables binarios o como Reliable Services. Usando el modelo de programación de Reliable Services, los servicios pueden utilizar directamente las API de programación de Service Fabric para consultar el sistema, informar del estado, recibir notificaciones acerca de la configuración y los cambios de código y detectar otros servicios. Una diferencia clave con Service Fabric es el enfoque prioritario dado a la creación de servicios con estado mediante Reliable Collections.

  • Otras opciones, como Docker Enterprise Edition, se pueden ejecutar en un entorno de IaaS en Azure. Puede encontrar plantillas de implementación en Azure Marketplace.

Contenedores

A veces se habla de contenedores y microservicios como si fueran lo mismo. Aunque esto no es cierto (los contenedores no son necesarios para generar microservicios), los contenedores tienen algunas de las ventajas que son especialmente apropiadas para los microservicios, como:

  • Portabilidad. Una imagen de contenedor es un paquete independiente que se ejecuta sin necesidad de instalar las bibliotecas u otras dependencias. Esto hace que sean fáciles de implementar. Los contenedores pueden iniciarse y detenerse rápidamente, por lo que puede poner en marcha nuevas instancias para controlar más carga o para recuperarse de errores de nodo.

  • Densidad. Los contenedores son ligeros en comparación con la ejecución de una máquina virtual, ya que comparten recursos de sistema operativo. Esto permite empaquetar varios contenedores en un nodo único, lo que es especialmente útil cuando la aplicación consta de muchos servicios pequeños.

  • Aislamiento de recursos. Puede limitar la cantidad de memoria y CPU que están disponibles para un contenedor, lo que puede ayudar a garantizar que un proceso descontrolado no agotará los recursos del host. Consulte el patrón Bulkhead para más información.

Arquitectura sin servidor (funciones como un servicio)

Con una arquitectura sin servidor, no se administran las máquinas virtuales ni la infraestructura de red virtual. En su lugar, se implementa código y el servicio de hospedaje controla la colocación de ese código en una máquina virtual y lo ejecuta. Este enfoque tiende a favorecer a las pequeñas funciones pormenorizadas que se coordinan mediante el uso de los desencadenadores basados en eventos. Por ejemplo, un mensaje que se colocan en una cola puede desencadenar una función que lee de la cola y procesa el mensaje.

Azure Functions es un servicio de proceso sin servidor que admite varios desencadenadores de función, incluidas las solicitudes HTTP, las colas de Service Bus y los eventos de Event Hubs. Si desea una lista completa consulte Conceptos básicos sobre los enlaces y desencadenadores de Azure Functions. Tenga en cuenta también a Azure Event Grid, que es un servicio de enrutamiento de eventos administrados de Azure.

¿Orquestador o sin servidor?

Estos son algunos de los factores a considerar a la hora de elegir entre un enfoque con orquestador y un enfoque sin servidor.

Capacidad de administración: una aplicación sin servidor es fácil de administrar porque la plataforma administra todos los recursos de proceso. Un orquestador aunque abstrae algunos aspectos de la administración y la configuración de un clúster, no oculta por completo las máquinas virtuales subyacentes. Con un orquestador, tendrá que pensar en problemas, como el equilibrio de carga, uso de CPU y memoria y funciones de red.

Flexibilidad y control. Un orquestador le ofrece un gran control sobre la configuración y administración de los servicios y del clúster. Como contrapartida tiene una complejidad adicional. Con una arquitectura sin servidor, se renuncia a un cierto grado de control porque se extraen estos detalles.

Portabilidad. Todos los orquestadores enumerados aquí (Kubernetes, DC/OS, Docker Swarm y Service Fabric) se pueden ejecutar de forma local o en varias nubes públicas.

Integración de aplicaciones. Puede ser difícil compilar una aplicación compleja mediante una arquitectura sin servidor, debido a la necesidad de coordinar, implementar y administrar muchas funciones independientes pequeñas. Una opción en Azure consiste en usar Azure Logic Apps para coordinar un conjunto de Azure Functions. Para encontrar un ejemplo de este enfoque, consulte Creación de una función que se integre con Azure Logic Apps.

Costo. Con un orquestador, se paga por las máquinas virtuales que se ejecutan en el clúster. Con una aplicación sin servidor, solo se paga por el consumo real de los recursos de proceso. En ambos casos, debe tener en cuenta el costo de los servicios adicionales, como almacenamiento, bases de datos y servicios de mensajería.

Escalabilidad. Azure Functions se escala automáticamente para satisfacer la demanda en función del número de eventos de entrada. Con un orquestador, puede escalar horizontalmente aumentando el número de instancias de servicio que se ejecutan en el clúster. También puede escalar agregando máquinas virtuales adicionales al clúster.

Nuestra implementación de referencia, usa principalmente Kubernetes, pero hemos usado Azure Functions para un servicio: el servicio Delivery History. Azure Functions era una buena opción para este servicio en concreto porque es una carga de trabajo basada en eventos. Mediante el uso de un desencadenador de Event Hubs para invocar la función, el servicio necesitó una cantidad mínima de código. Además, el servicio Delivery History no forma parte del flujo de trabajo principal, por lo que ejecutarlo fuera del clúster Kubernetes no afecta a la latencia de un extremo a otro de las operaciones iniciadas por el usuario.

Pasos siguientes

Comunicación entre servicios