Networking na Era dos Contêineres

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

Para aqueles que ainda não estão familiarizados com os padrões de tráfego do seu data center, vamos recapitular: Norte-sul é do usuário para o aplicativo ou do cliente para o servidor ou dentro e fora do data center. Leste-oeste é de servidor para servidor, de aplicativo para aplicativo, de serviço para serviço ou simplesmente dentro do data center.

Os padrões de tráfego norte-sul são impactados pelo aumento de usuários, aplicativos e coisas assim. Quanto mais conexões entre usuário e aplicativo forem necessárias, mais tráfego norte-sul você verá. O tráfego leste-oeste é afetado pelas arquiteturas de aplicativos e pela tecnologia de infraestrutura. Ao combinar tecnologias como virtualização e contêineres com arquiteturas emergentes, como microsserviços, você acaba tendo um aumento exponencial no número de “aplicativos” ou “serviços” que devem se comunicar entre si no data center.

Basicamente , quanto mais distribuída uma arquitetura de aplicativo e sua infraestrutura se tornam, mais tráfego leste-oeste você verá.

Somando-se a esse aumento está a tendência de aplicativos de “dimensionamento correto”. Em vez de o planejamento de capacidade ser baseado em projeções de crescimento, a capacidade é baseada no que é necessário agora, mais um pouco. Graças ao amadurecimento de tecnologias como o dimensionamento automático, podemos usar recursos de forma mais eficiente, deixando menos recursos de computação e rede ociosos, consumindo orçamento sem produzir valor correspondente . A propósito, esse é um dos benefícios da nuvem privada: a capacidade de aproveitar melhor os recursos que, de outra forma, permaneceriam ociosos, fornecendo provisionamento e gerenciamento orientados a serviços que permitem o uso de 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 a dos aumentos norte-sul.

Agora, cada mudança significativa nas arquiteturas de aplicativos e tecnologia nos últimos vinte anos resultou em uma reação igual na “rede”. Isso ocorre porque a rede é responsável por gerenciar o tráfego, não importa a direção que ele esteja tomando. Leste-oeste, norte-sul, não importa. Seja virtual ou físico, há uma rede envolvida para garantir que o tráfego vá de onde está para onde precisa estar.

A questão agora, já que estamos vendo aumentos ainda maiores no tráfego leste-oeste graças à decomposição de aplicativos devido aos microsserviços, é como a rede deve responder? Mais precisamente, como os serviços na rede devem responder para fornecer as funções críticas (disponibilidade, segurança, otimização) necessárias para entregar aplicativos aos usuários ou, cada vez mais, a outros aplicativos?

IMPACTO UM: MUDANDO PARA O APLICATIVO 

Claramente, a primeira resposta a essa pergunta é que os serviços afins de aplicativos devem se aproximar do aplicativo . Eles não podem permanecer lá fora, na borda do padrão norte-sul, e fornecer serviços para aplicativos que os consomem principalmente em um padrão leste-oeste. Esse é o uso ineficiente dos recursos de rede e o impacto dos padrões de roteamento que causam latência na comunicação do aplicativo. É aqui que começamos a ouvir termos como “tromboning” e “hairpinning” de padrões de tráfego que descrevem uma rota pela rede que requer sair de uma máquina, atravessar a rede em direção ao norte e depois retornar à mesma máquina. Essa latência se traduz em custos comerciais reais em termos de produtividade reduzida ('tenha paciência comigo, meu 'computador' está lento hoje') e maior abandono de carrinhos de compras e aplicativos da web por parte dos consumidores. É isso que queremos evitar: se o tráfego estiver indo de leste a 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 aplicativos web, devem ser implantáveis em formatos operacionalmente compatíveis. Em outras palavras, não vamos colocar hardware de rede na frente de cada aplicativo (ou microsserviço) que aparecer. Portanto, as plataformas nas quais esses serviços são fornecidos devem ser virtualizadas ou conteinerizadas para serem operacionalmente compatíveis com arquiteturas e tecnologias emergentes. Eles também devem ser programáticos, fornecendo APIs e modelos que permitam uma abordagem orientada a DevOps para provisionamento e gerenciamento. Os serviços, sejam eles de aplicativos ou de rede, precisam ser orquestráveis. A SDN, se puder se integrar com as ferramentas e estruturas que dominam os ambientes de infraestrutura e operações de aplicativos, também pode atender a essa necessidade. 

IMPACTO TRÊS: A ARQUITETURA É CRÍTICA

A terceira resposta é que a arquitetura se torna ainda mais importante do que nunca. Só porque alguém pode implantar um serviço de rede no mesmo host que seu aplicativo não significa necessariamente que ele deva ser implantado lá. Dependendo do que é e de qual será sua interação com outros serviços (e instâncias de serviços), o posicionamento se torna uma questão séria a ser considerada. O 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 é diretamente traduzível em lucro ou prejuízo comercial . Qualquer falha (hardware, software, rede, armazenamento) nesse cenário no host no qual os serviços são implantados resulta em tempo de inatividade (e um tempo de inatividade horrível) porque os serviços responsáveis por garantir que os aplicativos estejam disponíveis também estão inativos. Em uma arquitetura de aplicativo altamente decomposta (microsserviços), isso pode ser desastroso se as dependências desses aplicativos forem altas.

É necessária uma consideração cuidadosa (arquitetura) para garantir que as melhores práticas relacionadas ao desempenho e à disponibilidade não sejam ignoradas pela atração da resposta mais óbvia (e fácil).

O NETWORKING CONTINUA SENDO UM EXERCÍCIO DE ARQUITETURA

O networking é e continua sendo um esforço arquitetônico. Não se trata apenas de fatores de forma, é apenas uma maneira de obter recursos de rede onde você precisa, de forma mais rápida e eficiente. Trata-se do posicionamento desses recursos e de como isso afeta tudo a montante na pilha: os serviços de rede, os serviços de aplicativo, o desempenho do aplicativo e, finalmente, o sucesso do negócio - ou o fracasso.

A rede na era dos contêineres, da virtualização e da nuvem tem tanto a ver com arquitetura quanto com operações.