Ocho razones por las que el futuro del escalado de contenedores pasa por las mallas de servicios

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Los microservicios son excelentes para agilizar el desarrollo, pero la complejidad de estas arquitecturas reside en la comunicación entre servicios de la que dependen los microservicios.

En este momento, existen al menos tres opciones arquitectónicas diferentes para escalar microservicios en contenedores. Todas ellas se basan —como cualquier sistema de escalado— en un balanceador de carga basado en proxy. Cada una presenta sus propios desafíos. Varios de ellos se deben al simple hecho de que el escalado dentro de entornos de contenedores suele depender de las tablas IP y de su capacidad limitada para manejar cualquier elemento situado por encima de las capas de red tradicionales (es decir, IP y TCP).

Todos estos proxies ofrecen la misma funcionalidad básica: escalar los servicios distribuidos por todo el entorno de contenedores. Lo sorprendente es que los servicios son entidades efímeras. En realidad, no existen, salvo en los archivos de recursos (configuración) que los definen. El problema para las soluciones de escalado basadas en tablas IP es que estos servicios son entidades de capa 7 (HTTP) que, a menudo, actúan como «backend» de una única llamada a la API en lugar de hacerlo para una aplicación completa.

Las aplicaciones, tal como las conocemos, pueden parecer desde el lado del cliente una estructura única e integral. En realidad, están compuestas por numerosos microservicios diferentes (y distribuidos). Algunos de esos servicios son exclusivamente internos y están diseñados para que los utilicen otros servicios. Esto implica una gran cantidad de comunicación entre servicios dentro del entorno de contenedores.

En estos entornos se necesita enrutamiento L7 (HTTP), ya que todo son API sobre HTTP/HTTP2. También se necesita un enfoque coherente en materia de seguridad, autenticación y aplicación de políticas. Nada de eso se puede conseguir con un enfoque basado en tablas IP.

Como suele ocurrir, el código abierto viene al rescate. Han surgido varias mallas de servicios de código abierto para hacer frente a estos retos. Al igual que sucede con muchos proyectos de código abierto, estas mallas de servicios (como Istio) están siendo ampliadas por proyectos como Aspen Mesh con funcionalidades (y soporte) que ofrecen soluciones de nivel empresarial.

Estas iniciativas ampliadas se centran en resolver los ocho retos a los que se enfrentan las organizaciones al implementar microservicios en contenedores.

Estos son los ocho retos y cómo una malla de servicios puede superarlos:

1. Compilación – Este es uno de los retos para los que una malla de servicios tiene poco que ofrecer, aparte de integrar las políticas con las cadenas de herramientas de CI/CD y garantizar un modelo de configuración declarativo para que la malla de servicios pueda tratarse como infraestructura como código.
2. Pruebas e integración – Una malla de servicios puede resultar útil en este ámbito al garantizar la coherencia de las políticas entre los entornos de desarrollo, pruebas, producción, etc. Algunas organizaciones quieren eliminar por completo los despliegues por fases. Este enfoque funcionaba bien en el pasado, pero es uno de los obstáculos que introducen latencia en el proceso de despliegue. Estas organizaciones buscan una forma de desplegar servicios directamente en producción y utilizar mecanismos de direccionamiento del tráfico y reversión para hacer frente a los fallos.
3. Control de versiones – Una malla de servicios puede actuar como una puerta de enlace de API básica para enrutar el tráfico en función de variables como la versión de la API e incluso convertir versiones para facilitar los periodos de transición entre versiones de una API. No siempre es posible obligar a los clientes a actualizarse, especialmente en el caso de las aplicaciones de consumo, lo que implica recibir solicitudes para varias versiones. Una malla de servicios puede convertir las solicitudes destinadas a versiones anteriores de la API a la versión más reciente para reducir los costes y la carga que supone mantener varias versiones de una misma API.
4. Despliegue – Gracias a su capacidad para comunicarse con fluidez mediante HTTP, una malla de servicios es un entorno ideal para habilitar despliegues azul/verde, pruebas canary y el direccionamiento del tráfico.
5. Registro – El registro distribuido siempre plantea dificultades, que se agravan aún más en entornos donde la vida útil de las instancias varía considerablemente. Una malla de servicios ofrece una ubicación común y centralizada para implementar el registro, así como la posibilidad de realizar funciones como el seguimiento de solicitudes.
6. Monitorización – La monitorización es fundamental para la escalabilidad. Aunque las aplicaciones pueden implementar determinadas funciones (reintentos, disyuntores, etc.) para hacer frente al inevitable fallo de un servicio, esto supone una carga que la aplicación no debería tener que asumir. Una malla de servicios asume la responsabilidad de la comunicación entre servicios y proporciona un punto centralizado para la monitorización. El objetivo es centrarse en el MTTD y el MTTR en producción, porque operar en producción es difícil y los fallos son inevitables.
7. Depuración: cuanto más complejo es un sistema, más difícil resulta depurarlo. Una malla de servicios puede ayudar a analizar la causa raíz, proporcionar estadísticas y notificaciones previas a los fallos mediante análisis y telemetría, y poner los contenedores en cuarentena en lugar de eliminarlos para poder examinarlos a fondo. Esto resulta especialmente útil cuando el fallo se debe a fugas de memoria lentas.
8. Redes – Las redes siguen siendo fundamentales para los contenedores, quizá incluso más que en entornos menos complejos. El deseo de abstraer los servicios de dichas redes implica que hay muchos componentes que no conviene implementar en cada servicio: descubrimiento de servicios, gestión de SSL y certificados, disyuntores, reintentos, supervisión del estado, etc. El objetivo de los microservicios era «programar de forma local, programar a pequeña escala». La necesidad de incluir funciones relacionadas con las redes sobrecarga los microservicios y genera deuda arquitectónica y técnica adicional. Una malla de servicios asume esas funciones y proporciona la escalabilidad y la seguridad deseadas sin entorpecer el desarrollo.

La malla de servicios es una evolución apasionante que combina los principios modernos de la nube y los contenedores con unos sólidos fundamentos de escalabilidad. Cabe esperar que la malla de servicios gane terreno a medida que, a lo largo de 2018, sigan aumentando la adopción de contenedores y la demanda de escalabilidad y soporte de nivel empresarial.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie