Analyse de rentabilité du HTTP/2
HTTP/2 a été développé dans un souci de performances.
Cela étant dit, il semble simple d’établir une analyse de rentabilisation basée sur le fait que la performance est primordiale, en particulier lorsque des applications mobiles sont impliquées. Que les coûts soient mesurés en termes de productivité ou de profit, la mauvaise performance est toujours un problème important soulevé par les consommateurs en ce qui concerne leurs achats, leur engagement et leur utilisation des applications mobiles.
Mais c’est le cas le plus simple. N’importe qui peut y parvenir simplement en examinant une série d’enquêtes sur le sujet. Nous savons tous que si une application ne répond pas en 5 secondes ou moins, les consommateurs et les employés deviennent nerveux. Étant donné qu’il existe, en dehors du passage à HTTP/2, une grande variété de services liés aux performances que les organisations peuvent utiliser pour résoudre le problème, il faudra peut-être fournir une impulsion plus forte avant que les organisations décident de passer à HTTP/2 avec la certitude qu’elles sont des entreprises « cloud first ».
Considérez donc que de nombreuses fonctionnalités de HTTP/2 sont issues de la compréhension de ce que les développeurs contournaient si souvent dans HTTP/1.1 que c'est devenu une pratique standard . Des pratiques telles que l'inlining, la concaténation et le partitionnement de domaine. Bien que tous ces changements aient contribué à améliorer les performances, chacun d’entre eux a malheureusement entraîné une dette technique qui pèse encore aujourd’hui sur les développeurs et les opérations. La migration vers HTTP/2 peut éliminer ces pratiques en tant que source de dette technique à l’avenir et offre un moyen de « rembourser » la dette qui existe aujourd’hui.
La dette technique (et architecturale) est engendrée par les choix . Choix effectués concernant la technologie à adopter, le produit à acheter, l’architecture à mettre en œuvre. Cela peut également provenir de décisions basées sur l'endroit dans l'architecture de l'application où une solution particulière sera implémentée.
Par exemple, certaines limitations de HTTP/1.1 ont été contournées par les développeurs grâce à l'intégration de petites images et à la concaténation de petits fichiers. Cela a effectivement amélioré les performances, mais au prix de l’élimination de la mise en cache d’applications supplémentaires (dans le réseau) en tant qu’option. Cela nécessite également une attention particulière pendant le cycle de vie de l'application, car toute modification apportée à ces images intégrées ou aux fichiers constituant le fichier concaténé unique doit être reflétée dans chaque application. Le manque de modularité est une source de dette technique qui perdurera tant que cette application sera en service.
La dette technique, comme la dette réelle, nécessite un service. Cela a un prix : les intérêts. À chaque changement et à chaque mise à jour, l’intérêt s’accroît. Cela nécessite du temps et de l’attention de la part du développeur. Cela nécessite des ressources de test. Cela nécessite des ressources réseau et de calcul. L’organisation passe alors plus de temps à rembourser sa « dette » qu’à innover ou à se développer, et il lui est difficile de tirer parti des nouvelles technologies, méthodologies et concepts architecturaux qui offrent des avantages concurrentiels.
Il faut régler cette dette. En fait, ce problème a été éliminé, mais il faut au moins le régler.
Pour HTTP/1.1, le moyen de mettre fin au cycle d’endettement de HTTP/1.1 est d’adopter HTTP/2 à l’avenir. En abordant un large éventail de limitations techniques et de protocole, HTTP/2 offre aux développeurs un moyen de s'éloigner des solutions de contournement du passé et de faire des choix différents pour l'avenir. Des choix qui ne s’accompagnent pas de dette technique. Les applications existantes conservent cette dette, certes, mais peuvent être déplacées ou remplacées par des applications qui utilisent HTTP/2 et libèrent à la fois les développeurs et les opérateurs des contraintes imposées par les anciens standards de HTTP/1.1.
HTTP/2 ne concerne pas uniquement un protocole et des applications plus rapides. Il s’agit également d’éliminer les contraintes pesant sur le développement et les opérations, ce qui les libère de la dette technique et offre aux organisations la possibilité de profiter d’autres moyens d’améliorer les performances. Des moyens moins susceptibles d’engendrer le type de dette technique ou architecturale qui empêcherait les entreprises de gagner dans la course pour gagner dans le jeu des applications .