Argumentando el argumento comercial a favor de HTTP/2
HTTP/2 fue desarrollado teniendo en cuenta el rendimiento.
Dicho esto, parece sencillo elaborar un análisis de negocios basado en la realidad de que el rendimiento es lo más importante, en particular cuando hay aplicaciones móviles involucradas. Independientemente de que los costos se midan en productividad o en ganancias, el bajo rendimiento es siempre un problema importante que plantean los consumidores con respecto a sus compras, interacción y uso de aplicações móviles.
Pero ese es el caso fácil. Cualquiera puede hacerlo simplemente examinando una serie de encuestas sobre el tema. Todos sabemos que si una aplicación no responde en 5 segundos o menos, tanto los consumidores como los empleados se ponen nerviosos. Dado que hay, además de migrar a HTTP/2, una amplia variedad de servicios relacionados con el rendimiento disponibles para que las organizaciones los utilicen para abordar el problema, es posible que sea necesario brindar un mayor impulso antes de que las organizaciones decidan migrar a HTTP/2 con la firmeza con la que han determinado que son empresas "que priorizan la nube".
Consideremos, entonces, que muchas de las capacidades de HTTP/2 surgieron de la comprensión de qué era lo que los desarrolladores evitaban tan a menudo en HTTP/1.1 que se convirtió en una práctica estándar . Prácticas como la incrustación en línea, la concatenación y la fragmentación de dominios. Si bien todos ellos contribuyeron a mejorar el rendimiento, lamentablemente cada uno generó una deuda técnica que todavía hoy pesa sobre los desarrolladores y las operaciones por igual. La migración a HTTP/2 puede eliminar esas prácticas como fuente de deuda técnica en el futuro y proporciona un camino para “saldar” la deuda que existe hoy en día.
La deuda técnica (y arquitectónica) se genera por las decisiones que tomamos . Decisiones sobre qué tecnología adoptar, qué producto comprar, qué arquitectura implementar. También puede provenir de decisiones basadas en dónde en la arquitectura de la aplicação se implementará una solución particular.
Por ejemplo, los desarrolladores lograron sortear algunas limitaciones de HTTP/1.1 incorporando imágenes pequeñas y concatenando archivos pequeños. De hecho, esto mejoró el rendimiento, pero a costa de eliminar el almacenamiento en caché de aplicaciones adicionales (en la red) como opción. También se requiere atención durante el ciclo de vida de la aplicación, ya que cualquier cambio en esas imágenes en línea o en los archivos que componen el archivo concatenado único deben reflejarse en cada aplicação. La falta de modularidad es una fuente de deuda técnica que continuará mientras esa aplicação esté en servicio.
La deuda técnica, al igual que la deuda real, requiere servicio. Y esto tiene un precio: el interés. Con cada cambio y cada actualización ese interés aumenta. Requiere tiempo y atención del desarrollador. Requiere recursos de prueba. Requiere recursos de red y computacionales. Esto hace que la organización dedique más tiempo al servicio de su “deuda” que a la innovación o la expansión, y dificulta el aprovechamiento de nuevas tecnologías, metodologías y conceptos arquitectónicos que ofrecen ventajas competitivas.
Es necesario abordar esta deuda. En realidad, está eliminado, pero como mínimo es necesario abordarlo.
Para HTTP/1.1, el medio para terminar con el ciclo de deuda de HTTP/1.1 es adoptar HTTP/2 en el futuro. Al abordar una amplia gama de limitaciones técnicas y de protocolo, HTTP/2 ofrece a los desarrolladores una manera de abandonar las soluciones alternativas del pasado y tomar decisiones diferentes en el futuro. Opciones que no vengan cargadas de deuda técnica. Las aplicações existentes conservan esa deuda, sí, pero pueden trasladarse o reemplazarse por aplicações que usan HTTP/2 y liberan tanto al equipo de desarrollo como al de operaciones de las restricciones que les impusieron los antiguos servidores HTTP/1.1.
HTTP/2 no se trata sólo de un protocolo y aplicaciones más rápidos. También se trata de eliminar las restricciones sobre el desarrollo y las operaciones que los liberan de la deuda técnica y brindan a las organizaciones la oportunidad de aprovechar otras formas de mejorar el rendimiento. Formas que tengan menos probabilidades de incurrir en el tipo de deuda técnica o arquitectónica que impedirá que la empresa gane en la carrera para ganar en el juego de las aplicações .