La malla de servicios (Service Mesh) es una práctica de arquitectura para administrar y visualizar conjuntos de múltiples microservicios basados en contenedores.
¿Por qué es conveniente la malla de servicios 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, implementamos estos requerimientos 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.
Exploremos estos conceptos en mayor detalle.
¿Qué es una malla de servicios – Service Mesh?
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.
¿Cómo hace una malla de servicios 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 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, dirige el flujo de tráfico entre los proxies y el plano de control recolectando las métricas de rendimiento.
¿Cómo funciona una malla de servicio – Service Mesh?
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.
Principales ventajas de un 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 contendor 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
- Mayor complejidad: El uso de service mesh va a aumentar la complejidad general de la solución, al agregar componentes para coordinar la malla de servicios, en los planos de control y en cada Pod o cada servidor de acuerdo al esquema de la solución.
- Tecnología aún en sus inicios: plataformas como Istio, Envoy y Bouyant todavía están en sus primeros años de desarrollo, aunque ofrecen funcionalidades usadas en producción en diferentes empresas.
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.