As três principais características de um proxy de aplicativo moderno
Mantenha o lado quente quente e o lado frio frio.
Você deve se lembrar (se você tiver idade suficiente e não, não se preocupe, não vou pedir para você levantar a mão) de uma campanha anos atrás do McDonald's promovendo embalagens de alguns de seus produtos que mantinham "o lado quente quente e o lado frio frio".
O conceito era bem simples: separar o quente do frio, mas mantê-lo em um único recipiente para facilitar o transporte.
Essa noção de separação dentro do mesmo “contêiner” é realmente a base do que torna um proxy de aplicativo, bem, um proxy. Mantém o lado do cliente cliente e o lado do aplicativo… aplicativo.
Ok, isso pode não ser traduzido tão bem quanto eu gostaria, afinal.
Ainda assim, o conceito é válido e importante para entender um proxy de aplicativo.
Fundamentalmente, um proxy é um software que é posicionado logicamente entre dois participantes em uma troca de comunicação. Um proxy de aplicativo fica entre um aplicativo e um cliente. Agora, nem todos os proxies são proxies completos . Um proxy completo requer separação interna dos dois lados; essencialmente, um proxy completo tem duas pilhas de rede independentes contidas em um único dispositivo. O lado do cliente (o lado quente) e o lado do aplicativo (o lado frio).
Eu sei, a analogia realmente não está funcionando bem, não é? Trabalhe comigo, é tudo o que tenho por enquanto.
O motivo pelo qual isso é (ou deveria ser) um requisito para um proxy de aplicativo é que ele fornece ao proxy a capacidade de participar da troca entre o cliente e o servidor. Isso é necessário para fornecer funcionalidades como minificação (que melhora o desempenho do aplicativo) e funções de segurança (como limpeza de dados) e multiplexação TCP (otimização), bem como um amplo conjunto de outros serviços.
É nessa “lacuna” interna entre o lado do cliente e o lado do aplicativo que a mágica acontece. É aí que qualquer número de serviços – desde balanceamento de carga rudimentar até firewall de aplicativo avançado e controle de acesso de aplicativo – fazem seu trabalho. As solicitações são efetivamente encerradas no lado do cliente de um proxy de aplicativo. Depois disso, ocorre um processo muito parecido com o encadeamento de serviços, só que tudo acontece internamente, nas velocidades do barramento interno e do processador (que são quase sempre mais rápidas do que a velocidade da rede). A inspeção é iniciada. Políticas são aplicadas. Transformações ocorrem. Decisões são tomadas. Uma conexão separada entre o proxy e o aplicativo é feita, e a solicitação é enviada.
Quando essa solicitação retorna ao proxy, acontece o inverso. A inspeção é iniciada. Os dados são apagados. As políticas são aplicadas. Depois, ele volta para o lado do cliente, onde pode ser transferido de volta para o cliente.
E tudo isso acontece em menos de um segundo porque é tudo interno ao proxy.
Como o objetivo de um proxy de aplicativo é fornecer uma ampla gama de serviços de aplicativo – disponibilidade, segurança, mobilidade, identidade e acesso e desempenho – ele realmente deveria ser um proxy completo. Somente um proxy completo é projetado para participar de cada solicitação e resposta. Proxies simples (que na verdade são proxies sem estado, se você quiser se aprofundar mais) só participam da conversa inicial, quando a conexão entre o cliente e o aplicativo está sendo criada. Sua finalidade é escolher uma instância do aplicativo e então “costurar” a conexão entre os dois. Depois disso, o proxy não participa. Ele vê um “fluxo” (uma construção TCP de camada 4 que você pode ter ouvido ao discutir SDN, o que é outra discussão para outro momento) e simplesmente encaminha pacotes de um lado para o outro, misturando o quente e o frio indiscriminadamente. (Ver? Eu sabia que a analogia acabaria funcionando.)
Agora, dito isso, um proxy de aplicativo moderno (e escalável) deve ser um proxy completo e ter três características principais: programabilidade, desempenho e protocolos.
A programabilidade é essencial em data centers modernos e na nuvem para dar suporte à automação, orquestração e padronização. Também é essencial no caminho dos dados para habilitar segurança e serviços que fornecem valor exclusivo aos negócios e operações, permitindo suporte para protocolos personalizados e ampliação dos existentes. A performance parece simples, mas não é. Como um proxy de aplicativo interage com cada solicitação, ele precisa ser não apenas rápido, mas extremamente rápido. Ele precisa fazer o que precisa ser feito rapidamente, sem adicionar latência à troca, o que prejudica a experiência do aplicativo. Isso não é tão fácil quanto parece, especialmente quando há tanta pressão para usar computação de propósito geral como base para implantação.
Por fim, os protocolos são importantes. A primeira coisa que pensamos quando dizemos “aplicativo” é provavelmente HTTP. Isso não é surpresa; o HTTP é o novo TCP e a língua franca da Internet. Mas não é o único protocolo em uso, especialmente em uma era de comunicações via Internet. Há também SIP e UDP. Sem mencionar SMTP (você ainda envia e-mails, certo?) e LDAP. E quanto ao SSL e TLS? Com um foco (e urgência) cada vez maior em obter SSL Everywhere, bem, em todos os lugares, é ainda mais essencial que um proxy de aplicativo fale SSL/TLS – e fale com extrema fluência. Porque, caso contrário, esse requisito de desempenho pode não ser atendido.
Um proxy de aplicativo pode fornecer a plataforma que os data centers modernos precisam para enfrentar desafios de segurança e desempenho, automatizar e orquestrar seu caminho para custos operacionais mais baixos e garantir a experiência de aplicativo ideal para clientes consumidores e corporativos. Mas ele precisa ser um proxy de aplicativo completo com capacidade de programação, desempenho e suporte a protocolos para garantir que nenhum aplicativo fique para trás.