¿Las redes basadas en la intención son una tecnología “fallida”?
A mediados de la década de 2010, tanto los expertos en marketing de tecnología como los analistas se enamoraron de una tecnología que llamaron redes basadas en la intención (IBN) y la promovieron ampliamente.
Ahora, casi una década después, ya no se oye hablar mucho de IBN. Pero eso no significa que se haya ido.
Este artículo detalla la historia de IBN y sus fundamentos vitales para la infraestructura moderna en la nube de hoy, 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 adaptarse 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 en tratar de unificar este trabajo, y en 2013 organizó la “Cumbre IBN” en HP Labs en Palo Alto. Se extendieron invitaciones a todos los conocidos por estar trabajando en soluciones de políticas de red para SDN y proyectos en la nube, incluyendo 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 empresas 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 visión general técnica para un sistema IBN.
Lea el documento, Intent 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 lo haga específico 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, existe 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 aseguraron que estábamos tirando a la basura e ignorando la implementación por lo que no había valor. Señalamos que no lo estábamos tirando a la basura, sino trasladándolo a otro lugar bajo el control de un proceso de mapeo. Declarar la intención “pura” no requiere que los autores de políticas sean expertos en las tecnologías de infraestructura, sino que solo tienen que entender las limitaciones del negocio para las políticas.
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 mapeos del servicio activo del repositorio y la información de red del manejador del SBI; y tomar las acciones 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 Intent NBI”.

La descripción del bucle activo de intención es consistente con un término que se ha hecho bien conocido de Kubernetes que describe a los controladores que traducen la intención declarativa a los comportamientos del sistema como construidos sobre un bucle de reconciliación continua (CRL) que mantiene continuamente una implementación de la intención declarada dentro de la infraestructura.
Este artículo utilizará el término Bucle de Reconciliación Continua o CRL para referirse a todos esos enfoques técnicos.

2017: IBN es “la próxima gran cosa”
Poco después de que publicamos 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 vendedores finalmente hicieron que IBN no tuviera sentido, como lo hacen, primero por cada proveedor que afirma que siempre ha tenido IBN. Y luego, como resultado, la gente finalmente dejó de hablar de ello.
Después de todo ese ruido, uno puede mirar hacia atrás y preguntarse: ¿IBN fue un fracaso en términos prácticos?
La respuesta es no - todo lo contrario, de hecho.
Hoy: IBN está vivo y bien en la infraestructura moderna de la nube
No hablamos mucho de IBN, pero es omnipresente en la infraestructura moderna en la nube.
Tres ejemplos ilustran la amplitud de uso de este enfoque en entornos de producción grandes.
Políticas de red de Kubernetes
El controlador de políticas Container Network Interface (CNI) de K8, la Lista de Revocación de Certificados (CRL), conoce el estado de todos los pods/endpoints, switches virtuales, proxies sidecar, gateways, NATs, etc. También conoce mapeos para la implementación (direcciones IP, puertos, protocolos, identidad, autorización, etiquetas, espacios de nombres, etc.) y ejecuta un bucle de reconciliación continuo para mantener la implementación consistente con las políticas de red.
Los desarrolladores proporcionan Kubernetes políticas de red (KNP) sin detalles de implementación (intención), y el controlador lo hace así. Los KNP permiten a los usuarios especificar atributos de nivel inferior como la dirección IP o el puerto, pero la mejor práctica es utilizar selectores basados en etiquetas en las declaraciones de políticas locales para beneficiarse de la automatización estatal distribuida 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 intencional a las máquinas y contenedores de metal desnudo y virtuales mediante el uso de una abstracción similar basada en etiquetas. Esto abarca varias instancias dinámicas que utilizan un controlador CRL para mantener las restricciones de políticas.
Existe un controlador distribuido (PCE), preconfigurado con políticas abstraídas, dinámicas y basadas en etiquetas que utiliza el bucle de reconciliación continua para implementar estas políticas 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 diversas plataformas de infraestructura de nube pública y locales.
Enebre/Apstra
Apstra IBN también cuenta con un modelo declarativo con automatización para convertir políticas abstractas a implementaciones de infraestructura específicas. No obstante, 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 “superpuesta”. Crean y controlan características de una red virtual encima de una red que ya cuenta con 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 data center conectados por cables. Pero, al igual que los ejemplos anteriores, mantiene la consistencia mediante la conciliación continua de políticas declarativas con la red.
IBN: La columna vertebral del performance en 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 performance necesarios para las cargas de trabajo en la nube.
Si tiene miles o más instancias dinámicas de una “aplicación” en constante cambio, 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 oculta toda la magia de hacerlo realidad detrás de esa interfaz. Permite que las instancias con comportamientos similaros/idénticos se traten como un grupo al que se puede aplicar la política.
Si tu intención es “las cosas del grupo A pueden comunicarse con las cosas del grupo B”, creas una regla simple que nunca necesita cambiar. Es la regla correcta y conduce al comportamiento correcto ya sea que no haya instancias, una, dos, tres o mil millones de instancias, en un solo servidor o millones de instancias. Sólo hay una regla, pero su implementación en un sistema grande podría requerir actualizaciones dinámicas a mil millones de reglas de firewall en cien mil firewalls.
Es el desarrollo de estos enormes controladores de bucle de reconciliación continua, distribuidos y automatizados los que hacen posible la implementación de políticas de red global para sistemas distribuidos a gran escala que las empresas 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 se han ido hace mucho tiempo: 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 ha tomado silenciosamente todo el viaje en el ciclo de bombo. Está tan profundamente entretejido en los cimientos de la creación de redes modernas que ya no tiene una palabra de moda asociada con él.
El hecho de que múltiples partes inventaran soluciones conceptualmente similares de manera aislada es siempre una señal tan fuerte de que algo importante está sucediendo. Las personas que hicieron este trabajo son en gran parte desconocidas, pero saben que ayudaron a habilitar las cosas increíbles que podemos hacer hoy en la nube.
Esta capacidad está resultando aún más importante ya que ciberamenazas el aumento y la protección de Cero Confianza la creación de redes, en particular, 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 brechas en la nube híbrida aquí.
Interesado en proteger su red en la nube con Illumio Zero Trust ¿Segmentación? Contáctanos hoy para una consulta y demostración.