¿Qué es una malla de servicios?

Uno de los mayores retos a los que se enfrentan los desarrolladores de aplicaciones en el escenario empresarial actual es la escalabilidad. A medida que aumenta el número de usuarios de aplicación, a los ingenieros de DevOps (la metodología de desarrollo de software que acelera la entrega de aplicación mediante la automatización) les resulta más difícil supervisar el rendimiento del servicio. Una malla de servicios proporciona características clave que ayudan a supervisar y gestionar servicios críticos, como el registro, el seguimiento y el control del tráfico.

A medida que las aplicaciones se han vuelto fundamentales para la transformación digital, ha aumentado la importancia de las mallas de servicios. Hoy en día, son los facilitadores clave de algunas de las tecnologías de aplicaciones más avanzadas disponibles, incluidas las aplicaciones nativas de la nube, los microservicios y los contenedores.

Según Forbes, en 2022, el 70 % de las organizaciones ya ejecutaban una malla de servicios y el 19 % la estaba evaluando.¹

Los microservicios, también conocidos como arquitectura de microservicios, son un enfoque arquitectónico nativo de la nube en el que las aplicaciones se construyen a partir de muchos componentes o servicios independientes y más pequeños. Este enfoque permite a los desarrolladores actualizar el código más fácilmente y agregar o eliminar características y funcionalidades sin afectar al resto de la aplicación, lo que se traduce en una alta escalabilidad.

Las mallas de servicio son críticas para la arquitectura de microservicios. Proporcionan una capa de infraestructura altamente configurable en la que todos los servicios de la aplicación de microservicios pueden conectarse e intercambiar información. Además de una malla de servicios, la arquitectura de microservicios también se utiliza junto con la tecnología de contenedores y su plataforma más popular, Kubernetes.

La tecnología conocida como contenedores, junto con una de sus plataformas de orquestación de contenedores más populares, Kubernetes, se ha vuelto indispensable para la funcionalidad de la malla de servicios, ya que permite a los desarrolladores gestionar aplicaciones complejas basadas en microservicios.

Los contenedores son unidades ejecutables de software que empaquetan el código de la aplicación junto con sus bibliotecas y dependencias, lo que permite que se ejecute en cualquier entorno informático. Con la proliferación de contenedores en la arquitectura de aplicaciones moderna, la gestión de grandes grupos de contenedores se convirtió rápidamente en un reto.

Entra en escena Kubernetes (también conocido como k8s o Kube), una plataforma de orquestación de contenedores que se ha convertido en una de las soluciones de orquestación más populares disponibles actualmente en el mercado. Los clústeres de Kubernetes, conjuntos de nodos que representan máquinas físicas y máquinas virtuales (VM),se administran en el plano de control.

Otro aspecto importante de la funcionalidad de la malla de servicios es la forma en que se gestiona el acceso a los servicios dentro de un clúster específico, un proceso conocido como ingreso.

Las aplicaciones más populares de hoy en día exigen que se desplieguen muchas cargas de trabajo o tareas y procesos informáticos a la vez. Una arquitectura de microservicios permite a los desarrolladores crear cada aplicación como una colección de servicios pequeños e independientes que son más fáciles de administrar.

Sin embargo, para que el código de aplicación funcione, los microservicios deben comunicarse de forma rápida y precisa, y aquí es donde la arquitectura de malla de servicios es crítica. Las mallas de servicios están diseñadas de manera que brindan a los desarrolladores más control sobre la comunicación de servicio a servicio dentro de una aplicación.

En su nivel más fundamental, las mallas de servicios dependen de un tipo de comunicación conocida como comunicación basada en proxy para mejorar la gestión y el control de las aplicaciones basadas en microservicios. La característica de comunicación basada en proxy cuenta con servidores proxy (también conocidos como proxies) que funcionan como intermediarios entre el microservicio y la red de una organización, lo que permite enrutar el tráfico hacia y desde un servicio a través de proxies. Esta capacidad, conocida como comunicación de proxy de red, es crítica para mantener la gestión, la observabilidad y la seguridad de muchas aplicaciones.

Además de los proxies, una arquitectura de malla de servicios se basa en 2 componentes principales que le permiten funcionar: el plano de control y el plano de datos.

El plano de control es la parte de la red informática que controla cómo se enrutan los datos entre los usuarios y los dispositivos (también conocidos como nodos). Los planos de control siguen reglas o protocolos de enrutamiento que se basan en algoritmos que determinan la mejor ruta que deben seguir los datos a través de una red.

En una malla de servicios, el plano de control incluye proxies diseñados específicamente, llamados proxies sidecar, que abstraen ciertas funcionalidades, como la supervisión y la seguridad, para hacerlas más eficientes. Cuando un servicio necesita comunicarse con otro servicio en una malla de servicios, el proxy sidecar intercepta la solicitud y crea un canal seguro y encriptado para que viaje.

El plano de datos, también conocido como plano de reenvío, permite que los datos se envíen por la red a través de dispositivos como enrutadores y conmutadores. Los planos de datos utilizan proxies sidecar para gestionar la mensajería entre servicios y funcionalidades importantes, como la interrupción de circuitos y los reintentos de solicitudes. El plano de datos es también donde se llevan a cabo capacidades clave como el equilibrio de carga, el descubrimiento de servicios y el enrutamiento.

Además del plano de datos y el plano de control, el gateway de interfaces de protocolo de aplicaciones (API) es otra parte importante de la arquitectura de microservicios que está estrechamente relacionada con la funcionalidad de malla de servicio.

Las API son protocolos que permiten a las aplicaciones de software comunicarse e intercambiar datos. Las API gateways son herramientas que actúan como intermediarios entre los clientes API (por ejemplo, la popular API REST que ayuda a los desarrolladores a construir aplicaciones) y los servicios de backend ubicados en un servidor.

Las API gateways y las mallas de servicio son similares en el sentido de que ambos permiten un desarrollo de aplicación más eficiente. Sin embargo, mientras que un API gateway controla el acceso a las API, una malla de servicios conecta microservicios dentro de la aplicación. Las mallas de servicio y las API gateways se despliegan con frecuencia juntos para aumentar la flexibilidad y la observabilidad en un ecosistema de desarrollo de aplicaciones.

Las mallas de servicios y la arquitectura de microservicios que estas hacen posible aportan numerosos beneficios críticos a las organizaciones. A continuación, se enumeran algunos de los más comunes.

Una malla de servicios proporciona observabilidad integrada, una comprensión más profunda del estado de un sistema complejo, para toda una arquitectura de microservicios. Esto permite a los desarrolladores supervisar métricas importantes, como las dependencias, la latencia y las tasas de error, que son fundamentales para comprender cómo funciona una aplicación.

La observabilidad también ayuda con la resolución de problemas, la optimización del rendimiento, la telemetría (registro del comportamiento del sistema) y la depuración, ya que ofrece a los desarrolladores una visión completa y sin obstáculos del funcionamiento interno de un ecosistema de microservicios.

Para que las aplicaciones funcionen correctamente, los desarrolladores y administradores de aplicación deben controlar cómo los servicios se comunican entre sí dentro de la aplicación. Una malla de servicios aumenta las capacidades de gobernanza para las organizaciones que despliegan arquitecturas de microservicios, por ejemplo, la forma en que los equipos aplican los requisitos de seguridad y cumplimiento en sectores fuertemente regulados.

Además, las mallas de servicio proporcionan capas de infraestructura dedicadas específicamente para manejar las demandas de comunicación de servicio a servicio con aplicaciones distribuidas, que se ejecutan en más de una computadora conectada a la vez.

Las mallas de servicio ayudan a garantizar la comunicación segura entre los servicios a través de características como el cifrado y la autenticación Mutual Transport Layer Security (MTLs). La autenticación mTLS ayuda a garantizar que el tráfico en una aplicación sea seguro y confiable en ambas direcciones entre el cliente y el servidor.

mTLS también proporciona confidencialidad de datos al cifrar la información que se envía a través de la comunicación de servicio a servicio. Permite a los administradores aplicar políticas de autorización, como el acceso a endpoint específicos, un proceso conocido como seguridad endpoint.

Las mallas de servicios tienen una capacidad conocida como descubrimiento automático de servicios que ayuda a reducir la carga de trabajo que supone gestionar los endpoints de los servicios, es decir, la ubicación en la malla de servicios desde la que se puede acceder a un microservicio específico. Un registro de servicios permite que los servicios se encuentren y se comuniquen entre sí automáticamente, independientemente de dónde se encuentren, lo que permite a los desarrolladores desplegar nuevos servicios de forma rápida y sencilla.

El equilibrio de carga, es decir, la distribución del tráfico de red entre varios servidores para optimizar el rendimiento de las aplicaciones, es una capacidad clave de las mallas de servicios. Mediante el uso de algoritmos, la malla de servicios ayuda a equilibrar las cargas de trabajo entre los nodos, optimizar los recursos informáticos y, en general, garantizar la alta disponibilidad de una aplicación.

Las mallas de servicios proporcionan características avanzadas de gestión y división del tráfico para ayudar a optimizar el flujo de información y recursos a través de una red. Aunque tanto la gestión del tráfico como la división del tráfico se utilizan para controlar el flujo de información en una red, hay una diferencia importante que vale la pena destacar. La gestión del tráfico se centra en cambios sistémicos a largo plazo en la infraestructura para mejorar el flujo de información, mientras que la división del tráfico implica la distribución del tráfico en función del peso entre los backends o las versiones del servicio.

Las mallas de servicio proporcionan un control detallado y altamente específico sobre el enrutamiento y el comportamiento del tráfico, lo que permite transiciones más fluidas cuando una aplicación se actualiza a una versión de software más nueva. Por ejemplo, en la muy popular implementación canary, una nueva versión de una aplicación solo se lanza a un pequeño grupo de usuarios para probar sus características y rendimiento antes de ponerla a disposición de todos los demás.

El mercado global de proveedores de malla de servicios ya es sólido y está creciendo rápidamente. Según una encuesta reciente, se valoró en 0.22 mil millones de dólares en 2023 y se prevé que crezca a 5.05 mil millones de dólares en 2032, una tasa de crecimiento anual compuesta (CAGR) del 41.3 %.²

En una industria que crece a un ritmo tan rápido, seleccionar la solución de malla de servicios adecuada puede ser todo un reto. Algunos factores clave a considerar incluyen el costo, la facilidad de implementación, la compatibilidad con las tecnologías existentes, la seguridad, el rendimiento y el soporte.

Estas son 5 de las soluciones de malla de servicios más populares disponibles y una breve descripción de lo que las hace únicas.

La malla de servicio más popular disponible es Istio. Su amplio conjunto de características lo hace altamente adaptable y adecuado para cargas de trabajo a nivel empresarial. Istio es conocido por sus avanzadas capacidades de gestión del tráfico, sus características de seguridad y su extensibilidad, que se ve reforzada por su amplio ecosistema de colaboradores.

Al igual que otras ofertas de malla de servicios, Istio es un proyecto de código abierto, lo que significa que fue desarrollado y mantenido a través de la colaboración abierta y puesto a disposición de cualquier persona para su uso. Funciona bien con Kubernetes y muchas otras tecnologías adyacentes a la malla de servicios.

Más ligera y sencilla que Istio, Linkerd es una solución de malla de servicios simple que mejora el rendimiento mientras mantiene una baja latencia. Linkerd tiene todas las funcionalidades básicas que las empresas esperan de una malla de servicios, incluido el equilibrio de carga, el descubrimiento de servicios, el cifrado y más. Al igual que Istio, Linkerd también es de código abierto.  

NGINX es más completa que la mayoría de las otras mallas de servicios. Funciona tanto como servidor web como proxy inverso, lo que significa que puede ofrecer una gama más amplia de protocolos que otras mallas de servicios. NGINX se diseñó para obtener el máximo rendimiento y estabilidad, y es utilizado por muchos sitios web de alto tráfico. Al igual que Linkerd, Istio y otras soluciones de malla de servicios, es de código abierto.

Creado por la popular empresa de infraestructura basada en la nube HashiCorp, Consul es una malla de servicio multinube que ofrece muchas de las mismas características que otras mallas de servicio populares. Consul es una de las soluciones de malla de servicios más flexibles disponibles y se puede utilizar en muchos sistemas operativos (SO) diferentes, incluidos Windows, Linux, macOS, FreeBSD y Solaris. Consul también es de código abierto y es mejor conocido por su popular complemento Prometheus que mejora las capacidades de monitoreo.

Diseñada específicamente para su uso con despliegues en la nube de Amazon Web Services (AWS), la malla de aplicaciones de AWS es una malla de servicios con muchas de las mismas características que Linkerd, Istio y otras, incluida la seguridad mejorada, la gestión del tráfico y la observabilidad. Sin embargo, AWS no es flexible y solo se considera una buena opción para organizaciones que ya están integradas en la arquitectura de AWS.