Uso do BIG-IP da F5 para eliminar camadas ao dimensionar aplicações em contêineres

Ou seriam ‘lágrimas’ de frustração? ¯\_(ツ)_/¯ Talvez sejam ambos.

Existe uma relação entre arquiteturas de rede e de aplicação. Normalmente gostamos de falar sobre como mudanças e transformações nas arquiteturas de aplicativos impactam 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 drástico nos aplicativos e em sua arquitetura.

Ou seja, uma das razões pelas quais estamos vendo a decomposição de monólitos em muitos microsserviços agora, em vez de durante os anos do SOA, é por causa da rede. Ou para ser mais preciso, por causa da velocidade da rede. Na época do SOA, havia limitações impostas pela natureza da rede (e pelas leis da física) que tornavam impossível compor uma única resposta de mais de três ou quatro serviços. Ok, não é impossível, mas é indesejável devido à latência de cada chamada.

Hoje, temos redes mais rápidas e mais completas e uma computação muito mais rápida que torna essa decomposição viável. O que torna tudo ainda mais fácil é a natureza dos contêineres que muitas vezes são combinados com microsserviços como café com donuts. Como “a rede” entre dois serviços que precisam se comunicar é frequentemente uma construção virtual (os pacotes nunca saem do servidor host e, portanto, não sofrem a latência incorrida para serem “colocados na rede”), o número de serviços que podem ser invocados para responder a uma única solicitação é muito maior do que poderíamos razoavelmente atingir nos dias do SOA.

Isso não significa, no entanto, que devemos ignorar quantas conexões e saltos temos que percorrer para responder a uma solicitação ou o impacto que a arquitetura tem no desempenho do aplicativo. Porque mesmo que a computação seja mais rápida e os pipelines sejam mais pesados, a sobrecarga operacional ainda é algo com que temos que lidar. Algo que ainda impede 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) em uma arquitetura.

Reduzindo a complexidade de ambientes de contêiner

A maioria das implantações de contêineres usará algum tipo de balanceador de carga dentro do cluster para gerenciar a escala de microsserviços/aplicativos dentro do ambiente de contêiner. Isso ocorre porque eles geralmente são encarregados de fazer o roteamento L7 de APIs (que é o controle de entrada) e as construções nativas de balanceamento de carga são baseadas em iptables, que obviamente não falam HTTP – a linguagem do roteamento L7. Então, há um monte de balanceadores de carga L7 dentro do contêiner do cluster.

Agora, a maioria das implantações também vai querer balanceamento de carga fora do cluster para levar tráfego externo ao balanceador de carga correto dentro do cluster. Para fazer isso, eles usam o balanceamento de carga simples para distribuir solicitações para o balanceador de carga correto dentro dele.

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

O problema é que o número de instâncias lb internas flutua (às vezes drasticamente). Toda vez que houver uma mudança, o BIG-IP precisa saber. Tradicionalmente, essa tem sido uma operação manual, exigindo que o proprietário do BIG-IP saia e modifique o pool manualmente. Isso é frustrante para o desenvolvimento e o DevOps, e tedioso para o NetOps. Em outras palavras, ninguém quer fazer dessa maneira.

É por isso que existem soluções como o F5 Container Connector . O F5 Container Connector é um serviço nativo de contêiner que se integra ao orquestrador de contêineres e observa o ambiente. Quando há uma alteração que afeta um lb interno, isso aciona um processo para atualizar o BIG-IP . Isso significa que, à medida que a demanda aumenta e diminui, o BIG-IP é automaticamente mantido atualizado e capaz de distribuir adequadamente as solicitações para um lb interno ativo e saudável. Não é necessária nenhuma modificação manual.

Essa arquitetura de dimensionamento de duas camadas tem a vantagem de fornecer um local de entrada conveniente (o BIG-IP) no qual o SSL/TLS pode ser encerrado, proporcionando melhorias de desempenho mensuráveis. Legal.

Mas por que parar por aí? O BIG-IP é capaz de fornecer roteamento L7 . Se você estiver empregando os serviços do F5 Container Connector, poderá obter mais ganhos de desempenho (e menor sobrecarga operacional) eliminando completamente o lb interno . Realmente. O BIG-IP pode atuar como um controlador de entrada para o Kubernetes e o Red Hat OpenShift.

Ao mover a responsabilidade de entrada para o BIG-IP, você elimina uma camada inteira de escala (o lb interno), o que melhora imediatamente o desempenho. Como o lb externo é um F5 BIG-IP , você pode implantar ainda mais serviços de aplicativos focados em segurança, como um WAF avançado com defesa de bot no ponto de contato, em vez de dentro do cluster de contêineres (ou não implantá-lo). 

Choque de Clãs Ops

À medida que os contêineres entram em produção com mais frequência (e isso acontecerá), haverá uma necessidade de maior colaboração entre DevOps e NetOps para implementar esses tipos de melhorias e garantir a escala, a velocidade e a segurança dos aplicativos. Afinal, não se trata apenas de apertar botões e canais de autoatendimento. A arquitetura é um componente crítico que precisará ser projetado com a contribuição do DevOps e do NetOps, para que não ignoremos oportunidades de melhorar coisas como o desempenho dos aplicativos.

Porque o desempenho do aplicativo é um esporte de equipe. Ele é impactado pelo código (AppDev), pela plataforma na qual o código é implantado (DevOps), pela arquitetura de rede e pelos serviços de aplicativo usados para proteger e dimensionar o aplicativo (NetOps). Empregar otimização arquitetônica eliminando camadas quando possível faz sentido operacional e comercial. Mas requer a participação de todos os jogadores da equipe.

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