O tradutor de coloquialismo de contêiner para NetOps

Há dias em que o jargão que vem do termo container land faz sua cabeça girar. Com cada nova capacidade ou recurso oferecido por soluções relacionadas – malha de serviço, orquestradores, registros – parece exigir um novo termo ou frase. Essa frase geralmente faz sentido para o DevOps, mas evoca uma expressão confusa e confusa do NetOps.

Mais ou menos como aquela que você faz quando pergunto onde fica o bebedouro mais próximo. Você chama isso de fonte de água. Em Wisconsin, chamamos isso de borbulhador. Mesma coisa, termo diferente.

Acontece que muitos dos "novos" recursos e capacidades relacionados ao dimensionamento de contêineres internamente e em cenários de multi-nuvem são, na verdade, apenas fontes de água que o DevOps está chamando de borbulhador. Esse choque de coloquialismos pode causar atrito com o NetOps, já que os contêineres continuam a se tornar populares sem parar. Mesmo que os clusters de contêineres mantenham uma existência isolada, semelhante a uma mini-nuvem, na produção, ainda há pontos de contato com a rede corporativa sobre os quais o NetOps continua a reinar. E, invariavelmente, NetOps e DevOps terão que trabalhar juntos para dimensionar esses clusters com segurança em um mundo multinuvem.

CONTROLADOR DE ENTRADA

• Como foi observado , o termo “controlador de entrada” deu uma nova cara ao balanceamento de carga da camada 7 (troca de conteúdo, roteamento de conteúdo, etc.). Um controlador de entrada é um proxy compatível com a camada 7 (HTTP) que roteia solicitações para o recurso apropriado dentro de um cluster de contêineres.  A diferença significativa entre os proxies HTTP usados pelo NetOps na rede e aqueles que servem como pontos de entrada para clusters de contêineres é que um controlador de entrada deve estar ciente do contêiner. Por "ciente do contêiner", quero dizer que ele é configurado e gerenciado automaticamente com base nas alterações que ocorrem no ambiente do contêiner, particularmente no arquivo de recursos que descreve como o ingress deve rotear as solicitações de entrada.

Balanceamento de carga com reconhecimento de latência

• Parece legal e fresco, não é? Mas quando você retira o quimono, a NetOps concorda enfaticamente ao descobrir que isso não é nada além de alavancar um algoritmo de balanceamento de carga de "resposta mais rápida". A intenção é melhorar o desempenho do aplicativo “ desviando o tráfego de instâncias lentas ”. O motivo pelo qual isso é mencionado é porque, em geral, os algoritmos nativos de balanceamento de carga usados pelos orquestradores de contêineres são apáticos. Round Robin é praticamente o padrão, e sabemos que é o último algoritmo que você deve escolher se estiver tentando otimizar o desempenho. Ser capaz de rotear solicitações com base no melhor desempenho é muito importante, considerando que cada chamada de microsserviço para microsserviço feita para atender a uma única solicitação de cliente adiciona latência própria.

Entrada multi-cluster

• Vou começar dizendo que isso soa muito mais legal do que o termo que a indústria vem usando há quase vinte anos. Essencialmente, isso é GSLB (Balanceamento Global de Carga de Servidor). Sim, eu sei que você está decepcionado, mas, nos bastidores, é isso que o ingresso multicluster faz. Você pega um controlador de entrada e espalha um pouco de gerenciamento de tráfego global ao redor dele e pronto! Você tem GSLB para clusters de contêineres em uma configuração de várias nuvens. Estou votando para substituir GSLB por este termo no lado do NetOps, porque soa mais impressionante.

Esses não são os únicos termos que aparecem, nem serão os últimos. Eles são os mais relevantes em termos de funcionalidade e capacidades “na rede” sendo subsumidos pelo DevOps. Alguns deles precisarão da atenção do NetOps à medida que forem migrando para ambientes de produção (como o Multi-Cluster Ingress) e outros não. O balanceamento de carga com reconhecimento de latência dentro de ambientes de contêiner provavelmente continuará sendo responsabilidade do DevOps, embora seja bom ter um entendimento durante as discussões sobre como melhorar o desempenho ou a disponibilidade.

Há um componente cultural no DevOps que é frequentemente negligenciado ou completamente ignorado. À medida que o movimento continua a deixar sua marca no 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 crítica. Isso significa encontrar um ponto em comum. Entender o jargão um do outro pode ser um bom primeiro passo para construir uma cultura mais colaborativa necessária para garantir que as implantações de aplicativos sejam tão rápidas, seguras e confiáveis quanto sua entrega.