carloscastilla - Fotolia

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

Las aplicaciones componibles pueden construirse a partir de la conexión de microservicios que se ejecutan en sus propios contenedores. Este enfoque en la nube requiere un nuevo enfoque para las redes.

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".

Malla de red para la computación en la nube

En un intento por simplificar las redes en una arquitectura de microservicios, la comunidad de redes CNCF busca desarrollar una red de malla de servicios compartidos de código abierto, donde se pueden gestionar las comunicaciones de contenedor a contenedor.

Brandon Philips, CTO de CoreOS en Red Hat, dijo que debido a que un contenedor tiene una dirección IP y puede proporcionar metadatos simples, es posible comenzar a crear reglas de red a su alrededor.

Berg, de IBM, dijo que la red debería ser parte de la estructura de cómo los desarrolladores trabajan con las aplicaciones, pero añadió: "No podemos esperar que todos los desarrolladores comprendan los problemas complejos de las redes".

Se necesita un enfoque estándar para conectarse y comunicarse con microservicios. La estandarización y la uniformidad simplifican la gestión. Pero escalar cada microservicio individualmente será un desafío, advirtió Tony Lock, analista distinguido de Freeform Dynamics.

Es por eso que las organizaciones con sistemas de microservicios a gran escala están construyendo y desplegando su arquitectura de una manera uniforme. Oliver Beattie, jefe de ingeniería en Monzo Bank, dijo: "La uniformidad es muy importante. Nos brinda una plataforma que es fácil de administrar. Si puedes centralizar algo, puedes administrarlo mucho mejor”.

"RPC [llamada a procedimiento remoto] es un ejemplo de esto: todos nuestros servicios se comunican entre sí de la misma manera y existen razones de peso para usar RPC, a menos que exista un caso de uso extraño que no encaje".

Se están llevando a cabo varios proyectos para abordar el desafío de las redes definidas por software en microservicios. FD.io (Fast data – Input/Output) es una colección de varios proyectos y bibliotecas que apunta a soportar servicios flexibles, programables y componibles que se ejecutan en una plataforma de hardware genérica. Mientras tanto, Istio es una plataforma abierta para conectar, administrar y asegurar microservicios.

El sitio de subastas suizo Ricardo.ch es una de las compañías que está probando Isto. Cedric Meury, jefe de ingeniería de plataforma en Ricardo.ch: "La desventaja de los microservicios es que los contratos entre ellos tienen que codificarse de alguna manera y si no tiene los mejores probadores y desarrolladores, un contrato se romperá y el front-end fallará. Esto aumenta exponencialmente cuantos más servicios tienes".

Meury dijo que cada desarrollador tiene que escribir el código del cliente, el código del servidor y el código web, junto con el soporte de una gran cantidad de otros protocolos de red, y todo este código repetitivo debe ponerse en una malla de servicios.

"Simplemente puede implementar una función y colocarla en la malla, que maneja todas las redes, midiendo el registro y el rastreo", dijo. "No hay forma de evitar tener una malla de servicio. Vamos en esta dirección con Istio para un par de nuestras API [interfaces de programación de aplicaciones]".

Muchas de las herramientas que se desarrollan para admitir redes nativas en la nube son muy nuevas, por lo que llevará tiempo que los productos maduren hasta un punto en que las organizaciones puedan usarlas en sistemas de producción para proporcionar la malla de red para sus arquitecturas de microservicios.

Investigue más sobre Computación en la nube

ComputerWeekly.com.br
Close