Como usar o F5 BIG-IP para eliminar camadas ao escalar aplicações em contêineres

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

Ou seriam “lágrimas” de frustração? ¯\_(ツ)_/¯ Talvez sejam as duas coisas.

Existe uma relação entre as arquiteturas de rede e de aplicações. Normalmente, gostamos de falar sobre como as mudanças e transformações nas arquiteturas de aplicações afetam a rede, tanto em termos de soluções quanto de sua arquitetura. Mas o inverso também é verdadeiro: a arquitetura e o comportamento da rede podem ter um impacto bastante significativo nas aplicações e em sua arquitetura.

A saber, um dos motivos pelos quais estamos vendo a decomposição de monólitos em muitos microsserviços agora em vez de isso ter ocorrido durante a era da SOA é a rede. Ou, para ser mais preciso, a velocidade da rede. Na época da SOA, havia limitações impostas pela natureza das redes (e pelas leis da física) que tornavam impossível compor uma única resposta a partir de mais de três ou quatro serviços. Bem, não impossível, mas indesejável devido à latência gerada por cada chamada.

Hoje, temos redes mais rápidas e com maior largura de banda, além de uma capacidade computacional uma ordem de grandeza mais veloz, o que torna essa decomposição viável. Isso fica ainda mais fácil graças à natureza dos contêineres, que costumam acompanhar os microsserviços como café e donuts. Como “a rede” entre dois serviços que precisam se comunicar muitas vezes é uma construção virtual (os pacotes nunca chegam a sair do servidor host e, portanto, não sofrem a latência decorrente de serem “colocados na rede”), o número de serviços que podem ser acionados para responder a uma única solicitação é muito maior do que seria razoavelmente possível alcançar na época da SOA.

No entanto, isso não significa que devemos ignorar quantas conexões e saltos precisamos percorrer para responder a uma solicitação, nem o impacto que a arquitetura exerce sobre o desempenho da aplicação. Afinal, embora o processamento esteja mais rápido e a largura de banda seja maior, a sobrecarga operacional ainda é algo com que precisamos lidar — e que continua prejudicando o desempenho. Uma das maneiras mais fáceis de lidar com a sobrecarga operacional (e melhorar o desempenho) é reduzir a complexidade, eliminando camadas (desnecessárias) da arquitetura.

Reduzindo a complexidade dos ambientes de contêineres

A maioria das implantações de contêineres usa algum tipo de balanceador de carga dentro do cluster para gerenciar a escala dos microsserviços/aplicativos no ambiente de contêineres. Isso ocorre porque esses balanceadores geralmente são responsáveis pelo roteamento de APIs na camada 7 (ou seja, pelo controle de entrada), enquanto os mecanismos nativos de balanceamento de carga são baseados em iptables, que, obviamente, não entende HTTP — a linguagem do roteamento na camada 7. Portanto, há vários balanceadores de carga de camada 7 dentro do cluster de contêineres.

Agora, a maioria das implantações também precisará de balanceamento de carga fora do cluster para direcionar o tráfego externo ao balanceador de carga correto dentro do cluster. Para isso, elas usam o tradicional balanceamento de carga para distribuir as solicitações ao balanceador de carga correto dentro do cluster.

Chamaremos o balanceador de carga externo de BIG-IP e o que fica dentro do cluster de balanceador de carga interno. Porque o blog é meu, por isso.

O problema é que o número de instâncias do balanceador de carga interno varia (às vezes drasticamente). Sempre que há uma mudança, o BIG-IP precisa ser informado. Tradicionalmente, essa tem sido uma operação manual, exigindo que o responsável pelo BIG-IP acesse o sistema e modifique o pool manualmente. Isso é frustrante para as equipes de desenvolvimento e DevOps e trabalhoso para a equipe de NetOps. Em outras palavras, ninguém quer fazer isso dessa forma.

É por isso que existem soluções como o F5 Container Connector. O F5 Container Connector é um serviço nativo de contêineres que se integra ao orquestrador de contêineres e monitora o ambiente. Quando ocorre uma alteração que afeta um balanceador de carga interno, ele aciona um processo para atualizar o BIG-IP. Isso significa que, conforme a demanda aumenta ou diminui, o BIG-IP é mantido automaticamente atualizado e consegue distribuir adequadamente as solicitações para um balanceador de carga interno ativo e íntegro. Não é necessária nenhuma alteração manual.

Essa arquitetura de escalabilidade em duas camadas tem a vantagem de oferecer um ponto de entrada conveniente (o BIG-IP) no qual o SSL/TLS pode ser terminado, proporcionando melhorias mensuráveis de desempenho. Ótimo.

Mas por que parar por aí? O BIG-IP é capaz de fornecer roteamento de camada 7. Se você utiliza os serviços do F5 Container Connector, pode obter ganhos adicionais de desempenho (e reduzir a sobrecarga operacional) eliminando completamente o balanceador de carga interno . É verdade. O BIG-IP pode atuar como um controlador de entrada para Kubernetes e Red Hat OpenShift.

Ao transferir a responsabilidade pelo ingresso para o BIG-IP, você elimina toda uma camada de escalabilidade (o balanceador de carga interno), o que melhora imediatamente o desempenho. Como o balanceador de carga externo é um F5 BIG-IP, você também pode implantar serviços de aplicativos voltados à segurança, como um WAF avançado com proteção contra bots, no ponto de contato, em vez de dentro do cluster de contêineres (ou simplesmente não os implantar).

Confronto entre os clãs de operações

À medida que os contêineres forem implantados em produção com mais frequência (e serão), haverá uma necessidade de maior colaboração entre DevOps e NetOps para implementar esses tipos de melhorias e garantir a escalabilidade, a velocidade e a segurança dos aplicativos. Afinal, não se trata apenas de apertar botões e usar pipelines de autoatendimento. A arquitetura é um componente essencial que precisará ser projetado com a contribuição tanto de DevOps quanto de NetOps, para não deixarmos de aproveitar oportunidades de melhorar aspectos como o desempenho dos aplicativos.

Isso porque o desempenho das aplicações é um trabalho em equipe. Ele é afetado pelo código (AppDev), pela plataforma em que o código é implantado (DevOps), pela arquitetura de rede e pelos serviços de aplicação usados para proteger e dimensionar a aplicação (NetOps). Adotar a otimização arquitetural, eliminando camadas sempre que possível, faz sentido tanto do ponto de vista operacional quanto empresarial. Mas isso exige a participação de todos os integrantes da equipe.

Então, peça pizza e cerveja, reúna as equipes de DevOps e NetOps e comece a conversar. Descubra se você também pode melhorar o desempenho dos aplicativos eliminando camadas desnecessárias do seu ambiente de contêineres.

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