A rede baseada em intenção é uma tecnologia “fracassada”?

Em meados da década de 2010, especialistas em marketing de tecnologia e analistas se apaixonaram — e elogiaram amplamente — uma tecnologia que chamaram de Intent-Based Networking (IBN).

Agora, quase uma década depois, você não ouve mais falar muito do IBN. Mas isso não significa que tenha sumido.

Este artigo detalha a história da IBN e seus fundamentos vitais para a infraestrutura de nuvem moderna de hoje — e a segurança na nuvem.

Início dos anos 2010: adaptação às rápidas mudanças nas redes em nuvem

Pouco antes disso, na HP Networking, o escritório do CTO viu novas abstrações de rede semelhantes sendo inventadas isoladamente por vários grupos que tentavam se adaptar à nova escala e taxa de mudança nas redes em nuvem. Muito desse trabalho estava sendo feito em projetos de código aberto (por exemplo, OpenStack, Open Day Light).

A HP decidiu investir recursos na tentativa de unificar esse trabalho e, em 2013, organizou o “IBN Summit” no HP Labs em Palo Alto. Os convites foram estendidos a todos conhecidos por trabalharem em soluções de política de rede para projetos de SDN e nuvem, incluindo pessoas da Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMware etc. As diferentes partes apresentaram aspectos de seu trabalho nessa área e concordaram em tentar encontrar um caminho para uma API comum.

Meados de 2010: Definindo o IBN

Representantes de muitas dessas empresas continuaram trabalhando juntos no grupo de trabalho North-Bound Interface (NBI) da Open Networking Foundation (ONF) enquanto eu era presidente. Em outubro de 2016, o ONF publicou um documento com o objetivo de apresentar o consenso dos membros sobre uma definição e visão geral técnica de um sistema IBN.

Leia o documento, Intent NBI - Definição e Princípios, aqui.

A definição deste documento pode ser resumida em uma espécie de regra de ouro: a intenção não inclui nenhum detalhe de implementação que a torne específica para a plataforma ou a infraestrutura.

A intenção consiste em declarações declarativas sobre os comportamentos de rede desejados em termos comerciais. Separadamente, há um processo de mapeamento que sabe como implementar a intenção na configuração/estado/topologia atual da infraestrutura.

Os críticos alegaram que estávamos descartando e ignorando a implementação, então não havia valor. Salientamos que não o estávamos jogando fora, mas sim movendo-o para outro lugar sob o controle de um processo de mapeamento. Declarar a intenção “pura” não exige que os autores de políticas sejam especialistas em tecnologias de infraestrutura, mas precisam apenas entender as restrições comerciais da política.

Nesse documento, a definição do ONF descreveu um “loop ativo intencional” dentro do controlador:

“Esse elemento é responsável por avaliar continuamente as intenções de serviço ativas e os mapeamentos do repositório e das informações de rede do manipulador do SBI; e por tomar as medidas necessárias para instanciar novas configurações de serviço ou modificar adequadamente as existentes em função das alterações de intenção detectadas (repo) e/ou das alterações de mapeamento (repo) e/ou do Intent NBI.”

A descrição do loop ativo da intenção é consistente com um termo que se tornou conhecido no Kubernetes, que descreve os controladores que traduzem a intenção declarativa em comportamentos do sistema como sendo construídos em um loop de reconciliação contínua (CRL) que mantém continuamente uma implementação da intenção declarada na infraestrutura.

Este artigo usará o termo Loop de reconciliação contínua ou CRL para se referir a todas essas abordagens técnicas.

2017: IBN é “a próxima grande novidade”

Logo após publicarmos o documento, o setor começou a falar sobre o IBN quando a Gartner cunhou o termo em 2017 e o chamou de “a próxima grande novidade” em um artigo do blog.

Os profissionais de marketing acabaram tornando o IBN sem sentido, como fazem, primeiro, ao afirmar que cada fornecedor sempre teve o IBN. E então, como resultado, as pessoas finalmente pararam de falar sobre isso.

Depois de todo esse barulho, pode-se olhar para trás e se perguntar: o IBN foi um fracasso em termos práticos?

A resposta é não - muito pelo contrário, na verdade.

Hoje: o IBN está vivo e bem na infraestrutura de nuvem moderna

Não falamos muito sobre o IBN, mas ele é onipresente na infraestrutura de nuvem moderna.

Três exemplos ilustram a amplitude do uso dessa abordagem em grandes ambientes de produção.

Políticas de rede do Kubernetes

O controlador de políticas da Container Network Interface (CNI) do K8, o Certificate Revocation List (CRL), conhece o estado de todos os pods/endpoints, switches virtuais, proxies secundários, gateways, NATs etc. Ele também conhece os mapeamentos para implementação (endereços IP, portas, protocolos, identidade, autorização, rótulos, namespaces etc.) e executa um ciclo de reconciliação contínuo para manter a implementação consistente com as políticas de rede.

Os desenvolvedores fornecem Kubernetes políticas de rede (KNPs) sem detalhes de implementação (intenção), e o controlador faz isso. Os KNPs permitem que os usuários especifiquem atributos de nível inferior, como endereço IP ou porta, mas a melhor prática é usar seletores baseados em rótulos nas declarações de políticas locais para se beneficiar da automação de estado distribuída no mecanismo KNP.

Illumio Policy Compute Engine (PCE) e Illumio VEN (agente)

A Illumio tem um produto corporativo maduro e amplamente implantado que traz a proposta de valor intencional para máquinas e contêineres virtuais e bare metal usando uma abstração semelhante baseada em rótulos. Isso abrange várias instâncias dinâmicas usando um controlador de CRL para manter as restrições de política.

Há um controlador distribuído (PCE), pré-configurado com políticas abstratas, dinâmicas e baseadas em rótulos que usa o ciclo de reconciliação contínua para implementar essas políticas no contexto do estado e da topologia atuais da infraestrutura.

A aplicação real da política, nesse caso, é feita programando as ferramentas nativas de nível inferior para várias plataformas de infraestrutura de nuvem pública e local.

Zimbro/Apstra

O Apstra IBN também tem um modelo declarativo com automação para converter políticas abstratas em implementações de infraestrutura específicas. No entanto, o problema que ele resolve é um pouco diferente dos exemplos anteriores.

Tanto as políticas de rede do Kubernetes quanto a plataforma da Illumio podem ser categorizadas como tecnologias de rede “sobrepostas”. Eles criam e controlam recursos de uma rede virtual em cima de uma rede que já tem conectividade básica entre dispositivos físicos.

A solução Juniper Apstra tem a capacidade de criar e controlar a rede “Äúunderlay” que inclui racks cheios de dispositivos de data center conectados por cabos. Mas, como os exemplos acima, ele mantém a consistência por meio da reconciliação contínua das políticas declarativas com a rede.

IBN: A espinha dorsal do desempenho da nuvem em grande escala

A camada adicional de abstração fornecida por uma abordagem baseada em intenção é necessária para alcançar a escala, a taxa de mudança e o desempenho necessários para cargas de trabalho na nuvem.

Se você tem milhares ou mais instâncias dinâmicas de um “aplicativo” em constante mudança, os humanos não podem estar no caminho certo para atualizar políticas. Uma interface baseada em intenção “comprime” o espaço de regras da perspectiva do usuário e esconde toda a magia de tornar isso realidade por trás dessa interface. Ele permite que instâncias com comportamentos semelhantes/idênticos sejam tratadas como um grupo ao qual a política pode ser aplicada.

Se sua intenção é “as coisas do grupo A podem se comunicar com as do grupo B”, você cria uma regra simples que nunca precisa mudar. É a regra correta e leva ao comportamento correto, independentemente de não haver instâncias, uma, duas, três ou um bilhão de instâncias, em um único servidor ou em milhões. Há apenas uma regra, mas sua implementação em um grande sistema pode exigir atualizações dinâmicas para um bilhão de regras de firewall em cem mil firewalls.

É o desenvolvimento desses enormes controladores de circuito de reconciliação contínua, distribuídos e automatizados que possibilitam a implementação de políticas globais de rede para sistemas distribuídos de grande escala, que estão sendo cada vez mais construídos na nuvem por empresas globais.

Os dias de uma planilha do Excel com as regras para todos os seus firewalls já se foram — qualquer abordagem manual e individualizada de “programar firewalls” para sistemas maiores é igualmente obsoleta.

A segurança moderna na nuvem depende do IBN

A IBN silenciosamente fez toda a viagem no ciclo de hype. Está tão profundamente enraizado nas bases das redes modernas que não tem mais uma palavra da moda associada a ela.

O fato de várias partes terem inventado soluções conceitualmente semelhantes isoladamente é sempre um forte sinal de que algo importante está acontecendo. As pessoas que fizeram esse trabalho são em grande parte desconhecidas, mas sabem que ajudaram a viabilizar as coisas incríveis que podemos fazer na nuvem atualmente.

Essa habilidade está se mostrando ainda mais importante, pois ameaças cibernéticas aumento e proteção de Confiança zero o networking, em particular, se torna ainda mais crítico. A natureza confiável e escalável do IBN, por sua vez, permite que plataformas como a Illumio ofereçam segurança confiável e escalável na nuvem.

Saiba mais sobre como o Illumio CloudSecure contém violações na nuvem híbrida aqui.

Interessado em proteger sua rede em nuvem com Illumio Zero Trust Segmentação? Entre em contato conosco hoje para uma consulta e demonstração.