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 bon nombre des fonctionnalités de HTTP/2 viennent de la compréhension des contournements fréquents que les développeurs effectuaient sous HTTP/1.1 au point d’en faire une pratique courante. Des méthodes comme l'intégration directe, la concaténation et le partitionnement de domaine. Si chacune a apporté des gains de performance, elles ont aussi accumulé une dette technique qui pèse encore aujourd’hui sur les développeurs et les équipes opérationnelles. Passer à HTTP/2 vous permet de supprimer ces pratiques comme source de dette technique à l’avenir et vous offre un moyen de résorber celle déjà existante.
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, les développeurs ont contourné certaines limites de HTTP/1.1 en intégrant de petites images et en concaténant de petits fichiers. Cette approche a effectivement amélioré les performances, mais vous perdez la possibilité de mettre en cache au-delà de l’application (dans le réseau). Elle demande aussi une vigilance continue durant le cycle de vie de l’application, car toute modification de ces images intégrées ou des fichiers concaténés doit être répercutée dans chaque application. L'absence de modularité crée une dette technique qui persistera tant que vous maintenez l’application en service.
La dette technique, comme une dette réelle, nécessite un entretien. Elle a un coût : les intérêts. À chaque modification et mise à jour, ces intérêts s’accumulent. Nous devons mobiliser le temps et l’attention des développeurs. Nous devons consacrer des ressources aux tests. Nous devons utiliser des ressources réseau et de calcul. Ainsi, vous passerez plus de temps à gérer cette « dette » qu’à innover ou croître, ce qui complique l’adoption des nouvelles technologies, méthodologies et architectures susceptibles d’offrir un avantage compétitif.
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 .