Redes en la era de los contenedores
En los últimos años, a medida que la virtualización y ahora la contenerización han aumentado la densidad de aplicaciones en cualquier pieza de hardware, nos hemos obsesionado con el desafío de gestionar el tráfico de este a oeste en lugar del tráfico de norte a sur.
Para aquellos que aún tienen algunos problemas con los patrones de tráfico de su centro de datos, hagamos un resumen: Norte-Sur es de usuario a aplicación o de cliente a servidor o dentro y fuera del centro de datos. Este-oeste es de servidor a servidor, de aplicación a aplicación, de servicio a servicio o simplemente dentro del centro de datos.
Los patrones de tráfico de norte a sur se ven afectados por el aumento de usuarios, aplicaciones y cosas. Cuanto más conexiones de usuario a aplicación se requieran, más tráfico de norte a sur verá. El tráfico de este a oeste se ve afectado por las arquitecturas de aplicação y la tecnología de infraestructura. Al combinar tecnologías como la virtualización y los contenedores con arquitecturas emergentes como los microservicios, se obtiene un aumento exponencial en la cantidad de “aplicaciones” o “servicios” que deben comunicarse entre sí en el centro de datos.
Básicamente , cuanto más distribuida sea la arquitectura de una aplicação y su infraestructura, más tráfico de este a oeste habrá.
Este aumento se ve agravado por la tendencia a “adaptar el tamaño adecuado” de las aplicaciones. En lugar de basar la planificación de la capacidad en proyecciones de crecimiento, la capacidad se basa en lo que se necesita ahora, más un poco más. Gracias a tecnologías maduras como el escalamiento automático, podemos usar los recursos de manera más eficiente, dejando menos recursos computacionales y de red inactivos, consumiendo presupuesto sin producir valor proporcional . Este es, por cierto, uno de los beneficios de la nube privada: la capacidad de aprovechar mejor los recursos que de otro modo permanecerían inactivos al brindar un aprovisionamiento y una gestión orientados a servicios que permiten el uso de los recursos en tiempo real.
Pero me estoy desviando del tema. La cuestión es que el tráfico este-oeste está aumentando gracias a las arquitecturas y tecnologías a un ritmo que probablemente supera el del aumento norte-sur.
Ahora bien, cada cambio significativo en las arquitecturas y tecnologías de las aplicação durante los últimos veinte años ha tenido como resultado una reacción equivalente en “la red”. Esto se debe a que la red es responsable de gestionar el tráfico sin importar en qué dirección vaya. Este-oeste, norte-sur, no importa. Ya sea virtual o físico, existe una red involucrada para garantizar que el tráfico llegue desde donde está hasta donde necesita estar.
La pregunta ahora, ahora que estamos viendo aumentos aún mayores en el tráfico de este a oeste gracias a la descomposición de las aplicações debido a los microservicios, es ¿cómo debería responder la red? Más precisamente, ¿cómo deberían responder los servicios de la red para proporcionar las funciones críticas (disponibilidad, seguridad, optimización) que se requieren para entregar aplicaciones a los usuarios o, cada vez más, a otras aplicaciones?
IMPACTO UNO: PASANDO A LA APLICACIÓN
Claramente, la primera respuesta a esta pregunta es que los servicios afines a la aplicación deben acercarse a la aplicación . No pueden permanecer en el límite del patrón norte-sur y prestar servicios a aplicaciones que los consumen principalmente en un patrón este-oeste. Esto es un uso ineficiente de los recursos de la red y el impacto de los patrones de enrutamiento provoca latencia en la comunicación de las aplicação . Aquí es donde empezamos a escuchar términos como “tromboning” y “hairpinning” de patrones de tráfico que describen una ruta a través de la red que requiere salir de una máquina, atravesar la red hacia el norte y luego regresar a la misma máquina. Esa latencia se traduce en costos comerciales reales en términos de menor productividad (“tengan paciencia, mi 'computadora' está lenta hoy”) y mayor abandono de carritos de compra y aplicaciones web por parte de los consumidores. Eso es lo que queremos evitar; si el tráfico va de este a oeste, entonces los servicios deberían estar en esa ruta de datos.
IMPACTO DOS: COMPATIBILIDAD OPERATIVA
La segunda respuesta es que estos servicios, como el equilibrio de carga y la seguridad de las aplicaciones web, deben poder implementarse en formatos operativamente compatibles. En otras palabras, no vamos a colocar hardware de red delante de cada aplicación (o microservicio) que aparezca. Por lo tanto, las plataformas sobre las que se prestan estos servicios deben estar virtualizadas o contenerizadas para que sean operativamente compatibles con las arquitecturas y tecnologías emergentes. También deben ser programáticos, proporcionando API y plantillas que permitan un enfoque orientado a DevOps para el aprovisionamiento y la gestión. Los servicios, ya sean aplicação o redes, deben ser orquestables. SDN, si puede integrarse con las herramientas y los marcos que dominan los entornos de infraestructura y operaciones de aplicação , también puede abordar esta necesidad.
IMPACTO TRES: LA ARQUITECTURA ES CRÍTICA
La tercera respuesta es que la arquitectura se vuelve aún más importante que nunca. El hecho de que se pueda implementar un servicio de red en el mismo host que su aplicação no significa necesariamente que deba implementarse allí. Dependiendo de qué sea y cuál será su interacción con otros servicios (e instancias de servicios), la ubicación se convierte en un tema serio a considerar. Un equilibrio de carga mal diseñado, por ejemplo, puede generar patrones de tráfico aterradores que generan una latencia innecesaria; latencia que se traduce directamente en ganancias o pérdidas comerciales . Cualquier falla (hardware, software, red, almacenamiento) en este escenario en el host en el que se implementan los servicios da como resultado un tiempo de inactividad (y un tiempo de inactividad desagradable, además) porque los servicios responsables de garantizar que las aplicaciones estén disponibles también están inactivos. En una arquitectura de aplicação altamente descompuesta (microservicios), esto podría ser desastroso si las dependencias de estas aplicaciones son altas.
Es necesaria una consideración cuidadosa (arquitectura) para garantizar que las mejores prácticas en cuanto a rendimiento y disponibilidad no se ignoren por el atractivo de la respuesta más obvia (y más fácil).
LA CREACIÓN DE REDES SIGUE SIENDO UN EJERCICIO EN ARQUITECTURA
La creación de redes es y sigue siendo un esfuerzo arquitectónico. No se trata solo de factores de forma, es simplemente una manera de llevar los recursos de red donde los necesitas de manera más rápida y eficiente. Se trata de la ubicación de esos recursos y su impacto en todo lo que está aguas arriba en la pila: los servicios de red, los servicios de la aplicación, el rendimiento de la aplicación y, en última instancia, el éxito o el fracaso del negocio.
La creación de redes en la era de los contenedores, la virtualización y la nube tiene tanto que ver con la arquitectura como con las operaciones.