Linkerd brille sur la durée là où la ferveur pour Istio s’estompe
L’utilisation du maillage de services dans le monde réel prend son essor. Les premiers utilisateurs de Linkerd affirment que sa convivialité a été la clé de leur succès jusqu’à présent, avec cette technologie complexe.
Linkerd 1, basé sur JVM et lancé par Buoyant.io en 2016, a été le premier produit estampillé service mesh disponible sur le marché. D’ailleurs, Buoyant a inventé le terme utilisé aujourd’hui par tout un secteur.
Mais l’intérêt des entreprises pour le maillage de services – une architecture de réseau à grande échelle qui répartit l’application des politiques entre les proxys de données – n’a vraiment pris son essor qu’avec celui de Kubernetes au cours des trois dernières années. Cette technologie se prête bien aux infrastructures de microservices qui fonctionnent sur des containers et nécessitent une gestion de réseau bien plus fine que pour les workloads s’exécutant sur des machines virtuelles.
Le berceau de la création de Kubernetes, Google, a emboîté le pas en annonçant Istio en 2017 avec IBM et Lyft. Linkerd 2, qui est arrivé en 2018, a commencé à rattraper le niveau de support pour Kubernetes, mais à ce moment-là, Istio avait capté une grande partie du buzz autour du maillage des services. La course était lancée.
Istio a particulièrement ébloui les utilisateurs lors des premières discussions avec des fonctionnalités plus sophistiquées sur le plan technique pour les environnements containerisés, notamment le TLS mutuel (mTLS) intégré pour la sécurité. Il a également attiré l’attention grâce à une connexion avec le proxy side-car Envoy, une coqueluche du monde CNCF largement considérée comme le standard du secteur. Linkerd, en revanche, exploite son propre proxy.
Buoyant est minuscule comparé à Google et IBM. L’entreprise privée, fondée en 2015, a levé 24 millions de dollars de fonds, selon Crunchbase. Dans son rapport financier annuel de l’année 2019, IBM mentionne avoir engrangé 77,1 milliards de dollars. Alphabet, la société mère de Google, a réalisé un chiffre d’affaires de 162 milliards de dollars.
L’écart de taille entre les mainteneurs de chaque projet se reflète dans le nombre de participations communautaires qu’ils ont obtenues jusqu’à présent. Linkerd a le soutien du CNCF, son site web indique qu’il compte plus de 100 contributeurs. Mais l’application web Stackalytics montre que les ingénieurs de Buoyant sont de loin les membres les plus actifs avec 991 commits, constituant 80,4 % du nombre total de participations ; suivent 204 contributions indépendantes, représentant 16,5 % de cet ensemble.
Quant à Istio, si Google est le premier contributeur au projet dans l’analyse de Stackalytics, avec 1 705 commits, soit 53 % du total, les contributeurs indépendants ont réalisé 25,3 % des commits, suivis de Red Hat et IBM, avec 7,4 % et 7,1 %, respectivement.
Néanmoins, cette année, la domination d’Istio dans les discussions, essentiellement théoriques, a commencé à faiblir. Et pour cause, Google a choisi de ne pas en faire don au CNCF ou à toute autre fondation open source établie. Les responsables du projet ont préféré élargir le comité directeur pour inclure quatre nouveaux membres en dehors des girons IBM et Google, en septembre.
Alors que le maillage de services passait de la démonstration à des mises en production, Linkerd a su convaincre les premiers utilisateurs par sa simplicité d’usage, avant même qu’il ne puisse égaler toutes les fonctionnalités d’Istio.
« Nous avons commencé avec des containers et Kubernetes sur GKE. Nous avons déployé Istio il y a deux ans et demi, principalement pour notre machine learning et nos back-end data science », relate Matt Young, architecte principal du cloud de la place de marché en ligne EverQuote à Cambridge (Massachusetts). « Il a fonctionné comme annoncé… mais sa complexité était assez importante. »
Les utilisateurs de Linkerd ont commencé petit pour soutenir leur croissance
La compagnie est passée de startup à licorne, après son introduction en bourse en 2018. Elle dispose aujourd’hui d’un environnement tentaculaire et de plus de 150 développeurs, mais d’une équipe de cinq ingénieurs pour gérer son infrastructure cloud native.
Lorsque cette équipe a entrepris d’expérimenter Istio, elle n’administrait qu’un seul cluster Kubernetes dans GKE. Cet environnement comprend désormais de multiples clusters hébergés sur Amazon EKS et Kubernetes multi-tenancy orchestrer à l’aide de l’outil IaC Terraform de Hashicorp.
Pourtant, continuer avec Istio même à une échelle beaucoup plus petite il y a deux ans aurait nécessité au moins cinq ingénieurs supplémentaires, ou une augmentation comparable des coûts des services professionnels de Google Cloud, estime Matt Young. C’est alors qu’il a commencé à étudier Linkerd.
« Istio, c’est comme une Bugatti : il en faut deux ou trois parce qu’il y en a toujours une en panne. Et on avait besoin de rouler vite sur un chemin de terre. »
Matt YoungArchitecte principal du cloud, Everquote
« Il y avait moins de définitions de ressources personnalisées et un modèle de déploiement beaucoup plus simple », assure Matt Young. « Istio, c’est comme une Bugatti : il en faut deux ou trois parce qu’il y en a toujours une en panne. Et on avait besoin de rouler vite sur un chemin de terre. »
Plus précisément, EverQuote souhaitait obtenir un équilibrage de charge gRPC, car le trafic de son réseau a augmenté, pour finalement être multiplié par huit.
« En fait, nous n’avons pas réussi à déployer tout Istio », avoue Matt Young. « Nous n’avons utilisé que la passerelle d’entrée et juste assez de control plane pour gérer la répartition de charge. Nous avons coupé court quand nous avons compris que cela nécessiterait beaucoup plus d’apprentissages — même le diagnostic et le dépannage étaient encore en cours, et nous avons rapidement réalisé que cela ne serait pas viable ».
Un autre professionnel de l’IT travaillant pour une entreprise en pleine croissance en Europe, l’éditeur de logiciels Finleap Connect, a vécu une expérience similaire lors des débuts d’Istio en 2017.
« Nous avons installé Istio alors que ce qui allait devenir Linkerd n’était pas disponible », témoigne Christian Hüning, directeur de la technologie du cloud chez Finleap Connect. « Mais nous avons découvert que les développeurs devaient faire trop de choses pour faire fonctionner Istio. »
Istio est désormais plus simple à déployer et à maintenir, notamment depuis que son control plane s’appuie sur une architecture monolithique (la fameuse version 1.5 qui avait semé la discorde dans un premier temps). Mais Linkerd a également eu le temps d’étendre ses propres caractéristiques différenciées, telles que des outils d’observabilité intégrés.
Everquote a poussé son utilisation de Linkerd, passant d’un équilibrage de charge relativement sobre à une gestion fine de la latence du réseau. En ce sens, Matt Young apprécie cette imbrication du service mesh avec des composants de surveillance open source tel que Prometheus, ainsi que des tableaux de bord incorporés.
« Linkerd fait tourner Prometheus dans son control plane, et le fait d’exposer des métriques dès le départ nous a permis d’augmenter considérablement notre productivité », indique-t-il.
Linkerd comble les lacunes du service mesh
Istio avait l’avantage sur Linkerd grâce au mTLS. Pour rappel, il s’agit du mécanisme par lequel le serveur et le client s’authentifient mutuellement sur un réseau. Par le passé, cette authentification se concentrait sur les clients vérifiant le certificat du serveur, mais pas l’inverse.
L’administration du mTLS est l’un des principaux arguments de vente du service mesh dans les environnements containerisés. Ceux-ci dépendent de nombreux clients et de connexions réseau complexes qui rendent son déploiement manuel à la fois nécessaire et extrêmement difficile. Le mTLS est apparu pour la première fois sous forme expérimentale dans Linkerd 2.2 au début de l’année 2019.
Au cours des 18 derniers mois qui ont suivi, Linkerd a rattrapé son retard en matière de mTLS. Il est maintenant intégré par défaut à chaque connexion du réseau de services de Linkerd, sans besoin de configuration artisanale (Istio mTLS peut également être installé automatiquement depuis la version 1,4). Dans la version 2.9, livrée en novembre, le mTLS de Linkerd s’étend au-delà des liaisons HTTP et gRPC pour prendre en charge le protocole TCP utilisé par les applications et les bases de données stateful.
Entre-temps, au cours des six derniers mois, une nouvelle génération de produits de maillage de services a vu le jour, notamment un projet dédié à Kubernetes lancé par Microsoft en août, et en octobre, des versions stables de solutions comme celles de Kong Kuma et Nginx de F5. Kong Kuma et l’Open Service Mesh de Microsoft sont tous deux des composants open source sous la gouvernance de la CNCF. Ils misent sur la facilité d’utilisation qui manque à Istio – des propositions de valeur que Buoyant défend depuis des années.
« Alors que les éditeurs entrent dans cette première phase de généralisation du marché, ils veulent rendre le service mesh bien plus simple à consommer et à gérer. »
Brad CasemoreAnalyste, IDC
« C’est là que nous observons tout le monde se diriger », déclare Brad Casemore, analyste chez IDC. « Alors que les éditeurs entrent dans cette première phase de généralisation du marché, ils veulent rendre le service mesh bien plus simple à consommer et à gérer ».
Bien que Linkerd ait ouvert la voie en ce sens, la société continue d’affiner certaines de ses fonctions plus sophistiquées pour les environnements à large échelle. Par exemple, l’équipe de Patrick Hüning doit attendre qu’un pull request qu’elle a soumis soit complété, avant de pouvoir mettre à niveau Linkerd 2.7. Cela permettra à Finleap de personnaliser les limites des ressources de Prometheus. Pour l’instant, les défauts de Linkerd posent des problèmes de performance pour les grands clusters Kubernetes de Finleap, très denses.
Envoy, le sujet qui touche le PDG de Buoyant
Envoy joue une place importante dans l'architecture d'Istio.
William Morgan, PDG et fondateur Buoyant, a tendance à s’énerver lorsque le sujet Envoy vient sur la table. Les clients potentiels du service mesh évoquent souvent l’absence d’intégration de Linkerd avec le projet embarqué par la CNCF quand ils évaluent les produits disponibles sur le marché. Mais William Morgan croit fermement que ce constat résulte d’un manque de compréhension, plutôt que d’une véritable nécessité pour Linkerd de se connecter avec le proxy Envoy.
« Il y a des gens qui disent avoir besoin d’Envoy, mais ce n’est pas une réelle exigence », a-t-il déclaré dans une interview le mois dernier. « Une partie de la confusion autour du service mesh provient du bruit provoqué par les détails de déploiement alors que l’on devrait se concentrer sur les problèmes que les utilisateurs essaient de résoudre avec ».
« Il y a des gens qui disent avoir besoin d’Envoy, mais ce n’est pas une réelle exigence. »
William MorganPDG, Buoyant
Comme le mTLS, le proxy de Linkerd a également été affiné au fil du temps. Les responsables de Linkerd ont déployé Linkerd2-proxy en juillet, réécrit en langage de programmation Rust pour en améliorer les performances. Le mois dernier, la version 2.9 de Linkerd a ajouté la prise en charge du proxy multicœur.
Certains observateurs de l’industrie pensent qu’essayer de concurrencer Envoy à ce stade est une cause perdue, mais William Morgan n’est pas du tout d’accord.
« En fin de compte, les exigences de Linkerd concernant la consommation des ressources et la sécurité étaient tout simplement trop restrictives pour qu’Envoy soit un choix réaliste », a-t-il écrit dans un article de blog publié en juillet. « Envoy était un couteau suisse, alors que nous avions besoin d’une aiguille ».
Les analystes sont partagés sur la relation entre Envoy et Linkerd. Brad Casemore n’est toujours pas sûr qu’il vaille la peine pour Linkerd de combattre l’élan d’Envoy alors que le maillage de service se généralise, même s’il dispose d’une technologie supérieure.
« Au niveau de la couche de données – les clients ne remarquent pas vraiment les différences relativement mineures entre l’un ou l’autre », constate Brad Casemore d’IDC. « Il sera intéressant de voir s’ils [Buoyant] pourront vraiment montrer qu’ils sont meilleurs qu’Envoy, surtout si Envoy bénéficie d’un soutien aussi important, et pas seulement dans la communauté Istio ».
À l’inverse, l’analyste du Gartner Fintan Ryan s’attend à ce que le débat sur Envoy s’estompe au fur et à mesure que les déploiements des service mesh se développent.
« La plupart des organisations n’ont pas besoin d’être conscientes de la complexité de ce qu’il se passe sous le capot », tranche-t-il.
Pour approfondir sur Architectures logicielles et SOA
