Escalabilidade é um recurso essencial tanto para negócios quanto para aplicativos. Do lado comercial, escalonar as operações é essencial para viabilizar a nova economia de aplicativos e seu estado quase constante de implantação frenética. No lado da aplicação, a escalabilidade é a forma como damos suporte ao crescimento das populações de consumidores e empresas, garantindo desempenho e disponibilidade de alto nível para ambos.
No centro da escalabilidade está o balanceamento de carga. Desde meados da década de 1990, o balanceamento de carga tem sido a maneira pela qual dimensionamos aplicativos distribuindo cargas de trabalho entre conjuntos cada vez maiores de servidores, redes, aplicativos e serviços.
Antigamente, o balanceamento de carga tinha tudo a ver com a rede. Com base em técnicas e protocolos existentes que dimensionavam redes, o balanceamento de carga se concentrou nos aspectos da comunicação cliente-servidor que poderiam ser usados para distribuir cargas de trabalho. Nascia o Plain Old Load Balancing (POLB).
Funcionou, e funcionou bem. Sem o POLB é quase impossível saber se a web como a conhecemos teria se concretizado. Foi – e ainda é – essencial para dar suporte à população corporativa e de consumidores de hoje, bem como para dar suporte à população de amanhã.
Em algum momento no início dos anos 2000, a localização estratégica do balanceador de carga fez dele a plataforma perfeita para expansão para outros recursos que melhorassem a experiência do aplicativo. Aceleração, otimização, armazenamento em cache e compactação de aplicativos foram eventualmente adicionados. A segurança também encontraria seu caminho para essa mesma plataforma, já que sua posição na rede seria perfeita demais para ser ignorada. Como guardião dos aplicativos, sua capacidade de inspecionar, extrair, modificar e transformar o tráfego de aplicativos fornece insights exclusivos que se aplicam tanto à segurança quanto ao desempenho.
Em algum momento no início dos anos 2000, fomos além do POLB e nos tornamos outra coisa. Os balanceadores de carga se tornaram plataformas de entrega de aplicativos, tão competentes em entregar aplicativos seguros, rápidos e disponíveis quanto antes em escaloná-los com o POLB.
O ADC (controlador de entrega de aplicativos), como essas plataformas modernas são conhecidas, é capaz não apenas de oferecer recursos POLB, mas uma verdadeira cornucópia de recursos que o tornam inestimável para as pessoas que hoje são encarregadas não apenas de implantar aplicativos, mas também de entregá-los.
Cada vez mais, não são as equipes de rede, mas os arquitetos e as operações.
Essa mudança foi impulsionada por uma série de tecnologias que surgiram na última década. Do ágil à nuvem, do DevOps ao mobile, as melhores práticas hoje estão levando alguns serviços de aplicativos para fora da rede e para o domínio dos aplicativos.
E durante a transferência de responsabilidade pela escalabilidade da rede para arquitetos e operações, o ADC está sendo implantado como se estivesse preso na década de 1990. Tratado como um POLB, a maior parte do valor que ele oferece aos arquitetos e operações na melhoria do desempenho e da segurança é deixado na mesa (ou, mais apropriadamente, no rack).
Isso geralmente ocorre porque os arquitetos e equipes de operações agora responsáveis por dimensionar aplicativos não estão familiarizados com o que um ADC pode fazer por eles e, mais importante, com seus aplicativos e arquiteturas. É hora de mudar isso e ir além do POLB.
O objetivo do POLB era simples: disponibilidade. Seja por meio da implementação de uma arquitetura HA (Alta Disponibilidade) baseada em redundância ou usando uma arquitetura de escalonamento N+1, o objetivo era o mesmo: manter o site (ou aplicativo) ativo e disponível, não importa o que aconteça.
Hoje o objetivo ainda é disponibilidade, mas aliado à eficiência e agilidade. Todas as três são características essenciais dos negócios modernos e das arquiteturas que dão suporte às suas aplicações críticas. Para chegar lá, no entanto, temos que ir além do POLB, para um mundo de roteamento de aplicativos e distribuição de carga que traz essas eficiências críticas para arquiteturas e infraestrutura de aplicativos. Esses recursos são baseados na camada 7 da pilha de rede – a camada de aplicação – e em arquiteturas modernas isso significa HTTP.
Os proxies L7 LB são capazes não apenas de distribuir carga com base em variáveis do aplicativo, como carga de conexão, tempos de resposta e status do aplicativo, mas também de despachar (rotear) com base em URLs, cabeçalhos HTTP e até mesmo dados dentro de mensagens HTTP.
Capazes de analisar, extrair e agir sobre esses vários tipos de dados da camada de aplicação, os balanceadores de carga L7 hoje podem participar e aumentar aplicativos e arquiteturas de microsserviços de várias maneiras, incluindo:
Como um L7 LB é posicionado logicamente a montante dos aplicativos que ele atende, ele tem visibilidade de cada solicitação – e resposta. Isso significa que ele é capaz de executar uma variedade de verificações e balanços em solicitações antes que elas possam prosseguir para a aplicação desejada. Essas verificações e equilíbrios são essenciais para garantir que o tráfego malicioso seja detectado e rejeitado, evitando que seus efeitos adversos afetem a estabilidade, a disponibilidade e a integridade dos aplicativos de back-end.
Mas é mais do que apenas impedir que tráfego ruim chegue aos servidores, é também impedir que agentes mal-intencionados. Isso significa ser capaz de identificá-los – e não apenas aqueles sem credenciais válidas, mas aqueles que estão usando credenciais que não lhes pertencem em primeiro lugar. O papel do controle de acesso vem crescendo à medida que o número de violações resultantes de credenciais roubadas tem aumentado. A nuvem também reintroduziu a urgência de gerenciar credenciais globalmente em todos os aplicativos, para reduzir o risco potencial de contas órfãs e de teste que concedem acesso a dados corporativos armazenados em aplicativos baseados em SaaS. A federação de identidades se tornou mais do que apenas uma estratégia de melhoria de produtividade, ela se tornou uma tática fundamental na estratégia geral de segurança corporativa.
Os recursos que podem ser adicionados a um LB L7 incluem aqueles que analisam o comportamento e a identidade dos clientes, bem como o conteúdo real das mensagens trocadas entre clientes e serviços de backend. Isso permite que o L7 LB execute funções que incluem:
O desempenho é um componente crítico para o sucesso da aplicação – e, portanto, do negócio. Antigamente, as organizações implantavam diversas soluções de aceleração de aplicativos na frente dos aplicativos para acelerar o processo de entrega. Os ADCs incorporaram essas mesmas soluções como componentes opcionais (adicionais), mas acabaram integrando esses recursos diretamente como parte dos principais recursos de balanceamento de carga; um reflexo da importância do desempenho para seu foco principal na entrega de aplicativos e serviços.
Por isso, o L7 LB possui uma variedade de recursos e funções focadas em melhorar o desempenho. Algumas dessas funções – em particular aquelas que atuam nas respostas do aplicativo enviadas de volta ao cliente – são focadas no conteúdo. Muitas delas são técnicas básicas de desenvolvimento usadas para tornar o conteúdo menor, enquanto outras se concentram em diminuir o número de viagens de ida e volta entre o cliente e o servidor necessárias.
Também é importante observar que os proxies L7 não se concentram apenas na otimização de conteúdo, mas também são facilitadores essenciais de arquiteturas focadas em desempenho, que incluem técnicas de balanceamento de carga de banco de dados, bem como a integração de caches na memória (como o memcached) para melhorar o desempenho geral do aplicativo. Os proxies L7 adequados para habilitar essas arquiteturas geralmente são habilitados com uma linguagem de script de caminho de dados que fornece a capacidade de personalizar a distribuição e o roteamento.
Outros recursos estão focados na redução da sobrecarga em servidores de backend como uma forma de melhorar o desempenho, além de poder distribuir a carga com base nos limites de desempenho.
A otimização de recursos e capacidades de um L7 LB inclui:
Lado do cliente (Otimização de resposta) |
Lado do servidor de backend |
• Minificação • Compressão HTTP • Buffering • Agregação de scripts • Descarregamento SSL |
• Multiplexação TCP • Cache • Distribuição de carga baseada no desempenho • Auto-escalabilidade |
Se qualquer infraestrutura deve ser mais integrada à arquitetura do aplicativo, ela deve ser capaz de ser integrada ao pipeline de CI/CD. Isso significa dar suporte a metodologias modernas, relacionadas a DevOps e Agile, e aos conjuntos de ferramentas que permitem a execução de estratégias automatizadas de lançamento e entrega.
Para isso, o L7 LB deve fornecer não apenas APIs por meio das quais ele pode ser gerenciado, mas também os meios pelos quais ele pode ser monitorado e implantado para garantir que o feedback e a entrega contínuos sejam possíveis para atender aos cronogramas e orçamentos exigentes de hoje.
O F5 oferece suporte a uma variedade de opções programáticas para provisionamento, implantação, gerenciamento e monitoramento da infraestrutura L7 LB, incluindo:
Há uma variedade de razões pelas quais a responsabilidade pela infraestrutura de aplicativos como POLB e L7 LB está sendo transferida das equipes de rede para as equipes de aplicativos e operações. Seja a adoção do Agile ou DevOps como uma resposta à demanda empresarial por mais aplicativos com prazos de entrega mais curtos ou à necessidade de escalar mais rapidamente do que nunca, ir além do POLB fornecerá uma gama maior de opções de segurança, desempenho e disponibilidade necessárias para dar suporte a aplicativos modernos e arquiteturas de entrega em uma plataforma única, gerenciável e programável que se encaixa no pipeline moderno de CI/CD.
É hora de considerar ir além do POLB e começar a aproveitar a infraestrutura que está cada vez mais caindo em seu domínio.