Les rôles des sidecars dans une architecture de microservices

Service Mesh et sidecars

Les sidecars sont directement associés à un service mesh, qui est une couche d'infrastructure à faible latence gérant de gros volumes de communication entre les services d'application. Originellement, ce modèle de maillage de service doit simplifier les pratiques transversales telles que le routage, la résilience, la sécurité et l'observabilité. Parmi les implémentations de maillage de services propriétaires et open source les plus connues figurent Istio, Consul, Nginx Service Mesh et AWS App Mesh.

Le sidecar s'attache à chaque service au sein d'une application distribuée et peut établir des connexions avec chaque machine virtuelle ou instance de conteneur nécessaire pour effectuer des opérations de routine. Les sidecars sont capables de gérer les tâches qu'il vaut mieux abstraire des services individuels, comme les systèmes de monitoring et les vérifications des protocoles de sécurité.

Les avantages des sidecars pour les microservices

Les service mesh et les sidecars font désormais partie intégrante des architectures de microservices, car ils permettent de contrôler la communication entre services, d'administrer l'acheminement des demandes, d'assurer la tolérance aux pannes et de contribuer au maintien de la haute disponibilité. Les sidecars peuvent également fournir un support direct pour les tâches essentielles de gestion des microservices, telles que la découverte de services et le traçage distribué.

Le sidecar permet également aux composants d'accéder aux services depuis n'importe quel endroit en utilisant n'importe quel langage. En tant que mécanisme de proxy de communication, le sidecar sert aussi de traducteur pour la gestion des dépendances inter-langues. Cela est bénéfique non seulement pour les applications distribuées présentant des exigences d'intégration particulièrement complexes, mais aussi pour les systèmes applicatifs qui dépendent fortement d'intégrations externes, de services de gestion et d'outils de développement.

Meilleures pratiques pour les implémentations de sidecars

L'utilisation de sidecars dans les architectures de microservices présente de nombreux avantages, mais cette technologie n'est pas facile à mettre en place et à maintenir. S'il n'est pas géré correctement, l'ajout de ces composants abstraits peut ajouter de la latence aux communications réseau, au lieu de les rationaliser.

En particulier, l'ajout de sidecars à des environnements déjà complexes peut rendre le développement et la gestion des applications plus difficiles. Les développeurs et les Ops doivent se familiariser avec la nouvelle couche de services. Il faut appréhender le fonctionnement du service mesh et la manière dont il modifiera potentiellement le comportement des applications. Cela nécessite notamment une bonne compréhension de la gestion des conteneurs dans un système de microservices distribué, étant donné que le maillage de services est souvent déployé au-dessus d'orchestrateurs de conteneurs comme Kubernetes.

Les sidecars comportent également une part de risque en ce qui concerne les mécanismes de rejeu des transactions ayant échoué. Les équipes chargées de l'architecture logicielle dotent généralement les services de la capacité de relancer les transactions ayant échoué afin d'éviter d'arrêter inutilement les processus applicatifs associés. Cependant, de nombreux éditeurs de maillage de services propriétaires équipent aussi les sidecars de la même fonctionnalité. Lorsque plusieurs mécanismes de relance fonctionnent en parallèle, il peut en résulter des transactions dupliquées qui drainent des ressources cruciales et font chuter les performances globales de l'application à des niveaux préoccupants.

Pour tirer le meilleur parti des sidecars dans les scénarios de microservices, et éviter certains des pièges mentionnés ci-dessus, appliquez ces meilleures pratiques dès le départ :

• N'utilisez les sidecars que lorsque c'est nécessaire. Si une application ne contient que quelques services de base qui ne sont pas sujets à de fréquentes défaillances de communication, la complexité de gestion associée au maillage de services et aux sidecars n'est peut-être pas le bon choix, car elle ajoutera probablement des frais de gestion inutiles.
• Créez des tableaux de bord centralisés de surveillance et de suivi des demandes. Les sidecars étant généralement impliqués dans de grands volumes de trafic distribué, il est impératif de fournir aux équipes de développement et d'exploitation des tableaux de bord centralisés leur permettant de rester au fait de l'observabilité, d'effectuer un suivi efficace des demandes et d'accéder facilement aux journaux d'erreurs.
• Envisagez d'ajouter des mesures de sécurité réseau supplémentaires. La plupart des produits de maillage de services sont livrés avec un ensemble de fonctions de sécurité de base, telles que des outils de gestion des certificats, d'authentification et d'autorisation. Toutefois, il peut être prudent d'ajouter et d'appliquer des restrictions réseau supplémentaires sur les sidecars afin de limiter la communication entre les services sensibles qui résident dans certains conteneurs.