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 à gérer et exploiter dans un environnement de conteneurs rend l’expertise technologique un critère essentiel pour choisir un maillage de services. Les organisations ayant standardisé NGINX pour leur infrastructure s’orientent naturellement vers une solution de maillage NGINX, car elle inclut l’ensemble des logiciels NGINX, du proxy NGINX ou de NGINX Unit jusqu’à NGINX Controller. Votre expertise opérationnelle en NGINX et dans son écosystème libre réduit les frictions et accélère votre déploiement.

D’autres organisations partagent les mêmes opinions sur des solutions libres alternatives comme Istio et Envoy. Aspen Mesh utilise Envoy et se construit sur Istio, ce qui convient mieux aux entreprises ayant déjà investi dans cette technologie. Nous proposons une distribution d’Istio éprouvée, renforcée, empaquetée et validée. Aspen Mesh complète Istio avec plusieurs fonctionnalités, notamment une interface utilisateur simplifiée via son tableau de bord, un cadre de politiques permettant de définir, mesurer et appliquer des objectifs métiers, ainsi que des outils comme Istio Vet et Traffic Claim Enforcer. Comme NGINX, Aspen Mesh s’intègre aussi harmonieusement 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.