¿Cómo nos ayudan las mallas de servicio (services mesh)?

Continuamos con la serie de post dedicada a las mallas/mesh con un nuevo artículo. Ya os contamos qué son las mallas/mesh, cuáles son sus estructuras, topologías y arquitecturas que forman los sistemas y aplicaciones. También hemos repasado los principales puntos de la arquitectura de microservicios y el papel de la estructura de mallas. Hemos visto los trade-offs en la arquitectura de microservicios, sus beneficios y peajes o cómo se comunican y coordinan.

En este nuevo post nos centramos en las mallas de servicio (services mash): qué son, sus características, su arquitectura y cómo nos ayudan.

Pero, ¿por qué las mallas de servicios?

Casi todas las empresas con una arquitectura orientada a servicios de tamaño moderado se enfrentan a los mismos problemas:

• Una arquitectura compuesta por una variedad de lenguajes.
• Servicios que ejecutan implementaciones de una biblioteca RPC, incluidas implementaciones parciales o cero de limitación de velocidad, interrupción de circuitos, tiempos de espera, reintentos, etc.
• Implementaciones diferentes o parciales de métricas, registro y seguimiento tanto en servicios propios como en componentes de infraestructura como Elastic Load Balancers.
• El deseo de pasar a la Arquitectura Orientada a Servicios por los beneficios de escalabilidad, pero sabiendo que puede haber caos para los desarrolladores de aplicaciones en su lucha por dar sentido a un sustrato de red inherentemente poco confiable.

Las mallas de servicios permiten resolver algunos problemas básicos de las infraestructuras de microservicios relacionadas con funcionalidades transversales de soporte e infraestructura.

Características de las mallas de servicios

Una malla de servicios es un componente de infraestructura dedicado que facilita la observación, el control y la seguridad de la comunicación entre servicios hasta ahora sobre todo en el patrón de arquitectura Service-Oriented. A diferencia de los enfoques anteriores, como los Buses de Servicios Empresariales (ESB) o las Pasarelas de API, una malla de servicios abarca la naturaleza distribuida de las aplicaciones de microservicios y solo se centra en la red en lugar de las funciones de negocio. Se centra en la comunicación síncrona entre servicios basada en protocolos síncronos como REST o gRPC (aquí te contamos qué es gRPC y cómo funciona).

Funcionalidades

Algunas de las funcionalidades que nos facilitan la malla de servicios son:

1. Monitorización

Un sistema de microservicios debe incluir una infraestructura de monitorización que recoja la información de todos los microservicios y la haga accesible. Esto es necesario para hacer un seguimiento de las métricas para el enorme número de microservicios distribuidos. Se pueden implementar alarmas y análisis posteriores basados en estas métricas.

Los proxies en el plano de datos pueden medir información básica sobre el tráfico de red, como las latencias o el rendimiento. Sin embargo, también es posible obtener más información del tráfico de red. La malla de servicios necesita entender el protocolo e interpretarlo. Por ejemplo, HTTP tiene algunos códigos de estado definidos que permiten a la malla de servicios determinar si una solicitud se ha realizado con éxito o no. De este modo, la malla de servicio también puede medir las tasas de error y similares.

Las métricas proporcionadas por una malla de servicios podrían ser suficientes para gestionar un sistema de microservicios. Sin embargo, para un análisis de la causa raíz, podrían ser útiles las métricas adicionales del interior de los microservicios.

Los datos de invocaciones de servicio permiten realizar grafos de dependencia que ayudan en tareas de comprensión y debugging de la aplicación.

2. Logging

El logging es otra tecnología importante para obtener más información sobre un sistema. Una malla de servicios recoge información sobre la comunicación en red. También puede escribir esa información en un archivo de logging. Los registros de acceso que contienen entradas para cada acceso HTTP son una importante fuente de información para evaluar el éxito de los sitios web. Por lo tanto, un registro que solo contenga información sobre el tráfico de la red podría ser útil para la evolución y mantenimiento de las aplicaciones.

3. Resiliencia

La resiliencia significa que los microservicios individuales siguen funcionando incluso si otros microservicios fallan. Si un microservicio llama a otro microservicio y el microservicio llamado falla, esto tendrá un impacto, y posteriormente no sería necesario llamar al microservicio en absoluto hasta que estuviera otra vez operativo.

Por lo tanto, el microservicio que llama se comportará de manera diferente y podría no ser capaz de responder con éxito a cada solicitud, el microservicio debe seguir respondiendo. Una solicitud no debe bloquearse porque entonces otros microservicios podrían bloquearse y podría producirse una cascada de bloqueos y tener recursos consumidos pudiendo producirse un efecto bola de nieve hasta bloquear el sistema.

También los retrasos en la comunicación de la red podrían provocar estos problemas.

Existen diferentes formas de tratar el intento fallido de comunicación entre servicios:

• Circuit Breaker: los circuit breakers en los sistemas protegen una parte del sistema cortando parte del tráfico. Como las mallas de servicios añaden proxies a la comunicación entre los microservicios, los circuit breakers pueden añadirse sin cambiar el código.
• Reintentos: los reintentos repiten las peticiones fallidas. Son una forma obvia de aumentar la resiliencia: Si el fallo es transitorio, el reintento puede hacer que la petición tenga éxito. Sin embargo, los reintentos también aumentan el número de peticiones. Por lo tanto, el microservicio llamado tendrá una mayor carga y podría volverse inestable. Para resolver este problema se puede utilizar un circuit breaker.
• Timeout: los timeouts aseguran que el microservicio llamado no se bloquee durante demasiado tiempo. De lo contrario, si todos los hilos están bloqueados, el microservicio que realiza las llamadas podría no ser capaz de aceptar más peticiones. Por lo tanto, un timeout no hace más probable que una solicitud tenga éxito, sino que hace que la solicitud falle más rápido para que se bloqueen menos recursos.

4. Routing

Cualquier sistema de microservicios necesita alguna forma de enrutar las peticiones entre los microservicios y enrutar una petición desde el exterior al microservicio correcto. La implementación de estas características puede ser muy sencilla. Un proxy inverso puede ser suficiente para enrutar las solicitudes desde el exterior a los microservicios correctos.

Sin embargo, también son útiles las capacidades de enrutamiento para diferentes opciones de deployment que se pueden plantear:

• Canary deployment: primero se despliega una instancia de la nueva versión de un microservicio mientras todavía hay algunas instancias de la versión antigua. Paso a paso, se enruta más y más tráfico a la nueva versión. Al mismo tiempo, la nueva versión se monitoriza. Por lo tanto, si hay un problema con la nueva versión, se hará evidente, mientras todavía hay algunas instancias de la versión antigua y, en consecuencia, es fácil revertirlo. El enrutamiento avanzado apoya este proceso dividiendo el tráfico entre las dos versiones. Esto puede hacerse de forma aleatoria o según segmentos específicos como dispositivos o regiones geográficas.
• Otra forma de mitigar el riesgo de un despliegue es la duplicación. En este caso, la versión nueva y la antigua de un microservicio se ejecutan en paralelo. Ambas reciben el tráfico y responden a él. Es posible observar en detalle los diferentes comportamientos y determinar si la nueva versión funciona correctamente. Istio descarta automáticamente las respuestas del nuevo servicio. En ese caso, el riesgo de desplegar una nueva versión es esencialmente inexistente.
• Las pruebas A/B permiten a diferentes usuarios acceder a distintas versiones de un microservicio. Una vez más, el enrutamiento aleatorio de solicitudes o el enrutamiento de solicitudes para segmentos específicos de clientes es un requisito previo para este enfoque. Es bastante fácil implementar estas características una vez que los proxies de la malla de servicios están en su lugar. La única diferencia podría ser que no solo hay que gestionar el tráfico entre microservicios, sino también el tráfico desde el exterior.

5. Seguridad

Es posible cifrar el tráfico de red entre los proxies. Sin embargo, sigue existiendo el tráfico de red entre el proxy y el microservicio. Normalmente, el proxy y el microservicio se ejecutan en la misma máquina. Así que, aunque el tráfico pueda parecer tráfico de red, en realidad circula dentro de la máquina donde se ejecuta y no por una red real. Por lo tanto, las mallas de servicios pueden implementar el cifrado y la confidencialidad de forma transparente.

6. Mejora de los Legacies

Las mallas de servicios son muy útiles para las arquitecturas de microservicios porque resuelven muchos de los retos de los sistemas distribuidos. La arquitectura de microservicios existe desde hace años y su popularidad sigue creciendo. Sin embargo, muchos equipos han experimentado que desmontar su aplicación monolítica puede llevar mucho tiempo. Una malla de servicios puede añadir funciones de supervisión, enrutamiento, resistencia y seguridad a las partes heredadas de la aplicación y facilitar la integración de aplicaciones heredadas e híbridas en arquitecturas modernas.

Retos

Aunque las mallas de servicios tienen muchas ventajas, también añaden algunos retos. Por ejemplo, añaden proxies a la comunicación. Esto aumenta la latencia de la comunicación en la red, ya que la comunicación pasa por más saltos. En algunos casos, la latencia es muy importante. Por ejemplo, para las aplicaciones de comercio electrónico, una latencia ligeramente superior puede afectar a los ingresos.

Por ello, es importante que la latencia adicional de los proxies sea lo más pequeña posible. Es posible recopilar datos sobre las solicitudes en el proxy y enviarlos posteriormente a la infraestructura de malla de servicios. De este modo, el envío de la información no aumenta aún más la latencia.

Por supuesto, la propia malla de servicios necesita ejecutarse. Esto consumirá memoria y CPU. Sin embargo, el hardware es cada vez más barato y añadir algunos recursos de hardware para mejorar la fiabilidad de un sistema podría ser aceptable.

Arquitectura de la malla de servicios

Una malla de servicios se compone de dos capas, el plano de datos y el plano de control.

El plano de datos

Consiste en un número de proxies de servicio, cada uno desplegado junto a cada instancia de microservicio. Esto se denomina patrón sidecar: Las capacidades que cada servicio necesita se extraen en un contenedor adicional (el sidecar) que se coloca junto a cada instancia de servicio. Hasta ahora, los casos típicos de uso de un sidecar han sido la monitorización básica y el cifrado de las conexiones de red. Por lo tanto, se desplegó un proxy de servicio como sidecar que intercepta todo el tráfico de red. La configuración de estos contenedores de sidecar de proxy de servicio y cualquier actualización de los mismos tenía que realizarse manualmente.

El plano de control

En una malla de servicios, los proxies de servicios, que constituyen el plano de datos, son configurados automáticamente por la segunda capa de una malla de servicios. Cualquier cambio en el comportamiento de la malla de servicios configurado por el desarrollador se aplica al plano de control y se distribuye automáticamente a los proxies de servicio. Como se muestra en la anterior figura, el plano de control también procesa los datos de telemetría que recogen los proxies de servicio.

Interfaz de malla de servicios

Existen varias implementaciones de malla de servicios, cada una de las cuales introduce diferentes conceptos y API. Mientras tanto, una malla de servicios también ha resultado ser una base adecuada para herramientas más avanzadas.

La diversidad de implementaciones de mallas de servicios obliga a los desarrolladores y usuarios de herramientas a vincular su software a una malla de servicios específica. Esto llevó a Microsoft, HashiCorp, Buoyant y Solo.io a crear la interfaz de malla de servicios SMI (Service Mesh Interface), una especificación de la API para las características de la malla de servicios. Los usuarios y las herramientas que se vinculan a SMI pueden utilizar las características de la malla de servicios independientemente de la implementación. Existen adaptadores que implementan una parte de SMI para las tres principales mallas de servicios Linkerd, Istio y Consul.

Conclusión

Las mallas de servicios se basan en una idea bastante sencilla: añadir proxies a la comunicación entre microservicios y añadir una infraestructura para configurar el proxy y evaluar los datos que envían los proxies (esta idea es bastante potente). Proporciona una monitorización básica, seguridad, análisis de las dependencias y resiliencia. No es necesario cambiar ningún código para disfrutar de estos beneficios.

Sin embargo, para el seguimiento de los microservicios tienen que enviar los IDs únicos para cada llamada. Así que en ese caso se necesitan algunos cambios en el código. Las mallas de servicios solo pueden proporcionar un registro básico para el tráfico de red. Eso puede ser de poco valor. Y, por supuesto, la infraestructura adicional tiene un coste: la latencia aumenta y la infraestructura adicional también consume memoria y CPU.

Sin embargo, en general, las mallas de servicios resuelven desafíos que son bastante importantes para los sistemas de microservicios y, por lo tanto, son un buen complemento a una arquitectura basada en microservicios.