Blog
¡Simplifica tu arquitectura de Microservicios! Bienvenidos los Service Mesh
Índice
- Introducción
- Entonces… ¿Qué es un Service Mesh?
- ¿De qué está compuesto un Service Mesh?
- Plano de Datos (Data plane)
- Plano de Control (Control plane)
- Conclusiones
Introducción
En la actualidad se hace cada vez más común ver cómo organizaciones optan por arquitecturas basadas en microservicios para dotar a sus aplicaciones de todas las ventajas que pueden llegar a proporcionar este tipo de modelos (modularidad, escalabilidad, resiliencia, etc.).
Gracias a esta creciente demanda, es cada vez más amplia la gama de frameworks (Sprint Boot, Akka, MicroProfile (JavaEE), Node.js, Vert.X…) y herramientas (Docker, Docker Swarm, Kubernetes, Openshift…) que buscan resolver muchos de los obstáculos inherentes a la construcción y despliegue de este tipo de soluciones. Sin embargo, aún son muchos los retos que quedan por atender, sobretodo los relacionados con la implementación de mecanismos de comunicación entre los diversos componentes.
En este sentido, es muy habitual que se establezcan comunicaciones punto a punto, proveyendo a cada microservicio de la lógica adicional necesaria para controlar los aspectos más importantes, como el enrutamiento, la tolerancia a fallos, la latencia, el descubrimiento de servicios, la trazabilidad distribuida, la seguridad, etc. De este tipo de soluciones, el principal inconveniente es la complejidad y esfuerzo añadido a la propia solución de negocio a la que se le busca dar respuesta.
Sumado a las necesidades de las propias comunicaciones entre los servicios, existen algunos otros aspectos importantes que suelen ser muy complicados de solventar en términos de:
- Estandarización en las comunicaciones.
- Monitorización.
- Métricas.
- Trazabilidad distribuida de las peticiones.
- Seguridad.
- Despliegue.
- Aprovisionamiento de recursos (tanto de procesamiento como de almacenamiento).
El concepto de Service Mesh (o malla de Servicio) nace como un mecanismo para solucionar este conjunto de características y pretenden definir una tipología de patrones de arquitectura sobre la infraestructura en lugar de hacerlo sobre el propio código.
Cuando hablamos de Service Mesh no hablamos de una una nueva funcionalidad dentro del ecosistema de microservicios, sino más bien de la reubicación de algunas características existentes con el objetivo de simplificar la manera en que lo hemos venido haciendo.
Entonces… ¿Qué es un Service Mesh?
Un Service Mesh es una capa de infraestructura configurable para una arquitectura de microservicios. Hace que la comunicación entre instancias de servicio sea flexible, confiable y rápida. Un Mesh puede proporcionar la detección de servicios, equilibrio de carga, cifrado, autenticación y autorización, soporte para el patrón de circuit break y otras capacidades.
El Service Mesh se implementa, generalmente, al proporcionar una instancia de proxy, llamada sidecar, para cada instancia de servicio. Los sidecars manejan comunicaciones entre servicios, monitorización, inquietudes relacionadas con la seguridad, cualquier cosa que se pueda abstraer de los servicios individuales. De esta manera, los desarrolladores pueden manejar el desarrollo, el soporte y el mantenimiento del código de la aplicación en los servicios; y Operaciones puede mantener el Service Mesh y ejecutar la aplicación.
La responsabilidad principal del Service Mesh es entregar las solicitudes del servicio A al servicio B de una manera confiable, segura y oportuna. Desde el punto de vista funcional, esto es algo similar a la función de un ESB donde se interconectan sistemas heterogéneos para la comunicación de mensajes. La diferencia aquí es que no hay un componente centralizado sino una red distribuida de componentes.
Algunas de las funcionalidades que se esperan de una buena implementación de Service Mesh son:
- Soluciones básicas de disponibilidad tal como patrones de Circuit-breaking, reintentos y time-outs, gestión de errores, balanceo de carga y failover.
- Descubrimiento de servicios a través de un registro de servicio dedicado.
- Capacidades de enrutamiento de peticiones a versiones diferentes de servicios.
- Generación y almacenamiento de métricas de ratios de éxito y errores, latencias, nivel de servicio y trazabilidad distribuida.
- Seguridad a nivel de transporte (TLS) y gestión de claves.
- Mecanismos de autenticación/autorización.
- Soporte para despliegue de contenedores.
- Soporte a la comunicación entre servicios a través de distintos protocolos (HTTP/1.1, HTTP/2, gRPC, etc.).
¿De qué está compuesto un Service Mesh?
Para poder llevar a cabo toda la funcionalidad que pretende aportar un Service Mesh, éste implementa algunos de los patrones de diseño y de aplicaciones distribuidas ya conocidos pero en lugar de aplicarlos sobre el código, lo realiza sobre la propia infraestructura.
En tal sentido, en el patrón sidecar un servicio principal se ve ampliado mediante uno paralelo (como un sidecar unido a su motocicleta) sin acoplamiento e incluso a veces sin conocimiento de su existencia.
Plano de Datos
A muy alto nivel, el Plano de Datos son las instancias de los servicios del Service Mesh, sus proxies sidecar y las interacciones entre ellos. Sus funciones son:
- Descubrimiento de servicios (Service Discovery).
- Comprobación de disponibilidad (Health check).
- Enrutamiento y balanceo de carga: time-out, reintentos, circuit-breaker, fail-over.
- Securización y control de acceso (autenticación / autorización).
- Visibilidad: métricas, monitorización, logging y trazabilidad.
Modelo de comunicaciones basado en proxies sidecar.
Plano de Control
Dado que un Service Mesh está conformado por un conjunto de elementos ligeros, es muy lógico pensar en la posibilidad de implementar algún elemento centralizado o plano de control que permita gestionar estas instancias (o sidecars) para poder implementar políticas de control, recolección de métricas, monitorización, etc.
A pesar de que son los propios sidecars los que proporcionan las funcionalidades mencionadas anteriormente, es dentro del plano de control donde se realiza la configuración global de estas funcionalidades y quien permite configurar los sidecars para convertirlos en un sistema distribuido.
En un Service Mesh, el plano de control es el responsable de configurar la red de sidecars para dotar al mismo de las siguientes configuraciones:
- Enrutamiento.
- Despliegues.
- Descubrimiento de servicios.
- Balanceo de carga.
- Circuit-breaker, políticas de reintentos, time-outs.
Algunos ejemplos de implementaciones de Service Mesh
Un caso de uso común para una arquitectura basada en un Service Mesh es aquel en que se utilizan contenedores y microservicios para resolver problemas de desarrollo de aplicaciones muy exigentes. Los pioneros en este tipo de implantaciones de microservicios incluyen compañías como Lyft, Netflix y Twitter, que brindan servicios sólidos a millones de usuarios en todo el mundo, hora tras hora. Para necesidades de aplicaciones menos exigentes, es probable que las arquitecturas más simples sean suficientes.
Aunque son ya varias las compañías que han hecho públicas sus soluciones de Service Mesh (con mayor o menor grado de madurez), podríamos destacar las siguientes implementaciones:
Conclusiones
Las arquitecturas basadas en Service Mesh no siempre serán la respuesta a todos los problemas de desarrollo y despliegue de aplicaciones basadas en microservicios. Los arquitectos y desarrolladores tienen una gran cantidad de herramientas disponibles para necesidades específicas, por lo que pensar que siempre podemos utilizar un Service Mesh puede ser muy costoso.
Los elementos que se unen en una arquitectura de Service Mesh, como contenedores, Kubernetes y microservicios, pueden ser y son, utilizados de manera productiva en implementaciones que no son de servicio. Por ejemplo, Istio, que fue desarrollado como una alternativa para un arquitectura basada en Service Mesh, está diseñado para ser modular, por lo que los desarrolladores pueden elegir lo que necesitan de él. Con esto en mente, vale la pena desarrollar una comprensión sólida de los conceptos de un Service Mesh, incluso si no está seguro de si se implementará una aplicación de servicios.
En Autentia, proporcionamos soporte a desarrollo trabajando a diario con los equipos de arquitectura internos de nuestros clientes, definiendo arquitecturas orientadas a microservicios, ETL, nosql, arquitectura BELK, etc., ayudando a numerosas empresas a mejorar la escalabilidad y disponibilidad de sus proyectos. Te invito a que te informes sobre los servicios profesionales de Autentia y el soporte que podemos proporcionar a tu empresa.