Défendre l’adoption de HTTP/2 auprès de l’entreprise

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

HTTP/2 a été développé dans un souci de performance.

Cela étant dit, il semble facile de justifier cette approche sur le plan commercial en partant du constat que les performances sont primordiales, en particulier lorsqu’il s’agit d’applications mobiles. Que les coûts se mesurent en termes de productivité ou de bénéfices, les mauvaises performances constituent toujours un problème majeur soulevé par les consommateurs concernant leurs achats, leurs interactions et leur utilisation des applications mobiles.

Mais c’est le cas le plus simple. N’importe qui peut arriver à cette conclusion en examinant simplement les nombreuses enquêtes menées sur le sujet. Nous savons tous que si une application ne répond pas en 5 secondes ou moins, les consommateurs comme les employés s’impatientent. Étant donné qu’en dehors du passage à HTTP/2, les entreprises disposent d’une grande variété de services liés aux performances pour remédier au problème, il faudra peut-être une motivation supplémentaire avant qu’elles ne décident de migrer vers HTTP/2 avec la même détermination qu’elles ont mise à se déclarer adeptes du « cloud first ».

Considérons donc que bon nombre des fonctionnalités de HTTP/2 sont nées de l’analyse des difficultés que les développeurs contournaient si souvent dans HTTP/1.1 que ces solutions de contournement sont devenues des pratiques courantes. Il s’agit notamment de l’intégration en ligne, de la concaténation et du partitionnement de domaine. Si toutes ces pratiques ont contribué à améliorer les performances, chacune a malheureusement généré une dette technique qui pèse encore aujourd’hui sur les développeurs comme sur les équipes d’exploitation. La migration vers HTTP/2 permet d’éviter que ces pratiques continuent d’alimenter la dette technique et offre un moyen de « rembourser » la dette existante.

La dette technique (et architecturale) résulte des choix effectués : choix de la technologie à adopter, du produit à acheter ou de l’architecture à mettre en œuvre. Elle peut également découler de décisions concernant l’emplacement, au sein de l’architecture applicative, où une solution donnée sera mise en œuvre.

Par exemple, les développeurs ont contourné certaines limitations de HTTP/1.1 en incorporant de petites images et en concaténant de petits fichiers. Cela a effectivement amélioré les performances, mais au prix de l’abandon de la mise en cache hors application (sur le réseau). Cette approche nécessitait également une attention particulière tout au long du cycle de vie de l’application, car toute modification apportée à ces images incorporées ou aux fichiers constituant le fichier concaténé unique devait être répercutée dans chaque application. Ce manque de modularité constitue une source de dette technique qui perdurera tant que l’application restera en service.

La dette technique, comme une dette réelle, doit être remboursée. Elle a un coût : les intérêts. À chaque modification et à chaque mise à jour, ces intérêts s’accumulent. Elle mobilise le temps et l’attention des développeurs. Elle nécessite des ressources de test, ainsi que des ressources réseau et de calcul. L’organisation consacre alors davantage de temps à rembourser sa « dette » qu’à innover ou à se développer, et peine à tirer parti des nouvelles technologies, méthodologies et approches architecturales susceptibles de lui procurer des avantages concurrentiels.

Il faut s’attaquer à cette dette. L’éliminer, en réalité, mais il faut au minimum la prendre en charge.

Pour mettre fin au cycle de la dette liée à HTTP/1.1, il faut désormais adopter HTTP/2. En remédiant à un large éventail de limitations techniques et protocolaires, HTTP/2 permet aux développeurs d’abandonner les solutions de contournement du passé et de faire désormais des choix différents, qui ne s’accompagnent pas d’une dette technique. Certes, les applications existantes conservent cette dette, mais elles peuvent être migrées ou remplacées par des applications utilisant HTTP/2, libérant ainsi les équipes de développement et d’exploitation des contraintes que leur imposaient les anciennes solutions de secours propres à HTTP/1.1.

HTTP/2 ne se résume pas à un protocole et à des applications plus rapides. Il s’agit aussi de supprimer les contraintes qui pèsent sur les équipes de développement et d’exploitation, afin de les libérer de la dette technique et de permettre aux organisations de tirer parti d’autres moyens d’améliorer les performances. Des moyens moins susceptibles d’engendrer le type de dette technique ou architecturale qui empêcherait l’entreprise de s’imposer dans la course à la victoire dans le jeu des applications.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie