Criando o caso de negócios para HTTP/2
O HTTP/2 foi desenvolvido com desempenho em mente.
Dito isso, parece simples criar um caso de negócios com base na realidade de que o desempenho é fundamental, principalmente quando se trata de aplicativos móveis. Não importa se os custos são medidos em produtividade ou lucro, o baixo desempenho é sempre um problema significativo levantado pelos consumidores em relação às suas compras, engajamento e uso de aplicativos móveis.
Mas esse é o caso fácil. Qualquer um pode fazer isso simplesmente examinando uma série de pesquisas sobre o assunto. Todos nós sabemos que se um aplicativo não responde em 5 segundos ou menos, consumidores e funcionários ficam inquietos. Considerando que, além da mudança para HTTP/2, há uma grande variedade de serviços relacionados ao desempenho disponíveis para as organizações usarem para resolver o problema, pode ser necessário um maior ímpeto antes que as organizações decidam mudar para HTTP/2 com a certeza de que são empresas "cloud first".
Considere, então, que muitos dos recursos do HTTP/2 surgiram da compreensão do que os desenvolvedores faziam com tanta frequência no HTTP/1.1 que ele se tornou uma prática padrão . Práticas como inlining, concatenação e fragmentação de domínio. Embora todos eles tenham contribuído para melhorias no desempenho, infelizmente cada um deles gerou uma dívida técnica que ainda hoje está sobrecarregando desenvolvedores e operações. A migração para HTTP/2 pode eliminar essas práticas como uma fonte de dívida técnica no futuro e fornece um caminho para “pagar” a dívida que existe hoje.
A dívida técnica (e arquitetônica) é contraída por escolhas . Escolhas feitas sobre qual tecnologia adotar, qual produto comprar, qual arquitetura implementar. Também pode vir de decisões baseadas em onde na arquitetura do aplicativo uma solução específica 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 pequenos arquivos. Isso, de fato, melhorou o desempenho, mas ao custo de eliminar o cache de aplicativos extras (na rede) como uma opção. Também exigiu atenção durante o ciclo de vida do aplicativo, pois qualquer alteração nas imagens embutidas ou nos arquivos que compõem o único arquivo concatenado precisa ser refletida em cada aplicativo. A falta de modularidade é uma fonte de dívida técnica que continuará enquanto o aplicativo estiver em serviço.
A dívida técnica, assim como a dívida real, exige serviço. Isso tem um preço: juros. A cada mudança e atualização esse interesse aumenta. Requer tempo e atenção do desenvolvedor. Requer recursos de teste. Requer recursos de rede e computação. Isso faz com que a organização gaste mais tempo pagando sua “dívida” do que em inovação ou expansão, e dificulta o aproveitamento de novas tecnologias, metodologias e conceitos arquitetônicos que oferecem vantagens competitivas.
Essa dívida precisa ser resolvida. Eliminado, na verdade, mas, no mínimo, precisa ser resolvido.
Para HTTP/1.1, o meio de acabar com o ciclo de dívida do HTTP/1.1 é adotar o HTTP/2 daqui para frente. Ao abordar uma ampla gama de limitações técnicas e de protocolo, o HTTP/2 oferece uma maneira para os desenvolvedores abandonarem as soluções alternativas do passado e fazerem escolhas diferentes no futuro. Escolhas que não vêm carregadas de dívida técnica. Os aplicativos existentes mantêm essa dívida, sim, mas podem ser movidos ou substituídos por aplicativos que usam HTTP/2 e liberam tanto o desenvolvimento quanto as operações das restrições impostas a eles pelos antigos padrões do HTTP/1.1.
O HTTP/2 não se trata apenas de um protocolo e aplicativos mais rápidos. Também se trata de eliminar restrições ao desenvolvimento e às operações, libertando-os da dívida técnica e proporcionando às organizações a oportunidade de aproveitar outras maneiras de melhorar o desempenho. Formas com menor probabilidade de incorrer no tipo de dívida técnica ou arquitetônica que impedirá as empresas de vencer na corrida para vencer no jogo dos aplicativos .