Na infraestrutura de rede tradicional, geralmente há três planos arquiteturais associados à infraestrutura de rede: dados, controle e gerenciamento.
As definições exatas desses planos podem variar de acordo com o tipo e a implementação específica da infraestrutura, mas esses arquétipos se aplicam com bastante precisão à maioria das infraestruturas de rede.
- Plano de dados
- Às vezes chamado de caminho de dados na terminologia moderna, o plano de dados é o caminho pelo qual os pacotes (dados) trafegam. O plano de dados é responsável por receber um pacote e encaminhá-lo ao destino correto.
- Plano de controle
- Em geral, o plano de controle determina para onde os dados são encaminhados. Os protocolos de roteamento são bons exemplos de funções do plano de controle, assim como os processos decisórios de nível mais elevado, que hoje podem ser mais dinâmicos. A implementação específica varia e pode ir desde o plano de dados repassar dados ao plano de controle para que este tome uma decisão até o plano de controle observar os dados de forma transparente e agir com base em gatilhos específicos. Os planos de controle também costumam ser responsáveis por monitorar a integridade dos dispositivos e coletar estatísticas.
- Plano de gerenciamento
- O plano de gerenciamento é o mais visível dos três planos, pois é nele que interagimos com o plano de controle. Os planos de gerenciamento tradicionais usam CLI (interfaces de linha de comando), enquanto os planos de gerenciamento modernos preferem APIs (interfaces de programação de aplicações). Independentemente do método utilizado, o plano de gerenciamento permite que os operadores definam políticas que são aplicadas pelo plano de controle. Isso inclui opções de configuração, como algoritmos de balanceamento de carga e políticas de permissão/negação baseadas em características como endereço IP e tipo de dispositivo.

Mas há outro tipo de orquestração em ação nos bastidores, que passa praticamente despercebido pelos operadores. Ele não tem nada a ver com gerenciamento, exceto pelo fato de estar assumindo algumas responsabilidades dos operadores humanos.
A diferença aqui é que as ações são acionadas automaticamente por alterações no ambiente durante a execução, em vez de ocorrerem como um evento de implantação. No entanto, as informações sobre o que mudou são essenciais, o que significa que precisam ser obtidas de algum lugar.
Em um modelo operacional tradicional, essas informações geralmente vêm de tíquetes ou solicitações de mudança. No caso dos modelos operacionais modernos e, especificamente, dos contêineres, essas informações vêm de registros de serviços por meio de um mecanismo de descoberta.
Registros e descoberta de serviços
A natureza dos ambientes de contêineres pressupõe que os endereços IP, na prática, não são relevantes para o ambiente da aplicação. No entanto, eles são importantes para a infraestrutura, pois os dados ainda precisam ser roteados e encaminhados de um dispositivo para outro a fim de percorrer o caminho entre o cliente e a aplicação. Em ambientes modernos, esses endereços IP geralmente existem por curtos períodos (o tempo de vida de um contêiner/serviço).
Considere estas conclusões da DataDog (grifos nossos):
A rápida adoção de orquestradores (veja o fato 4) parece estar reduzindo ainda mais a vida útil dos contêineres, pois a inicialização e a interrupção automatizadas dos contêineres resultam em uma taxa de rotatividade mais alta. Em organizações que utilizam um orquestrador, a vida útil típica de um contêiner é de cerca de 12 horas. Em organizações sem orquestração, um contêiner dura, em média, seis dias.
Fonte: <https://www.datadoghq.com/docker-adoption>
Imagine se você, como operador, tivesse que atualizar as tabelas de roteamento ou os pools de balanceamento de carga a cada seis dias, ou até mesmo a cada doze horas. Você praticamente não faria outra coisa. O risco de erros de configuração seria significativo e provavelmente aumentaria quanto mais tempo você fosse obrigado a operar em modo manual para gerenciar as alterações em um cluster de contêineres.
Um registro de serviços — como o Consul — torna-se um componente essencial da implantação de contêineres. Os registros de serviços monitoram as instâncias e os serviços, bem como seus respectivos endereços IP. Nesse sentido, podem ser comparados a um "DNS para contêineres e serviços".
Assim, o registro de serviços acompanha as características atuais dos contêineres no cluster. A descoberta é o processo de se conectar ao registro de serviços (via API ou por meio da assinatura de uma fila de mensagens) para associar instâncias a endereços IP.
Isso significa que a infraestrutura que precisa encaminhar o tráfego para um serviço ou uma instância específica dentro de um cluster de contêineres deve ser capaz de obter um endereço IP. Afinal, por mais que os contêineres ocultem a rede da aplicação, eles ainda dependem dela para transportar dados de um lugar para outro.
O Quarto Plano: Orquestração
Isso introduz uma nova camada arquitetural na infraestrutura, que interage com ambientes de orquestração de contêineres. Essa camada — a camada de orquestração — integra-se ao ambiente de contêineres e utiliza recursos como a descoberta de serviços para automatizar a identificação de serviços e instâncias. Isso significa que um balanceador de carga pode descobrir automaticamente os membros de um pool e atualizá-lo continuamente com base nas mudanças no ambiente. Dessa forma, reduz-se a necessidade de as equipes de operações atualizarem manualmente os pools de balanceamento de carga — uma tarefa cada vez mais tediosa quando os contêineres têm uma vida útil média inferior a uma semana.

Este plano não se destina à interação com operadores. A configuração, o monitoramento e a operação continuam sendo realizados por meio de um plano de gerenciamento. A localização de um registro de serviços seria configurada por meio do plano de gerenciamento, mas usada pelo plano de orquestração para se conectar ao plano de controle e comunicar alterações a ele.
Podemos definir o plano de orquestração da seguinte forma.
- O plano de orquestração é um dos planos menos visíveis na arquitetura de infraestrutura. A interação com ele ocorre por meio do plano de gerenciamento, cuja principal responsabilidade é direcionar o plano de orquestração para o registro de serviços apropriado. Sua função é atualizar os componentes dinâmicos no plano de controle para garantir o encaminhamento adequado e a disponibilidade dos recursos em contêineres.
Ainda há dúvidas sobre se esse plano deve ser integrado ao dispositivo juntamente com os planos de controle e de dados ou se ele é simplesmente uma camada sobre o plano de gerenciamento (o que alteraria ligeiramente nosso diagrama, mas não afetaria a interação entre planos e componentes). Muitos dispositivos tradicionais já oferecem suporte a esse plano emergente por meio de extensões que se integram a ambientes de contêineres e realizam alterações por meio do plano de gerenciamento. Esse é um bom exemplo de refatoração de arquiteturas tradicionais para ampliar a funcionalidade em ambientes modernos. Mas, em última análise, talvez não seja a solução ideal.
Por que isso é importante?
À primeira vista, pode parecer que a introdução de um quarto plano para a infraestrutura não faz diferença. Afinal, sua função é tirar dos operadores parte da responsabilidade por tarefas tediosas. Isso não pode ser ruim.
Isso não é ruim, mas é importante entender que essa mudança de uma configuração estática para uma configuração dinâmica traz consequências para algumas das funções mais importantes do plano de controle. A descoberta de serviços se torna tão crítica que garantir sua disponibilidade e segurança deve ser uma prioridade. Na prática, ela se torna o ponto único de falha do qual depende toda a infraestrutura da sua aplicação.
Os registros de serviços são construídos com base nas mesmas premissas que sustentam a maioria das aplicações modernas: eles são projetados para lidar com falhas. Pode ocorrer uma situação em que o endereço IP que você acabou de descobrir desapareça antes que seja possível encaminhar o tráfego para a instância correspondente. A maioria das infraestruturas consegue retransmitir nesse momento, mas o processo leva tempo. Microssegundos fazem diferença na economia digital, portanto, opções tradicionais como tempos limite e intervalos de descoberta terão impacto nas arquiteturas modernas que dependem da descoberta. O monitoramento também se torna muito mais crítico, pois a capacidade de determinar a integridade e a disponibilidade o mais rápido possível pode fazer a diferença entre um usuário satisfeito e um usuário que deixa de interagir. Ambas são questões de negócios das quais todos em uma organização moderna devem estar cientes e incorporar às suas próprias métricas e expectativas.
A implementação do plano de orquestração em sua infraestrutura, bem como a escolha do registro de serviços, tornam-se fatores importantes no processo de decisão sobre qual tecnologia utilizar. Avalie cuidadosamente suas opções, pois elas afetam tanto a disponibilidade quanto o desempenho das aplicações fornecidas por meio de arquiteturas baseadas em contêineres.
Sobre o autor

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...