Les microservices sont susceptibles d'être au moins autant plébiscités par les dirigeants d'entreprise et les chefs de projet que par les développeurs. Il s'agit de l'une des caractéristiques les plus inhabituelles des microservices, car l'enthousiasme pour l'architecture est généralement réservé aux équipes de développement de logiciels. La raison : les microservices reflètent mieux la manière dont de nombreux chefs d'entreprise souhaitent structurer et diriger leurs équipes et leurs processus de développement.

En d'autres termes, les microservices sont un modèle architectural qui facilite davantage un modèle opérationnel souhaité. Dans une enquête récente d'IBM auprès de plus de 1200 développeurs et cadres IT, 87 % des utilisateurs des microservices s'accordent à dire que l'adoption des microservices en vaut la peine, en termes d'investissement et d'efforts. Vous pouvez explorer d'autres perspectives sur les avantages et les défis des microservices en utilisant l'outil interactif.

Voici quelques-uns des avantages des microservices pour l'entreprise.

Déployables de manière indépendante

La caractéristique la plus importante des microservices est sans doute le fait que, les services étant plus petits et pouvant être déployés indépendamment, une prise de décision venue « d'en haut » n'est plus nécessaire pour modifier une ligne de code ou ajouter une nouvelle fonction dans une application.

Les microservices promettent aux organisations un antidote aux frustrations viscérales associées aux petits changements très chronophages. Il n'est pas nécessaire d'avoir un doctorat en informatique pour voir ou comprendre la valeur d'une approche qui facilite la rapidité et l'agilité.

Mais la rapidité n'est pas le seul avantage de cette méthode de conception des services. Un modèle organisationnel émergent courant consiste à rassembler des équipes interfonctionnelles autour d'une problématique métier, d'un service ou d'un produit. Le modèle des microservices s'inscrit parfaitement dans cette tendance, car il permet à une organisation de créer de petites équipes interfonctionnelles autour d'un service ou d'un ensemble de services et de les faire fonctionner de manière agile.

Le faible couplage des microservices permet également d'isoler les défauts et d'améliorer la résilience des applications. De plus, la petite taille des services, associée à leurs limites et à leurs modèles de communication clairs, permet aux nouveaux membres de l'équipe de comprendre plus facilement le codebase et d'y contribuer rapidement, un avantage évident en termes de rapidité et de moral pour les employés.

L'outil adapté au travail

Dans les modèles d'architecture multi-niveaux traditionnels, une application partage généralement une pile commune et une grande base de données relationnelle prenant en charge l'ensemble de l'application. Cette approche présente plusieurs inconvénients évidents, dont le plus important est que chaque composant d'une application doit avoir en commun une pile, un modèle de données et une base de données, même s'il existe un outil clairement plus efficace pour la tâche pour certains éléments. Cela donne une mauvaise architecture, et c'est frustrant pour les développeurs qui savent qu'il existe une meilleure façon, plus efficace, de créer ces composants.

En revanche, dans un modèle de microservices, les composants sont déployés de manière indépendante et communiquent par une combinaison de REST, de diffusion en flux d'événements et de courtiers de messages, de sorte que la pile de chaque service peut être optimisée pour le service. La technologie évolue en permanence, et une application composée de plusieurs petits services est beaucoup plus facile et moins coûteuse à faire évoluer vers une technologie plus souhaitable dès qu'elle est disponible.

Une mise à l'échelle précise

Avec les microservices, les services peuvent être déployés individuellement, mais également mis à l'échelle individuellement. Correctement mis en œuvre, les microservices nécessitent moins d'infrastructure que les applications monolithiques, car ils permettent une mise à l'échelle précise des seuls composants qui le nécessitent, au lieu de l'application entière dans le cas des applications monolithiques.

Il existe aussi des défis

Les avantages considérables des microservices s'accompagnent de défis importants. Passer d'une approche monolithique aux microservices implique une complexité de gestion accrue, beaucoup plus de services créés par un bien plus grand nombre d'équipes, déployés dans beaucoup plus d'emplacements. Des problèmes dans un service peuvent causer, ou être causés par, des problèmes dans d'autres services. Les données de consignation (utilisées pour la surveillance et la résolution des problèmes) sont plus volumineuses et peuvent être incohérentes entre les services. Les nouvelles versions peuvent causer des problèmes de rétrocompatibilité. Les applications impliquent davantage de connexions réseau, ce qui peut entraîner un plus grand de problèmes de latence et de connectivité. Une approche DevOps (comme nous le verrons ci-après) peut résoudre bon nombre de ces problèmes, mais l'adoption de DevOps comporte ses propres défis.

Néanmoins, ces défis n'empêchent pas de nouvelles adoptions des microservices ni un engagement accru de ceux qui les ont déjà adoptés. Les données d'une nouvelle enquête d'IBM révèlent que 56 % des non-utilisateurs actuels sont susceptibles ou très susceptibles d'adopter les microservices dans les deux prochaines années, et que 78 % des utilisateurs actuels des microservices augmenteront probablement le temps, les investissements et les efforts dévolus aux microservices.

L'architecture de microservices est souvent décrite comme optimisée pour DevOps et l'intégration continue/la distribution continue (CI/CD), et dans le contexte de petits services pouvant être déployés fréquemment, il est facile de comprendre pourquoi. 

Mais il existe une autre façon d'envisager la relation entre les microservices et DevOps : les architectures de microservices requièrent le DevOps pour être efficaces. Si les applications monolithiques présentent toute une série d'inconvénients qui ont été évoqués plus haut dans cet article, elles ont l'avantage de ne pas être un système réparti complexe comportant de multiples pièces mobiles et des piles technologiques indépendantes. En revanche, compte tenu de l'augmentation massive de la complexité, des pièces mobiles et des dépendances qui accompagnent les microservices, il serait imprudent d'aborder les microservices sans investir massivement dans le déploiement, le contrôle et l'automatisation du cycle de vie.

Dans la vidéo suivante, Andrea Crawford propose de s'immerger d'avantage dans le DevOps :

Les microservices ne sont pas forcément exclusivement pertinents pour le cloud computing, mais il existe plusieurs raisons importantes pour lesquelles ils vont si souvent de pair, des raisons qui vont au-delà du fait que les microservices sont un style architectural courant pour les nouvelles applications et que le cloud est une destination d'hébergement largement utilisée pour les nouvelles applications.

Les avantages en termes d'utilisation et de coûts associés au déploiement et à la mise à l'échelle de composants individuels font partie des avantages de l'architecture de microservices. Bien que ces avantages existent toujours, dans une certaine mesure, avec une infrastructure sur site, la combinaison de petits composants évolutifs de manière indépendante et d'une infrastructure à la demande et facturée à l'utilisation permet réellement d'optimiser les coûts.

Ensuite, et c'est peut-être plus important, un autre avantage majeur des microservices est que chaque composant individuel peut adopter la pile la mieux adaptée à sa tâche spécifique. La prolifération de piles peut entraîner une complexité et une surcharge importantes si vous la gérez vous-même, mais la consommation de la pile sous-jacente sous forme de services cloud peut réduire considérablement les problèmes de gestion. En d'autres termes, même s'il n'est pas impossible de déployer votre propre infrastructure de microservices, ce n'est pas conseillé, surtout au début.

Dans les architectures de microservices, il existe de nombreux modèles communs de conception, de communication et d'intégration qui sont utiles et permettent de répondre à certains des défis et opportunités les plus courants, notamment :

• Le modèle BFF (Backend-for-frontend) : Ce modèle insère une couche entre l'expérience utilisateur et les ressources auxquelles cette expérience fait appel. Par exemple, une application utilisée sur un ordinateur de bureau aura des limites de taille d'écran, d'affichage et de performance différentes de celles d'un appareil mobile. Le modèle BFF permet aux développeurs de créer et de prendre en charge un type de backend par interface utilisateur en utilisant les meilleures options pour cette interface, plutôt que d'essayer de prendre en charge un backend générique qui fonctionne avec n'importe quelle interface mais peut avoir un impact négatif sur les performances du frontend.
• Modèles d'entité et d'agrégat :  Une entité est un objet distingué par son identité. Par exemple, sur un site de commerce électronique, un objet Produit peut se distinguer par son nom, son type et son prix. Un agrégat est une collection d'entités associées qui doivent être traitées comme une seule unité. Ainsi, pour le site de commerce électronique, une commande est une collection (agrégat) de produits (entités) commandés par un acheteur. Ces modèles sont utilisés pour classer les données de manière significative.
• Modèles de détection de service :  Ils permettent aux applications et aux services de se trouver. Dans une architecture de microservices, les instances de service changent dynamiquement en raison de la mise à l'échelle, des mises à niveau, des défaillances de service, et même de l'arrêt du service. Ces modèles fournissent des mécanismes de reconnaissance pour faire face à cette situation transitoire. L'équilibrage de la charge peut utiliser des modèles de reconnaissance de service en se servant des contrôles d'état et des défaillances de service comme de déclencheurs pour rééquilibrer le trafic.
• Modèles de microservices d'adaptateur :  les modèles d'adaptateur doivent être considérés comme des adaptateurs de prise que vous utilisez lorsque vous allez dans un autre pays. La fonction des modèles d'adaptateur est de traduire les relations entre des classes ou des objets qui sont incompatibles. Une application qui repose sur des API tierces peut nécessiter un modèle d'adaptateur pour garantir la communication entre l'application et les API.
• Modèle d'application Strangler :  Ces modèles permettent de gérer la restructuration d'une application monolithique en applications de microservices. Le nom pittoresque (étrangleur) fait référence à la façon dont, au fil du temps, une plante grimpante (microservices) envahit lentement un arbre (une application monolithique) et l'étrangle.

Vous pouvez en savoir plus à propos de ces modèles dans "Comment utiliser des modèles de développement avec des microservices (partie 4)." IBM Developer fournit également beaucoup d'informations si vous souhaitez en savoir plus sur les autres modèles de code de microservices .

S'il existe de nombreux modèles qui permettent de gérer efficacement les microservices, il en existe tout autant qui peuvent rapidement mettre en difficulté une équipe de développement. Voici une liste de choses à ne pas faire en matière de microservices :

• La première règle des microservices est de ne pas créer de microservices :plus précisément,ne démarrez pas avec des microservices . Les microservices constituent un moyen de gérer la complexité lorsque les applications sont devenues trop volumineuses et trop lourdes pour être mises à jour et gérées facilement. Ce n'est que lorsque vous commencez à vous rendre compte des difficultés et de la complexité de l'application monolithique qu'il peut s'avérer utile de réfléchir à la manière dont vous pourriez restructurer cette application en services plus petits. Tant que vous ne ressentez pas cette difficulté, il n'est pas vraiment nécessaire de la restructurer.
• Ne créez pas de microservices sans DevOps ni services cloud : Créer des microservices signifie créer des systèmes distribués, or ces derniers sont complexes (ils le sont d'autant plus si vous faites des choix qui les complexifient encore davantage). Tenter de créer des microservices sans a) une automatisation adéquate du déploiement et de la surveillance ou b) des services cloud gérés pour prendre en charge votre infrastructure hétérogène et tentaculaire, c'est s'exposer à de nombreux problèmes inutiles. Épargnez-vous ces problèmes pour vous consacrer à l'état de l'infrastructure. 
• Ne créez pas trop de microservices de trop petite taille : Si vous allez trop loin dans l'aspect "micro" au niveau des microservices, vous pourriez facilement générer des frais et une complexité qui vont l'emporter sur les gains globaux d'une architecture de microservices. Il est préférable d'opter pour des services de plus grande taille et de ne séparer ceux-ci que lorsqu'ils commencent à développer des caractéristiques auxquelles les microservices répondent, à savoir qu'il devient difficile et lent de déployer des changements, qu'un modèle de données commun devient trop complexe ou que différentes parties du service ont des exigences différentes en termes de charge et d'échelle.
• Ne transformez pas les microservices en SOA : Les microservices et l'architecture orientée services (SOA) sont souvent confondus dans la mesure où, à leur niveau le plus élémentaire, ils s'intéressent tous deux à la construction de composants individuels réutilisables qui peuvent être consommés par d'autres applications. La différence entre microservices et SOA réside dans le fait que les projets de microservices consistent généralement à restructurer une application pour en faciliter la gestion, tandis que l'architecture SOA vise à modifier le fonctionnement des services IT à l'échelle de l'entreprise. Un projet de microservices qui se transforme en projet SOA risque de céder sous son propre poids.
• Ne tentez pas d'être Netflix :Netflix a été l'un des premiers pionniers de l'architecture de microservices en créant et gérant une application qui représentait un tiers de l'ensemble du trafic Internet, une sorte de grande tempête qui a nécessité la création d'une importante quantité de code et de nombreux services personnalisés inutiles pour une application moyenne. Il est préférable de commencer à un rythme que vous pouvez gérer, d'éviter la complexité et d'utiliser autant d'outils prêts à l'emploi que possible.

Si vous voulez en savoir plus sur l'utilisation des microservices, ou si vous devez renforcer vos compétences dans ce domaine, essayez l'un de ces tutoriels :

• Présentation des microservices
• Exercice rapide : Créer des microservices d'application Web hautement évolutifs avec Node.js
• Initiation aux microservices Java à l'aide de Spring Boot et Cloudant
• Créer, exécuter et déployer des microservices Spring en cinq minutes
• Microservices, architecture orientée services et API : amis ou ennemis ?

Les microservices permettent un développement innovant au rythme de l'entreprise moderne. Apprenez à tirer parti de l'évolutivité et de la flexibilité du cloud en déployant des microservices indépendants dans des environnements cloud. Découvrez les bénéfices de la modernisation de vos applications avec l'aide d'IBM.

Pour aller plus loin :

• Libérez vos équipes de développement en vous appuyant sur l'itération automatisée via des outils de développement cloud natifs IBM.
• Apprenez-en plus sur Kubernetes géré en démarrant avec Red Hat OpenShift sur IBM Cloud ou le service IBM Cloud Kubernetes . Consultez aussi IBM Cloud Code Engine pour en savoir plus sur l'informatique sans serveur.
• Les microservices concernent tout autant le processus et l'organisation de l'équipe que la technologie. Planifiez stratégiquement votre approche DevOps avec IBM DevOps.

Commencez dès aujourd'hui avec un  compte IBM Cloud.