¿Es la creación de redes basadas en la intención una tecnología "fallida"?
A mediados de la década de 2010, tanto los expertos en marketing tecnológico como los analistas se enamoraron de una tecnología que llamaron Redes Basadas en la Intención (IBN, por sus siglas en inglés).
Ahora, casi una década después, ya no se oye hablar mucho de IBN. Pero eso no significa que se fue.
Este artículo detalla la historia de IBN y sus fundamentos vitales para la infraestructura de nube moderna de hoy en día, y la seguridad en la nube.
Principios de la década de 2010: Adaptación a los rápidos cambios en las redes en la nube
Justo antes de esto, en HP Networking, la oficina del CTO vio nuevas abstracciones de red similares inventadas de forma aislada por múltiples grupos que intentaban adaptar a la nueva escala y tasa de cambio en las redes en la nube. Gran parte de este trabajo se realizaba en proyectos de código abierto (por ejemplo, OpenStack, Open Day Light).
HP decidió invertir recursos para tratar de unificar este trabajo, y en 2013 organizó la "IBN Summit" en HP Labs en Palo Alto. Se extendieron invitaciones a todos los que se sabe que trabajan en soluciones de políticas de red para proyectos SDN y en la nube, incluida la gente de Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMWare, etc. Las diferentes partes presentaron aspectos de su trabajo en esta área y acordaron tratar de encontrar un camino hacia una API común.
Mediados de la década de 2010: definición de IBN
Los representantes de muchas de estas compañías continuaron trabajando juntos en el grupo de trabajo North-Bound Interface (NBI) de la Open Networking Foundation (ONF) mientras yo era presidente. En octubre de 2016, la ONF publicó un documento destinado a presentar el consenso de los miembros sobre una definición y una descripción técnica para un sistema IBN.
Lea el documento, Intención NBI - Definición y principios, aquí.
La definición de este documento se puede resumir en una especie de regla de oro: la intención no incluye ningún detalle de implementación que la haga específica para la plataforma o la infraestructura.
La intención consiste en declaraciones declarativas sobre los comportamientos de red deseados en términos comerciales. Por separado, hay un proceso de mapeo que sabe cómo implementar la intención en la configuración/estado/topología actual de la infraestructura.
Los críticos afirmaron que estábamos tirando e ignorando la implementación, por lo que no tenía valor. Señalamos que no lo estábamos tirando, sino moviéndolo a otro lugar bajo el control de un proceso de mapeo. Declarar la intención "pura" no requiere que los autores de la política sean expertos en las tecnologías de infraestructura, sino que solo tienen que comprender las restricciones comerciales de la política.
En ese documento, la definición de ONF describía un "bucle activo de intención" dentro del controlador:
"Este elemento es responsable de evaluar continuamente las intenciones y asignaciones de servicio activo del repositorio y la información de red del controlador SBI; y tomar las medidas necesarias para crear instancias nuevas, o modificar adecuadamente las existentes, configuraciones de servicio en función de los cambios de intención detectados (repo) y/o de los cambios de mapeo (repo) y/o de la intención NBI".

La descripción del bucle activo de intención es coherente con un término que se hizo bien conocido en Kubernetes y que describe los controladores que traducen la intención declarativa a los comportamientos del sistema como si se construyeran en un bucle de reconciliación continua (CRL) que mantiene continuamente una implementación de la intención declarada dentro de la infraestructura.
En este artículo se usará el término bucle de reconciliación continua o CRL para referir a todos estos enfoques técnicos.

2017: IBN es "la próxima gran cosa"
Poco luego de publicar el documento, la industria comenzó a hablar de IBN cuando Gartner acuñó el término en 2017 y lo llamó la "próxima gran cosa" en un artículo de blog.
Los especialistas en marketing finalmente hicieron que IBN no tuviera sentido, como lo hacen, primero por cada proveedor que afirma que siempre tuvo IBN. Y luego, como resultado, la gente finalmente dejó de hablar de eso.
Luego de todo ese ruido, uno puede mirar hacia atrás y preguntar: ¿Fue IBN un fracaso en términos prácticos?
La respuesta es no, todo lo contrario, de hecho.
Hoy: IBN está vivo y coleando en la infraestructura moderna de la nube
No hablamos mucho de IBN, pero es omnipresente en la infraestructura moderna de la nube.
Tres ejemplos ilustran la amplitud del uso de este enfoque en grandes entornos de producción.
Directivas de red de Kubernetes
El controlador de políticas de interfaz de red de contenedores (CNI) de K8, la lista de revocación de certificados (CRL), conoce el estado de todos los pods/puntos finales, conmutadores virtuales, proxies sidecar, puertas de enlace, NAT, etc. También conoce las asignaciones para la implementación (direcciones IP, puertos, protocolos, identidad, autorización, etiquetas, espacios de nombres, etc.) y ejecuta un ciclo de reconciliación continuo para mantener la implementación coherente con las políticas de red.
Los desarrolladores proporcionan políticas de red de Kubernetes (KNP) sin detalles de implementación (intención), y el controlador lo hace. Los KNP permiten a los usuarios especificar atributos de nivel inferior como la dirección IP o el puerto, pero la práctica recomendada es usar selectores basados en etiquetas en las declaraciones de políticas locales para beneficiarse de la automatización de estado distribuido en el motor KNP.
Illumio Policy Compute Engine (PCE) e Illumio VEN (agente)
Illumio tiene un producto empresarial maduro y ampliamente implementado que lleva la propuesta de valor de intención a máquinas y contenedores virtuales y sin sistema operativo mediante el uso de una abstracción similar basada en etiquetas. Esto abarca varias instancias dinámicas que emplean un controlador CRL para mantener las restricciones de políticas.
Hay un controlador distribuido (PCE), preconfigurado con directivas abstractas, dinámicas y basadas en etiquetas que emplea el bucle de reconciliación continua para implementar estas directivas en el contexto del estado y la topología de la infraestructura actual.
La aplicación real de políticas, en este caso, se realiza mediante la programación de las herramientas nativas de nivel inferior para varias plataformas de infraestructura de nube pública y local.
Juniper/Apstra
Apstra IBN también tiene un modelo declarativo con automatización para convertir políticas abstractas en implementaciones de infraestructura específicas. Sin embargo, el problema que resuelve es ligeramente diferente al de los ejemplos anteriores.
Tanto las políticas de red de Kubernetes como la plataforma de Illumio se pueden clasificar como tecnologías de red "superpuestas". Crean y controlan características de una red virtual sobre una red que ya tiene conectividad básica entre dispositivos físicos.
La solución Juniper Apstra tiene la capacidad de crear y controlar la red 'Äúunderlay'Äù que incluye racks llenos de dispositivos de centros de datos conectados por cables. Pero, al igual que los ejemplos anteriores, mantiene la coherencia mediante la conciliación continua de las políticas declarativas con la red.
IBN: la columna vertebral del rendimiento de la nube a escala
La capa de abstracción adicional proporcionada por un enfoque basado en la intención es necesaria para lograr la escala, la tasa de cambio y el rendimiento necesarios para las cargas de trabajo en la nube.
Si tiene miles o más instancias dinámicas de una "aplicación" que cambia constantemente, los humanos no pueden estar en el camino rápido para actualizar las políticas. Una interfaz basada en la intención "comprime" el espacio de reglas desde la perspectiva del usuario y esconde toda la magia de hacerlo realidad detrás de esa interfaz. Permite que las instancias con comportamientos similares o idénticos se traten como un grupo al que se puede aplicar la directiva.
Si su intención es "las cosas del grupo A pueden comunicar con las cosas del grupo B", crea una regla simple que nunca necesita cambiar. Es la regla correcta y maneja al comportamiento correcto ya sea que no haya instancias, una, dos, tres o mil millones de instancias, en un solo servidor o millones. Solo hay una regla, pero su implementación en un sistema grande podría requerir actualizaciones dinámicas de mil millones de reglas de firewall en cien mil firewalls.
Es el desarrollo de estos controladores de bucle de reconciliación continua enormes, distribuidos y automatizados lo que hace posible implementar políticas de red globales para sistemas distribuidos a gran escala que las compañías globales construyen cada vez más en la nube.
Los días de una hoja de cálculo de Excel con las reglas para todos sus firewalls quedaron atrás: cualquier enfoque manual e individualizado para "programar firewalls" para sistemas más grandes es igualmente obsoleto.
La seguridad moderna en la nube se basa en IBN
IBN tomó silenciosamente todo el viaje en el ciclo de exageración. Está tan profundamente entretejido en los cimientos de las redes modernas que ya no tiene una palabra de moda asociada.
El hecho de que múltiples partes inventaron soluciones conceptualmente similares de forma aislada es siempre una señal fuerte de que algo importante está sucediendo. Las personas que hicieron este trabajo son en gran parte desconocidas, pero saben que ayudaron a hacer las cosas asombrosas que podemos hacer en la nube hoy.
Esta capacidad está demostrando ser aún más importante a medida que aumentan las amenazas cibernéticas y la protección de las redes Zero Trust , en individuo, se vuelve aún más crítica. La naturaleza confiable y escalable de IBN, a su vez, permite que plataformas como Illumio ofrezcan seguridad confiable y escalable en la nube.
Obtenga más información sobre cómo Illumio CloudSecure contiene las infracciones en la nube híbrida aquí.
¿Está interesado en proteger su red en la nube con Illumio Zero Trust Segmentation? Contáctenos hoy para una consulta y demostración.