O mundo do desenvolvedor de aplicações e o do arquiteto de redes não poderiam ser mais diferentes, exceto, talvez, na maneira como cada um enxerga a área do outro.
Uma perspectiva típica da rede sobre a implantação de uma aplicação costuma ser assim:
Enquanto isso, do outro lado do “muro”, a perspectiva do desenvolvedor sobre a implantação da mesma aplicação geralmente é assim:
Sem dúvida, ambas são precisas em seus respectivos domínios, mas ignoram em grande medida a arquitetura real uma da outra. Isso ilustra por que tantos problemas surgem quando as aplicações entram em produção. E eles de fato surgem. Uma pesquisa aponta que, em 2013, “90% dos desenvolvedores disseram que passavam fins de semana, feriados e férias corrigindo emergências em aplicações na fase de produção[1]”. Embora muitas delas certamente estejam relacionadas a defeitos e erros de software, muitas outras são, sem dúvida, causadas pelas inúmeras diferenças entre os ambientes. Produção não é desenvolvimento, e vice-versa.
Os aplicativos atuais utilizam diversos serviços presentes em ambientes de produção, mas raramente disponíveis em ambientes de desenvolvimento ou teste: balanceadores de carga para garantir escalabilidade, caches para melhorar o desempenho e firewalls de aplicativos web para reforçar a segurança. Esses serviços não apenas processam todas as solicitações e respostas à medida que elas trafegam pela rede entre o usuário e o aplicativo (ou entre o aplicativo e a API, se preferir), como também, em alguns casos, modificam as solicitações e/ou respostas. Um bom exemplo disso é o endereço IP do usuário. Esse valor está presente nos cabeçalhos HTTP de todas as solicitações, mas, ao passar por um proxy de balanceamento de carga, ele se torna o endereço IP do proxy, e não o do cliente.
Para o desenvolvedor desavisado, isso pode fazer com que os aplicativos “quebrem” e resultar em horas de solução de problemas, além do tempo necessário para modificar o aplicativo. Esses tipos de problemas decorrentes das diferenças entre os ambientes são, sem dúvida, a razão pela qual 28% dos desenvolvedores que responderam a uma pesquisa[2] em meados de 2015 disseram que “mais de 50% dos problemas em produção poderiam ter sido identificados e corrigidos com o ambiente de teste adequado”. E mais da metade (52%) afirmou que “entre 25% e 50% dos problemas em produção teriam sido corrigidos”.
Muitos dos problemas que surgem em produção podem ser atribuídos diretamente a diferenças na aplicação, especialmente naquelas desenvolvidas com metodologias ágeis. Os métodos ágeis podem aumentar a probabilidade de esses tipos de conflitos ocorrerem em produção devido à frequência das alterações no código.
Cada vez mais, muitos desses desafios — embora de forma alguma todos — são resolvidos com o uso de um proxy programável, pois isso elimina a necessidade de alterar o código que já está em produção e de atrasar ainda mais o lançamento da aplicação no mercado. O problema de “endereço IP” mencionado anteriormente costuma ser resolvido configurando o proxy para inserir um novo cabeçalho HTTP que contenha o endereço IP real, para que os desenvolvedores continuem tendo acesso a essa informação. Além disso, os proxies de balanceamento de carga de camada 7 são eficientes no roteamento de solicitações de aplicações e APIs com base em diversos dados, incluindo versionamento e assinaturas de API.
É interessante observar que o único componente frequentemente destacado tanto em diagramas de engenharia de software quanto de redes é o balanceador de carga. Embora esse proxy seja tradicionalmente implantado e gerenciado pela equipe de redes, ele é tão essencial para as arquiteturas de aplicações que quase sempre é incluído como parte da aplicação. Da mesma forma, os desenvolvedores reconhecem atualmente a importância do balanceamento de carga para a escalabilidade das aplicações e geralmente o incluem em seus diagramas.
Isso também reflete o número crescente de casos em que as equipes de desenvolvimento e operações assumiram a responsabilidade pela escalabilidade e, consequentemente, passaram a controlar o balanceamento de carga de suas aplicações. Isso é positivo, pois significa que as equipes de desenvolvimento e operações podem incluir — e espera-se que estejam incluindo — o balanceamento de carga (com todos os benefícios da camada 7) no pipeline de CI/CD, especialmente durante os testes, para garantir que possíveis problemas sejam identificados rapidamente e resolvidos antes da entrada em produção. Antecipar o balanceamento de carga no pipeline de CI/CD também possibilita uma abordagem mais abrangente à entrega contínua, na qual todo o pacote da aplicação (a arquitetura) é gerenciado como código e pode ser atualizado simultaneamente. Isso permite que a infraestrutura de rede (categoria em que o balanceamento de carga tradicionalmente se enquadra) ofereça suporte a uma arquitetura imutável, na qual as aplicações (ou os microsserviços, caso você siga esse caminho) são reimplantadas por completo com novas configurações, em vez de serem simplesmente atualizadas, evitando a entropia natural do software, que pode gerar desafios e dívida técnica.
O proxy é, em muitos aspectos, a ponte que conecta a “rede” à “aplicação”, transpondo a lacuna figurativa (mais parecida com um muro, para sermos sinceros) que separa engenheiros e arquitetos de software e de redes. Essa é uma das lacunas que o DevOps precisa abranger para que as organizações consigam escalar e enfrentar os desafios das arquiteturas modernas.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...