Manie du maillage de service : Choisir Aspen Mesh ou NGINX
Parallèlement à l’écosystème plus vaste des conteneurs, les maillages de services continuent de progresser vers la maturité. Nous n'en sommes qu'aux débuts et il existe une variété d'approches appliquées pour résoudre le problème de la gestion du trafic intra-conteneur avec des maillages de services.
Nous (c'est le « nous » de l'entreprise) avons répondu à de nombreuses questions avant notre acquisition officielle de NGINX ce printemps. Plusieurs d’entre eux se sont concentrés sur les domaines de « chevauchement » en matière de technologie et de solutions. Après tout, NGINX et F5 proposent tous deux des solutions de distribution d’applications basées sur des proxy. NGINX et F5 construisent tous deux un service mesh. La question était : qui gagnerait ?
Parce que c’est souvent ainsi que cela se passe avec les acquisitions.
Comme mon homologue de NGINX et moi-même l’avons souvent répété, les technologies considérées comme se chevauchant étaient, à notre avis, plus complémentaires que concurrentes. C’est également vrai avec nos solutions de service mesh.
Notre logique découle d’une vision partagée de la livraison d’applications. Nous constatons tous deux l’impact que les conteneurs et le cloud, les microservices et une prépondérance de failles de sécurité ont sur les architectures et les modèles de distribution d’applications. De la même manière qu’il n’existe plus de « chemin de données unique pour fournir toutes les applications », il n’existe plus de « modèle de distribution d’applications unique pour fournir tous les services d’application ». Le cloud introduit plusieurs chemins de données. Les conteneurs introduisent un nouveau chemin de données. Les deux élargissent le placement possible des services d'application d'un proxy basé sur le réseau (un ADC) à une longue liste d'emplacements allant du client au réseau, au serveur, au conteneur et au cloud.
Comme nous l’avons noté dans un article consacré aux architectures dans notre série Bridging the Divide , le choix de l’endroit et de la manière dont on fournit des services d’application dépend de nombreux facteurs. Il ne s’agit pas simplement d’un choix entre les implémentations des fournisseurs ou entre « entreprise ou FOSS » ; c’est un choix qui doit prendre en compte l’emplacement (cloud ou sur site), le modèle opérationnel et même la facilité de mise en œuvre par rapport aux fonctionnalités requises. Compte tenu de l’étendue du chemin de distribution, cela offre plusieurs options pour l’insertion de services d’application.
C'est pourquoi nous considérons notre portefeuille combiné F5 et NGINX comme complémentaire et non concurrent. Parce que le marché global de la fourniture d’applications n’est plus en concurrence pour le placement dans un seul endroit, mais plutôt en concurrence pour le placement dans plusieurs endroits.
Les maillages de services sont conçus pour évoluer, sécuriser et fournir une visibilité sur les environnements de conteneurs. S’agissant d’une technologie naissante et en évolution rapide, de nombreux modèles émergent. L'un est basé sur l'utilisation d'un proxy side-car ( Envoy est devenu un projet CNCF de premier plan et le proxy side-car standard de l'industrie) et l'autre tire parti des proxys par application, à la manière de NGINX Plus .
Nous prévoyons actuellement de prendre en charge les deux, car les clients ont des opinions très tranchées sur leurs choix d’infrastructure en matière de conteneurs. Certains préfèrent Istio et Envoy et d’autres sont standardisés sur tout ce qui concerne NGINX.
Le nombre de composants qui doivent être exploités et gérés dans un environnement de conteneur est tel que l'expertise existante en technologie est un facteur important dans le choix d'un maillage de services. Les organisations qui ont standardisé NGINX pour leur infrastructure sont naturellement susceptibles de se tourner vers une solution de maillage de services NGINX, car elle comprend tous les logiciels NGINX, du proxy NGINX ou de l'unité NGINX au contrôleur NGINX. L’expertise opérationnelle existante dans NGINX et son écosystème open source peut signifier moins de frictions et de retards dans le déploiement.
D’autres organisations ont le même point de vue sur des solutions open source alternatives comme Istio et Envoy. Aspen Mesh utilise Envoy et s'implémente sur Istio, il convient donc plus naturellement aux organisations disposant déjà d'investissements dans la technologie sous-jacente. Il s'agit d'une distribution d'Istio testée, renforcée, packagée et contrôlée. Aspen Mesh ajoute plusieurs fonctionnalités à Istio, notamment une expérience utilisateur plus simple via le tableau de bord Aspen Mesh, un cadre politique qui permet aux utilisateurs de spécifier, de mesurer et d'appliquer des objectifs commerciaux, ainsi que des outils tels qu'Istio Vet et Traffic Claim Enforcer . Aspen Mesh, comme NGINX, s'intègre également bien avec F5 BIG-IP.
NGINX et Aspen Mesh offrent tous deux la gestion et la visualisation des clusters Kubernetes. Aspen Mesh et NGINX proposent tous deux leur solution en option sur site. Les deux fournissent un traçage et des mesures qui sont essentiels pour résoudre le problème de la visibilité, un défi de production majeur noté par 37 % des organisations dans le rapport State of Kubernetes de Replex .
Les organisations qui préfèrent une approche basée sur un proxy side-car pour le service mesh préféreront Aspen Mesh. Les organisations qui estiment que les maillages de services basés sur des proxys par application répondent le mieux à leurs besoins préféreront NGINX.
Votre choix dépend de divers facteurs et nous pensons que cet espace émergent est suffisamment important pour continuer à soutenir des choix qui répondent à différentes combinaisons de besoins et d’exigences.