Redes na Era dos Contêineres

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

Nos últimos anos, à medida que a virtualização e, agora, a conteinerização aumentaram a densidade de aplicativos em cada componente de hardware, ficamos obcecados com o desafio de gerenciar o tráfego leste-oeste em vez do tráfego norte-sul.

Para quem ainda não está muito familiarizado com os padrões de tráfego de data centers, vamos recapitular: Norte-sul é o tráfego entre usuário e aplicativo, entre cliente e servidor ou de entrada e saída do data center. Leste-oeste é o tráfego entre servidores, entre aplicativos, entre serviços ou simplesmente dentro do data center.

Os padrões de tráfego norte-sul são afetados pelo aumento do número de usuários, aplicativos e dispositivos. Quanto mais conexões entre usuários e aplicativos forem necessárias, maior será o tráfego norte-sul. O tráfego leste-oeste é afetado pelas arquiteturas de aplicativos e pela tecnologia de infraestrutura. Quando tecnologias como virtualização e contêineres são combinadas com arquiteturas emergentes, como microsserviços, ocorre um aumento exponencial no número de “aplicativos” ou “serviços” que precisam se comunicar entre si em todo o data center.

Basicamente, quanto mais distribuídos se tornam a arquitetura de uma aplicação e sua infraestrutura, mais tráfego leste-oeste você verá.

Somando-se a esse aumento, há a tendência de dimensionar os aplicativos de acordo com as necessidades reais. Em vez de o planejamento da capacidade se basear em projeções de crescimento, a capacidade é definida com base no que é necessário agora, acrescido de uma pequena margem. Graças ao amadurecimento de tecnologias como o escalonamento automático, podemos usar os recursos com mais eficiência, reduzindo a quantidade de recursos computacionais e de rede ociosos, que ficam consumindo orçamento sem gerar um valor proporcional. Aliás, esse é um dos benefícios da nuvem privada: a capacidade de aproveitar melhor recursos que, de outra forma, permaneceriam ociosos e seriam desperdiçados, por meio do provisionamento e do gerenciamento orientados a serviços, que permitem o uso dos recursos em tempo real.

Mas estou divagando. A questão é que o tráfego leste-oeste está aumentando graças às arquiteturas e tecnologias, a uma taxa que provavelmente supera o crescimento do tráfego norte-sul.

Agora, toda mudança significativa nas arquiteturas e tecnologias de aplicações ao longo dos últimos vinte anos provocou uma reação equivalente na “rede”. Isso porque a rede é responsável por gerenciar o tráfego, independentemente da direção em que ele flui. Leste-oeste, norte-sul, não importa. Seja virtual ou física, a rede está envolvida em garantir que o tráfego vá de onde está para onde precisa chegar.

A questão agora, diante do aumento ainda maior do tráfego leste-oeste decorrente da decomposição das aplicações em razão dos microsserviços, é: como a rede deve responder? Mais precisamente, como os serviços na rede devem responder para fornecer as funções essenciais (disponibilidade, segurança e otimização) necessárias para disponibilizar aplicações aos usuários ou, cada vez mais, a outras aplicações?

IMPACTO UM: MIGRANDO PARA O APLICATIVO

Muito claramente, a primeira resposta a essa pergunta é que os serviços com afinidade ao aplicativo precisam se aproximar dele. Eles não podem continuar lá fora, na borda do padrão norte-sul, prestando serviços a aplicativos que os consomem principalmente em um padrão leste-oeste. Isso representa um uso ineficiente dos recursos de rede, e os padrões de roteamento resultantes geram latência na comunicação entre aplicativos. É nesse contexto que começamos a ouvir termos como “tromboning” e “hairpinning” para descrever padrões de tráfego em que uma rota pela rede precisa sair de uma máquina, percorrer a rede em direção ao norte e depois retornar à mesma máquina. Essa latência se traduz em custos reais para as empresas, na forma de redução da produtividade (‘tenha paciência, meu ‘computador’ está lento hoje’) e aumento do abandono de carrinhos de compras e aplicativos web pelos consumidores. É isso que queremos evitar; se o tráfego flui no sentido leste-oeste, os serviços devem estar nesse caminho de dados.

IMPACTO DOIS: COMPATIBILIDADE OPERACIONAL

A segunda resposta é que esses serviços, como balanceamento de carga e segurança de aplicações web, devem poder ser implantados em formatos operacionalmente compatíveis. Em outras palavras, não vamos instalar hardware de rede na frente de cada aplicação (ou microsserviço) que surgir. Portanto, as plataformas nas quais esses serviços são fornecidos devem ser virtualizadas ou conteinerizadas para que sejam operacionalmente compatíveis com arquiteturas e tecnologias emergentes. Elas também devem ser programáveis, oferecendo APIs e modelos que viabilizem uma abordagem orientada a DevOps para provisionamento e gerenciamento. Os serviços, sejam eles de aplicação ou de rede, precisam ser orquestráveis. A SDN, se puder ser integrada às ferramentas e aos frameworks predominantes nos ambientes de operações de infraestrutura e aplicações, também poderá atender a essa necessidade.

IMPACTO TRÊS: A ARQUITETURA É FUNDAMENTAL

A terceira resposta é que a arquitetura se torna ainda mais importante do que nunca. O simples fato de ser possível implantar um serviço de rede no mesmo host que seu aplicativo não significa necessariamente que ele deva ser implantado ali. Dependendo do que ele é e de como será sua interação com outros serviços (e instâncias de serviços), o posicionamento se torna uma questão importante a ser considerada. Um balanceamento de carga mal arquitetado, por exemplo, pode resultar em padrões de tráfego assustadores que geram latência desnecessária; latência que pode ser traduzida diretamente em lucro — ou prejuízo — para a empresa. Qualquer falha (de hardware, software, rede ou armazenamento) nesse cenário, no host em que os serviços estão implantados, resulta em indisponibilidade (e das piores), pois os serviços responsáveis por garantir a disponibilidade dos aplicativos também ficam fora do ar. Em uma arquitetura de aplicativos altamente decomposta (microsserviços), isso pode ser desastroso se houver um alto grau de dependência desses aplicativos.

É necessário avaliar cuidadosamente a arquitetura para garantir que as práticas recomendadas de desempenho e disponibilidade não sejam deixadas de lado pela atração da solução mais óbvia (e mais fácil).

A REDE CONTINUA SENDO UM EXERCÍCIO DE ARQUITETURA

A rede é e continua sendo um esforço de arquitetura. Não se trata apenas de formatos físicos; eles são apenas uma forma de disponibilizar os recursos de rede onde você precisa deles, com mais rapidez e eficiência. Trata-se do posicionamento desses recursos e de como isso afeta tudo o que está acima na pilha: os serviços de rede, os serviços de aplicativos, o desempenho dos aplicativos e, em última análise, o sucesso — ou o fracasso — dos negócios.

Na era dos contêineres, da virtualização e da nuvem, as redes dizem respeito tanto à arquitetura quanto às operações.

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