Que sont les microservices ?

La plupart des systèmes logiciels ont traditionnellement été construits comme une seule application monolithique. Les composants et les fonctionnalités y sont étroitement couplés, par opposition aux liens plus lâches qui unissent les éléments dans les architectures en microservices ou orientées services. Cette approche classique a plusieurs inconvénients :

• la difficulté à apporter des améliorations et des modifications à une base de code en constante augmentation, la refactorisation de la base de code est délicate car chaque modification peut avoir un impact sur l’ensemble de l’application ;
• la complexité accrue du test et du déploiement des modifications, car toute l’application monolithique est affectée ;
• l’augmentation du risque : la défaillance d’un composant entraîne l’interruption de toute l’application.

Les microservices offrent davantage de flexibilité qu’un système monolithique traditionnel. Il n’existe pas de chemin unique pour développer des microservices, mais il existe des directives générales pour bien gérer les données au sein des architectures de microservices. La complexité de la gestion des données, qui incite souvent une équipe de développement à envisager les microservices, peut avoir diverses causes :

• le travail avec de grandes équipes ;
• la prise en charge de nombreux modèles d’interaction utilisateur ;
• la possibilité pour les différentes fonctions de l’entreprise d’évoluer indépendamment ;
• la possibilité d’offrir de nombreux services web différents.

Mais la plus grande différence est la taille : les équipes sont souvent confrontées à une application monolithique trop volumineuse pour être modifiée, déployée et redimensionnée.

La SOA convient mieux aux environnements d’applications d’entreprise vastes et complexes qui nécessitent une intégration avec de nombreuses applications hétérogènes. Les microservices, en revanche, sont plus adaptés aux systèmes web plus petits et bien partitionnés, offrant un contrôle beaucoup plus important aux développeurs. Diviser les applications en portions plus petites n’est pas une idée nouvelle : l’architecture orientée services (SOA) a précédé les microservices.

Selon le manifeste de la SOA :

• la valeur commerciale prime sur la stratégie technique ;
• les objectifs stratégiques sont plus importants que les avantages propres au projet ;
• l’interopérabilité intrinsèque est plus importante que l’intégration personnalisée ;
• les services partagés sont plus importantes que les implémentations spécifiques ;
• la flexibilité prime sur l’optimisation ;
• l’amélioration progressive est à privilégier par rapport à la poursuite de la perfection initiale.

Les microservices s’inscrivent dans une transition plus large des services informatiques vers la culture DevOps, dans laquelle les équipes de développement et des opérations travaillent en étroite collaboration pour prendre en charge une application tout au long de son cycle de vie. Une entreprise doit envisager de mettre en œuvre des microservices si elle possède déjà une culture SOA.

Pour résumer, une architecture orientée services est un ensemble de services qui communiquent entre eux. La communication peut impliquer un simple transfert de données, ou la coordination d’une activité par deux services ou plus.

L’architecture orientée services représente une stratégie efficace pour des cycles de développement agiles et rapides. L’un des principaux avantages des microservices est qu’ils permettent aux développeurs de déployer un cycle de livraison continu. Avant d’adopter des microservices, une entreprise doit d’abord évaluer la technologie en place. La question n’est pas de savoir quelle architecture est la plus performante. Il est surtout essentiel d’évaluer l’objectif de l’application que vous créez.

Un conteneur est une méthode d’empaquetage, de déploiement et d’exécution d’un programme ou d’un processus Linux. On peut tout à fait créer une application monolithique géante en tant que conteneur, ou une application construite avec des microservices qui n’utilise aucun conteneur.

En tant qu’allocation de ressources utile, le conteneur est un sujet qui passionne les professionnels du DevOps. En tant que modèle de conception de logiciel, les microservices passionnent les développeurs. Les conteneurs et les microservices sont tous deux utiles mais ils ne sont pas nécessairement associés.

Les deux principaux défis d’une approche de microservices résident dans les styles de travail des différentes équipes et le sentiment de n’avoir jamais « terminé ». Au sujet du premier, si les microservices permettent une amélioration de la productivité et élargissent le choix d’outils, il arrive souvent que chaque équipe préfère utiliser ses propres langages, frameworks et bibliothèques. L’indépendance propre aux microservices peut freiner les équipes qui n’y sont pas préparées.

Deuxièmement, les architectures monolithiques ont quelque chose de très séduisant : les changements prennent la forme d’un grand projet dont les points de départ et d’arrivée sont clairs. Avec les microservices, le changement est toujours en cours. Le changement constant n’est pas un « bug » mais une fonctionnalité d’un système viable et évolutif, et les équipes peu familiarisées avec ce type de flux devront peut-être faire un effort pour s’adapter.

Citons enfin un troisième défi, la complexité des microservices, qui nécessite une approche stratégique de la supervision.

L’une des principales raisons qui motive l’adoption des microservices est qu’ils permettent de se consacrer aux priorités de l’entreprise en accélérant l’innovation. L’avènement du DevOps, lui aussi axé sur la rapidité et les résultats, a également stimulé l’intérêt pour les microservices.

De nombreuses entreprises sont passées d’une architecture monolithique à une structure de microservices, notamment Amazon, Spotify, Uber, Groupon et Karma. Grâce aux microservices, les développeurs de Netflix déploient chaque jour des milliers de sections de code pour prendre en charge plus de 139 millions d’abonnés et 10 milliards d’heures de films et de séries télé. 

Les microservices ont notamment l’avantage d’accélérer le développement et le déploiement de logiciels, ce qui permet d’économiser de l’argent et peut donner à l’organisation un avantage compétitif. L’architecture de microservices est un choix idéal pour les développeurs qui ne peuvent pas prédire les types d’appareils sur lesquels l’application va s’exécuter. Les développeurs peuvent proposer des mises à niveau rapides et contrôlées sans ralentir ni arrêter l’application. Mais les avantages ne s’arrêtent pas là :

• la stabilité. La décomposition fonctionnelle permet d’augmenter ou de réduire chaque composant de l’application indépendamment des autres. On peut ainsi isoler les défaillances, et une interruption touchant un seul composant n’arrêtera pas en principe l’ensemble de l’application ;
• pas de dépendance vis-à-vis d’un fournisseur ou d’une technologie spécifique. Vous avez la possibilité de choisir une pile technologique différente pour différents microservices ;
• la simplicité d’élaboration et de maintenance. En raison de leur conception à usage unique, les composants peuvent être construits et maintenus par des équipes plus petites. Chaque équipe peut être interfonctionnelle. Chaque microservice peut être déployé indépendamment ;
• un code de meilleure qualité. La modularisation d’une solution globale en composants discrets permet aux équipes de développement d’applications de se concentrer sur des sections plus petites. Cela simplifie le processus global de code et de test ;
• une coordination plus facile entre les équipes. Contrairement aux architectures orientées services (SOA) traditionnelles, qui impliquent généralement de lourds protocoles de communication inter-processus, les microservices utilisent des technologies de diffusion d’événements qui facilitent l’intégration ;
• le traitement en temps réel. Au cœur d’une architecture de microservices se trouve un framework de publication-abonnement qui permet de traiter les données en temps réel pour offrir des résultats et des informations sans délai ;
• le développement rapide des projets. Les microservices fonctionnent de manière indépendante: vous n’avez donc pas besoin de changer la base de code pour modifier les fonctionnalités. Vous pouvez modifier un composant, le tester, puis le déployer individuellement. Vous réduisez ainsi les délais de livraison de l’application ;
• ils permettent une évolution dynamique. L’évolutivité ne concerne pas seulement la possibilité d’augmenter les capacités. Il faut également tenir compte des efforts impliqués. Les microservices permettent d’identifier plus facilement les goulots d’étranglement de l’évolutivité et de les résoudre au niveau de chaque microservice.

La supervision est un élément essentiel des architectures de microservices. Si la fragmentation des applications en microservices de composants offre de nombreux avantages, elle crée également de la complexité. Les microservices doivent communiquer entre eux et chaque composant créé et mis à jour individuellement doit fonctionner avec d’autres composants, avec un minimum de latence. Ainsi, lorsque vous gérez une application composée de microservices, vous gérez un réseau de composants interconnectés. Une gestion efficace de ce réseau est essentielle à la fiabilité globale.

La supervision et l’observabilité sont plus faciles pour les développeurs qui ont déjà adopté les pratiques DevOps/Agile. Conformément à ces approches, les microservices s’appuient sur l’automatisation et la collaboration dans tous les aspects du cycle de vie du développement logiciel (SDLC). La gestion des configurations, les serveurs CI/CD, l’APM, la supervision du réseau, les tableaux de bord, l’automatisation des alertes et la gestion des incidents sont des fondamentaux pour les équipes exécutant des microservices.

La supervision des microservices englobe deux volets essentiels : la supervision de base et le déploiement rapide des applications.

• Supervision de base : il est essentiel de pouvoir détecter rapidement les problèmes qui ne l’ont pas été lors de la phase de test. On parle naturellement de détecter les problèmes techniques (erreurs de comptage, disponibilité du service, etc.) mais il est également avantageux de superviser les problèmes commerciaux (une baisse des commandes, par exemple). Si un problème apparaît soudainement, vous pouvez rapidement rétrograder les services et les systèmes d’exploitation suspects de façon indépendante.
• Déploiement rapide des applications : face à une telle quantité de services à gérer, les administrateurs doivent pouvoir les déployer rapidement, dans des environnements de test comme en production, généralement en quelques heures seulement. Si l’intervention manuelle est acceptable au début, vous chercherez bientôt à l’automatiser complètement.

Ces capacités impliquent un changement organisationnel important : une collaboration étroite entre les développeurs et les opérations, qui caractérise la culture DevOps. Cette collaboration est nécessaire pour garantir un provisionnement et un déploiement rapides. Vous devez également être en mesure de réagir rapidement lorsque votre supervision signale un problème.

Avec les systèmes distribués, les différentes équipes peuvent contribuer à une culture d’observabilité, notamment en améliorant l’orchestration, l’équilibrage de charge et l’isolement des interruptions de service.

Bien entendu, la supervision n’est que la réponse de première ligne dans la maintenance d’une architecture de microservices. Lorsqu’une anomalie est détectée, il faut également réagir. Il est important d’avoir un processus d’alerte et un plan de réponse aux incidents pour répondre rapidement et efficacement.

L’architecture de microservices est encore relativement jeune, mais elle ne fera que gagner en popularité avec le temps. L’utilisation des microservices permet aux équipes de se développer de manière indépendante en faisant évoluer leurs produits et leurs applications. Quelle que soit la manière dont vous implémentez les microservices, l’un des principaux objectifs doit être d’accélérer la mise sur le marché. Ce puissant argument suffit à de nombreuses équipes.