Una red de servicios es una capa de infraestructura de TI que controla la comunicación de servicio a servicio a través de una red para permitir que partes separadas de una aplicación se comuniquen entre sí. A menudo se usa como un enfoque elegante para ofrecer comunicaciones entre contenedores en una arquitectura nativa de la nube.
Pero si bien la optimización de las comunicaciones de datos entre aplicaciones en entornos híbridos en contenedores puede ayudar a dominar la complejidad e incluso el costo, esto no exige necesariamente una arquitectura de malla de servicios.
Steve Judd, arquitecto de soluciones en Venafi, proveedor de gestión de identidades de máquinas y consultor de Kubernetes, advierte que el uso de una red de servicios para separar la lógica de la aplicación del lado de la red no reducirá necesariamente los complejos dolores de cabeza de gestión de TI para todas las organizaciones. Pero proporciona algunos beneficios de seguridad.
Los contenedores de Kubernetes deben comunicarse entre sí a través de algún tipo de red. Pero tener una arquitectura de comunicaciones plana, donde cualquier contenedor puede “hablar” con cualquier otro contenedor en un clúster, es problemático, le dice a Computer Weekly.
“Por razones de seguridad, probablemente desee aislar algunas de esas cargas de trabajo, de modo que no tengan la libertad de hablar con lo que quieran”, agrega Judd. “Es posible que desee que diferentes contenedores puedan autenticarse de manera efectiva entre sí a través de TLS mutuo [transport layer security].”
Los actores malintencionados pueden apuntar a arquitecturas nativas de la nube, por lo que las consideraciones de seguridad y cumplimiento siguen siendo clave cuando se piensa en la optimización y administración de la red. Los directores de seguridad de la información (CISO) pueden requerir TLS mutuo. La red de servicios de forma predeterminada puede ayudar a administrar esos certificados de seguridad de forma autónoma.
Las principales opciones de malla de servicios, incluidos Linkerd o Istio, brindan portabilidad TLS mutua lista para usar, siendo Istio más un enfoque de “fregadero de cocina” que Linkerd, dice Judd.
Complejidad más o menos para algunos
Por ahora, es probable que las industrias y los sectores altamente regulados, como los bancos y otros proveedores de servicios financieros, sean los que más adopten las tecnologías de redes de servicios. Esto se debe a que una red de servicios ofrece una manera de cumplir con ciertos requisitos de cumplimiento normativo en un entorno de Kubernetes.
Judd explica: “No es necesario tocar las aplicaciones que se ejecutan en las aplicaciones de microservicios. No es necesario que les importe que tenga TLS mutuo y tráfico encriptado, porque eso se hace de forma externa a esos microservicios. Todo lo que saben es que pueden hablar con este tipo de puerto y la cosa del otro lado responde”.
Al capturar cada solicitud individual que va entre dos contenedores o cargas de trabajo en un clúster, una arquitectura de red de este tipo también ofrece una gran capacidad de observación.
“Puede hacer cosas como la trazabilidad, puede obtener métricas de rendimiento mucho mejores en términos de latencia, volumen y ancho de banda, etc., además de tipos de políticas de red para la gestión y el control del tráfico”, dice Judd.
Dicha trazabilidad ofrece a los departamentos de TI la capacidad de implementar patrones de “disyuntores” para una mayor resiliencia, por ejemplo, permitiendo un cambio a una carga de trabajo diferente si la primera no responde dentro de una cantidad específica de segundos.
Según Judd, una red de servicios también ofrece más opciones cuando se trata de actualizar microservicios.
Supongamos que una aplicación se compone de cinco microservicios de “versión uno”, con todo el tráfico de red yendo felizmente entre ellos. Si desea actualizar uno de esos microservicios a la versión dos sin comprometerse a enviar todo el tráfico en primera instancia, puede enviar un tramo de tráfico, de acuerdo con una métrica específica.
Junto con los despliegues graduales de microservicios, debido a que la malla de servicios “entiende” el tráfico de la red, puede agregar eso a la configuración de la malla durante la prueba.
“Eso se llama ‘liberación canario’, como el canario en una mina de carbón para ver si el canario muere”, dice Judd. “Simplemente diga, ‘Envíe el 5% de todo mi tráfico a este nuevo servicio’, y monitoréelo. Si parece que está funcionando, puedes decir: ‘Ahora envía el 50 %'”.
Pero, como señala Judd, la oferta más “fregadero de cocina” de Istio puede ser bastante complicada y requiere una gran cantidad de configuración y conocimientos relacionados para hacerlo bien. “Entonces tienes que pasar mucho tiempo resolviendo problemas, tal vez. Así que eso es una especie de desventaja”, dice.
Linkerd ofrece una malla mucho más delgada lista para usar, pero tiene integraciones con varias otras tecnologías. En implementaciones canary, se integrará con una herramienta diferente para proporcionar ese aspecto como parte de la malla, dice Judd.
Sin embargo, los requisitos se pueden cumplir de otra manera si no necesita optar específicamente por la red de servicio. Probablemente, solo alrededor del 15 % de todos los clústeres de Kubernetes en el mundo actualmente ejecutan una red de servicios. De ese 15%, una participación mayoritaria es malla de servicios relacionada con Istio, y el resto es principalmente Linkerd, dice Judd.
La subcontratación sigue siendo una opción
Cuando se trata de comenzar con una red de servicios, Kai Waehner, director de tecnología (CTO) de campo en Confluent, señala que los departamentos de TI tienen varias opciones: trabajar con Istio y Envoy, o Linkerd con Sidecar, o enfocarse en algún servicio capacidades de malla a través de la provisión de software como servicio (SaaS) “bajo el capó”.
“Nuestros clientes nos han dicho: ‘Solo queremos usar su servicio y deben optimizarlo internamente’. Los proveedores de software pueden hacer eso por usted, por lo que no tiene que preocuparse”, dice.
Un motor central puede administrar las optimizaciones de red y enrutamiento, logrando terminaciones internas, conexiones de limitación de velocidad y vinculando o enrutando el tráfico de clúster físico internamente por un costo total más bajo. Los proveedores como Confluent implementan internamente patrones de malla de servicio, señala Waehner.
Con conexiones de red optimizadas y transferencias a través de patrones de rendimiento de red, con la configuración correcta, se pueden reducir los costos. Ese es un caso de uso superior para las redes celulares, más allá de la “nube de gran contrato”, dice.
Manish Mangal, director global de 5G y negocios de servicios de red en Tech Mahindra, dice que la compañía utiliza una red de servicios al migrar las plataformas nativas de la nube de las redes de telecomunicaciones hacia 5G para comunicaciones optimizadas e implementaciones multinube.
“Recomendamos arquitecturas de malla de servicio como Istio a nuestros clientes para asegurar, conectar y monitorear servicios a escala y en todas las geografías con pocos o ningún cambio en el código de servicio”, dice Mangal.
Él dice que una red de servicios puede ayudar al rendimiento de la red en los sistemas distribuidos con enrutamiento de tráfico eficiente, equilibrio de carga, encriptación y seguridad del tráfico, observabilidad y monitoreo, resiliencia del servicio y descubrimiento del servicio, lo que ayuda a reducir el tiempo de inactividad y, potencialmente, también el costo.
“Las aplicaciones de contenedores y microservicios, y sus desarrolladores, pueden requerir un aislamiento lógico de la complejidad de los requisitos de seguridad y enrutamiento de la red. La abstracción proporcionada por una red de servicios permite una implementación rápida y flexible de microservicios independientes de la red física”.
Mangal dice que los puntos finales de malla de servicios se pueden ejecutar en cualquier arquitectura basada en contenedores y entre nubes, rastreando la latencia y las métricas de rendimiento para la entrega de servicios entre nubes. Pero como señala Mangal, la tecnología de malla de servicio aún se considera un enfoque relativamente nuevo para trabajar con aplicaciones distribuidas basadas en contenedores de una manera centrada en el software.
Cuando una organización decide que necesita una red de servicios, hay una variedad de proveedores que podrían aparecer en una lista corta. Hay alrededor de 12 marcas de mallas de servicio disponibles para administrar topologías de red cada vez más complicadas y heterogéneas de una manera más definida por software. Cada uno tendrá diferentes fortalezas y conjuntos de características. Por ejemplo, una organización puede decidir que tiene múltiples requisitos en torno a la seguridad y el cumplimiento, que a menudo no son compatibles con Kubernetes. Este requisito determina la elección de la plataforma de malla de servicio.
Luego está la cuestión del ajuste arquitectónico. Según Roman Spitzbart, vicepresidente de EMEA para ingeniería de soluciones en Dynatrace, una red de servicios encaja bien en una organización que utiliza una arquitectura empresarial altamente distribuida y basada en microservicios. Se necesita una comprensión clara de la arquitectura, lo que significa herramientas adicionales de observabilidad. Pero el uso de herramientas adicionales ofrece más oportunidades para que las cosas salgan mal.
Esta quizás sea una de las barreras que enfrentan las organizaciones más pequeñas al considerar una red de servicios. “Solo las grandes organizaciones están dispuestas a optar por este nivel de complejidad; los beneficios para ellos serán lo suficientemente grandes. Para las organizaciones pequeñas, no quiero decir que la malla de servicios vaya a ser un dolor de cabeza, pero va a ser muy compleja y no muy beneficiosa”, dice Spitzbart.