Em 1983, quando eu ainda estava aprendendo a espiar e cutucar o hardware do meu Apple ][e, um grupo de pessoas com ideias semelhantes nas indústrias de computadores e telecomunicações se reuniu para criar uma especificação detalhada que chamaram de Open Systems Interconnection (OSI). O que começou como um esforço para desenvolver interfaces reais acabou se transformando em um modelo de referência comum que, por sua vez, poderia ser usado por outros – como o IETF – para desenvolver interfaces. Essas interfaces poderiam – e se tornaram – eventualmente padrões: IP, TCP, HTTP, etc…
Esse modelo de referência foi ensinado à maioria de nós que cursamos aulas de ciência da computação na faculdade. Aprendemos sobre as “sete camadas do OSI” apenas para descobrir no mundo real que as implementações reais raramente mapeiam claramente o modelo de rede OSI.
Ainda assim, ele mapeia bem o suficiente para que continuemos a usá-lo como o modelo de referência que ele deveria ser. A maioria de nós entende que a Camada 4 se refere ao TCP, a Camada 7 ao HTTP e as Camadas 2/3 ao IP e Ethernet. Eles são quase intercambiáveis.
Alguns anos atrás, até entramos em debates sobre onde, exatamente, os protocolos de sobreposição associados à SDN e às redes virtuais pertenciam. Eles não eram realmente da camada 2, mas também não eram exatamente da camada 3. Eles estavam meio termo.
Conseguimos ignorar isso, na maior parte do tempo, e apenas acenamos vagamente para as duas camadas e nos referimos a elas apenas como "rede de sobreposição". Todos entenderam o que queríamos dizer, e tínhamos outras coisas para discutir, como a definição de nuvem e se o DevOps era apropriado para a empresa ou não.
Entre nos contêineres – ou mais precisamente, nas redes de contêineres. O mundo altamente volátil e automatizado dos Ambientes de Orquestração de Contêineres (COE) deu origem à necessidade de ainda mais camadas na pilha de rede.
Assim como na rede de sobreposição, não estamos inclinados a criar novas camadas no modelo OSI porque, bem, é uma referência padrão neste momento e mudar os padrões pode levar muito tempo. Junto. Longo. Tempo. Mas, assim como a rede de sobreposição, essas camadas ainda existem como interfaces existenciais na pilha de rede. E assim como a rede de sobreposição, estou inclinado a dar a elas "meias" camadas porque elas são muito importantes para o futuro da rede no COE.
O primeiro 'meio passo' fica entre as camadas 4 e 5. É aqui que a execução e a automação da malha de serviço entram em cena. Em poucas palavras, uma malha de serviço é construída a partir de proxies implantados em side-cars que interceptam todas as solicitações. Isso permite que eles executem roteamento específico de domínio para serviços no ambiente de contêiner. Ele pressupõe que existam protocolos de ordem inferior e efetivamente os estende. Isso é necessário porque todas as camadas de rede abaixo dela assumem que a conectividade e o roteamento são baseados somente no endereço IP. E embora seja assim que os pacotes são movidos em um ambiente de contêiner, a decisão sobre qual endereço IP e porta enviar uma determinada solicitação não se baseia nessas informações. Ele se baseia em uma variedade de variáveis relacionadas ao status e à localização do serviço e do aplicativo. Basicamente, estamos analisando metainformações sobre uma solicitação e usando-as para determinar como encaminhá-la. Essas meta-informações são essenciais para estabelecer a “malha” que, por sua vez, garante a disponibilidade e a escala de cada serviço.
O segundo 'meio passo' fica próximo ao topo, acima da camada 7. Brincadeiras à parte sobre a “camada humana (camada 8)”, o COE na verdade coloca uma camada de metadados acima do aplicativo que fornece a “cola” que faz a escala em ambientes em contêineres funcionar. Essas são as “etiquetas” de aplicativo ou serviço usadas para identificar serviços discretos para os quais o COE oferece escala automatizada. Sem as tags, é quase impossível distinguir um aplicativo do outro. Isso ocorre porque todas as camadas da pilha OSI são identificáveis por construções específicas, como endereço IP e porta. Embora já entendamos há muito tempo que as implementações arquitetônicas que dependem do compartilhamento de construções externas ao ambiente (servidores virtuais e redes baseadas em host), os contêineres criaram os mesmos problemas dentro do ambiente. O compartilhamento de portas e endereços IP dificulta a diferenciação entre serviços nas velocidades necessárias.
A adição de ‘tags’ na camada 7.5 em ambientes em contêineres oferece a esses serviços de rede (como balanceamento de carga e roteamento) a capacidade de identificar recursos de forma exclusiva e garantir escala e disponibilidade ao mesmo tempo.
As novas “camadas de contêiner” permitem que o ambiente se desvincule das construções de rede e, no processo, garantam maior portabilidade do que as tecnologias anteriores que permaneceram firmemente vinculadas a outras camadas na pilha de rede. Ao operar em “meias camadas” e assumir a existência das camadas tradicionais, os ambientes em contêineres ganham independência de qualquer esquema ou arquitetura de rede específica e podem se mover com igual facilidade entre desenvolvimento e teste, teste e produção, no local e na nuvem.