La folie du maillage de services : choisir entre Aspen Mesh et NGINX

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

À l’instar de l’écosystème plus large des conteneurs, les maillages de services poursuivent leur progression vers la maturité. Nous n’en sommes toutefois qu’aux prémices, et diverses approches sont mises en œuvre pour résoudre le problème de la gestion du trafic entre conteneurs à l’aide de maillages de services.

Nous (c’est-à-dire l’entreprise) avons répondu à de nombreuses questions à l’approche de l’acquisition officielle de NGINX au printemps dernier. Plusieurs d’entre elles portaient sur les domaines de « chevauchement » entre nos technologies et nos solutions. Après tout, NGINX et F5 proposent toutes deux des solutions de mise à disposition d’applications basées sur des proxys. NGINX et F5 développent également toutes deux un maillage de services. La question était donc : lequel l’emporterait ?

Parce que c’est souvent ainsi que les choses se passent lors d’une acquisition.

Comme mon homologue de NGINX et moi-même l’avons souvent répété, les technologies présentées comme faisant double emploi étaient, selon nous, davantage complémentaires que concurrentes. Cela vaut également pour nos solutions de maillage de services.

Notre raisonnement découle d’une vision commune de la mise à disposition des applications. Nous constatons tous deux l’impact des conteneurs et du cloud, des microservices et de la multiplication des failles de sécurité sur les architectures et les modèles de mise à disposition des applications. De même qu’il n’existe plus « un seul chemin de données pour acheminer toutes les applications », il n’existe plus « un seul modèle de mise à disposition des applications pour fournir tous les services applicatifs ». Le cloud introduit plusieurs chemins de données. Les conteneurs en introduisent un nouveau. Tous deux élargissent les possibilités de déploiement des services applicatifs, qui ne se limitent plus à un proxy réseau (un ADC), mais couvrent une longue liste d’emplacements allant du client au cloud, en passant par le réseau, le serveur et le conteneur.

Comme nous l’avons indiqué dans un article consacré aux architectures de notre série Bridging the Divide, le choix du lieu et de la manière dont les services applicatifs sont fournis dépend de nombreux facteurs. Il ne s’agit pas simplement de choisir entre les solutions de différents fournisseurs ou entre « entreprise et logiciels libres » ; ce choix doit tenir compte de l’emplacement (dans le cloud ou sur site), du modèle opérationnel, mais aussi de la facilité de mise en œuvre par rapport aux fonctionnalités requises. Compte tenu de l’étendue du chemin de livraison, il existe plusieurs possibilités d’intégration des services applicatifs.

C’est pourquoi nous considérons que notre portefeuille combiné F5 et NGINX est complémentaire et non concurrentiel. En effet, sur le marché global de la fourniture d’applications, la concurrence ne porte plus sur un emplacement unique, mais sur plusieurs emplacements.

Les maillages de services sont conçus pour assurer la mise à l’échelle et la sécurité des environnements de conteneurs, ainsi que pour offrir une visibilité sur ceux-ci. Cette technologie étant récente et évoluant rapidement, plusieurs modèles voient le jour. L’un repose sur l’utilisation d’un proxy side-car (Envoy s’est imposé comme un projet CNCF de premier plan et comme le proxy side-car de référence dans le secteur), tandis que l’autre tire parti de proxys propres à chaque application, à l’image de NGINX Plus.

Nous prévoyons actuellement de prendre en charge les deux, car nos clients ont des avis très tranchés sur leurs choix d’infrastructure en matière de conteneurs. Certains préfèrent Istio et Envoy, tandis que d’autres ont tout standardisé sur NGINX.

Le nombre de composants à exploiter et à gérer dans un environnement de conteneurs est tel que l’expertise technologique existante constitue un facteur important dans le choix d’un maillage de services. Les entreprises qui ont standardisé leur infrastructure sur NGINX seront naturellement enclines à se tourner vers une solution de maillage de services NGINX, car celle-ci repose entièrement sur des logiciels NGINX, du proxy NGINX ou de NGINX Unit à NGINX Controller. L’expertise opérationnelle existante en matière de NGINX et de son écosystème open source peut réduire les difficultés et les délais de déploiement.

D’autres organisations partagent ce point de vue concernant des solutions open source alternatives telles qu’Istio et Envoy. Aspen Mesh utilise Envoy et s’appuie sur Istio, ce qui en fait un choix plus naturel pour les organisations ayant déjà investi dans la technologie sous-jacente. Il s’agit d’une distribution d’Istio testée, renforcée, packagée et validée. Aspen Mesh ajoute plusieurs fonctionnalités à Istio, notamment une expérience utilisateur simplifiée grâce au tableau de bord Aspen Mesh, un cadre de gestion des politiques qui permet aux utilisateurs de définir, de mesurer et de faire respecter des objectifs métier, ainsi que des outils tels que Istio Vet et Traffic Claim Enforcer. À l’instar de NGINX, Aspen Mesh s’intègre également parfaitement à F5 BIG-IP.

NGINX et Aspen Mesh proposent tous deux des fonctionnalités de gestion et de visualisation des clusters Kubernetes. Aspen Mesh et NGINX proposent tous deux leur solution en option sur site. Tous deux fournissent des fonctions de traçage et des métriques essentielles pour résoudre le problème de visibilité, l’un des principaux défis en production signalé par 37 % des organisations dans le rapport State of Kubernetes Report from Replex.

Les organisations qui privilégient une approche du maillage de services reposant sur des proxys side-car préféreront Aspen Mesh. Celles qui estiment que les maillages de services reposant sur un proxy par application répondent mieux à leurs besoins préféreront NGINX.

Votre choix dépend de divers facteurs, et nous estimons que ce domaine émergent est suffisamment important pour continuer à proposer des solutions répondant à différentes combinaisons de besoins et d’exigences.

À 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