Linkerd fait un travail solide lorsque les équipes veulent un maillage de services léger et natif de Kubernetes. Mais au fur et à mesure que les systèmes se développent, les priorités changent. Ce qui commence comme une solution propre peut se transformer en une nouvelle couche que les équipes doivent exploiter, déboguer et expliquer. Soudain, vous ne vous contentez plus d'expédier des services, vous gérez le comportement du maillage, les politiques et les cas limites qui ralentissent les choses.

C'est généralement à ce moment-là que les équipes commencent à regarder autour d'elles. Certaines veulent plus de visibilité sans avoir recours à des maillages internes profonds. D'autres ont besoin d'un contrôle du trafic plus simple, d'une meilleure observabilité ou de moins de pièces mobiles. Dans ce guide, nous examinons les alternatives Linkerd sous un angle pratique - des outils qui aident les équipes à maintenir des services fiables sans faire de l'infrastructure un travail à plein temps.

1. AppFirst

AppFirst aborde le problème sous un angle différent de celui d'un maillage de services traditionnel. Au lieu de se concentrer sur les politiques de trafic ou le comportement des sidecars, ils poussent les équipes à ne plus penser à l'infrastructure. L'idée est que les développeurs définissent ce dont une application a besoin - CPU, réseau, bases de données, image de conteneur - et qu'AppFirst s'occupe de tout ce qui se trouve en dessous. En pratique, cela plaît souvent aux équipes qui ont commencé avec Kubernetes et Linkerd pour simplifier la mise en réseau, puis ont réalisé qu'elles passaient encore beaucoup de temps à examiner les changements d'infrastructure et à déboguer les problèmes spécifiques au cloud.

Ce qui ressort, c'est la façon dont AppFirst traite l'infrastructure comme quelque chose que les développeurs ne devraient pas avoir à assembler pièce par pièce. On n'attend pas des équipes qu'elles connaissent Terraform, YAML ou des modèles spécifiques au cloud. Pour une équipe qui a initialement adopté Linkerd pour réduire le bruit opérationnel, AppFirst peut sembler être un pas de plus dans la même direction - moins de pièces mobiles, moins d'outils internes et moins de débats sur la façon dont les choses doivent être connectées. Il s'agit moins de contrôler finement le trafic que d'éliminer le besoin de gérer cette couche.

Faits marquants :

• Modèle axé sur l'application plutôt que sur la configuration au niveau de la maille
• Journalisation, surveillance et alerte intégrées sans installation supplémentaire
• Piste d'audit centralisée pour les changements d'infrastructure
• Visibilité des coûts par application et par environnement
• Fonctionne sur AWS, Azure et GCP

Pour qui c'est le mieux :

• Les équipes produits qui veulent éviter de gérer un maillage de services.
• Les développeurs fatigués de maintenir les modèles Terraform et Cloud
• Équipes de petite et moyenne taille sans groupe dédié à la plateforme
• Les entreprises normalisent la manière dont les applications sont déployées dans les nuages

Informations de contact :

• Site web : www.appfirst.dev

2. Istio

Istio est généralement le premier nom qui revient lorsque les équipes vont au-delà de Linkerd. Il s'agit d'un maillage de services complet qui étend Kubernetes avec la gestion du trafic, la sécurité et l'observabilité, mais il apporte également plus de décisions et plus de surface. Les équipes arrivent souvent ici après que Linkerd ait commencé à se sentir limité, en particulier lorsqu'elles ont besoin de règles de routage avancées, de configurations multi-clusters ou d'un contrôle plus approfondi sur le comportement service à service.

Istio peut être exécuté dans différents modes, y compris son approche ambiante plus récente qui réduit le besoin de sidecars. Cette flexibilité est utile, mais elle signifie également que les équipes doivent être claires sur les problèmes qu'elles essaient réellement de résoudre. Istio fonctionne mieux lorsqu'une certaine maturité opérationnelle est déjà en place. Il ne supprime pas tant la complexité qu'il ne la centralise, ce qui peut être un bon compromis si vous avez besoin de politiques cohérentes pour de nombreux services et environnements.

Faits marquants :

• Routage avancé du trafic pour les déploiements canari et échelonnés
• Sécurité intégrée mTLS et services basés sur l'identité
• Observabilité approfondie grâce aux mesures et à la télémétrie
• Fonctionne sur Kubernetes, les machines virtuelles et les environnements hybrides.
• Modèles de déploiement multiples, y compris les modes side-car et ambiant

Pour qui c'est le mieux :

• Équipes exploitant des environnements Kubernetes de grande taille ou à plusieurs clusters.
• Organisations disposant d'une plateforme dédiée ou d'un SRE
• Charges de travail nécessitant des contrôles fins du trafic et de la sécurité

Informations de contact :

• Site web : istio.io
• Twitter : x.com/IstioMesh
• LinkedIn : www.linkedin.com/company/istio

3. HashiCorp Consul

Consul se situe quelque part entre un outil classique de découverte de services et un maillage complet de services. Bien qu'il puisse être utilisé avec Kubernetes, il n'y est pas lié, ce qui est souvent la principale raison pour laquelle les équipes considèrent Consul comme une alternative à Linkerd. Il est courant de voir Consul adopté dans des environnements où certains services fonctionnent sur Kubernetes, d'autres sur des VM, et quelques-uns vivent encore dans des configurations plus anciennes qui ne peuvent pas être facilement déplacées.

Les fonctionnalités de maillage sont présentes, y compris mTLS, la division du trafic et les proxys basés sur Envoy, mais elles sont optionnelles plutôt qu'obligatoires. Certaines équipes utilisent Consul principalement pour la découverte de services et ajoutent progressivement des fonctionnalités de maillage. Cette approche incrémentale peut être utile lorsque le remplacement de Linkerd impliquerait un changement important et perturbateur. La contrepartie est que Consul introduit ses propres concepts de plan de contrôle, qui prennent du temps à comprendre si les équipes viennent d'un contexte Kubernetes uniquement.

Faits marquants :

• Découverte de services et fonctions de maillage dans une seule plateforme
• Prise en charge de Kubernetes, des VM et des déploiements hybrides.
• Sécurité des services basée sur l'identité avec mTLS
• Gestion du trafic L7 à l'aide des proxys Envoy
• Fonctionne dans des configurations sur site, multi-cloud et hybrides.

Pour qui c'est le mieux :

• Équipes exploitant des services dans des environnements mixtes
• Les organisations qui ne peuvent pas se standardiser sur Kubernetes seul.
• Plates-formes souhaitant la découverte et le maillage de services dans un seul système

Informations de contact :

• Site web : developer.hashicorp.com/consul
• Facebook : www.facebook.com/HashiCorp
• Twitter : x.com/hashicorp
• LinkedIn : www.linkedin.com/company/hashicorp

4. Kuma

Kuma se positionne comme un maillage de services à usage général qui ne suppose pas que tout vit à l'intérieur de Kubernetes. Les équipes se tournent souvent vers lui lorsque Linkerd commence à se sentir trop limité à Kubernetes, surtout s'il y a encore des VM ou des charges de travail mixtes dans le tableau. Kuma s'exécute au-dessus d'Envoy et agit comme un plan de contrôle qui fonctionne à travers les clusters Kubernetes, les machines virtuelles, ou les deux en même temps. Cette flexibilité a tendance à être plus importante dans les environnements réels que sur les diagrammes d'architecture.

D'un point de vue opérationnel, Kuma s'oriente vers une configuration basée sur des politiques plutôt que sur des réglages constants. Les politiques L4 et L7 sont intégrées et les équipes n'ont pas besoin de devenir des experts Envoy pour mettre en place le routage de base, la sécurité ou l'observabilité. Un modèle courant est celui d'une équipe de plateforme gérant un plan de contrôle tandis que différentes équipes de produits opèrent à l'intérieur de maillages séparés. Ce n'est pas l'option la plus légère, mais elle est souvent choisie lorsque la simplicité doit s'étendre au-delà d'un seul cluster.

Faits marquants :

• Fonctionne sur Kubernetes, les machines virtuelles et les environnements hybrides.
• Politiques de trafic L4 et L7 intégrées
• Prise en charge de plusieurs maillages à partir d'un seul plan de contrôle
• Envoy est intégré par défaut, il n'est pas nécessaire d'installer un proxy séparé.
• GUI, CLI et REST API disponibles

Pour qui c'est le mieux :

• Équipes exécutant à la fois des services Kubernetes et des services basés sur des machines virtuelles.
• Les organisations qui ont besoin de configurations multi-clusters ou multizones
• Les équipes chargées des plates-formes soutiennent plusieurs groupes de produits
• Environnements où le champ d'application de Linkerd semble trop étroit

Informations de contact :

• Site web : kuma.io
• Twitter : x.com/KumaMesh

5. Traefik Mesh

Traefik Mesh adopte une approche sensiblement différente de celle de Linkerd et d'autres meshes. Au lieu d'injecter des sidecars, il s'appuie sur un modèle plus " opt-in " qui évite de modifier chaque pod. Cela le rend attrayant pour les équipes qui veulent avoir une visibilité sur le trafic des services sans s'engager dans un déploiement complet du maillage à travers le cluster. L'installation a tendance à être rapide, ce qui est souvent la première chose que les gens remarquent lorsqu'ils le testent.

L'ensemble des fonctionnalités se concentre sur la visibilité du trafic, le routage et la sécurité de base plutôt que sur l'application de politiques approfondies. Traefik Mesh s'appuie sur Traefik Proxy, il est donc familier aux équipes qui utilisent déjà Traefik pour l'entrée. Il n'est pas conçu pour une gouvernance multi-cluster complexe, mais il fonctionne bien en tant que couche légère lorsque Linkerd semble être plus complexe que ce dont l'équipe a réellement besoin.

Faits marquants :

• Aucune injection dans le side-car n'est nécessaire
• Construit sur la base de Traefik Proxy
• Prise en charge native du trafic HTTP et TCP
• Métriques et traçage avec Prometheus et Grafana
• Contrôles d'accès et de trafic compatibles avec le SMI
• Installation simple basée sur Helm

Pour qui c'est le mieux :

• Équipes souhaitant un maillage de services à faible engagement
• Clusters Kubernetes où les sidecars sont un problème
• Les petites plates-formes privilégient la visibilité du trafic plutôt que la profondeur de la politique

Informations de contact :

• Site web : traefik.io
• Twitter : x.com/traefik
• LinkedIn : www.linkedin.com/company/traefik

6. Amazon VPC Lattice

Amazon VPC Lattice prend un chemin différent de la plupart des alternatives Linkerd. Au lieu d'agir comme un maillage de services traditionnel avec des sidecars, il fonctionne comme une couche de mise en réseau de services gérée par AWS. Il connecte les services à travers les VPC, les comptes et les types de calcul sans nécessiter l'injection de proxies dans chaque charge de travail. Cela suffit à changer la façon dont les équipes envisagent la communication entre services.

En pratique, le VPC Lattice intéresse souvent les équipes qui souhaitent un comportement similaire à celui d'un maillage sans pour autant utiliser un maillage. Le routage du trafic, les politiques d'accès et la surveillance sont gérés par des constructions natives d'AWS, ce qui assure la cohérence avec IAM et d'autres services AWS. L'inconvénient est qu'il reste fermement à l'intérieur d'AWS. Pour les équipes déjà engagées, c'est généralement acceptable.

Faits marquants :

• Pas de proxy sidecar nécessaire
• Connectivité service à service gérée sur AWS
• Fonctionne avec les VPC, les comptes et les types d'ordinateurs.
• Intégration avec AWS IAM pour le contrôle d'accès
• Prise en charge du routage TCP et de la couche d'application

Pour qui c'est le mieux :

• Les organisations se modernisent sans adopter de side-cars
• Environnements mêlant conteneurs, instances et sans serveur.
• Les équipes remplacent Linkerd pour réduire les frais généraux opérationnels

Informations de contact :

• Site web : aws.amazon.com
• Facebook : www.facebook.com/amazonwebservices
• Twitter : x.com/awscloud
• LinkedIn : www.linkedin.com/company/amazon-web-services
• Instagram : www.instagram.com/amazonwebservices

7. Cilium

Cilium aborde le problème du maillage des services d'un point de vue réseau plutôt que proxy. Au lieu de s'appuyer entièrement sur les proxys sidecar, il utilise eBPF à l'intérieur du noyau Linux pour gérer la connectivité, la sécurité et la visibilité des services. C'est souvent la raison pour laquelle Cilium entre en scène lorsque les équipes estiment que Linkerd ajoute trop de surcharge ou de latence, en particulier dans les clusters avec des volumes de trafic élevés.

Ce qui rend Cilium intéressant en tant qu'alternative à Linkerd, c'est que les fonctionnalités de maillage de services sont optionnelles et flexibles. Certaines équipes commencent par l'utiliser pour la mise en réseau de Kubernetes et les politiques de réseau, puis activent progressivement les capacités de maillage par la suite. D'autres l'adoptent spécifiquement pour éviter les sidecars. La courbe d'apprentissage est cependant différente. Le débogage se rapproche du niveau du noyau, ce qui plaît à certaines équipes et en gêne d'autres au début.

Faits marquants :

• Maillage de services basé sur l'eBPF sans sidecars obligatoires
• Traite les protocoles de réseau et d'application en même temps
• Fonctionne de L3 à L7 selon la configuration
• Options flexibles de plan de contrôle, y compris l'intégration d'Istio

Pour qui c'est le mieux :

• Équipes sensibles à la charge de travail des mandataires
• Les plateformes Kubernetes utilisent déjà Cilium pour la mise en réseau.
• Environnements avec de grandes grappes ou un débit élevé
• Les ingénieurs sont à l'aise pour travailler au plus près de la couche du système d'exploitation

Informations de contact :

• Site web : cilium.io
• LinkedIn : www.linkedin.com/company/cilium

8. Maille Kong

Kong Mesh est construit au-dessus de Kuma et adopte une approche plus structurée des opérations de maillage de services. Il prend en charge les charges de travail basées sur Kubernetes et VM et se concentre sur le contrôle centralisé à travers plusieurs zones ou environnements. Les équipes se tournent généralement vers Kong Mesh lorsque Linkerd commence à se sentir trop limité pour les configurations cross-cluster ou hybrides, en particulier lorsque la gouvernance et le contrôle d'accès deviennent des préoccupations quotidiennes.

D'un point de vue opérationnel, Kong Mesh semble plus lourd que Linkerd, mais plus délibéré. Les politiques relatives aux tentatives, à mTLS et au routage du trafic sont appliquées au niveau de la plateforme plutôt que d'être résolues à plusieurs reprises par chaque équipe. Certaines organisations l'utilisent en même temps que Kong Gateway, tandis que d'autres le traitent purement comme un maillage. Quoi qu'il en soit, il a tendance à apparaître dans les environnements où les équipes de la plateforme recherchent davantage la cohérence que le minimalisme.

Faits marquants :

• Exécution dans des environnements Kubernetes et VM
• mTLS intégré, gestion du trafic et découverte de services
• Prise en charge du maillage multizone et multilocataire
• Options de plan de contrôle centralisé, y compris SaaS ou auto-hébergé

Pour qui c'est le mieux :

• Équipes de plates-formes gérant plusieurs clusters ou régions
• Organisations avec des charges de travail hybrides ou basées sur des machines virtuelles
• Environnements nécessitant une gouvernance plus forte que celle offerte par Linkerd
• Des équipes prêtes à troquer la simplicité contre un contrôle centralisé

Informations de contact :

• Site web : konghq.com
• Twitter : x.com/kong
• LinkedIn : www.linkedin.com/company/konghq

9. Red Hat OpenShift Service Mesh

OpenShift Service Mesh est étroitement lié à la plateforme OpenShift et suit un schéma familier pour les équipes qui y exécutent déjà des charges de travail. Sous le capot, il est basé sur Istio, Envoy et Kiali, mais emballé d'une manière qui correspond à la vision de Red Hat sur les opérations de cluster. Pour les équipes qui quittent Linkerd, il s'agit moins d'un changement d'outil que d'un choix de plateforme plus large.

Ce qui ressort généralement de la pratique, c'est la part du cycle de vie du maillage qui est déjà intégrée à OpenShift lui-même. L'installation, les mises à jour et la visibilité sont intégrées à d'autres fonctionnalités d'OpenShift, ce qui peut réduire le nombre de tableaux de bord distincts que les équipes doivent vérifier. En même temps, cela suppose que vous êtes à l'aise pour vous engager avec OpenShift en tant que runtime. Ce compromis convient à certaines équipes et en limite d'autres.

Faits marquants :

• Construit sur Istio et Envoy avec l'intégration OpenShift-native
• Tableaux de bord centralisés via OpenShift et Kiali
• Prise en charge des configurations de maillage de services à plusieurs clusters
• Politiques mTLS et de gestion du trafic intégrées

Pour qui c'est le mieux :

• Les organisations qui souhaitent que les opérations de maillage soient alignées sur les outils de la plate-forme
• Environnements où le cycle de vie des clusters est étroitement contrôlé
• Groupes remplaçant Linkerd dans le cadre d'un déploiement plus large d'OpenShift.

Informations de contact :

• Site web : www.redhat.com
• Courriel : apac@redhat.com
• Facebook : www.facebook.com/RedHat
• Twitter : x.com/RedHat
• LinkedIn : www.linkedin.com/company/red-hat
• Adresse : 100 E. Davie Street Raleigh, NC 27601, USA
• Téléphone : 888 733 4281

10. Maille Gloo

Gloo Mesh se concentre moins sur le maillage lui-même que sur la gestion des maillages basés sur Istio à travers les clusters et les environnements. Il entre souvent en scène lorsque Linkerd commence à se sentir trop limité pour les configurations multi-clusters ou lorsque les équipes luttent pour maintenir la cohérence des déploiements Istio. Au lieu de réécrire le fonctionnement du maillage, Gloo Mesh se place au-dessus et gère le cycle de vie, la visibilité et la politique dans les environnements.

Une chose qui se démarque est la façon dont il prend en charge les modèles sidecar et sidecarless grâce au mode ambiant d'Istio. Cette flexibilité a tendance à séduire les équipes de plateforme qui jonglent avec différents besoins d'application en même temps. Au quotidien, Gloo Mesh appartient généralement à une équipe centrale plutôt qu'à des équipes de service individuelles, ce qui modifie la façon dont les décisions relatives au routage et à la sécurité sont prises.

Faits marquants :

• Visibilité multi-clusters et multi-environnements
• Gestion centralisée des politiques et du cycle de vie
• Prise en charge des modèles avec et sans side-car
• L'accent est mis sur la cohérence opérationnelle

Pour qui c'est le mieux :

• Les équipes de la plateforme utilisent Istio à grande échelle
• Organisations gérant de nombreux clusters ou régions
• Les équipes dépassent le stade de Linkerd pour s'orienter vers des topologies plus complexes

Informations de contact :

• Site web : www.solo.io
• Twitter : x.com/soloio_inc
• LinkedIn : www.linkedin.com/company/solo.io

11. Flomesh Service Mesh

Flomesh Service Mesh, souvent abrégé en FSM, est conçu pour les équipes qui se soucient beaucoup des performances et de la flexibilité du matériel. Il utilise un proxy de plan de données appelé Pipy, écrit en C++, qui apparaît rapidement lorsque les équipes exécutent des clusters denses ou des charges de travail en périphérie où l'utilisation des ressources est réellement importante. Comparé à Linkerd, FSM a tendance à être plus pratique et configurable, en particulier lorsque les équipes commencent à travailler avec du trafic au-delà du HTTP de base.

Un autre détail qui détermine l'utilisation de FSM est son ouverture à l'extension. Le plan de données comprend un moteur JavaScript, ce qui signifie que les équipes peuvent modifier le comportement sans reconstruire l'ensemble du maillage. Cela est intéressant dans les environnements où les règles de mise en réseau changent souvent ou lorsque des protocoles inhabituels sont en jeu. FSM s'appuie également sur des configurations Kubernetes multi-clusters, de sorte qu'il apparaît généralement dans les conversations où un cluster ne suffit plus et où les modèles de trafic commencent à s'étendre.

Faits marquants :

• Proxy Pipy conçu pour une utilisation réduite des ressources
• Prise en charge des architectures x86, ARM64 et autres
• Prise en charge de Kubernetes multi-classe à l'aide de MCS-API
• Contrôleurs d'entrée, de sortie et d'API de passerelle intégrés
• Prise en charge d'un grand nombre de protocoles au-delà du protocole HTTP standard

Pour qui c'est le mieux :

• Équipes exploitant des clusters Kubernetes de grande taille ou à haute densité.
• Environnements avec matériel ARM ou mixte
• Plates-formes nécessitant un comportement personnalisé du trafic

Informations de contact :

• Site web : flomesh.io
• Courriel : contact@flomesh.cn
• Twitter : x.com/pipyproxy

12. Maille de tremble

Aspen Mesh est un maillage de services basé sur Istio, conçu pour les fournisseurs de services, en particulier ceux qui travaillent dans les télécommunications et les environnements réglementés. Il apparaît le plus souvent dans les projets de transition de la 4G à la 5G, où les microservices font partie d'un système beaucoup plus vaste et où la visibilité du trafic n'est pas facultative. Par rapport à Linkerd, Aspen Mesh est moins axé sur la légèreté que sur la prévisibilité et l'inspectabilité.

L'une des différences les plus pratiques est l'accent mis sur l'inspection du trafic et la gestion des certificats. Aspen Mesh comprend des outils qui permettent aux opérateurs de voir le trafic au niveau du service et de l'abonné, ce qui est important lorsque la conformité, la facturation ou le dépannage sont liés au comportement du réseau. Il est généralement géré par des équipes centrales de plateforme ou de réseau plutôt que par des développeurs d'applications, et il s'adapte mieux aux environnements où Kubernetes n'est qu'une pièce d'un tableau d'infrastructure plus vaste.

Faits marquants :

• Construit sur Istio avec des outils opérationnels supplémentaires
• Conçu pour les installations multi-clusters et multi-locataires
• Inspection des paquets pour une visibilité détaillée du trafic
• Forte concentration sur la gestion des certificats et des identités
• Prise en charge des réseaux à double pile IPv4 et IPv6

Pour qui c'est le mieux :

• Plateformes de télécommunications et de fournisseurs de services
• Environnements réglementés avec des besoins de visibilité stricts
• Équipes gérant les transitions de la 4G à la 5G
• Organisations gérant de grands clusters multi-locataires

Informations de contact :

• Site web : www.f5.com/products/aspen-mesh
• Facebook : www.facebook.com/f5incorporated
• Twitter : x.com/f5
• LinkedIn : www.linkedin.com/company/f5
• Instagram : www.instagram.com/f5.global
• Adresse : 801 5th Ave Seattle, Washington 98104 États-Unis
• Téléphone : 800 11275 435

13. Matière grise

Greymatter aborde le maillage de services sous un angle différent de la plupart des alternatives Linkerd. Au lieu de commencer par les proxies et les règles de routage, il se concentre sur la connectivité et la sécurité au niveau de la charge de travail dans des environnements déjà fragmentés. Ce problème se pose généralement dans les grandes entreprises où les services sont répartis entre plusieurs nuages, des systèmes sur site ou des environnements réglementés où la configuration manuelle n'est tout simplement pas envisageable. Dans ces cas, Greymatter remplace souvent un mélange de maillages partiels, de scripts personnalisés et d'outils de mise en réseau en périphérie plutôt qu'une configuration unique.

Ce qui ressort de l'utilisation quotidienne, c'est l'automatisation du comportement du maillage au lieu d'un réglage constant. Les politiques, les certificats et les connexions aux services sont gérés de manière centralisée, ce qui réduit la nécessité pour les équipes de toucher aux aspects internes du maillage. Comparé à Linkerd, cela semble moins orienté vers les développeurs et plus orienté vers l'infrastructure. Il n'essaie pas d'être léger ou invisible. Il est destiné aux environnements où la visibilité, l'auditabilité et la cohérence sont plus importantes que la réduction de l'encombrement.

Faits marquants :

• Connectivité centralisée des services dans les environnements en nuage et sur site
• Identité au niveau de la charge de travail et communication cryptée des services
• Gestion automatisée des certificats et des politiques
• Observabilité approfondie axée sur le comportement des applications plutôt que sur le trafic périphérique
• Conçu pour les déploiements multicloud et hybrides

Pour qui c'est le mieux :

• Entreprises exploitant des services dans plusieurs nuages
• Environnements soumis à des exigences strictes en matière de sécurité ou de conformité
• Les équipes de la plateforme remplacent les opérations manuelles de maillage

Informations de contact :

• Site web : greymatter.io
• Facebook : www.facebook.com/greymatterio
• Twitter : x.com/greymatterio
• LinkedIn : www.linkedin.com/company/greymatterio
• Adresse : 4201 Wilson Blvd, 3rd Floor Arlington, VA 22203

Conclusion

Linkerd est souvent le point de départ des équipes, et non leur point d'arrivée. Au fur et à mesure que les systèmes se développent, les questions changent. Certaines équipes ont besoin d'un contrôle plus étroit sur les clusters. D'autres veulent moins de pièces mobiles, ou moins de travail au niveau de la plateforme. Les alternatives présentées ici reflètent davantage ces compromis qu'une idée unique de ce que devrait être un maillage de services.

Ce qui importe le plus, c'est d'être honnête sur la façon dont votre équipe fonctionne aujourd'hui. Si le maillage nécessite une attention constante, il cesse d'être utile. S'il s'efface en arrière-plan tout en continuant à faire son travail, c'est généralement le signe que vous avez choisi la bonne direction. Il n'y a pas d'option parfaite, mais des outils qui s'adaptent mieux à certains environnements qu'à d'autres.