Las redes de los centros de datos han cambiado y no hay vuelta atrás. Se han vuelto tan complejos que no pueden ser entendidos en tiempo real por los seres humanos.

Tienen que ser automatizadas. Pero eso trae un peligro: ¿Cómo puedes estar seguro de que se han automatizado correctamente?

La complejidad proviene de las demandas de las aplicaciones que se ejecutan y la necesidad de ejecutarlas en múltiples nubes e infraestructura.

“Hay muchas demandas y presiones nuevas sobre las redes de los centros de datos”, dice el analista Brad Casemore de IDC, hablando en un evento en línea de DCD . “Las arquitecturas de aplicaciones realmente han redefinido los requisitos de redes de los centros de datos. Como resultado de la evolución de las arquitecturas de aplicaciones, existe la necesidad de modernizar los centros de datos”.

Las aplicaciones gobiernan la red

Las redes solían dictar términos a las aplicaciones que se ejecutaban en ellas, dice Sanjeevan Srikrishnan, arquitecto sénior de soluciones globales de Equinix: “En los viejos tiempos, salíamos y construíamos una red increíble. Diríamos, oye, quiero enlaces troncales de 100 G y toda esta infraestructura loca. Luego, la empresa vendría a nosotros y diría: '¿Puedo ejecutar mi aplicación en su red?' y decíamos "No, lo siento, no satisface nuestras necesidades".

Los arquitectos de red en realidad podrían pedirle a la empresa que se vaya y reconstruya las aplicaciones para que se adapten a la red.

Ya no es así: “Ya nadie lo hace así. La aplicación es el rey Kahuna. Es la parte inferior del triángulo. Es la base del equivalente tecnológico de la jerarquía de necesidades de Maslow. La experiencia del usuario es el rey”.

Satisfacer las demandas de experiencia del usuario sería lo suficientemente complejo, pero ahora las redes se construyen a partir de partes diversificadas y deben responder de manera coherente: "Todo responde realmente a las aplicaciones", dice Sagi Brody, CTO del proveedor de servicios administrados Opti9. “Y el entorno de producción de una organización empresarial hoy en día suele ser híbrido. Abarca la colocación, las nubes privadas, las nubes públicas y SaaS”.

Estas redes complejas se han ensamblado a partir de partes que históricamente estaban en silos, y debajo de las cubiertas, algo de eso no ha cambiado: "Estás viendo que las organizaciones pasan de configuraciones fijas y en silos a este nuevo mundo digital". dice Srikrishnan, “y nunca es una migración limpia. Siempre tienes una "deuda tecnológica" que se queda ahí y puede durar entre 10 y 15 años".

Además de eso, las responsabilidades cambian: “Muchas de las cosas que pensabas que el proveedor iba a tener, todavía las tienes. Está mezclando cuatro tipos diferentes de servicios, y tiene que controlar el cumplimiento y la seguridad de todos ellos individualmente, así como también cómo funcionan juntos”, dice Brody.

Estas redes también distribuyen más decisiones de red, dice Russ White, arquitecto de infraestructura de Juniper: "Desde la perspectiva de la arquitectura de red, ¿Cómo construyo estas redes que pueden manejar este tráfico de Edge y distribuir cosas de manera inteligente y aún tener algún tipo de núcleo?"

Rápido no es suficiente

Los servicios que se ejecutan en estas redes distribuidas híbridas tienen que responder instantáneamente, pero también de manera muy consistente, dice White: “Cuando trabajo en redes de hiperescala, ni siquiera es realmente la demora lo que importa. Es el nerviosismo”.

El retraso es cuando los paquetes de red tardan mucho en llegar. La fluctuación es cuando llegan, pero la demora es variable, lo que dificulta el tráfico en tiempo real, como las llamadas de voz, explica: "La consistencia es una clave enorme en este momento, ¿Cómo puedo hacer que la red funcione de manera constante todo el tiempo?"

Con todas estas diferentes partes de la red para administrar, es imposible que los administradores de red respondan lo suficientemente rápido para mantenerse al día con las demandas cambiantes.

“Los casos de uso híbrido nos están obligando a escenarios en los que necesitamos implementar cosas como VPN y VxLAN”, dice Sagi Brody, CTO del proveedor de servicios administrados Opti9. "Estos ya no son, literalmente, configurables a mano".

Lo más obvio es usar herramientas automatizadas para controlar la respuesta de la red a las condiciones cambiantes y quitarle la carga al administrador.

Pero, ¿Qué es exactamente lo que se está automatizando? Srikrishnan dice que la red es un término "nebuloso". “¿Estamos hablando de las redes virtuales que ven los desarrolladores? ¿O estamos hablando de la infraestructura subyacente que impulsa todo eso? Son dos cosas muy diferentes."

Otro problema es que la automatización no es simple. El primer enfoque fue crear un conjunto de reglas que proporcionaran una versión enlatada de la respuesta que daría un administrador a eventos específicos. Eso funciona bien la mayor parte del tiempo, pero si un evento está ligeramente fuera de las posibilidades consideradas por el programador de la red, la respuesta puede ser incorrecta y, a veces, desastrosa.

La automatización rápida es peligrosa

Brody dice que: “La automatización es importante. Pero también puede ser peligroso, hay que hacerlo bien. Tiene que ser un caso de uso específico”.

Brody dice que: “La inteligencia tiene que entrar y agregar algunas capas de lógica” para verificar si alguna acción causará problemas. “Un ejemplo es IPAM [gestión de direcciones IP]. Si IPAM dice que una subred está libre y no está en uso, antes de ir y asignar una dirección IP, verifiquemos si es enrutable”.

Casemore quiere ver la verificación: "Entonces, cuando se automatiza un cambio a escala, no causaría todo tipo de problemas ni dañaría parte de su red".

Automatización inteligente

Brody dice que la respuesta es crear una red que no solo esté automatizada, sino que sea inteligente: "Añade algo de inteligencia y algo de verificación lógica, y así sucesivamente".

White está de acuerdo: “Quiero que la red se caiga lo menos posible. Y creo que estamos confiando casi demasiado en la automatización y confiando poco en la automatización inteligente. Deberíamos poner el énfasis en la inteligencia y no en la automatización”.

Casemore de IDC agrega: “La automatización no solo se vuelve más completa, sino que se vuelve más inteligente y un poco más anticipatoria. Pasamos a una forma de automatización más proactiva”.

Pero esto tiene que hacerse sin añadir capas de complejidad. Brody quiere traerlo de vuelta a una vista más simple: “Tenemos que darle la vuelta. Tenemos que centrarnos en modelos declarativos, imponiendo nuestra configuración ideal en la red”. En lugar de que la automatización configure la red, quiere ver un "único punto de verdad", una configuración impuesta en la red física.

“Este es un nuevo paradigma”, dice. “Necesitamos avanzar hacia interfaces de máquina a máquina. Y tenemos que repensar”.

La gente solía pensar que podía construir cosas tan complejas como quisiera, dice, “siempre y cuando lo automaticemos. Y creo que debemos alejarnos de esa línea de pensamiento y comenzar a pensar en cómo puedo hacer que mi red sea más inteligente, para que pueda automatizar menos, pero que la automatización sea más inteligente”.

Brody dice: “Creo que nos estamos alejando de un mundo en el que puedes automatizar a medias y hacer las cosas a medias de forma manual. Tenemos que centrarnos en la simplicidad, todo tiene que ser lo más simple posible”.

Shrikrishnan cree que la respuesta puede ser la automatización temprana, desde cero: "Si hablamos de automatización desde el principio y usa las mejores prácticas, no está usando las manos en el teclado para implementar nada, a menos que esté usando un producto como Terraform o Ansible para llevar su código a producción en su infraestructura. Mientras haces esto, deberías validarlo”.

Observabilidad para la seguridad

El comportamiento de la red también tiene que ser "observable", una palabra clave que surge en las discusiones de la red. “Creo que es un género completamente nuevo de software”, dice Brody. “Estuve en [el evento tecnológico de AWS] Re:Invent este año, y la gran palabra de moda fue la observabilidad. Debido a que hemos hecho las cosas tan complejas, ahora tenemos este nuevo desafío de cómo observamos lo que sucede y dónde. ¿Y cómo lo solucionamos? Eso no era un problema hace años”.

Shrikirshnan está de acuerdo en que "la capacidad de observación es enorme" y dice que una red debe poder "recibir registros y responder a eventos en tiempo real".

Por ejemplo, ¿Qué pasa si un usuario normalmente está en Toronto, pero de repente aparece en Manila?

"¿Que esta pasando ahí? ¿Es este un caso de uso legítimo? ¿O es un mal actor? dice Shrikrishnan. “Ese usuario en Manila puede haber dejado su iPad en casa, y el iPad ahora está buscando correos electrónicos, pero el usuario está físicamente en Manila.

“¿Toma ahora el enfoque tradicional de SecOps y elimina su cuenta de usuario porque nota actividad maliciosa? O dices, oye, espera un minuto, esto podría ser legítimo. Permítanme pedirles credenciales. Y si es un caso de uso legítimo, ¿necesito ahora poner en marcha una infraestructura digital en Singapur para apoyarlos? porque necesitan una conectividad segura y confiable de regreso a mi infraestructura central”.

En una red de confianza cero, la autenticación de los usuarios es automática y continua, dice White: "Cuando estaba en Cisco y hablé sobre la seguridad de la red, tenía una diapositiva que decía que podíamos hacer una ventaja crujiente con una DMZ realmente agradable [Zona desmilitarizada]. Y el interior de la red podría ser realmente masticable, como una galleta con chispas de chocolate. Hoy en día, lo siento, pero toda la red tiene que ser crujiente en todo momento, a través de la seguridad debe construirse desde cero y todo el A través del camino."

Ciclo vital

La automatización de la red también debe ser capaz de manejar el ciclo de vida de una red, es decir, el tiempo durante el cual será mantenida por varias personas con diferentes niveles de habilidad.

“Si es un ingeniero de redes sénior y ha estado en las trincheras, sabe qué construir”, dice Brody. “Pero alguien más nuevo y más joven puede tener la tarea de simplemente implementar hardware y conectarlo a algún software de automatización. Mi temor es, ¿Cómo me aseguro de que no va a hacer más mal que bien?”.

Es tentador diseñar una red para el Día Cero y entregarla el Día Uno, esperando que siga funcionando, dice Casemore: “No se trata solo del Día Cero y el Día Uno. Cuando planificas y diseñas algo, tienes que lidiar con cosas como la resolución de problemas y la corrección, y ese ciclo cerrado”.

La automatización tiene que funcionar en el día N, dice: "Para que pueda optimizar la gestión de cambios y asegurarse de que la red se perfeccione continuamente para que produzca los resultados que necesita para las aplicaciones que admite".

Para Brody, lo importante es tener una arquitectura de referencia que determine cómo se pueden combinar diferentes nubes y servicios según sea necesario.

White dice que se trata de intentar construir redes de una manera simple y modular que se pueda automatizar: “Porque hay un límite en cuanto a cuánto se puede sostener la cabeza. Y si lo ha hecho demasiado complejo, no puede ser flexible, porque nadie puede descubrir cómo hacerlo funcionar”.

Cómo funciona en la práctica

Hasta ahora, tan teórico. Pero, ¿Qué sucede cuando realmente desea entregar una red automatizada? Tomemos como ejemplo el sistema de automatización de red Apstra que adquirió y utiliza Juniper.

Apstra acuñó el término red "basada en la intención" para el salto de la automatización a la automatización inteligente, explica el ingeniero de redes de Juniper, Mikko Kiukkanen: "Estás describiendo la intención. Lo que quieres hacer, no cómo llegas allí”.

Algunas herramientas automatizan tareas como la generación de direcciones IP, pero no las verifican. Una red basada en la intención se basará en un diseño de referencia o "gráfico" que describe lo que la red debe lograr. Esto se asigna a una red que se puede crear a partir del hardware de varios proveedores.

“Generamos la sintaxis, luego de validar que la configuración y el diseño sean correctos, y enviamos la configuración a los switches”, dice. “Esto sucede el primer día, cuando lo implementas y lo entregas a operaciones. Después de eso, hacemos las operaciones del día a día, lo que significa el lado del monitoreo y la solución de problemas.

El comportamiento de la red se genera a partir del diseño de la red, que se almacena en una base de datos de gráficos en el Día Cero, dice Kiukkanen: “Es un almacén de datos complejo, que está conectado a un enrutador. Ahora nos brinda una vista mucho, mucho más granular del centro de datos”.

Cuando la red se está ejecutando, el gráfico se sincroniza con la red real, dice. "En lugar de consultar los dispositivos y mirar los archivos de registro en tiempo real, podemos consultar el gráfico, porque es una única fuente de información".

La automatización se ejecuta en el "plano de control", la interfaz de gestión de los conmutadores, no en el "plano de datos", los bits generales que transfieren: "Esto le da flexibilidad para agregar equipos, porque cuando le agrega cosas, está empujando cosas en el gráfico usando una interfaz gráfica”.

El sistema puede sondear continuamente si el gráfico coincide con la intención, es decir, si hay una falla o una falla.

Las intenciones pueden incluir niveles de servicio, por lo que si un enlace de red necesita operar a no más del 90 por ciento de su capacidad, el sistema se activará cuando un cambio rompa esa intención, dice.

“Si hay una anomalía como una dirección duplicada, la marcamos. Y luego simplemente presionas un clic, y dirá que no dejes que suceda”, dice.

“Podemos generar una alarma para una anomalía”, dice, y emitir un ticket de problema automáticamente para solucionarlo si se requiere la intervención humana.

No hay vuelta atrás

En la pandemia, la automatización de la red se puso a prueba, ya que miles de usuarios comenzaron a trabajar desde casa: “Una arquitectura de centro de datos central inflexible no lo habría permitido”.

Las redes inteligentes tienen que operar de manera autónoma, ajustándose para hacer frente a fallas y picos de demanda. “Este es el mejor momento cuando se habla de inteligencia y automatización”, dice Shrikrishnan.

Pero siempre va a ser un tipo limitado de autonomía, dice: “No quiero presentar la intención o el mensaje de que estamos tratando de construir a Skynet con automatización inteligente. Es un poco diferente.