A medida que las empresas se sienten cada vez más cómodos con la nube pública, están trasladando más y más cargas de trabajo a la nube, que tradicionalmente habrían sido procesadas en los centro de datos de sus sedes. Esto está creando un mercado competitivo con muchas empresas a escala de red posicionándose para aprovechar las potenciales oportunidades. Una de las claves para brindar servicios a este mercado rápidamente creciente es la automatización a través de las operaciones del 'fabric' (tejido) del centro de datos. Sin embargo, implementar la automatización en los actuales entornos ágiles y distribuidos en escala de redes, plantea varios retos que solo se están comenzando a abordar.

Automatización de operaciones (Ops) de Día 2+.

Una de las primeras áreas de automatización es la de operaciones de Día 2+. Cada vez más, la capa de la red está siendo considerada como un recurso consumible, igual que la computación y el almacenamiento. Los eventos motorizadores en el centro de datos son cargas de trabajo que se implementan en pilas de cómputo, lo que significa que el tejido de la red también es motorizado por esos eventos. Para automatizar esto, el tejido debe ser consumido a través de la misma interfaz que se usa para desplegar las cargas de trabajo, no por una configuración de servicio fuera de banda, lo que convierte a las configuraciones de la red en parte de la 'pipeline' (futuros proyectos) de desarrollo.

Podemos ver de qué manera esto funcionaría con las mejoras de categoría. Como son costosas para desplegar, las mejoras de categoría se hacen, tradicionalmente, todas a la vez, por lo general en períodos anuales. Cuanto más tiempo pueda permanecer en una versión la operadora del centro de datos, podrá evitar durante más tiempo los gastos y la disrupción que ocasiona una mejora. Sin embargo, en el veloz universo de DevOps, esto hace que las operaciones de red pierdan la sincronización con los otros equipos.

Lo que estamos observando es una tendencia a hacer que las operaciones de red sean más ágiles con mejoras más pequeñas y más frecuentes. Igual que DevOps, los equipos de operaciones de redes están comenzando a usar la automatización en la 'pipeline' de desarrollo. GitOps se está convirtiendo en tendencia, junto con la integración continua y el desarrollo continuo (CI/CD, por sus siglas en inglés). Con mejoras más pequeñas que ocurren más frecuentemente, se facilitan las pruebas debido a la reducción del delta de la funcionalidad, y el impacto es menor cuando se producen fallos.

Además de las mejoras, la localización de fallas y la mitigación de cortes también necesitan ser manejados en una 'pipeline'. Introducir cambios, solucionar cortes y manejar la gestión de eventos, son todas acciones que pueden automatizarse de esta manera. El aprendizaje de máquinas y la IA también pueden usarse, por ejemplo, para entrenar a la plataforma a mitigar automáticamente ciertos cortes.

Sistemas operativos de redes

Para hacer que las redes de centros de datos sean consumibles, necesitaremos hacer que el sistema operativo de red y la pila de automatización sean más extensibles. Esto habilitará a las operadoras y proveedores a construir funciones e integraciones como las que ya vemos con las pequeñas funciones de calidad de vida y las automatizaciones de flujos de trabajo.

Las extensiones necesitan ser gestionables mediante el uso de ampliaciones del modelo YANG. Las Definiciones de Recursos de Cliente de Kubernetes pueden proveer el esquema necesario y la extensibilidad de la API. Para que sean viables para el mercado más amplio, se deberá normalizar el apoyo a los esquemas de sistema operativo de redes (NOS, por sus siglas en inglés) como OpenConfig (en lugar de ser agregados tardíos) que sean lo suficientemente amplios como para admitir la transmisión directa de telemetría tanto para la configuración de la red como para la misma red. Estas clases de cambios facilitarán el ingreso de nuevos proveedores al mercado y harán que el ecosistema sea más competitivo.

Gemelos digitales y Sistemas de Prueba

Los laboratorios de pruebas deberán ser reemplazados por gemelos digitales que representen mejor el estado real de la red. Las discrepancias entre los entornos de laboratorios de pruebas y la red real son, con frecuencia, la razón de los cortes. A medida que la red se hace más consumible, su estado se alejará gradualmente del estado modelo, ya sea en el laboratorio o en las cajas de arena que solo emulan la configuración del modelo. Lo que se necesita son sistemas de prueba que puedan reflejar la topología, configuración y estado general reales de la red.

En otros sectores, los gemelos digitales han avanzado relativamente con capacidades casi en tiempo real. Nuestro sector está rezagado. De todas maneras, está logrando recuperarse con la introducción del NOS en contenedores y una reducción en los costes de los recursos de computación y almacenamiento necesarios para ejecutar grandes emulaciones. Para inyectar el estado real de la red del centro de datos en el gemelo digital, también tenemos que disponer de la transmisión continua de telemetría que sea suficientemente robusta como para capturar las capas de configuración y de normalización de estado de la red. Kubernetes puede proveer la capa de orquestación de la red.

Con esta clase de gemelo digital casi en tiempo real, es posible añadir pruebas automatizadas en la tubería de integración continua con mucha más seguridad. El desarrollo continuo podrá entonces mejorar un par de conmutadores de prueba, dejarlos funcionar durante una semana en la caja de arena, antes de implementar la mejora en toda la red, sabiendo que la prueba ha sido tan cercana al mundo real como fue posible.

Redes distribuidas y la automatización

El tema más general de la automatización, especialmente en varios procesos industriales, está poniendo mucho énfasis en la 'edge cloud' (nube de borde) para reducir la latencia. Ciertas funciones de la aplicación deben estar lo más cerca posible del usuario final y el tejido de la red debe apoyarlas. Esto podría significar, por ejemplo, que una función de la aplicación en contenedor que esté siendo ejecutada en dos contenedores en la nube central, repentinamente aumente a cuatro contenedores que funcionan en una nube de borde lejano, cuando la aplicación reacciona a la demanda local.

Esta no es una tarea sencilla. Hay diferentes orquestadores en el borde lejano, en el centro de datos central y en la red. La orquestación en múltiples dominios puede ocurrir sin complicaciones, en segundos o menos tiempo. El primer paso para los proveedores y las operadoras es simplificar el flujo de trabajo y permitir que sea consumido con un único clic de un botón. Pero, como muchas de estas aplicaciones bajo el entorno de “Industria 4.0” también son automatizadas, necesitamos ir un paso más adelante, automatizando el desarrollo de capacidad adicional en el borde lejano y creando todas las piezas correspondientes en el tejido. Esta es la clase de red autoimpulsada que se necesitará, con cambios de configuración que ocurran no solo una vez por semana o por mes, sino miles de veces por día o por hora, en forma de la implementación de nuevos servicios, y nuevos agregados a esos servicios.

Las ubicaciones de borde también crecerán de un puñado a cientos o incluso miles. Esto genera una dependencia muy intensa en las operaciones de automatización cuando se construyen y se implementan tejidos. Cuando las cargas de trabajo se incrementa, la red debe conectarse automáticamente a donde deben estar, de manera invisible. La provisión de estos nuevos servicios para consumidores e industrias significarán más infraestructura, no solo más conectividad, y la automatización de esa infraestructura en escala presentará problemas únicos que deberán resolver tanto los proveedores como las operadoras.

Para obtener más información, visite nuestro sitio web.