Ce que les entreprises doivent savoir
7 min read
Les microservices sont une approche du développement de logiciels qui a connu un intérêt croissant au cours de la dernière décennie, allant de pair avec d’autres tendances telles que le développement agile natif du cloud et, plus particulièrement, l’utilisation de conteneurs comme un véhicule de déploiement de composants logiciels.
L’adoption de microservices a augmenté au cours des dernières années. Une enquête réalisée par O’Reilly en 2020 sur plus de 1 500 organisations ont constaté que seulement un quart environ n’utilisait pas du tout les microservices. Sur les 75 % qui l’étaient, seulement 10 % environ les utilisaient depuis plus de cinq ans, ce qui signifie que la majorité a franchi le pas des microservices au cours des dernières années.
Les microservices ne sont pas une technologie spécifique, mais plutôt un style d’architecture logicielle et une approche de conception d’applications et de services. Au lieu de créer une application en tant qu’entité monolithique unique, l’approche des microservices consiste à décomposer les fonctionnalités requises en un ensemble de services plus petits et déployables indépendamment qui communiquent entre eux.
Cette approche présente plusieurs avantages, dont l’un est une évolutivité plus facile, car les composants individuels peuvent être mis à l’échelle indépendamment les uns des autres. Seules les parties de l’application susceptibles de faire l’objet d’une forte demande, par exemple, doivent être mises à l’échelle, généralement en démarrant de nouvelles instances de ce composant pour équilibrer la charge de travail, plutôt que de faire évoluer l’ensemble de l’application.
Les microservices se prêtent également à un processus de développement agile, car la plus petite taille des composants facilite l’amélioration continue et permet des mises à jour plus rapides du code. Il permet également d’utiliser différents langages de programmation pour différents composants, car certains langages peuvent être mieux adaptés à certains types de tâches. Étant donné que les composants sont petits, cela permet aux développeurs de comprendre plus facilement le code, ce qui peut avoir un effet d’entraînement sur la fiabilité.
Un autre avantage est la possibilité de réduire les temps d’arrêt grâce à une meilleure isolation des pannes. Si une seule instance de microservice échoue, il est moins probable que l’ensemble de l’application ou du service tombe en panne.
Inconvénients potentiels
Bien qu’il y ait des avantages à une approche de microservices, il y a aussi quelques inconvénients que les organisations doivent prendre en compte. Par exemple, bien que le développement de chaque composant de microservice puisse être plus simple, l’application ou le service dans son intégralité peut devenir plus complexe à gérer.
C’est particulièrement le cas avec un déploiement à n’importe quelle échelle, qui peut impliquer des dizaines ou des centaines d’instances individuelles de différents composants de microservice. La complexité ne vient pas seulement de la gestion de la communication entre toutes ces instances distinctes, mais aussi de la surveillance de chacune d’entre elles pour s’assurer qu’elles fonctionnent dans les paramètres attendus et ne consomment pas plus de ressources qu’elles n’en auraient normalement besoin, ce qui peut indiquer qu’il y a un problème.
Les tests et le débogage peuvent également devenir plus difficiles avec les microservices, simplement parce que le traçage de la source d’un bogue peut être plus difficile parmi un réseau d’instances de microservices, chacune avec son propre ensemble de journaux. Tester l’intégralité de l’application peut également être délicat, car chaque microservice ne peut être testé correctement qu’une fois que tous les services dont il dépend ont également été testés.
En particulier, la surveillance est plus importante dans un déploiement de microservices, mais la nature distribuée des composants la rend plus complexe que les applications traditionnelles, largement autonomes. Le système de surveillance doit fonctionner au niveau de chaque instance de microservice individuelle, tout en gardant un œil sur le réseau de dépendances entre les différents composants.
Le mode de fonctionnement des microservices a également des implications pour l’infrastructure de l’organisation. La prise en charge de la mise à l’échelle automatique pour répondre à une demande accrue implique que les ressources pour les nouvelles instances de microservices doivent pouvoir être provisionnées par des appels d’interface de programmation d’application (API), ce qui implique un certain niveau d’infrastructure définie par logiciel de type cloud.
Les données peuvent être un autre problème épineux lors de la création d’une application ou d’un service basé sur une architecture de microservices, ou pour être plus précis, où stocker les données. En effet, chaque instance de microservice est susceptible d’avoir son propre magasin de données, mais certaines applications peuvent nécessiter la possibilité d’accéder à un référentiel partagé. Différents services auront également des exigences différentes en matière de stockage de données, certains dans l’industrie affirmant qu’un La base de données NoSQL est la plus logique, tandis que d’autres préconisent de s’en tenir à SQL, si c’est ce que l’organisation a déjà déployé.
Il existe d’autres opinions divergentes sur cette question, certains experts estimant qu’une seule base de données (mais peut-être pas un seul schéma) partagée par plusieurs services est la meilleure approche, car, d’une part, elle permet aux organisations de réutiliser les procédures qu’elles ont dans place pour la sauvegarde et la restauration de la base de données. D’autres déconseillent cela, car cela crée un point de défaillance unique potentiel qui va à l’encontre de l’éthique des microservices.
Planifiez soigneusement
Tout cela signifie que l’architecture des microservices peut ne pas convenir à toutes les organisations, ni à tous les types d’applications. Cependant, les raisons de son adoption croissante sont que les microservices facilitent la mise en œuvre d’une approche plus agile du déploiement de services, ce que de nombreuses organisations recherchent désormais.
« Les organisations qui empruntent la voie des microservices ont tendance à être plus à la pointe que les autres », explique l’analyste indépendant Clive Londubat. « En tant que tels, ils auront également tendance à être plus ouverts à la réflexion sur les besoins d’un passage à une nouvelle topologie architecturale. Historiquement, la majorité des changements ont été évolutifs : les architectures de microservices réussies sont révolutionnaires, nécessitant une refonte complète de ce qui est fait.
En d’autres termes, les microservices peuvent être plus adaptés à un déploiement « green field » qui est construit à partir de zéro, plutôt que des organisations essayant de refactoriser ou de mettre à jour une application existante.
Comme déjà noté, DockerLes conteneurs logiciels de style sont une technologie qui est devenue dans l’esprit de beaucoup associée aux microservices, bien qu’ils ne soient qu’un moyen de mettre en œuvre un déploiement distribué tel que les microservices. D’autres moyens peuvent inclure des machines virtuelles légères, ou même le déploiement d’instances de microservices en tant que code non virtualisé s’exécutant dans un environnement de serveur, tout comme les applications quotidiennes. Informatique sans serveur fonctions serait une autre façon de mettre en œuvre des microservices.
Les conteneurs sont peut-être mieux adaptés que les machines virtuelles, car ils sont moins gourmands en ressources et il est beaucoup plus rapide de générer une nouvelle instance de conteneur que de faire tourner une nouvelle machine virtuelle. Les conteneurs sont également désormais une technologie relativement mature, avec un vaste écosystème d’outils pour prendre en charge l’orchestration (comme Kubernetes), les communications (telles que Istio) et la surveillance.
Il est intéressant de noter que l’enquête O’Reilly a révélé qu’une proportion supérieure à la moyenne de répondants ayant déclaré avoir réussi avec les microservices avaient choisi de les instancier à l’aide de conteneurs, tandis qu’une proportion plus élevée de répondants ayant décrit leurs efforts de microservices comme infructueux n’avaient pas utilisé de conteneurs.
Cela peut suggérer que les conteneurs sont une option moins risquée lors de la mise en œuvre de microservices, mais encore une fois, il s’agit davantage de choisir la bonne technologie pour l’application et les exigences spécifiques de l’organisation.
“Si nous regardons simplement un microservice, ce n’est qu’un stub fonctionnel”, explique Londubat. « Le conteneur doit fournir l’environnement dont le microservice a besoin, avec l’orchestration, etc.
En d’autres termes, la création de microservices implique un type de complexité différent des styles d’application traditionnels et plus monolithiques. Pour cette raison, il peut être considéré comme une technologie mieux adaptée aux nouvelles applications modernes ou natives du cloud, ou aux organisations qui refont leur informatique dans le cadre d’un processus de transformation numérique.
