Empresas no están listas para implicaciones de red de la arquitectura nativa de nube

La próxima iteración de computación de nube, Cloud 2.0, promete ofrecer una arquitectura de TI flexible donde las aplicaciones se construyen a partir de microservicios que se ejecutan en contenedores, todo orquestado a través de Kubernetes.

Pero los microservicios en contenedores necesitan un soporte completo de la red, y esto representa una sobrecarga masiva para DevOps, les advirtieron a los delegados que asistieron a la conferencia del Foro de Computación Nativa de la Nube (CNCF) en Copenhague.

En su presentación, Lew Tucker, CTO de computación de nube en Cisco, dijo: "Estamos reconsiderando las redes para microservicios. La computación distribuida no es muy fácil. Es complejo porque los microservicios necesitan comunicarse".

El desafío que enfrentan los usuarios de la tecnología de contenedores es que un contenedor que ejecuta un microservicio tiene una dirección IP de red, que necesita administración de red. La dirección IP se usa para permitir que otros contenedores se comuniquen con ella, con el fin de crear aplicaciones basadas en una arquitectura de microservicios.

Pero para soportar las redes, cada contenedor necesita proporcionar seguridad de red, firewalls, balanceo de carga, colas de mensajería y otros servicios de red esenciales. Abordar esta sobrecarga es la siguiente fase en la evolución del cómputo nativo de nube, según la CNCF.

Ed Warnicke, distinguido ingeniero de consultoría en Cisco Systems, dijo: "Las redes en Kubernetes está creciendo y algo tendrá que ceder porque no tienes suficientes ciclos de reloj de la CPU. Necesitamos una mejor forma de pensar acerca de la red”.

"Con Cloud 1.0, olvidamos que todas estas cosas eran un centro de costos. Lo que quiere de su red es accesibilidad y aislamiento. También quiere capacidad de servicio".

Daniel Berg, ingeniero distinguido en IBM Cloud, dijo: "Los componentes de red en una arquitectura en la nube son frágiles. La red es el problema no resuelto de la nube y el código abierto. Necesitamos que la red sea un ciudadano de primera clase de un sistema en la nube. He atacado el problema de la red: nuestras tablas de IP se apagaron y eso hizo caer los servidores de producción".

En una discusión del panel de usuarios sobre los desafíos de implementar y desplegar una arquitectura nativa de la nube, Sarah Wells, directora técnica de operaciones y confiabilidad en el Financial Times, advirtió que cuando una arquitectura de microservicio comienza a experimentar problemas, puede fallar rápidamente, lo que puede ser mucho más difícil de rastrear que la falla en un sistema monolítico.

"Operar un sistema de microservicios es algo totalmente diferente", dijo. "Necesita averiguar cómo [administrarlo] porque el tipo de fallas que obtiene son menos predecibles. Puede llenar fácilmente su InBox con alertas si continúa con un enfoque ingenuo monolítico [de supervisión]".

Esta es una situación que el Banco Monzo experimentó a comienzos de enero de este año. En una publicación que describe la interrupción, Wayne Tsai, un ingeniero de back-end en Monzo, dijo que había ocurrido debido a la sobrecarga de su sistema de mensajería asíncrona, NSQ. "Habíamos detenido accidentalmente el procesamiento de mensajes de todos los mensajes que estaban en cola para NSQ", dijo.

Cuando el servicio no se detuvo, los servicios de mensajería comenzaron a procesar los enormes retrasos y se saturaron de mensajes, dijo Tsai. "Distribuimos millones de mensajes en nuestros propios servicios, de hecho un ataque de denegación de servicio, y fue entonces cuando los problemas se agravaron. Algunos clientes experimentaron fallas al cargar la aplicación y una pequeña cantidad de pagos comenzó a fallar".