[09/08/2019] Uno de los cambios que se están produciendo en TI, bajo el principio de la transformación digital, es el desglose de grandes aplicaciones monolíticas en microservicios (unidades de funcionalidades pequeñas y discretas) que se ejecutan en contenedores, paquetes de software que incluyen todo el código del servicio, y las dependencias que se pueden aislar y mover fácilmente de un servidor a otro.
Las arquitecturas en contenedores como éstas crecen fácilmente y se ejecutan también con facilidad en la nube, y los microservicios individuales pueden implementarse e iterarse rápidamente. Sin embargo, a medida que las aplicaciones se hacen más grandes y se ejecutan simultáneamente múltiples instancias del mismo servicio, la comunicación entre estos microservicios se vuelve cada vez más compleja. Una malla de servicios es una forma emergente de arquitectura que apunta a conectar dinámicamente estos microservicios, reduciendo la carga administrativa y de programación.
¿Qué es una malla de servicios?
En el sentido más amplio, una malla de servicios es, como lo describe Red Hat, "una forma de controlar cómo las diferentes partes de una aplicación comparten datos entre ellas”. Sin embargo, esta descripción podría abarcar muchas cosas diferentes. De hecho, suena muy parecido al middleware con el que la mayoría de los desarrolladores están familiarizados en las aplicaciones cliente-servidor.
Lo que hace que una malla de servicios sea única es que está diseñada para adaptarse a la naturaleza única de los ambientes de los microservicios distribuidos. En una aplicación a gran escala creada a partir de microservicios, puede haber varias instancias de cualquier servicio dado, ejecutándose en varios servidores locales o en la nube. Obviamente, todas estas partes móviles dificultan que los microservicios individuales encuentren los otros servicios con los que necesitan comunicarse. Automáticamente, una malla de servicios se encarga de descubrir y conectar los servicios de momento a momento, de esta manera los desarrolladores humanos y los microservicios individuales no tienen que hacerlo.
Piense en una malla de servicios como el equivalente a una red definida por software (SDN, por sus siglas en inglés) para el nivel 7 del modelo de red OSI. Al igual que una SDN, la malla crea una capa de abstracción para que los administradores de red no tengan que lidiar con las conexiones físicas de red, una malla de servicios separa la infraestructura subyacente de la aplicación, de la arquitectura abstracta con la que interactúa.
La idea de una malla de servicios surgió orgánicamente cuando los desarrolladores comenzaron a lidiar con los problemas que generaban las arquitecturas distribuidas realmente enormes. Linkerd, el primer proyecto en esta área, nació como una rama de un proyecto interno en Twitter. Istio, otra malla de servicios popular con gran respaldo corporativo se originó en Lyft. (Veremos con más detalle estos dos proyectos en un momento).
El balanceo de carga de la malla de servicios
Una de las funciones clave que proporciona una malla de servicios es el balanceo de carga. Por lo general, pensamos que el balanceo de carga es una función de la red, se desea evitar que un servidor o enlace de red se vea abrumado por el tráfico, por lo que se les asigna rutas a sus paquetes de acuerdo con esto. Las mallas de servicios hacen algo similar a nivel de la aplicación, como describe Twain Taylor, y entender esto le da a usted una buena idea de lo que queremos expresar cuando señalamos que una malla de servicios es como una red definida por software para la capa de aplicaciones.
En esencia, uno de los trabajos de la malla de servicios es hacer un seguimiento de cuáles instancias de los varios microservicios distribuidos en toda la infraestructura están "más saludables”. Puede encuestarlos para ver cómo se están desempeñando o hacer un seguimiento de qué instancias están respondiendo lentamente y, de esta manera, atender solicitudes y enviar solicitudes posteriores a otras instancias. La malla de servicios puede realizar un trabajo similar para las rutas de red, notando cuándo los mensajes tardan demasiado en llegar a su destino y otras rutas para compensar. Esta desaceleración puede deberse a problemas con el hardware subyacente, o simplemente a los servicios que están sobrecargados con solicitudes o trabajando en su capacidad de procesamiento. Lo importante es que la malla de servicios puede encontrar otra instancia del mismo servicio y asignarle una ruta, haciendo el uso más eficiente de la capacidad de la aplicación en general.
Malla de servicios vs Kubernetes
Si está familiarizado con las arquitecturas basadas en contenedores, puede que se esté preguntando dónde encaja en esta imagen Kubernetes, la popular plataforma de orquestación de contenedores de código abierto. Después de todo, ¿no es el punto central de Kubernetes administrar la forma en que sus contenedores se comunican entre sí? Como el equipo de Kublr señala en su blog corporativo, podría pensar en el "servicio” de Kubernetes como un recurso muy básico de malla de servicios, ya que proporciona el descubrimiento de servicios y el balanceo de solicitudes por turnos. Pero las mallas de servicios plenamente equipadas ofrecen muchas más funcionalidades, como la administración de políticas de seguridad y encriptación, la "interrupción de circuitos” para suspender las solicitudes a instancias de respuesta lenta, el balanceo de carga como describimos anteriormente, y mucho más.
Tenga en cuenta que la mayoría de las mallas de servicios realmente requieren de un sistema de orquestación como Kubernetes para estar listas. Las mallas de servicios ofrecen mayores funcionalidades, no un reemplazo.
Malla de servicios vs gateways de API
Cada microservicio proporcionará una interfaz de programación de aplicaciones (API, por sus siglas en inglés) que sirve como medio por el cual otros servicios se comunican con él. Esto plantea la cuestión de las diferencias entre una malla de servicios y otras formas más tradicionales de administración de APIs, como los gateways de APIs. Como IBM explica, un gateway de API se encuentra entre un grupo de microservicios y el mundo "exterior”, las solicitudes de servicio de routing según sean necesarias para que el solicitante no necesite saber que se trata de una aplicación basada en microservicios. Por otro lado, una malla de servicios se encarga de mediar solicitudes, "dentro” de la aplicación de microservicios, con los distintos componentes conscientes de su ambiente.
Otra forma concebirla, como Justin Warren escribe en Forbes, es que una malla de servicios es para el tráfico de este a oeste dentro de unclúster y un gateway de API es para el tráfico de norte a sur que entra y sale del clúster. Pero toda la idea de una malla de servicios es todavía temprana y está en proceso de cambio. Muchas mallas de servicios, incluidas Linkerd e Istio, ahora también ofrecen funcionalidades norte-sur.
La arquitectura de la malla de servicios
La idea de una malla de servicios surgió solo en los últimos dos años, y existen varios enfoques diferentes para resolver el problema de la "malla de servicios”, es decir, administrar las comunicaciones para los microservicios. Andrew Jenkins de Aspen Mesh identifica tres opciones posibles con respecto a dónde podría vivir la capa de comunicación creada por la malla de servicios:
- En una biblioteca en la que cada uno de sus microservicios importa.
- En un agente de nodo que proporciona servicios a todos los contenedores en un nodo particular.
- En un contenedor sidecar que se ejecuta junto con su contenedor de aplicaciones.
El patrón basado en sidecar es uno de los patrones de malla de servicios más populares que existen, tanto así que, en general, se ha convertido en sinónimo de malla de servicios. Si bien eso no es estrictamente preciso, el enfoque de sidecar ha recibido tanto impulso que ésta es la arquitectura que veremos con más detalle.
Sidecars en una malla de servicios
¿Qué significa decir que un contenedor sidecar "corre junto con” su contenedor de aplicación? Red Hat tiene una explicación bastante buena. En una malla de servicios, cada contenedor de microservicios de este tipo tiene otro contenedor proxy que le corresponde. Toda la lógica requerida para la comunicación de servicio a servicio se extrae del microservicio y se coloca en el sidecar.
Esto puede parecer complicado: después de todo ¡usted está duplicando la cantidad de contenedores en su aplicación! Pero también está usando un patrón de diseño que es clave para simplificar las aplicaciones distribuidas. Al colocar todo ese código de redes y comunicaciones en un contenedor separado, lo ha hecho parte de la infraestructura y ha liberado a los desarrolladores para que no lo implementen como parte de la aplicación.
En esencia, lo que queda es un microservicio que puede centrarse directamente en su lógica empresarial. El microservicio no necesita saber cómo comunicarse con todos los demás servicios en el ambiente salvaje y loco en el que operan. Solo necesita saber cómo comunicarse con el sidecar, que se encarga del resto.
Mallas de servicios: Linkerd, Envoy, Istio, Conduit
Entonces, ¿cuáles son las mallas de servicios disponibles para su uso? Bueno, no existen exactamente productos comerciales disponibles en el mercado. La mayoría de las mallas de servicios son proyectos de código abierto que requieren cierta implementación. Los grandes nombres son:
- Linkerd (pronunciado "linker-dee”): Lanzado en el 2016 y, por lo tanto, el más antiguo de estos productos, Linkerd, derivó de una biblioteca desarrollada en Twitter. Otro competidor de peso en este espacio, Conduit, se incorporó al proyecto Linkerd y forma la base de Linkerd 2.0.
- Envoy: Creado en Lyft, Envoy ocupa la parte del "plano de datos” de una malla de servicios. Para proporcionar una malla de servicios completa, se debe emparejar con un "plano de control”, como...
- Istio: Desarrollado en colaboración por Lyft, IBM y Google, Istio es un plan de control para servicios de proxy como Envoy. Si bien Istio y Envoy son un par predeterminado, cada uno puede emparejarse con otras plataformas.
- Conduit de HashiCorp introducido con Conduit 1.2, una función llamada Connect añadió encriptación y autorización de servicio basada en identidad al sistema distribuido de HashiCorp, destinada al descubrimiento y la configuración del servicio, convirtiéndolo en una malla de servicios completa.
¿Qué malla de servicios es adecuada para usted? Una comparación está más allá del alcance de este artículo, pero vale la pena señalar que todos los productos anteriores han sido probados en ambientes grandes y exigentes. Linkerd e Istio tienen los conjuntos de funciones más extensos, pero todos están evolucionando rápidamente. Es posible que desee ver el desglose de las funciones de Linkerd, Envoy e Istio, escrito por George Miranda (aunque debe tener en cuenta que su artículo se escribió antes de que Conduit y Linkerd unieran fuerzas).
También tenga en cuenta que este espacio es nuevo y que podrían surgir nuevos competidores en cualquier momento. En noviembre del 2018, por ejemplo, Amazon comenzó a ofrecer un preview público de una malla de servicios de AWS. Considerando la cantidad de departamentos que usan la nube pública de Amazon, la aplicación AWS App Mesh debería tener un gran impacto.
Josh Fruhlinger, InfoWorld (EE.UU.)