Jump to section

Les microservices, qu'est-ce que c'est ?

Copier l'URL

Les microservices désignent une approche architecturale du développement d'applications. Ils sont distribués et faiblement couplés, de sorte que les modifications apportées par une équipe n'affectent pas l'ensemble de l'application. L'avantage de ce type d'architecture est que les équipes de développement sont en mesure de créer rapidement de nouveaux composants d'applications pour répondre aux évolutions des besoins de l'entreprise.

Une architecture de microservices se différencie d'une approche monolithique classique par le fait qu'elle décompose une application pour en isoler les fonctions clés. Chacune de ces fonctions est appelée « service » et ces services peuvent être développés et déployés indépendamment les uns des autres. Ainsi, chacun peut fonctionner (ou dysfonctionner) sans affecter les autres. Cela vous aide à adopter la dimension technologique du DevOps et à simplifier l'itération et la distribution continues (CI/CD) tout en les rendant plus accessibles.

image

Vous vous souvenez de la dernière fois que vous avez consulté un site de vente en ligne ? Vous avez certainement utilisé la barre de recherche du site pour parcourir la liste des produits disponibles. Cette fonctionnalité de recherche constitue un service. Le site vous a sans doute également recommandé des produits associés, à partir d'une base de données sur les préférences des acheteurs. Ces recommandations représentent également un service. Vous avez ajouté un article au panier ? Vous l'avez deviné : il s'agit là aussi d'un service.

Un microservice est donc une fonction essentielle d'une application, qui est exécutée de manière totalement indépendante des autres services. Cependant, une architecture de microservices ne se résume pas à la relation entre les fonctions fondamentales d'une application : elle permet aussi de restructurer les équipes de développement et la communication entre les services pour mieux se préparer aux inévitables pannes, mais aussi aux évolutions futures et à l'intégration de nouvelles fonctions.

Comment y parvenir ? Tout simplement en adaptant les bases d'une architecture orientée services (SOA) pour déployer des microservices.

Si la décomposition d'une application en fonctions pour éviter les pièges des architectures monolithiques vous semble être un concept familier, c'est parce que l'architecture de microservices ressemble à l'architecture orientée services (SOA), une conception logicielle déjà bien établie.

Au tout début, la moindre modification apportée à une application existante nécessitait une mise à jour complète de la version, avec son propre cycle d'assurance qualité, ce qui pouvait potentiellement ralentir de nombreuses équipes en aval. Cette approche est souvent qualifiée de « monolithique », car le code source de toute l'application était structuré au sein d'une unité de déploiement unique (souvent au format .war ou .ear). Lorsque la mise à jour d'une partie de l'application provoquait des erreurs, il fallait placer l'ensemble hors ligne pour annuler les modifications et résoudre le problème. Si cette approche reste viable pour des applications légères, les entreprises en pleine croissance ne peuvent se permettre de tels temps d'arrêt.

Place alors à l'architecture orientée services, qui structure les applications en services individuels et réutilisables qui communiquent via un ESB. Au sein de cette architecture, chacun des services individuels (organisés autour d'un processus métier spécifique) suit un protocole de communication (tel que SOAP, ActiveMQ ou Apache Thrift) pour « se déplacer » dans l'ESB. Ensemble, tous ces services intégrés via un ESB constituent une application.

D'un côté, cela permet de développer, tester et paramétrer les services simultanément, sans devoir subir des cycles de développement monolithiques. De l'autre, l'ESB représente cependant un point individuel de défaillance pour l'ensemble du système. En d'autres termes, les efforts qui visaient à supprimer le « monolithe » n'ont fait qu'en créer un autre : l'ESB, qui pourrait potentiellement ralentir toute l'entreprise.

Quelle est la différence ? Les microservices peuvent communiquer entre eux, généralement de manière stateless, donc les applications développées de cette manière peuvent être plus tolérantes aux pannes et moins tributaires d'un seul ESB. Cela permet également aux équipes de développement de choisir leurs propres outils puisque les microservices peuvent communiquer à l'aide d'API indépendantes de tout langage.

Finalement, les microservices ne sont pas une idée neuve, vu leur ressemblance avec l'architecture SOA. Cependant, ils sont devenus plus viables grâce aux progrès réalisés en matière de technologies de conteneurisation. Grâce aux conteneurs Linux, vous pouvez maintenant exécuter plusieurs parties d'une application indépendamment les unes des autres, sur le même matériel, avec un niveau de contrôle bien plus élevé sur leurs éléments et cycles de vie. Avec les API et les pratiques DevOps, les microservices conteneurisés constituent la base des applications cloud-native.

Les microservices stimulent vos équipes et vos routines grâce à un développement distribué. Vous pouvez aussi développer plusieurs microservices simultanément. Ainsi, davantage de développeurs peuvent travailler en même temps, sur la même application, ce qui réduit la durée du développement.

Mise sur le marché plus rapide

Comme les cycles de développement sont plus courts, l'architecture de microservices permet des déploiements et mises à jour plus agiles.

Haute évolutivité

À mesure que la demande pour certains services augmente, vous pouvez étendre les déploiements sur plusieurs serveurs et infrastructures pour répondre à vos besoins.

Résilience

Lorsqu'ils sont développés correctement, ces services indépendants n'ont aucun impact les uns sur les autres. Cela signifie que, lorsqu'un élément tombe en panne, l'ensemble de l'application ne cesse pas de fonctionner comme c'est le cas avec le modèle monolithique.

Facilité de déploiement

Les applications basées sur des microservices sont plus modulaires et légères que les applications monolithiques classiques. Aussi, vous pouvez les déployer plus sereinement. Certes, cela requiert une meilleure coordination (envisagez une couche de Service Mesh), mais les bénéfices peuvent être énormes.

Accessibilité

Vu que l'application est décomposée en plusieurs éléments, les développeurs peuvent plus facilement comprendre, mettre à jour et améliorer chacun de ces éléments. Résultat : des cycles de développement plus courts, surtout s'ils sont associés à des méthodes de développement agiles.

Ouverture

Grâce aux API qui utilisent plusieurs langages, les développeurs ont la liberté de choisir la technologie et le langage qui conviennent le mieux à chaque fonction.

Si votre entreprise envisage de passer à une architecture de microservices, préparez-vous à des changements, non seulement au niveau des applications, mais aussi au niveau des méthodes de travail des équipes. Ces changements culturels et structurels sont identifiés comme des défis, en partie parce que chaque équipe aura sa propre cadence de déploiement et sera responsable d'un service unique avec une clientèle spécifique. S'il ne s'agit pas des préoccupations habituelles des développeurs, elles n'en demeurent pas moins essentielles dans la mise en œuvre d'une architecture de microservices efficace.

Outre la culture et les processus, la complexité et l'efficacité sont les deux défis majeurs liés aux architectures de microservices. John Frizelle, architecte de plateformes pour Red Hat Mobile, a énoncé les huit catégories de défis suivantes dans son intervention lors du Red Hat Summit de 2017 :

  1. Création : il faut prendre le temps d'identifier les dépendances entre les services. Gardez à l'esprit que la création d'une version peut nécessiter la création de plusieurs autres versions à cause de ces dépendances. Prenez également en compte les effets que les microservices peuvent avoir sur vos données.
  2. Test : les tests d'intégration, tout comme les tests complets, peuvent se complexifier et prendre une importance capitale. Sachez qu'une panne d'un élément de l'architecture peut provoquer d'autres défaillances ailleurs, selon la manière dont vos services s'appuient les uns sur les autres.
  3. Production de versions : lorsque vous lancez de nouvelles versions, faites attention aux problèmes de rétrocompatibilité. Pour y remédier, pensez au développement selon une logique conditionnelle, même si vous risquez d'augmenter rapidement la complexité et l'encombrement. Autre solution : gérer plusieurs versions en parallèle pour différents clients, même si la maintenance et la gestion seront plus complexes.
  4. Déploiement : oui, c'est aussi un défi, du moins au début. Pour faciliter le déploiement, vous devez au préalable investir largement dans des solutions d'automatisation. En effet, les microservices deviennent vite trop complexes pour envisager un déploiement manuel. Réfléchissez à la manière dont vous allez déployer vos services, ainsi qu'à un ordre de priorité.
  5. Journalisation : avec des systèmes distribués, vous avez besoin de journaux centralisés pour regrouper vos données. Sans eux, l'évolutivité devient vite impossible à gérer.
  6. Surveillance : il est essentiel de disposer d'une vision centralisée du système pour identifier les sources des problèmes.
  7. Débogage : il n'est pas possible de recourir au débogage à distance depuis votre environnement de développement intégré (IDE), qui n'est de toute manière pas applicable à des dizaines ou à des centaines de services. Il n'existe malheureusement pas encore de solution de débogage universelle.
  8. Connectivité : réfléchissez à la découverte des services, qu'elle soit centralisée ou intégrée.

Calculer les économies que vous pourriez réaliser grâce à la migration

Certaines infrastructures virtuelles limitent votre choix en matière de logiciel en vous liant de plus en plus à des contrats de licence d'entreprise. La migration vers la virtualisation Open Source pourrait vous ouvrir la voie vers les conteneurs.

Keep reading

ARTICLE

Les microservices comme technologie d'intégration dans le secteur de la santé

Les microservices permettent aux développeurs, notamment ceux du secteur de la santé, de créer des applications qui sont constituées de services faiblement couplés, ce qui facilite les étapes de développement, de test, de déploiement et de mise à niveau.

ARTICLE

Les microservices, qu'est-ce que c'est ?

Les microservices désignent une approche architecturale du développement d'applications selon laquelle les différentes parties d'une application fonctionnent en synergie tout en étant séparées.

ARTICLE

Un Service Mesh, qu'est-ce que c'est ?

Un Service Mesh est une couche d'infrastructure comprise dans une application qui permet de documenter les interactions entre les services, pour simplifier l'optimisation des communications et réduire les temps d'arrêt.

En savoir plus sur les microservices

Produits

Plateforme de conteneurs Kubernetes pour les entreprises qui automatise l'exploitation de toute la pile pour la gestion des déploiements multicloud, de clouds hybrides et d'edge computing.

Ressources

Livre numérique

La voie vers les applications natives pour le cloud

Livre numérique

Apprendre la danse à un éléphant : synthèse

Formations

Cours gratuit

Développement d'applications cloud-native avec des architectures de microservices

Illustration - mail

Ce type de contenu vous intéresse ?

Inscrivez-vous à notre newsletter Red Hat Shares.