O Tradutor de Coloquialismos de Contêineres para NetOps

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Há dias em que o jargão do mundo dos contêineres deixa qualquer um de cabeça girando. Cada nova funcionalidade ou recurso oferecido por soluções relacionadas — malha de serviços, orquestradores, registros — parece exigir um novo termo ou expressão. Essa expressão muitas vezes faz sentido para o DevOps, mas deixa o NetOps com um olhar desconfiado e confuso.

É mais ou menos como a expressão que você faz quando pergunto onde fica o bebedouro mais próximo. Você o chama de “water fountain”. Em Wisconsin, nós o chamamos de “bubbler”. É a mesma coisa, só muda o termo.

Acontece que muitos dos “novos” recursos e funcionalidades relacionados ao dimensionamento de contêineres internamente e em cenários multinuvem são, na verdade, apenas bebedouros que o DevOps chama por outro nome. Esse choque de regionalismos pode gerar atritos com o NetOps à medida que os contêineres continuam avançando de forma ininterrupta rumo à adoção generalizada. Mesmo que os clusters de contêineres mantenham, em produção, uma existência isolada, semelhante a uma mininuvem, ainda há pontos de contato com a rede corporativa, sobre a qual o NetOps continua exercendo controle. E, inevitavelmente, NetOps e DevOps terão de trabalhar juntos para dimensionar esses clusters com segurança em um mundo multinuvem.

Controlador de Ingress

• Como já foi observado, o termo “controlador de ingresso” deu uma nova roupagem ao balanceamento de carga da camada 7 (comutação de conteúdo, roteamento de conteúdo etc.). Um controlador de ingresso é um proxy compatível com a camada 7 (HTTP) que encaminha as solicitações ao recurso apropriado dentro de um cluster de contêineres. A principal diferença entre os proxies HTTP usados pela equipe de operações de rede (NetOps) e aqueles que funcionam como pontos de entrada para clusters de contêineres é que um controlador de ingresso precisa estar ciente dos contêineres. Com “ciente dos contêineres”, quero dizer que ele é configurado e gerenciado automaticamente com base nas mudanças que ocorrem no ambiente de contêineres — especialmente no arquivo de recursos que descreve como o ingresso deve encaminhar as solicitações recebidas.

Balanceamento de carga com reconhecimento de latência

• Parece algo moderno e interessante, não é? Mas, ao analisar mais a fundo, a equipe de NetOps perceberá de imediato que isso nada mais é do que o uso de um algoritmo de balanceamento de carga baseado na “resposta mais rápida”. O objetivo é melhorar o desempenho da aplicação, “desviando o tráfego de instâncias lentas”. Isso merece destaque porque, em geral, os algoritmos nativos de balanceamento de carga usados por orquestradores de contêineres não levam o desempenho em consideração. O Round Robin é praticamente o padrão, embora saibamos que ele é um dos últimos algoritmos que você deveria escolher ao tentar otimizar o desempenho. A capacidade de encaminhar solicitações com base no melhor desempenho é muito importante, considerando que cada chamada entre microsserviços feita para atender a uma única solicitação do cliente acrescenta sua própria latência.

Entrada multicluster

• Vou começar dizendo que isso soa muito mais interessante do que o termo que o setor vem usando há quase vinte anos. Essencialmente, trata-se de GSLB (Balanceamento Global de Carga de Servidores). Sim, eu sei que você está decepcionado, mas, nos bastidores, é isso que o ingresso multicluster faz. Você pega um controlador de ingresso, adiciona uma pitada dos benefícios do gerenciamento global de tráfego e voilà! Você tem GSLB para clusters de contêineres em uma configuração multinuvem. Meu voto é substituir GSLB por esse termo no âmbito de NetOps, porque ele simplesmente soa mais impressionante.

Esses não são os únicos termos que surgiram, nem serão os últimos. Eles são os mais relevantes em termos de funcionalidades e recursos “na rede” que estão sendo incorporados pelo DevOps. Alguns deles exigirão a atenção do NetOps à medida que forem implementados em ambientes de produção (como o Ingresso Multicluster), enquanto outros não — o balanceamento de carga sensível à latência dentro de ambientes de contêineres provavelmente continuará sob a responsabilidade do DevOps, embora seja bom compreender o assunto durante discussões sobre como melhorar o desempenho ou a disponibilidade.

Há um componente cultural no DevOps que muitas vezes passa despercebido ou é simplesmente ignorado. À medida que o movimento continua a influenciar o NetOps e as operações de rede tradicionais adotam, lenta mas seguramente, seus princípios para alcançar uma rede ágil, a comunicação se torna essencial. Isso significa encontrar pontos em comum. Entender o jargão de cada área pode ser um bom primeiro passo para construir a cultura mais colaborativa necessária para garantir que as implantações de aplicações sejam tão rápidas, seguras e confiáveis quanto sua entrega.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

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 Vittie