O Poder do Proxy: Reduzindo a distância entre desenvolvimento e produção

O mundo do desenvolvedor de aplicativos e do arquiteto de rede não poderia ser mais diferente, exceto, talvez, na maneira como cada um vê o domínio do outro.

Uma perspectiva de rede típica de uma implantação de aplicativo geralmente se parece com isto:

Enquanto do outro lado do “muro” a perspectiva do desenvolvedor da mesma implantação de aplicativo geralmente se parece com isto:

Ambas são, sem dúvida, precisas em seus domínios, mas altamente indiferentes em relação à arquitetura real da outra. Isso ilustra o motivo pelo qual muitos problemas surgem quando os aplicativos entram em produção. E eles se levantam. A pesquisa observa que em 2013 “90% dos desenvolvedores disseram que estavam gastando fins de semana, feriados e férias para consertar emergências de aplicativos na fase de produção [1]”. Embora muitos deles certamente estejam relacionados a defeitos e erros de software, muitos outros são, sem dúvida, causados pelas muitas diferenças nos ambientes. Produção não é desenvolvimento, e vice-versa.

Os aplicativos de hoje aproveitam uma variedade de serviços que existem em ambientes de produção, mas raramente em ambientes de desenvolvimento ou teste: balanceadores de carga para escalabilidade, caches para melhorar o desempenho e firewalls de aplicativos da web para segurança. Esses serviços não apenas tocam em todas as solicitações e respostas à medida que percorrem a rede entre o usuário e o aplicativo (ou o aplicativo e a API, se preferir), mas, em alguns casos, eles modificam as solicitações e/ou respostas. Um bom exemplo disso é o endereço IP do usuário. Esse valor é encontrado nos cabeçalhos HTTP de cada solicitação, mas quando passa por um proxy de balanceamento de carga, ele se torna o endereço IP do proxy , não do cliente.

Para o desenvolvedor desavisado, isso pode fazer com que os aplicativos “quebrem” e resultem em horas de solução de problemas, além do tempo necessário para modificar o aplicativo. Esses tipos de problemas decorrentes de diferenças no ambiente são, sem dúvida, a razão pela qual 28% dos desenvolvedores que responderam a uma pesquisa [2] em meados de 2015 disse que “mais de 50% dos problemas de produção poderiam ter sido encontrados e corrigidos com o ambiente de teste certo”. E mais da metade (52%) disse que “entre 25% e 50% dos problemas de produção teriam sido corrigidos”.

Muitos dos problemas que surgem na produção são diretamente atribuíveis a diferenças na aplicação, especialmente aquelas desenvolvidas usando metodologias ágeis. Métodos ágeis podem aumentar a probabilidade desses tipos de conflitos surgirem na produção devido à frequência com que o código muda.

Cada vez mais, mas não todos, esses desafios são resolvidos usando um proxy programável, pois isso elimina a necessidade de alterar o código já em produção e atrasar ainda mais a entrega do aplicativo ao mercado. O problema do “endereço IP” mencionado acima é geralmente resolvido instruindo o proxy a inserir um novo cabeçalho HTTP que contenha o endereço IP real para que os desenvolvedores ainda tenham acesso a essas informações e os proxies de balanceamento de carga da camada 7 sejam adeptos ao roteamento de solicitações de aplicativos e API com base em uma variedade de dados, incluindo controle de versão e assinaturas de API.

É interessante notar que o componente que é frequentemente destacado nos diagramas de engenharia de software e de rede é o balanceador de carga. Embora esse proxy seja tradicionalmente implantado e gerenciado pela equipe de rede, ele é crítico o suficiente para arquiteturas de aplicativos e quase sempre é incluído como parte do aplicativo. Da mesma forma, os desenvolvedores reconhecem a importância do balanceamento de carga hoje para dimensionar aplicativos e geralmente o incluem em seus diagramas.

Isso também reflete o aumento de casos em que desenvolvedores e operações assumiram a responsabilidade pela escalabilidade e, portanto, assumiram o controle do balanceamento de carga de seus aplicativos.  Isso é bom, porque significa que o desenvolvimento e as operações podem (e esperamos que estejam) incluindo o balanceamento de carga (e todas as suas vantagens da camada 7) no pipeline de CI/CD, principalmente durante os testes, para garantir que quaisquer problemas potenciais possam ser encontrados rapidamente e resolvidos antes de passar para a produção. Transferir o balanceamento de carga para a esquerda no pipeline de CI/CD também permite uma abordagem mais holística para entrega contínua, na qual todo o pacote do aplicativo (arquitetura) é gerenciado como código e pode ser atualizado simultaneamente. Isso permite que a infraestrutura de rede (porque é onde o balanceamento de carga tradicionalmente se enquadra quando descrito) suporte uma arquitetura imutável na qual os aplicativos (ou microsserviços, se você estiver seguindo esse caminho) são completamente reimplantados com novas configurações em vez de simplesmente atualizados, evitando a entropia natural do software que pode introduzir desafios e dívida técnica.

O proxy é, de muitas maneiras, a ponte que conecta a “rede” ao “aplicativo” sobre a lacuna figurativa (mais como um muro, se formos honestos) que separa engenheiros e arquitetos de software e rede. Essa é uma das lacunas que o DevOps precisa incluir se as organizações quiserem escalar para enfrentar os desafios das arquiteturas modernas.

[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructure-survey-results/