Cómo justificar la adopción de HTTP/2 desde una perspectiva empresarial

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

HTTP/2 se desarrolló pensando en el rendimiento.

Dicho esto, parece sencillo justificarlo desde el punto de vista empresarial partiendo de la realidad de que el rendimiento es lo más importante, especialmente cuando se trata de aplicaciones móviles. Tanto si los costes se miden en términos de productividad como de beneficios, un rendimiento deficiente siempre es un problema importante que los consumidores señalan en relación con sus compras, su interacción y su uso de las aplicaciones móviles.

Pero ese es el caso fácil. Cualquiera puede defenderlo con solo examinar la gran cantidad de encuestas que existen sobre el tema. Todos sabemos que, si una aplicación tarda más de 5 segundos en responder, tanto los consumidores como los empleados se impacientan. Dado que, además de migrar a HTTP/2, las organizaciones disponen de una amplia variedad de servicios relacionados con el rendimiento para abordar el problema, quizá sea necesario ofrecerles un incentivo mayor antes de que decidan migrar a HTTP/2 con la misma determinación con la que han decidido convertirse en empresas que priorizan la nube.

Tengamos en cuenta, entonces, que muchas de las funcionalidades de HTTP/2 surgieron al comprender qué aspectos los desarrolladores sorteaban con tanta frecuencia en HTTP/1.1 que acabaron convirtiéndose en prácticas habituales: técnicas como la inserción en línea, la concatenación y la fragmentación de dominios. Aunque todas ellas contribuyeron a mejorar el rendimiento, por desgracia cada una generó una deuda técnica que aún hoy supone una carga tanto para los desarrolladores como para los equipos de operaciones. Migrar a HTTP/2 puede evitar que esas prácticas sigan generando deuda técnica y ofrece una vía para «saldar» la deuda existente.

La deuda técnica (y arquitectónica) surge de las decisiones. Decisiones sobre qué tecnología adoptar, qué producto adquirir o qué arquitectura implementar. También puede derivarse de decisiones sobre en qué parte de la arquitectura de la aplicación se implementará una solución concreta.

Por ejemplo, los desarrolladores sortearon algunas limitaciones de HTTP/1.1 incrustando imágenes pequeñas y concatenando archivos pequeños. Esto mejoró el rendimiento, pero a costa de descartar como opción el almacenamiento en caché fuera de la aplicación (en la red). También exigía prestar atención durante el ciclo de vida de la aplicación, ya que cualquier cambio en esas imágenes incrustadas o en los archivos que componían el único archivo concatenado debía reflejarse en todas las aplicaciones. La falta de modularidad es una fuente de deuda técnica que persistirá mientras esa aplicación siga en servicio.

La deuda técnica, al igual que la deuda real, requiere mantenimiento. Y tiene un coste: los intereses. Con cada cambio y cada actualización, esos intereses se acumulan. Requiere tiempo y atención por parte de los desarrolladores, así como recursos de pruebas, de red y de computación. Esto hace que la organización dedique más tiempo a gestionar su «deuda» que a innovar o expandirse, y dificulta el aprovechamiento de nuevas tecnologías, metodologías y conceptos arquitectónicos que ofrecen ventajas competitivas.

Hay que abordar esta deuda. De hecho, habría que eliminarla, pero como mínimo hay que abordarla.

En el caso de HTTP/1.1, la forma de poner fin al ciclo de deuda que genera es adoptar HTTP/2 de ahora en adelante. Al resolver una amplia variedad de limitaciones técnicas y del protocolo, HTTP/2 permite a los desarrolladores dejar atrás las soluciones provisionales del pasado y tomar decisiones diferentes en el futuro, decisiones que no estén lastradas por la deuda técnica. Las aplicaciones existentes conservan esa deuda, sí, pero pueden migrarse o sustituirse por aplicaciones que utilicen HTTP/2, liberando tanto a los equipos de desarrollo como a los de operaciones de las restricciones impuestas por los antiguos recursos habituales de HTTP/1.1.

HTTP/2 no consiste únicamente en disponer de un protocolo y unas aplicaciones más rápidos. También consiste en eliminar las limitaciones que pesan sobre los equipos de desarrollo y operaciones, liberándolos de la deuda técnica y brindando a las organizaciones la oportunidad de aprovechar otras formas de mejorar el rendimiento. Formas menos propensas a generar el tipo de deuda técnica o arquitectónica que impedirá a las empresas imponerse en la carrera por ganar en el mundo de las aplicaciones.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie