Service Meshes dans le Cloud Native World – La nouvelle pile

Les microservices occupent une place centrale dans l’industrie du logiciel. La transition d’une architecture monolithique à une architecture basée sur des microservices permet aux entreprises de déployer leur application plus fréquemment, de manière fiable, indépendante et évolutive sans aucun tracas. Cela ne veut pas dire que tout est vert dans l’architecture Microservice; certains problèmes doivent être résolus, comme lors de la conception de systèmes distribués. C’est là que le concept «Service Mesh» devient très populaire.

Nous pensons depuis un certain temps à diviser les grandes applications monolithiques en applications plus petites pour faciliter le développement et le déploiement de logiciels. Ce tableau ci-dessous, emprunté à la conférence de Burr Sutter intitulée «9 étapes pour réussir avec Kubernetes», explique l’évolution des microservices.

Source de l’image: Burr Sutter chez Devoxx

L’introduction du maillage de services était principalement due à une tempête parfaite au sein de la scène informatique. Lorsque les développeurs ont commencé à développer des systèmes distribués en utilisant une approche multilingue (polyglotte), ils avaient besoin d’une découverte de services dynamique. Des opérations étaient nécessaires pour gérer les inévitables échecs de communication en douceur et appliquer les politiques de réseau. Les équipes de plateforme ont commencé à adopter des systèmes d’orchestration de conteneurs tels que Kubernetes et souhaitaient acheminer le trafic de manière dynamique autour du système à l’aide de proxys réseau modernes pilotés par API, tels que Envoy.

Qu’est-ce qu’un service Mesh?

Certes, les microservices PEUVENT réduire la complexité du développement de logiciels dans les organisations, mais à mesure que le nombre de microservices au sein d’une organisation passe d’un chiffre à un chiffre élevé, les complexités interservices peuvent devenir décourageantes.

Par conséquent, un maillage de services est une approche appropriée pour gérer et contrôler la façon dont les différentes parties d’une application interagissent, communiquent entre elles et partagent des données. Un service mesh est une idée construite en tant que couche d’infrastructure dédiée directement dans une application. Cette couche d’infrastructure visible permet d’optimiser la communication et d’éviter les temps d’arrêt au fur et à mesure que l’application se développe.

Les microservices posent des défis tels que la complexité opérationnelle, la mise en réseau, la communication entre les services, la cohérence des données et la sécurité. C’est là que les maillages de services sont utiles et sont spécifiquement conçus pour relever ces défis posés par les microservices en offrant un niveau granulaire de contrôle sur la façon dont les services communiquent entre eux.

Offre de mailles de service:

• Découverte de service
• Mise en réseau des services
• Routage et gestion du trafic
• Cryptage et authentification / autorisation
• Mesures granulaires et capacités de surveillance
• Observabilité
• Limitation de débit
• Coupure de circuit
• L’équilibrage de charge
• Traçage distribué

Vous trouverez ci-dessous le graphique qui représente la tendance Google pour le terme de recherche « service mesh ». Comme vous pouvez le voir, il se déplace vers le haut et au-dessus.

Comment fonctionne un service Mesh?

Un maillage de services se compose principalement de deux composants essentiels: un plan de données et un plan de contrôle. Effectuer des appels de service à service rapides, fiables et sécurisés au sein d’une architecture de microservices est ce qu’un maillage de services s’efforce de faire. Bien qu’il soit appelé «maillage de services», il est plus approprié de dire «maillage de proxies» dans lequel les services peuvent se brancher et soustraire complètement le réseau.

Source de l’image: Glasnostic

Dans un maillage de service typique, ces proxys sont infusés dans chaque déploiement de service en tant que side-car. Plutôt que d’appeler les services directement sur le réseau, les services appellent leur proxy side-car local, qui gère la demande au nom du service, encapsulant ainsi les complexités de l’échange de service à service. L’ensemble interconnecté de proxys side-car implémente ce que l’on appelle le plan de données. Les composants d’un maillage de service qui sont utilisés pour configurer les proxys et collecter des métriques sont collectivement appelés plan de contrôle de maillage de service.

Les maillages de service sont destinés à résoudre les multiples obstacles rencontrés par les développeurs lorsqu’ils s’adressent aux points de terminaison distants. En particulier, les maillages de service aident les applications s’exécutant sur une plate-forme d’orchestration de conteneurs telle que Kubernetes.

Produits de maille de service

Un maillage de services est un excellent solutionneur de problèmes lorsqu’il s’agit de gérer vos applications cloud. Si quelqu’un exécute des applications dans une architecture de microservices, il est probablement considéré comme un bon candidat pour un maillage de services. Au fur et à mesure que l’organisation adopte une architecture de microservices, les services ont tendance à augmenter en nombre et un maillage de services vous permet de désencombrer la complexité accrue d’une énorme collection de microservices.

Certains produits de maillage de service largement utilisés comprennent:

• Istio, sorti en mai 2017, est un projet open source de Google, IBM et Lyft.

• Consul Connect, sorti en novembre 2018, est un projet de logiciel open source géré par HashiCorp.

API Gateway vs Service Mesh: mieux ensemble?

Alors qu’une passerelle API peut gérer le trafic est-ouest, un maillage de service semble être un meilleur ajustement ici car un maillage de service contient un proxy des deux côtés de la connexion.

De même, même si un maillage de service peut gérer le trafic nord-sud, une passerelle API est considérée comme un meilleur ajustement pour un tel arrangement car une partie de la connexion dépasse l’administration du maillage de service.

Le trafic nord-sud exige généralement la supervision de l’utilisateur final. Une passerelle API est beaucoup plus axée sur la gestion de l’expérience de l’utilisateur final.

Source de l’image: DZone

Les entreprises peuvent utiliser une passerelle API pour proposer des API en tant que produit à des clients / utilisateurs externes ou internes via un point d’entrée centralisé et pour administrer et réguler leur exposition. Ceci est généralement utilisé lorsque des applications complexes doivent se parler.

Source de l’image: Kong

Les maillages de service peuvent être utilisés pour créer une connectivité de trafic L4 / L7 sécurisée et fiable entre tous les services qui s’exécutent dans nos systèmes en utilisant un modèle de déploiement de side-car décentralisé qui peut être adopté et implémenté sur chaque service. Ils sont généralement utilisés pour créer une connectivité point à point entre tous les services liés à l’application.

Les entreprises utilisent souvent à la fois un maillage de services et une passerelle API, et les utilisent simultanément pour se compléter. Pour en savoir plus sur les maillages de service, consultez «Solutions de maillage de service: un cours intensif» de Melissa McKay.

Avez-vous vraiment besoin d’un maillage de service?

La réponse très générique et sûre est «cela dépend».

Cela dépend du cas d’utilisation, du timing, du nombre de microservices que vous exécutez, du coût et d’un examen attentif du coût par rapport aux avantages.

Les maillages de service permettent aux plates-formes logicielles d’effectuer de nombreuses applications. Ils fournissent une standardisation de l’infrastructure en ce qui concerne les défis de sécurité, d’évolutivité, d’observabilité et de gestion du trafic auxquels sont confrontés les développeurs et gérés de manière centralisée.

Si vous déployez votre premier, deuxième ou troisième microservice, vous n’avez probablement pas besoin d’un service mesh. Au lieu de cela, suivez la voie de l’apprentissage de Kubernetes et utilisez-le dans votre entreprise. Il y aura un point de basculement où vous apprécierez la nécessité d’un maillage de service. Aussi, lorsque le nombre de microservices dans notre projet augmentera, nous nous familiariserons naturellement avec les obstacles qu’un maillage de services résoudra. Cela nous aidera à préparer et à planifier notre voyage de maillage de service lorsque le moment idéal arrivera.

Source de l’image: NGINX

À mesure que la complexité de l’application augmente, la mise en œuvre d’un maillage de services devient une alternative réaliste à la mise en œuvre de capacités service par service. Ceci est très bien expliqué dans l’article de NGINX «Ai-je besoin d’un service Mesh?»

En réduisant les complexités impliquées dans une architecture de microservices, les maillages de services offrent une grande variété de fonctionnalités et sont devenus d’excellents agents DevOps. Ils deviennent incontournables si vous adoptez une méthode native pour le cloud. Les entreprises qui adoptent des maillages de service ne voient aucun signe de ralentissement.

Tout en utilisant des architectures de microservices, il est essentiel d’assurer le stockage et la sécurité des artefacts tels que les binaires, les images de conteneurs, les secrets, les métadonnées, etc. Par conséquent, il est fortement recommandé d’utiliser un gestionnaire de référentiel d’artefacts robuste tel qu’Artifactory, qui peut agir en tant que registre Docker et Kubernetes pour un processus de déploiement de microservices fluide et sans souci, et utilisez cette base pour plonger profondément dans une approche de maillage de services à mesure que vos besoins augmentent.

Joyeux DevOpsing!

Image de vedette via Pixabay.