A Istio y más allá: la interfaz de malla de servicios de Azure

El desarrollo de aplicaciones modernas, primero en la nube, al menos en Azure, se ha vuelto casi dependiente de Kubernetes. Tecnologías como Virtual Kubelets, AKS (Azure Kubernetes Service) y Azure Service Fabric Mesh son clave para crear aplicaciones distribuidas escalables en Azure, utilizando contenedores para implementar y administrar microservicios.

Al observar las herramientas de Kubernetes de Azure, está claro que Microsoft está trabajando mucho en y alrededor de Cloud Native Computing Foundation, trabajando en todos los aspectos del marco de código abierto. No debería sorprendernos; Microsoft contrató a uno de los fundadores del proyecto Kubernetes y luego adquirió Deis, un importante proveedor. El equipo de Deis está detrás de una de las últimas contribuciones de Azure al ecosistema de Kubernetes, Service Mesh Interface (SMI).

Presentamos mallas de servicio

Quizás sea mejor explicar primero qué es una malla de servicios y por qué es importante para cualquier aplicación basada en Kubernetes.

Las arquitecturas de TI modernas tienen que ver con la abstracción. Con los servicios en la nube, ya no necesitamos pensar en el hardware subyacente. Si usamos IaaS, definimos máquinas virtuales para alojar nuestro código. Con PaaS estamos aún más lejos del hardware, utilizando los servicios y API que elegimos, eligiendo un nivel de rendimiento adecuado para nuestras aplicaciones y presupuestos. Con arquitecturas basadas en contenedores como Kubernetes, estamos en un punto entre los dos: al usar servicios como AKS podemos definir las máquinas virtuales subyacentes, que luego alojan nuestros pods de contenedores y escalan horizontalmente con cambios en la computación y la memoria (y ahora con KEDA (ajuste de escala automático impulsado por eventos basado en Kubernetes), al recibir eventos).

Ese es solo un aspecto de la abstracción. Los microservicios de Kubernetes son, en el fondo, apátridas; utilizan almacenamiento externo y se asientan sobre redes físicas o virtuales. El aspecto de red de la ejecución de Kubernetes es probablemente el más complicado: a medida que los servicios escalan y reducen, debe modificar su red para que coincida con los cambios en su aplicación. Pero, ¿cómo se mantienen los servicios conectados cuando el front-end y el back-end de una aplicación pueden escalar a diferentes velocidades?

Ahí es donde entran en juego las mallas de servicio. Son una nueva capa de abstracción, una que saca su código de la red subyacente al aprovechar las capacidades de una red moderna definida por software. Al actuar como un conjunto de proxies de red que se implementan con su código, una malla de servicios gestiona la comunicación de servicio a servicio sin que su código necesite conocer la red subyacente. Puede pensar en una malla de servicios como un plano de control automatizado para la red de su aplicación, administrando el plano de control subyacente a medida que Kubernetes escala su código hacia arriba y hacia abajo.

Una red definida por software para microservicios

Tal vez se considere mejor como una forma de implementar un equilibrio de carga escalable, inteligente y consciente de la latencia junto con el descubrimiento de servicios, una malla de servicios es básicamente un enrutador distribuido con reglas de enrutamiento dinámico que se administran como parte de una implementación de Kubernetes. Puede definir reglas adicionales; por ejemplo, mantener separados los sistemas de producción y de prueba, o manejar la implementación de una nueva versión y el cambio entre versiones de contenedores. Cada pod de una aplicación tiene una instancia de malla de servicios que se ejecuta como un sidecar, con detección de servicios y otros elementos con estado que se ejecutan fuera de sus servicios.

Con una malla de servicios, está impulsando la inteligencia a una nueva capa de red, por lo que no tiene que ponerla en sus microservicios. ¿Necesitas cifrar una conexión? Ese es un trabajo para su red de servicios. ¿Necesita autorizar clientes? Otra tarea de la malla de servicios.

Demasiadas mallas

Combinar una implementación de Kubernetes con una malla de servicios tiene mucho sentido. Sin embargo, hay un gran problema más: ¿Cuál usas? ¿Enviado? Istio? Linkerd? Aspen Mesh? Si elige uno, ¿qué impide que un equipo de desarrollo en otra parte de su negocio elija otro? Entonces, ¿qué sucede si su empresa decide estandarizar en una plataforma específica?

Ese es el problema que Microsoft se propone resolver con Service Mesh Interface. En lugar de que cada malla de servicios tenga su propio conjunto de API, la SMI es una forma de implementar API comunes que funcionan en diferentes mallas de servicios, administrando esa nueva red inteligente. En lugar de bloquear su código en una malla de servicio específica y sus API, puede escribir código que aborde los casos de uso más comunes a través de una API común. Si necesita cambiar una malla de servicios, si cambia de proveedor o encuentra uno que funcione mejor, no es necesario cambiar su código, siempre que la malla de servicios implemente la SMI. Todo lo que necesita hacer es cambiar sus sidecars de malla de servicio y volver a implementar su código.

SMI: API de malla de servicios comunes

Al trabajar con empresas del ecosistema de Kubernetes como Hashicorp y Buoyant, Microsoft ha estado definiendo las características clave para SMI que respaldan las solicitudes comunes de sus clientes. En la versión inicial, se ha centrado en tres áreas: política de tráfico, telemetría de tráfico y gestión del tráfico. Estas tres áreas están controladas por la mayoría de las mallas de servicio, y la intención es hacer de esta una especificación que sea fácil de implementar sin cambiar la aplicación subyacente.

Al hacer de SMI un conjunto de API estándar, no hay nada que impida que los proveedores de malla de servicios sigan ofreciendo sus propias API o características adicionales fuera de las especificadas. Alternativamente, no necesitan hacer ningún cambio; Los terceros pueden crear capas de traducción que se ubican entre las API de SMI y las API de servicios propietarios. Tampoco necesitará una nueva versión de Kubernetes, ya que las API SMI se implementan como servidores API de extensión y definiciones de recursos personalizadas. Puede continuar e instalarlos en cualquier clúster, utilizando las herramientas de administración existentes. Eso debería hacer que SMI sea fácil para Azure y otros servicios de Kubernetes alojados en la nube para integrarlos en sus servicios de Kubernetes administrados existentes.

Ya sea que desee utilizar Linkerd o Aspen Mesh o NSX Service Mesh de VMware, con SMI podrá elegir el que prefiera, mejorando la portabilidad del código y evitando el bloqueo de servicios específicos en la nube. Luego existe la oportunidad de cambiar las mallas de servicio sin afectar su código. Si una nueva malla de servicios ofrece un mejor rendimiento, todo lo que necesita hacer es cambiar su canal de compilación para usar la nueva malla y luego implementar una aplicación actualizada.

Es interesante ver a Microsoft liderar un proyecto como este, trabajando con una amplia muestra representativa de la comunidad de Kubernetes. Al adoptar un enfoque que no se centra explícitamente en la creación de una malla de servicios, Azure puede ofrecer diferentes mallas de servicios como parte de la configuración de AKS, lo que le permite elegir la herramienta que desee sin necesidad de cambiar ningún código.