Les serveurs d’applications comme points d’insertion

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

Dans un précédent article, nous avons exploré l’idée d’ajouter des services applicatifs à des architectures d’applications en pleine évolution à l’aide d’un concept que nous appelons les « points d’insertion ». Pour celles et ceux qui n’auraient pas suivi, un point d’insertion est un emplacement architecturalement distinct sur le parcours des données, du code jusqu’au client, où il est pertinent d’ajouter des fonctionnalités qui sortent souvent du périmètre du développement ou qui sont plus efficaces sur le plan opérationnel.

Un ensemble robuste de fonctionnalités permet d’ajouter ou d’améliorer les applications qui représentent aujourd’hui les activités de l’entreprise.

Les points d’insertion comprennent le client, l’infrastructure et l’application elle-même. Chacun présente des avantages et des inconvénients lorsqu’il s’agit de trouver un équilibre entre efficacité opérationnelle et maîtrise des coûts. Par exemple, l’intégration d’un service applicatif de protection contre les attaques DDoS centré sur le réseau au niveau du client ou de l’application ne serait probablement efficace ni sur le plan opérationnel ni en termes de coûts. En effet, aucun de ces deux points d’insertion n’a accès aux capacités d’accélération matérielle offertes par une solution au niveau de l’infrastructure, ni à la visibilité nécessaire pour prendre une décision éclairée.

Nous recherchons donc des services applicatifs qui soient efficaces à la fois sur le plan opérationnel et économique au point d’insertion ; dans le cas présent, nous nous concentrons sur le serveur d’applications (la plateforme) lui-même.

La plateforme applicative comme point d’insertion

À première vue, ce point d’insertion peut sembler être un choix étrange. Les serveurs d’applications hébergent et fournissent des applications, et non des services applicatifs. Mais si l’on considère le rôle que jouent aujourd’hui NGINX et d’autres serveurs d’applications, on constate qu’ils font souvent office à la fois d’infrastructure et de serveur. Par exemple, certains serveurs d’applications peuvent servir, et servent effectivement, de point de terminaison SSL. La terminaison SSL est un service applicatif, souvent associé au déchargement SSL (accélération matérielle). Les services de pare-feu pour applications web sont eux aussi souvent associés aux serveurs d’applications au moyen de plug-ins.

L’utilisation du serveur d’applications comme point d’insertion n’est ni nouvelle ni inhabituelle. Dans notre étude État des services applicatifs en 2020, nous avons interrogé les participants sur cette possibilité de déploiement des services applicatifs. Nous avons constaté que ce point d’insertion suscitait de l’intérêt. Environ 6 % des personnes interrogées souhaiteraient utiliser un « plug-in » pour les services applicatifs. Neuf pour cent préféreraient une solution « en tant que service », qui nécessite un élément de code complémentaire (injecté ou inclus) pour être invoquée. Une faible proportion, 4 %, souhaiterait utiliser une bibliothèque pour intégrer des services applicatifs. Cette dernière option est fréquemment utilisée pour ajouter des fonctionnalités aux applications sans serveur (fonction en tant que service).

Dans de nombreux cas, le déploiement d’un service applicatif sur un serveur d’applications est pertinent sur le plan opérationnel. Comme ces services sont souvent configurés pour une seule application, ils peuvent être regroupés et déployés par la même équipe. La maîtrise du serveur d’applications renforce la confiance et facilite l’intégration dans les écosystèmes et les pipelines de déploiement.

Dans certains cas, il sera judicieux de déployer l’application et le service applicatif ensemble, sur une même instance d’un serveur d’applications unique. Par exemple, la protection de l’application au moyen d’une politique propre à celle-ci peut être intégrée et exécutée comme une étape du traitement des requêtes et des réponses. Il est logique que cette fonctionnalité soit appelée depuis le serveur et, si l’inspection est effectuée localement, cela peut améliorer les performances en supprimant les étapes supplémentaires et le traitement assuré par des services hébergés en dehors de l’environnement. Cette approche peut accroître l’efficacité tant opérationnelle que financière, en particulier si le service est facturé à l’heure ou à chaque appel.

Que le serveur d’applications soit utilisé pour héberger un service applicatif autonome ou à la fois l’application et le service applicatif, il constitue assurément un bon point d’intégration pour les services applicatifs appropriés.

À 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