Introduction

L’architecture de microservices, associée aux outils DevOps, a offert une nouvelle perspective au développement logiciel par l’intégration du développement, de la gestion et des opérations. Dans la pratique DevOps, il peut être difficile de savoir quels outils/technologies utiliser pour gérer les microservices dans votre équipe. Nous avons rassemblé un ensemble d’outils/technologies pour vous aider à décider lesquels devraient faire partie de votre pile afin de gérer les microservices via DevOps.

Avant d’aborder les outils/technologies, parlons brièvement de quelques styles d’architecture utilisés pour développer des logiciels. L’architecture monolithique est décrite comme une application logicielle unique dans laquelle différents composants sont combinés en une seule application à partir d’une même plateforme. L’architecture de microservices est une approche du développement d’applications dans laquelle une application importante est construite comme un ensemble de services modulaires.

Quelques défis de l’architecture de microservices peuvent être relevés en utilisant la pile Netflix OSS.

Les deux architectures possèdent leurs avantages et leurs défis, le choix dépendra des exigences du projet. Voyons quelques défis de l’architecture de microservices et comment ils peuvent être relevés grâce à la pile Netflix OSS :

Fig 1. Défis des microservices et solution Netflix OSS avec ELK Stack pour les microservices basés sur Java

Netflix OSS est principalement destiné à la pile Java. Il s’agit d’ensembles de bibliothèques/configurations qui doivent être inclus dans toutes vos applications Java en plus de la logique métier. C’est un défi avec Netflix, car en tant que développeur, vous devez vous concentrer à la fois sur la logique métier réelle de l’application et sur les configurations des bibliothèques Netflix dans chaque microservice que vous souhaitez gérer.

De même, tous les outils/technologies présentent leurs avantages et leurs défis et pour cette raison, nous utilisons différentes piles d’outils pour surmonter les défis. Nous avons mentionné une liste des outils les plus utilisés, vous pourriez utiliser les mêmes ou il est tout à fait possible de les remplacer par d’autres alternatives dont nous discuterons à la fin.

Outils et pile technologique pour gérer les microservices

Choisir un outil est toujours difficile et prend du temps. Avant de choisir un nouvel outil/technologie, posez-vous toujours les questions suivantes à vous-même/à votre équipe :

• Quels sont les défis des outils/technologies existants utilisés dans l’équipe ?
• Pourquoi l’équipe a-t-elle besoin de ces nouveaux outils/technologies ?
• Quels bénéfices ce nouvel outil/cette nouvelle technologie apportera-t-il à l’équipe ?
• Quels sont les défis de ce nouvel outil/technologie ?
• Quand/où pouvons-nous utiliser ce nouvel outil/cette nouvelle technologie dans la pile technologique existante ?

Fig 2. Pile technologique avec avantages et défis

• Si nous avons une application monolithique, nous pouvons la décomposer en microservices en suivant le modèle du strangler.
• Les microservices offrent quelques avantages mais présentent aussi des défis comme la découverte de services et des déploiements plus lents.
• Dockeriser (conteneriser) les microservices nous aide à accélérer les déploiements et les temps de démarrage, mais il n’existe aucun mécanisme de vérification d’état/redémarrage automatique pour les conteneurs arrêtés.
• Orchestrer les conteneurs procure des avantages tels que la vérification d’état, le redémarrage automatique et la mise à l’échelle automatique des conteneurs/pods.
• Les plateformes PaaS nous aident en offrant de nombreuses fonctionnalités prêtes à l’emploi ainsi que l’infrastructure sous-jacente.
• Enfin, nous pouvons gérer les microservices/API soit en utilisant une passerelle d’API, soit un maillage de services.

Nous pouvons utiliser les conteneurs Docker et Kubernetes pour la contenerisation et l’orchestration des microservices. Il s’agit de deux outils distincts ; si vous cherchez un outil/produit unique pouvant gérer à la fois la contenerisation et l’orchestration, alors vous pouvez utiliser Openshift, qui combine les conteneurs Docker et Kubernetes. Après utilisation d’Openshift, nous devons encore gérer les API (interactions Microservices), ce qui peut être fait via une passerelle/outil de gestion d’API supplémentaire ou un service mesh comme Istio. Istio gère également des exigences opérationnelles plus complexes telles que le déploiement canari, la limitation de débit, la télémétrie, la découverte de services, l’orientation du trafic, le circuit-breaker, la traçabilité et la reprise après défaillance. Ce qui rend Istio unique, c’est que toutes ces fonctionnalités sont disponibles avec presque aucune modification du code de l’application. En réalité, la plupart de ces fonctionnalités ne requièrent aucune modification de code, à l’exception de la traçabilité et du circuit breaker où il faut ajouter un certain niveau de configuration à notre application.

Brève présentation des outils utilisés dans la figure ci-dessus :

• Docker est un outil conçu pour faciliter la création, le déploiement et l’exécution d’applications en utilisant des conteneurs. Les conteneurs permettent à un développeur de regrouper une application avec toutes les composantes dont elle a besoin, comme les bibliothèques et autres dépendances, et de la déployer en une seule entité.
• Kubernetes est un système open source d’orchestration de conteneurs permettant d’automatiser le déploiement, la mise à l’échelle et la gestion des applications.
• La plateforme OpenShift PaaS est une combinaison de clusters Kubernetes et Docker. L’architecture d’OpenShift est conçue de façon à pouvoir prendre en charge et gérer les conteneurs Docker, qui sont hébergés sur toutes les couches à l'aide de Kubernetes.
• Istio réduit la complexité de la gestion des déploiements de microservices en offrant une façon uniforme de sécuriser, connecter et surveiller les microservices.

Dans l’univers des outils DevOps et TI, nous avons une foule d’outils parmi lesquels choisir et il n’est pas obligatoire de s’en tenir à la pile ci-dessus. Regardons quelques autres solutions :

Conclusion

Le choix du bon outil prend du temps, car de nombreux éléments comme la fonctionnalité, la licence, les avantages et les défis doivent être pris en compte. Il est toujours recommandé de d’abord comprendre les défis de la pile technologique existante, puis de rechercher l’outil approprié qui conviendra aux besoins de l’équipe en pesant les avantages/défis. Au final, tout dépend des besoins et des objectifs de l’équipe.