Comunicando aplicaciones modernas a gran escala: Parte 1, Entendiendo Service Mesh.
En esta serie de artículos, te adentrarás en los aspectos más esenciales que debes comprender sobre Service Mesh. Desde los patrones de comunicación más utilizados hasta una exploración de su entendimiento, arquitectura, ecosistema y despliegue.
Parte 1, Entendiendo Service Mesh, abarca los conceptos fundamentales, los problemas que resuelve y sus casos de uso.
Empecemos
La evolución de los sistemas hacia arquitecturas distribuidas, como los microservicios, ha traído consigo una serie de beneficios extraordinarios, pero también retos importantes que deben resolverse. A medida que un sistema distribuido crece, los enfoques tradicionales para gestionar las comunicaciones entre aplicaciones pueden volverse complejos.
Aunque el auge de la malla de servicios está vinculada con la transición de los sistemas hacia los microservicios. En última instancia, su objetivo principal es proporcionar superpoderes a las comunicaciones, independientemente de la arquitectura. En un mundo donde desarrollamos aplicaciones que se conectan con servicios ofrecidos por otras aplicaciones, la importancia de tener comunicaciones confiables es más relevante que nunca. Seguramente, podemos estar de acuerdo en afirmar que una característica esencial en las aplicaciones modernas es el gran número de integraciones con otros sistemas.
Ahora, cuando nos preguntamos cómo se comunican las aplicaciones, encontramos dos formas principales: comunicación asíncrona y comunicación síncrona. La comunicación síncrona implica que una aplicación (A) envía una solicitud a otra aplicación (B), y mientras (B) retorna una respuesta, (A) espera a que esto ocurra. Esta comunicación tiene lugar a través de la red, utilizando comúnmente protocolos como HTTP, TCP o gRPC.
Siempre que leas o escuches el término Service Mesh, piensa en una solución para abordar los desafíos de la comunicación sincrónica entre aplicaciones.
Quiero entender Service Mesh
Si buscamos en internet, tal vez encontremos que es una capa lógica de infraestructura que se ubica entre las aplicaciones para gestionar las comunicaciones, ofreciendo características como descubrimiento de servicios, balanceo de carga, encriptación de datos, manejo de fallas, monitoreo, entre otros. Sin embargo, al ver la complejidad que presenta Service Mesh en un inicio, prefiero imaginarlo como una brújula del mundo digital. Que te dice por donde ir, a quiénes vas a encontrar del otro lado, te lleva de manera segura a tu destino y por si fuera poco, en el trayecto mide tu velocidad, cuenta tus pasos, calcula la distancia que recorres y al final del viaje, pregunta: “¿Llegaste bien?”. Extrapolando esta analogía puedo traducir las funcionalidades de la brújula en términos de ingeniería:
Te dice por dónde ir: Service Mesh puede integrarse con un Service Discovery para obtener un directorio con información sobre la ubicación de los servicios, su dirección IP, puerto, estado de salud, DNS, etc. Así es como Service Mesh indica a las aplicaciones por donde ir, de acuerdo al destino a donde quieren llegar.
A quién vas a encontrar del otro lado: Después de conocer qué información maneja Service Mesh, en un escenario donde existan múltiples instancias de una misma aplicación es importante enviar el tráfico equitativamente para evitar sobre cargar una instancia más que otras, inmediatamente piensas en un balanceador de carga, Y si, Service Mesh puede hacer ese trabajo por ti.
Te lleva de manera segura a tu destino: La capa de aplicación por donde transitan las comunicaciones finalmente están soportadas por dispositivos de red, y la red puede fallar, Service Mesh tiene la capacidad de reintentar una comunicación en caso de fallas en la red o cuando la aplicación destino devuelve un estado de error. Adicionalmente, Service Mesh puede encriptar las comunicaciones y verificar la autenticidad del origen y destino.
Mide tu velocidad, el número de pasos y la distancia recorrida: Uno de los retos más grande a la hora de operar una arquitectura de aplicaciones distribuidas es conocer qué está sucediendo, particularmente cuando hablamos de comunicaciones deseamos conocer cuál es la latencia, los estados de falla y éxito, y quien habla con quién. Al final se trata de tener observabilidad en nuestro sistema.
¿Qué problemas resuelve?
Un enfoque común para resolver los problemas de resiliencia, seguridad, balanceo de carga y observabilidad inherentes a las comunicaciones entre aplicaciones es incorporar directamente la lógica requerida en las aplicaciones, las famosas bibliotecas compartidas. Con una malla de servicios evitamos la necesidad de incorporar estas características en el código de las aplicaciones. En cambio, la lógica de comunicación se traslada a la capa de infraestructura, donde todas las aplicaciones pueden acceder a ella de manera compartida. Los ingenieros responsables del desarrollo del producto pueden concentrarse en escribir la lógica empresarial, mientras tienen la facilidad de configurar la lógica asociada a las comunicaciones en una capa de infraestructura previamente aprovisionada por los ingenieros de plataforma sin requerir escribir una lógica personalizada.
Casos de Uso
Existen una amplia gama de casos de uso en los que Service Mesh puede ayudar a las comunicaciones en un sistema. Sin embargo, solo voy a describir dos casos de uso para intentar enseñar brevemente el potencial de una malla de servicios.
Aplicaciones fuera de línea y latencia impredecible
Supongamos que un sistema que ofrece servicios de terceros cuenta con varias aplicaciones backend, alrededor de 100, distribuidas en regiones diferentes unas de otras, con latencias inconsistentes, y aplicaciones que dejan de estar en línea en horarios impredecibles.
Una malla de servicios abstrae estas complejidades para encargarse de gestionar automáticamente la latencia alta con mecanismos de tiempo de espera preconfigurados que activan acciones para tratar exitosamente las comunicaciones, y frente a la comunicación con aplicaciones fuera de línea puede realizar reintentos de conexión o procesos de gestión ante comunicaciones fallidas repetidamente.
Despliegues controlados y granulares
Supongamos que tiene un sistema para alquiler de autos que cuenta con 5 aplicaciones backend, un día surge una nueva idea en su equipo pero parece demasiado arriesgada como para realizar un despliegue completo. Entonces encuentra que la malla de servicios ofrece la capacidad de enrutar una porción pequeña del tráfico total de su sistema en una determinada aplicación backend donde los ingenieros planean lanzar la nueva idea.
La mayoría de mallas de servicios tiene la capacidad de realizar despliegues de tipo canario (Canary Deployments) que consisten en asignar un porcentaje pequeño del tráfico a la nueva versión de la aplicación, mientras la versión anterior recibe el porcentaje restante, ayudando a la mitigación de riesgos al identificar problemas potenciales en un cambio de software antes de que afecten a todos los usuarios. Por otra parte, fomenta el aprendizaje continuo al tener la posibilidad de recopilar datos y métricas en tiempo real sobre el comportamiento de la nueva versión para tomar decisiones informadas sobre si se debe avanzar con el despliegue completo.
Curiosidad: El nombre del tipo de despliegue “canario” tiene origen en las minas de carbón donde si el canario dejaba de cantar o moría debido a la falta de oxígeno o gases tóxicos, esto alertaba a los mineros de un peligro inminente.
¡Nos vemos en el próximo capítulo!
En la parte 2, patrones de infraestructura, vamos a explorar las soluciones ampliamente utilizadas en la industria para las comunicaciones síncronas entre aplicaciones.