Justificando o HTTP/2 para a empresa

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

O HTTP/2 foi desenvolvido com foco em desempenho.

Dito isso, parece simples justificar o investimento com base no fato de que o desempenho é fundamental, especialmente quando se trata de aplicativos móveis. Sejam os custos medidos em termos de produtividade ou lucro, o baixo desempenho é sempre um problema significativo apontado pelos consumidores em relação às compras, à interação e ao uso de aplicativos móveis.

Mas esse é o caso mais simples. Qualquer pessoa pode chegar a essa conclusão simplesmente analisando uma série de pesquisas sobre o assunto. Todos sabemos que, se um aplicativo não responder em até 5 segundos, tanto consumidores quanto funcionários ficam impacientes. Considerando que, além da migração para o HTTP/2, há uma grande variedade de serviços relacionados ao desempenho que as organizações podem usar para resolver o problema, talvez seja necessário um incentivo maior para que elas decidam migrar para o HTTP/2 com a mesma convicção com que se declararam empresas que priorizam a nuvem.

Considere, então, que muitos dos recursos do HTTP/2 surgiram da compreensão daquilo que os desenvolvedores contornavam com tanta frequência no HTTP/1.1 que acabou se tornando uma prática padrão. Práticas como inlining, concatenação e fragmentação de domínio. Embora todas tenham contribuído para melhorar o desempenho, cada uma infelizmente gerou uma dívida técnica que, ainda hoje, sobrecarrega tanto os desenvolvedores quanto as equipes de operações. A migração para o HTTP/2 pode eliminar essas práticas como fonte de dívida técnica no futuro e oferecer um caminho para “quitar” a dívida existente hoje.

A dívida técnica (e arquitetural) é gerada por escolhas. Escolhas sobre qual tecnologia adotar, qual produto adquirir e qual arquitetura implementar. Ela também pode decorrer de decisões sobre em que ponto da arquitetura da aplicação uma determinada solução será implementada.

Por exemplo, algumas limitações do HTTP/1.1 foram contornadas pelos desenvolvedores com a incorporação de pequenas imagens e a concatenação de arquivos pequenos. Isso de fato melhorou o desempenho, mas ao custo de eliminar a possibilidade de armazenamento em cache fora da aplicação (na rede). Também exigiu atenção durante o ciclo de vida da aplicação, pois qualquer alteração nessas imagens incorporadas ou nos arquivos que compõem o único arquivo concatenado precisa ser refletida em todas as aplicações. A falta de modularidade é uma fonte de dívida técnica que persistirá enquanto essa aplicação estiver em uso.

A dívida técnica, assim como a dívida real, precisa ser administrada. Ela tem um custo: os juros. A cada alteração e atualização, esses juros se acumulam. Ela exige tempo e atenção dos desenvolvedores. Exige recursos de teste. Exige recursos de rede e computação. Com isso, a organização acaba dedicando mais tempo à gestão de sua “dívida” do que à inovação ou à expansão, além de ter dificuldade para aproveitar novas tecnologias, metodologias e conceitos arquitetônicos que oferecem vantagens competitivas.

Essa dívida precisa ser enfrentada. Na verdade, precisa ser eliminada, mas, no mínimo, precisa ser enfrentada.

Para encerrar o ciclo de dívida do HTTP/1.1, a solução daqui para a frente é adotar o HTTP/2. Ao resolver uma ampla gama de limitações técnicas e de protocolo, o HTTP/2 permite que os desenvolvedores deixem para trás as soluções alternativas do passado e façam escolhas diferentes no futuro — escolhas que não venham carregadas de dívida técnica. Sim, as aplicações existentes mantêm essa dívida, mas podem ser migradas ou substituídas por aplicações que usam HTTP/2, livrando tanto as equipes de desenvolvimento quanto as de operações das restrições impostas pelas antigas soluções de praxe do HTTP/1.1.

O HTTP/2 não se resume a um protocolo e aplicativos mais rápidos. Ele também elimina as limitações impostas às equipes de desenvolvimento e operações, livrando-as da dívida técnica e dando às organizações a oportunidade de aproveitar outras formas de melhorar o desempenho — formas menos propensas a gerar o tipo de dívida técnica ou arquitetural que impedirá a empresa de vencer na corrida pelo sucesso no mundo dos aplicativos.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

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 Vittie