Service Mesh: arquitectura de microservicios

Actualizamos este artículo en 2022 para incluir algunos de los desarrollos más importantes de servicios y evaluar la situación actual frente a la adopción de esta práctica.

¿Qué es Service Mesh? 

La malla de servicios, Service Mesh, es una práctica de arquitectura para administrar y visualizar conjuntos de múltiples microservicios basados en contenedores. 

En términos generales, un service mesh puede ser considerado como una infraestructura de software dedicada a manejar la comunicación entre microservicios. Proporciona y permite aplicaciones basadas en contenedores y microservicios, los cuales se integran directamente desde el interior del clúster.

Un service mesh proporciona servicios de vigilancia, escalabilidad y alta disponibilidad, a través de una API de servicios, en lugar de obligar su implementación en cada microservicio. El beneficio está en reducir la complejidad operativa asociada con las aplicaciones modernas de microservicios. 

Plano de Datos (Data Plane)

Muchas implementaciones de Service Mesh usan un proxy-sidecar para interceptar y administrar todo el tráfico de entrada y salida a una instancia particular de servicio.

El plano de datos en una malla de servicios se refiere al proxy-sidecar que se implanta junto con cada instancia de servicio, para que este pueda comunicarse con los demás servicios del sistema.

El proxy-sidecar es el plano de datos como tal, siendo responsable de traducir, reenviar y observar condicionalmente cada paquete de red que fluye hacia y desde una instancia de servicio. Esto además del enrutamiento, seguridad, descubrimiento de servicios, observabilidad y balanceo de carga.

Plano de Control (Control Plane)

El plano de control proporciona la configuración global de las funcionalidades ejecutadas por todos los planos de datos existentes en el Service Mesh, convirtiendo a esta red de planos de datos en un sistema distribuido.

Se encarga de gestionar y monitorizar todas las instancias de los proxy-sidecar, sirviendo para implementar políticas de control, recolección de métricas, monitorización, etc.

Patrones de despliegue

Hay dos patrones de despliegue: 

• Basado en un proxy por host. Por cada host se despliega un proxy, ejecutándose en el mismo host múltiples instancias de servicios de la aplicación, todas ellas enrutando el tráfico a través de una misma instancia de proxy.

• Basado en proxy-sidecar: Se despliega un proxy-sidecar por cada instancia de cada servicio. Este modelo es muy útil para despliegues que utilizan contenedores o Kubernetes.

¿Cómo funciona Service Mesh?

Al tener arquitecturas de microservicios se buscan beneficios como la autonomía, la flexibilidad y la modularidad. Sin embargo, surge el reto de contenerizar un gran monolito en dónde se debe ofrecer visibilidad y gobernanza con un ecosistema cada vez más grande de pequeños servicios.

¿Cómo hace una malla de servicios, service mesh, para abstraer esta complejidad en cada microservicio? Para entenderlo, revisemos el patrón de arquitectura conocido como sidecar.

Con un patrón sidecar, se crea un pequeño contenedor especial que se ejecuta al lado de cada microservicio. El nombre viene de los sidecar, las pequeñas cápsulas o sillas que se integran al lado de las motocicletas. Sidecar no es el único patrón de arquitectura pues existen diferentes patrones de arquitectura de microservicios.

El contenedor sidecar funciona como proxy, e implementa las funcionalidades comunes como proxy, autenticación, monitoreo, etc., dejando los microservicios libres para enfocarse en su funcionalidad específica. Un controlador central (control plane) organiza las conexiones, y dirige el flujo de tráfico entre los proxies y el plano de control, recolectando las métricas de rendimiento.

Existen diferentes formas de implementar la malla de servicios o service mesh. 

Principalmente depende de dónde existe la funcionalidad compartida entre los microservicios:

• Proxy de servicio por nodo: Cada nodo en el clúster tiene su propio contenedor de servicios proxy.

• Proxy de servicio por aplicación: Cada aplicación tiene su propio servicio proxy y su acceso a instancias de la aplicación del mismo.

• Dispositivos discretos: Un conjunto de dispositivos discretos re-enrutan el tráfico de encadenamiento de servicio. Esto sucede a través de una configuración manual o con un conjunto de adaptadores y plugins necesarios para la automatización de servicios.

• Cada instancia de la aplicación proxy de servicio: Cada una de las instancias tiene su propio “sidecar” proxy.

¿Por qué es conveniente Service Mesh para la arquitectura de microservicios?

Los microservicios requieren un conjunto de funcionalidades comunes como autenticación, políticas de seguridad, protección contra intrusos y ataques de denegación de servicio (DDoS), balanceo de carga, enrutamiento, monitoreo y gestión de fallos.

En una aplicación monolítica estos requerimientos se implementan  una sola vez, pero en entornos con decenas o cientos de contenedores no es práctico repetirlo en cada uno. Si estas funcionalidades deben implementarse y repetirse en múltiples microservicios, tenemos la carga adicional de hacerlo en diferentes lenguajes de programación (si es el caso) y por diferentes equipos. 

De esta manera surge la necesidad de una arquitectura más efectiva. Una solución a este problema es crear una malla de servicios o Service Mesh para ofrecer servicios integrados dentro del clúster. Los diferentes niveles de servicios que se mantienen a través de los entornos y que contienen aplicaciones y microservicios pueden ser aprovechados según sea necesario.

¿Qué problemas resuelve Service Mesh?

Manejo de tráfico

Un buen manejo de tráfico incrementa el rendimiento y permite una mejor estrategia de implementación. Las reglas de Service Mesh para el enrutamiento del tráfico permiten controlar fácilmente el flujo de tráfico y las llamadas API entre los servicios.

La malla de servicios simplifica la configuración de las propiedades del nivel de servicio, tales como tiempos de espera, interruptores automáticos, solicitud de reintentos y división/cambio del tráfico, facilitando así la configuración de tareas importantes.

Observabilidad

A medida que los servicios se hacen más complejos, comprender su proceder y rendimiento se convierte en un reto. Service Mesh genera una telemetría detallada que permite obtener una visibilidad completa de todas las comunicaciones dentro de la red de servicios, tales como la incorporación de tasas de éxito, latencias, volumen de solicitudes para cada servicio, etc.

Con esta telemetría se puede observar el comportamiento del servicio monitoreado, permitiendo que los operadores solucionen posibles problemas. Además, se puede mantener y optimizar sus aplicaciones al comprender con mayor profundidad cómo interactúan los servicios. 

Capacidades de seguridad

Los microservicios tienen necesidades de seguridad específicas, tales como la protección contra ataques de terceros, controles de acceso flexibles, Transport Layer Security (TLS) mutuo y herramientas de auditoría.

Service Mesh ofrece una seguridad integral que brinda a los operadores la capacidad de abordar todos estos problemas. Además, brinda una identidad fuerte, cifrado TLS transparente y herramientas de autenticación, autorización y auditoría para proteger los servicios y datos.

¿Qué es Istio? - Istio Service Mesh

Istio es un producto de código abierto que implementa un Service Mesh, ofreciendo de forma sencilla y flexible la automatización de las funciones de red de una aplicación, independiente de cualquier lenguaje.

Gloo Mesh

Gloo Mesh es un plano de control y Service Mesh basado en Istio, que simplifica y unifica la configuración, el funcionamiento y la visibilidad de la conectividad de servicio a servicio dentro de aplicaciones distribuidas.

Gloo Edge

Es un controlador de entrada rico en funciones, nativo de Kubernetes, y es además un API Gateway de última generación. Resulta excepcional en:

• Enrutamiento a nivel de función.

• Soporte para aplicaciones heredadas y microservicios.

• Capacidades de descubrimiento.

• Estrecha integración con los principales proyectos de código abierto.

Gloo Edge está diseñado exclusivamente para admitir aplicaciones híbridas, en las que pueden coexistir múltiples arquitecturas, tecnologías, nubes y protocolos.

Gloo Modules

GraphQL: Es un lenguaje de consulta para las API, para efectuar consultas desde las interfaces de usuario. Es muy flexible y potente para extraer datos de los microservicios, permitiendo obtener datos declarativos, donde el cliente especifica qué datos necesita de una API y los servicios subyacentes.

Gloo Gateway: Ofrece un API Gateway nativo de Istio y la funcionalidad Kubernetes Ingress. Se puede implementar como puerta de enlace con una configuración en capas o virtual, según los requerimientos de la arquitectura de la red.

Gloo Portal: Es un portal para desarrolladores de API, nativo de Kubernetes y creado para ejecutarse con Istio de forma nativa. Reduce la complejidad y permite a los desarrolladores publicar, documentar, compartir, descubrir y usar APIs con controles enriquecidos, seguridad integral e información detallada de la configuración.

Istio vs Linkerd

Istio es complejo debido a que está diseñado para ejecutarse sobre un servidor proxy Envoy, cuya reputación es la de ser difícil de usar. Por otro lado, Linkerd se limita a manejar Kubernetes y entornos de contenedores, donde otros tipos de implementación no están integrados tan estrechamente como con Istio.

Esta complejidad brinda a Istio capacidades que no tiene Linkerd, como máquinas virtuales, contenedores y software heredado, además de controlar el tráfico desde un solo plano de control. Es una buena opción para empresas que ejecutan una infraestructura compleja, pero es demasiado para implementaciones más pequeñas basadas en Kubernetes.

Service Mesh, microservicios, middleware y API gateways

¿Servcice Mesh no hace lo mismo que hacen los microservicios?

Una arquitectura de microservicios permite realizar cambios en los servicios de una aplicación, sin volver a implementarlos por completo. Los microservicios se comunican entre sí, pudiendo fallar individualmente sin que se interrumpa toda la aplicación.

Lo que hace posible los microservicios es la comunicación de servicio a servicio. La lógica que rige esta comunicación puede codificarse en cada servicio sin un Service Mesh, pero a medida que la comunicación se va haciendo más compleja, el Service Mesh se vuelve más valioso. 

¿Cómo se diferencia Service Mesh del ESB / middleware?

Una gran diferencia es que Service Mesh se centra en la lógica operativa y no en la lógica comercial, mientras que ESB (Enterprise Service Bus) se basa en la lógica comercial, siendo esto lo que ocasionó su caída.

¿Cómo se diferencia Service Mesh de los API gateways?

Se diferencian en que los API gateways manejan todo lo referente a ingresos, pero no las cuestiones dentro del clúster. Además, a menudo se comportan con una cierta cantidad de lógica comercial, por ejemplo: “El usuario A solo puede realizar 25 solicitudes al día”.

Principales ventajas de Service Mesh

• Permite la posibilidad de que empresas pequeñas puedan crear funciones y arquitecturas altamente escalables.

• Acelera el desarrollo, prueba y despliegue de las aplicaciones.

• Las aplicaciones se actualizan de manera más rápida y eficiente.

• Una capa ágil de datos no agregados de proxies situados junto al contenedor clúster puede resultar muy útil y eficaz a la hora de la gestión de servicios de red.

• Mayor libertad en la creación de aplicaciones innovadoras con entornos basados en contenedores.

• Conjunto de servicios de infraestructura necesarios para toda aplicación: equilibrio de carga, gestión de tráfico, enrutamiento, vigilancia, control de la aplicación, características de configuración y seguridad, etc.

Principales desventajas de Service Mesh

Muchos de los inconvenientes iniciales de servicio o growing pains  han sido resueltos en este momento. Sin embargo, podemos tener en cuenta las siguientes consideraciones:

• Las instancias de tiempo de ejecución se incrementan mediante el uso de Service Mesh.

• Cada llamada de servicio debe ejecutarse primero a través del proxy-sidecar, agregando un paso adicional.

• Service Mesh no aborda la integración con otros servicios o sistemas, y el tipo de enrutamiento o el mapeo de transformación.

• Aunque se reduce y centraliza la complejidad de la administración de la red, no se elimina. Por tanto, alguien debe integrar el Service Mesh en los flujos de trabajo y administrar su configuración.

Es posible que no necesite una arquitectura de service mesh hasta que tenga una topología compleja en que una operación involucra varios microservicios que se llaman unos a otros. 

Recomendamos explorar técnicas como despliegues tipo canario (canary deployments), actualizaciones progresivas como rolling updates, monitoreo usando APM (application performance monitoring) y logueo o rastreo distribuido. Adicionalmente aprovechar las funciones de auto escalamiento y verificación de estabilidad (health check) de plataformas como Kubernetes y OpenShift.

¿Cuál es el futuro de Service Mesh? ¿Debería usar un Service Mesh en 2022?

El ritmo frenético en que las empresas han venido adoptando Service Mesh muestra pocas señales de que vaya a desacelerarse. Al igual que lo que ha sucedido con las tecnologías muy exitosas, el futuro de Service Mesh posiblemente será que pase a un segundo plano, donde se dé por sentado que tiene que estar presente, sin que se le preste demasiada atención.

El futuro de Service Mesh no es tanto en cómo está avanzando la tecnología como tal, sino más bien en los aspectos que desbloquea. La pregunta es qué tipo de cosas nuevas se pueden hacer luego de implementar Service Mesh, lo que en este caso abre muchas posibilidades.

Si su organización tiene interés en implementar estrategias de microservicios o contenedores de la mano de expertos, lo invitamos a contactarnos.