A evolução dos controladores de entrega de aplicativos

No mundo dinâmico de hoje, as organizações enfrentam constantemente o desafio de entregar aplicativos essenciais a milhões de usuários ao redor do mundo. É extremamente importante que eles implantem serviços de rede e aplicativos para tornar os aplicativos escaláveis, seguros e disponíveis. Esta é uma das principais razões por trás da evolução dos Controladores de Entrega de Aplicativos (ADCs). Entretanto, nenhum desses recursos pode ser implementado sem uma base sólida em tecnologia básica de balanceamento de carga. Então, vamos começar entendendo a importância do balanceamento de carga, como ele leva à entrega eficiente de aplicativos e como os ADCs ainda estão evoluindo e adotando o mundo da nuvem em primeiro lugar.

O objetivo do balanceamento de carga é equilibrar o tráfego de entrada da rede ou do aplicativo em muitos servidores físicos e fazer com que esses servidores pareçam um único servidor para o mundo externo. Há muitos motivos para fazer isso, mas os principais motivadores são a necessidade de "escalabilidade", "alta disponibilidade" e "previsibilidade".

Escalabilidade é a capacidade de se adaptar dinamicamente, ou facilmente, ao aumento de carga sem afetar o desempenho existente. Alta disponibilidade (HA), por outro lado, é a capacidade de um site permanecer disponível e acessível mesmo durante a falha de um ou mais sistemas. A virtualização de serviços (imitação do comportamento de componentes de software para acelerar e testar o desenvolvimento de aplicativos) apresenta uma oportunidade interessante para escalabilidade e disponibilidade. Se o serviço ou ponto de contato do usuário for separado dos servidores reais, o aplicativo poderá ser dimensionado adicionando mais servidores. Além disso, a falha de um servidor individual não deixará o aplicativo inteiro indisponível. A previsibilidade é um pouco menos clara, pois representa partes da HA, bem como algumas lições aprendidas ao longo do caminho. Pode ser melhor descrito como ter controle sobre como e quando os serviços estão sendo entregues em relação à disponibilidade e ao desempenho.

Nos primórdios da Internet comercial, muitos aspirantes a milionários dotcom descobriram um problema sério em seus planos. Os mainframes não tinham software de servidor web (pelo menos não até o AS/400e) e, mesmo que tivessem, não tinham condições de adquiri-los com orçamentos iniciais. O que eles podiam pagar era hardware de servidor padrão e pronto para uso de um dos fabricantes de PC mais populares. O principal problema com a maioria deles era que não havia como um único servidor baseado em PC lidar com a quantidade de tráfego que seus negócios gerariam. E se isso acontecesse, eles ficariam offline e fora do mercado. Felizmente, algumas dessas pessoas tinham planos de ganhar milhões resolvendo esse problema específico. Isso levou ao nascimento do balanceamento de carga.

Antes de existirem dispositivos de balanceamento de carga comercialmente disponíveis e desenvolvidos especificamente para esse fim, houve muitas tentativas de utilizar a tecnologia existente para atingir as metas de escalabilidade e disponibilidade. A tecnologia mais prevalente (e ainda usada) era o DNS round-robin.

Com esse método, o DNS atribuiria vários endereços IP exclusivos a diferentes servidores, sob o mesmo nome DNS. Isso significava que na primeira vez que um usuário solicitasse uma resolução para “ www.example.com ”, o servidor DNS passaria cada nova conexão para o primeiro servidor da fila até chegar ao fim da fila, antes de retornar ao primeiro servidor novamente. Essa solução era simples e levou à distribuição uniforme de conexões entre uma série de máquinas.

Do ponto de vista da escalabilidade, essa solução funcionou muito bem, pois ofereceu uma oportunidade de adicionar um número quase ilimitado de servidores a um nome DNS. Entretanto, em relação à disponibilidade, a solução criou um obstáculo, pois o DNS não tinha capacidade de saber se os servidores listados estavam funcionando ou não. Se um servidor ficasse indisponível e um usuário tentasse acessá-lo, a solicitação poderia ser enviada para um servidor que estava inativo.

Outro fator determinante do round-robin de DNS foi a previsibilidade, que é um alto nível de confiança de que um usuário será enviado para um servidor específico. Isso se concentra na ideia de persistência — o conceito de garantir que um usuário não seja balanceado para um novo servidor depois que uma sessão tenha começado ou quando o usuário retome uma sessão suspensa anteriormente. Este é um problema muito importante que o DNS round-robin não conseguiu resolver.

Para resolver esse problema, uma das primeiras soluções desenvolvidas especificamente foi o balanceamento de carga integrado diretamente no software do aplicativo ou no sistema operacional (SO) do servidor de aplicativos. Embora houvesse tantas implementações diferentes quanto empresas que as desenvolveram, a maioria das soluções girava em torno de truques básicos de rede. Por exemplo, uma dessas soluções tinha todos os servidores em um pool (também conhecido como cluster), além de seu próprio endereço IP físico.

Quando os usuários tentavam se conectar ao serviço, eles se conectavam ao IP do pool em vez do IP físico do servidor. O servidor no pool que respondesse primeiro à solicitação de conexão redirecionaria o usuário para um endereço IP físico (seu próprio ou de outro sistema no pool) e a sessão de serviço seria iniciada. Um dos principais benefícios dessa solução foi que os desenvolvedores de aplicativos puderam usar uma variedade de informações para determinar a qual endereço IP físico o cliente deveria se conectar. Por exemplo, eles poderiam fazer com que cada servidor no pool mantivesse uma contagem de quantas sessões cada membro do pool já estava atendendo e, então, direcionar quaisquer novas solicitações para o servidor menos utilizado.

Inicialmente, a escalabilidade desta solução era clara. Tudo o que você precisava fazer era criar um novo servidor, adicioná-lo ao pool e aumentar a capacidade do seu aplicativo. Com o tempo, no entanto, a escalabilidade do balanceamento de carga baseado em aplicativos passou a ser questionada. Como os membros do pool precisavam permanecer em contato constante entre si para decidir para qual deles deveria ser feita a próxima conexão, o tráfego de rede entre os membros do pool aumentava exponencialmente a cada novo servidor adicionado ao pool. Depois que o pool cresceu até um certo tamanho (geralmente de 5 a 10 hosts), esse tráfego começou a impactar o tráfego do usuário final, bem como a utilização do processador dos próprios servidores. Portanto, a escalabilidade era ótima, desde que você não precisasse exceder um pequeno número de servidores (aliás, menos do que com o DNS round-robin).

O HA foi aumentado drasticamente com o DNS round-robin e balanceamento de carga de software. Como os membros do pool estavam em comunicação constante entre si e como os desenvolvedores de aplicativos podiam usar seu amplo conhecimento sobre aplicativos para saber quando um servidor estava funcionando corretamente, essas soluções praticamente eliminavam a chance de os usuários acessarem um servidor que não conseguisse atender às suas solicitações. É preciso ressaltar, no entanto, que cada iteração das características de HA que permitem inteligência teve um impacto correspondente na utilização do servidor e da rede, limitando ainda mais a escalabilidade. O outro impacto negativo do HA foi na área de confiabilidade. Muitos dos truques de rede usados para distribuir tráfego nesses sistemas eram complexos e exigiam monitoramento considerável no nível da rede. Consequentemente, esses métodos de distribuição frequentemente encontravam problemas que afetavam todo o aplicativo e todo o tráfego na rede do aplicativo.

Essas soluções também aumentaram a previsibilidade. Como os designers do aplicativo sabiam quando e por que os usuários precisavam retornar ao mesmo servidor em vez de serem balanceados por carga, eles puderam incorporar uma lógica que ajudou a garantir que os usuários permaneceriam persistentes, se necessário. Eles também usaram a mesma tecnologia de "pooling" para replicar informações de estado do usuário entre servidores, eliminando muitas das instâncias que exigiam persistência em primeiro lugar. Por fim, devido ao seu profundo conhecimento sobre aplicativos, eles conseguiram desenvolver algoritmos de balanceamento de carga com base na verdadeira integridade do aplicativo, em vez de fatores como conexões, que nem sempre eram uma boa indicação da carga do servidor.

Além das potenciais limitações na escalabilidade real e problemas com confiabilidade, o balanceamento de carga baseado em aplicativo proprietário também tinha uma desvantagem adicional: Dependia do fornecedor do aplicativo para desenvolver e manter. O principal problema aqui era que nem todos os aplicativos forneciam tecnologia de balanceamento de carga (ou pooling), e aqueles que forneciam geralmente não funcionavam com aqueles fornecidos por outros fornecedores de aplicativos. Embora houvesse diversas organizações que produziam software de balanceamento de carga independente de fornecedor e em nível de sistema operacional, elas infelizmente sofriam dos mesmos problemas de escalabilidade. E sem uma integração estreita com os aplicativos, essas "soluções" de software também enfrentaram desafios adicionais de HA.

A segunda iteração do balanceamento de carga desenvolvido especificamente surgiu como dispositivos baseados em rede. Esses são os verdadeiros pais fundadores dos atuais Controladores de Entrega de Aplicativos. Esses dispositivos residiam fisicamente fora dos próprios aplicativos e, embora tenham começado como balanceadores de carga, alcançavam seu balanceamento de carga usando técnicas de rede muito mais diretas, como NAT. Esses dispositivos apresentariam um endereço de servidor virtual para o mundo externo e, quando os usuários tentassem se conectar, os dispositivos encaminhariam a conexão para o servidor real mais apropriado.

O balanceador de carga podia controlar exatamente qual servidor recebia qual conexão e empregava "monitores de integridade" de complexidade crescente para garantir que o servidor de aplicativos (um servidor físico real) estivesse respondendo conforme necessário. Se o servidor não estivesse respondendo corretamente, o balanceador de carga pararia automaticamente de enviar tráfego para esse servidor até produzir a resposta desejada. Embora os monitores de integridade raramente fossem tão abrangentes quanto os criados pelos próprios desenvolvedores de aplicativos, a abordagem de hardware baseada em rede poderia fornecer serviços básicos de balanceamento de carga para quase todos os aplicativos de maneira uniforme e consistente, criando finalmente um ponto de entrada de serviço verdadeiramente virtualizado exclusivo para os servidores de aplicativos.

Do ponto de vista da escalabilidade, as organizações que começaram a substituir o balanceamento de carga baseado em software por uma solução baseada em hardware viram uma queda drástica na utilização de seus servidores. Isso evitou que eles tivessem que comprar servidores adicionais no curto prazo e ajudou a gerar maior ROI no longo prazo.

Da mesma forma, o HA ajudou a reduzir a complexidade da solução e a fornecer balanceamento de carga imparcial em relação ao aplicativo, resultando em maior confiabilidade e maior profundidade como solução. O hardware de balanceamento de carga baseado em rede permitiu que o proprietário da empresa fornecesse um alto nível de disponibilidade para todos os seus aplicativos, em vez de apenas alguns poucos com balanceamento de carga integrado.

A previsibilidade foi um componente essencial adicionado pelo hardware de balanceamento de carga baseado em rede. Agora era muito mais fácil prever para onde uma nova conexão seria direcionada e muito mais fácil de manipular. Esses dispositivos adicionaram inteligência ao processo, o que por sua vez ajudou a criar uma distribuição de carga controlada (em oposição à distribuição descontrolada do DNS dinâmico). Isso permitiu que os proprietários de empresas distribuíssem a carga aos servidores com base na capacidade do servidor de lidar com a carga.

O advento do balanceador de carga baseado em rede e da virtualização trouxe novos benefícios para segurança e gerenciamento, como mascarar a identidade dos servidores de aplicativos da comunidade da Internet e fornecer a capacidade de "sangrar" conexões de um servidor para que ele pudesse ser colocado offline para manutenção sem impactar os usuários. Esta é a base da qual os ADCs se originaram.

Com uma função de balanceamento de carga central, que também é um proxy completo, a TI viu um ótimo lugar para adicionar e consolidar serviços novos e emergentes. Isso levou à evolução de um dispositivo de balanceamento de carga para uma plataforma ADC extensível. Simplificando, o proxy é a base para o balanceamento de carga e a tecnologia subjacente que torna os ADCs possíveis.  

Ao discutir a segurança do ADC, a virtualização criada pelo proxy (a tecnologia base) é fundamental. Quer discutamos a transferência de criptografia SSL/TLS, autenticação centralizada ou mesmo firewalls fluentes em aplicativos, o poder dessas soluções reside no fato de que um balanceador de carga (hardware ou edição virtual) é o ponto agregado de virtualização em todos os aplicativos. A autenticação centralizada é um exemplo clássico. Os mecanismos tradicionais de autenticação e autorização sempre foram incorporados diretamente no próprio aplicativo. Assim como o balanceamento de carga baseado em aplicativo, cada implementação dependia e era exclusiva da implementação de cada aplicativo, resultando em métodos numerosos e diferentes. Em vez disso, ao aplicar autenticação no ponto de entrada virtualizado a todos os aplicativos, um método único e uniforme de autenticação pode ser aplicado. Isso não apenas simplifica drasticamente o design e o gerenciamento do sistema de autenticação, como também melhora o desempenho dos próprios servidores de aplicativos, eliminando a necessidade de executar essa função. Além disso, também elimina a necessidade — especialmente em aplicativos desenvolvidos internamente — de gastar tempo e dinheiro para desenvolver processos de autenticação em cada aplicativo separado.

Disponibilidade é o atributo do ADC mais fácil de vincular ao balanceador de carga original, pois se relaciona a todos os atributos básicos do balanceador de carga: escalabilidade, alta disponibilidade e previsibilidade. No entanto, os ADCs vão ainda mais longe do que o balanceador de carga. A disponibilidade para ADCs também representa conceitos avançados como dependência de aplicativos e provisionamento dinâmico. Os ADCs são capazes de entender que os aplicativos agora raramente operam de maneira independente: Eles geralmente dependem de outros aplicativos para cumprir seu design. Esse conhecimento aumenta a capacidade do ADC de fornecer disponibilidade de aplicativos ao levar esses outros processos em consideração também. Os ADCs mais inteligentes do mercado também fornecem interfaces programáticas que lhes permitem alterar dinamicamente a maneira como fornecem serviços com base em entradas externas. Essas interfaces permitem o provisionamento dinâmico e o dimensionamento automático para cima/baixo, necessários para ambientes modernos, como implantações em nuvem e em contêineres.

O aprimoramento de desempenho foi outra extensão óbvia do conceito de balanceamento de carga. Os balanceadores de carga melhoraram inerentemente o desempenho dos aplicativos ao garantir que as conexões não fossem direcionadas apenas aos serviços que estavam disponíveis (e respondendo em um período de tempo aceitável), mas também aos serviços com a menor quantidade de conexões e/ou utilização do processador. Isso garantiu que cada nova conexão fosse atendida pelo sistema mais capaz de lidar com ela. Mais tarde, quando o descarregamento SSL/TLS (usando hardware dedicado) se tornou um elemento comum nas ofertas de balanceamento de carga, ele reduziu a quantidade de sobrecarga computacional do tráfego criptografado, bem como a carga nos servidores de back-end, melhorando também seu desempenho.

Os ADCs de hoje vão ainda mais longe. Esses dispositivos geralmente incluem cache, compactação e até mesmo tecnologia de modelagem de taxa para aumentar ainda mais o desempenho geral e a entrega de aplicativos. Além disso, em vez de serem implementações estáticas de dispositivos autônomos tradicionais que fornecem esses serviços, um ADC pode usar sua inteligência de aplicativo inata para aplicar esses serviços somente quando eles gerarem um benefício de desempenho, otimizando assim seu uso.

Por exemplo, a tecnologia de compressão —apesar da crença comum—não é necessariamente benéfico para todos os usuários do aplicativo. Certamente, usuários com pequena largura de banda podem se beneficiar tremendamente de pacotes menores, já que o gargalo é a taxa de transferência real. Até mesmo conexões que precisam percorrer longas distâncias podem se beneficiar, pois pacotes menores significam menos viagens de ida e volta para transportar dados, diminuindo o impacto da latência da rede. No entanto, conexões de curta distância (por exemplo, dentro do mesmo continente) com grande largura de banda podem ter desempenho pior ao aplicar compressão. Como a taxa de transferência não é necessariamente o gargalo, a sobrecarga adicional de compactação e descompactação adiciona latência que o aumento da taxa de transferência não compensa do ponto de vista do desempenho. Em outras palavras, se não for gerenciada adequadamente, a tecnologia de compressão como solução pode ser pior que o problema original. Mas ao aplicar a compressão de forma inteligente somente quando isso beneficiar o desempenho geral, um ADC otimiza o uso e o custo da tecnologia de compressão, deixando mais ciclos do processador para funções que serão mais utilizadas.

Como a transformação digital é um imperativo estratégico tão importante, muitas empresas começaram a embarcar em sua jornada para a nuvem. Com o número crescente de aplicativos surgindo e mudando o mundo ao nosso redor, acredita-se que as organizações que estão migrando para a nuvem desfrutarão de muitos benefícios, como maior agilidade, melhor alinhamento de custos operacionais, escalabilidade sob demanda e mais foco em seus negócios principais.  

A “nuvem” não é uma entidade única e amorfa de recursos compartilhados de computação, armazenamento e rede; em vez disso, ela é composta por uma mistura complexa de provedores, infraestruturas, tecnologias e ambientes que geralmente são implantados em vários nós globais. Esta é a razão pela qual muitas empresas implantaram aplicativos em diversas nuvens diferentes: públicas, privadas e até mesmo uma combinação de todas elas. Esta é a multinuvem: a nova realidade.

Mesmo com esse cenário em rápida evolução, vários fatores estão retardando a adoção da nuvem. O primeiro desafio é a expansão da multinuvem, onde os aplicativos existentes foram “elevados e transferidos” e os aplicativos “nascidos na nuvem” foram implantados de forma não planejada e não gerenciada. Além disso, para atender às suas necessidades de curto prazo, as organizações tendem a usar plataformas de nuvem distintas, arquiteturas diferentes, serviços de aplicativos variados e múltiplos conjuntos de ferramentas. Isso resulta em complexidade arquitetônica em toda a empresa e torna a transferência de aplicativos de um ambiente para outro muito mais difícil, além de cara.

Os ADCs são a evolução natural do espaço crítico de rede que os balanceadores de carga do passado detinham. Embora os ADCs devam muito a esses dispositivos antigos, eles são uma nova geração que oferece não apenas disponibilidade, mas também desempenho e segurança. Como o nome sugere, eles se preocupam com todos os aspectos da entrega de um aplicativo da melhor maneira possível.

Com recursos avançados, como inteligência de aplicativos, descarregamento de SSL e interfaces programáticas, os ADCs modernos podem ajudar as organizações a expandir seus negócios e alcançar usuários em qualquer lugar, a qualquer hora. Com as necessidades em constante mudança do mundo técnico, os ADCs também são mais capazes de se adaptar às mais novas tecnologias em ambientes de contêineres e multinuvem.

No final, podemos dizer com segurança que os ADCs não serão apenas o principal canal e ponto de integração por meio do qual os aplicativos serão entregues de forma mais rápida, inteligente e segura, mas continuarão a evoluir e a adotar o mundo que prioriza a nuvem.