Architecture en microservices : comprendre un modèle aussi adulé que décrié !
Les microservices permettent de découper une application en plusieurs parties indépendantes, chacune avec sa propre fonction. Une flexibilité inédite pour évoluer rapidement... mais qui a ses défauts.
L’architecture en microservices est un peu la nouvelle trend chez les développeurs, mais qu’est-ce que c’est ? Et en quoi ça peut changer la façon de concevoir des applications ?
Commençons par expliquer le concept à ta grand-mère
Imagine que tu as une grande maison avec plusieurs pièces : une cuisine, un salon, une chambre, etc. Chaque pièce a une fonction différente et peut être utilisée indépendamment des autres. L'architecture microservices est comme cette maison : chaque "pièce" ou service effectue une tâche spécifique et fonctionne de manière autonome, mais toutes ces pièces se combinent pour créer une maison fonctionnelle.
Let’s dive in !
Quels sont les différents types d’infrastructures ?
Avant de rentrer en détail dans l’architecture en microservices, on va déjà regarder les différents types d’infrastructures qui sont utilisés :
Monolithique : On regroupe toutes les fonctionnalités d'une application dans un seul bloc de code, ce qui simplifie le développement initial mais peut devenir complexe à gérer et à mettre à jour à grande échelle.
Orientée services : On divise l'application en services distincts qui communiquent via des protocoles standardisés, offrant une meilleure modularité et réutilisabilité des composants.
Microservices : On pousse la modularité encore plus loin en divisant l'application en petits services indépendants, chacun ayant une responsabilité spécifique.
Qu'est-ce que l'Architecture Microservices ?
L'architecture microservices est une type d’architecture logicielle où une application est divisée en petits services autonomes qui communiquent entre eux via des API. Chaque microservice est responsable d'une fonction spécifique et peut être développé, déployé et mis à jour indépendamment des autres.
Cette architecture respecte les principes suivant :
Modularité Chaque microservice est conçu pour effectuer une tâche spécifique. Cela permet de découper l'application en unités plus petites et plus faciles à gérer. Exemple : Une application de commerce électronique peut avoir des microservices distincts pour la gestion des utilisateurs, des produits, des commandes et des paiements.
Indépendance Les microservices fonctionnent de manière autonome. Ils peuvent être développés, déployés et mis à jour sans affecter les autres services. Exemple : Si le microservice de gestion des commandes doit être mis à jour, cela peut être fait sans interrompre les services de paiement ou de gestion des produits.
Communication via API Les microservices communiquent entre eux via des API. Les API sont des points de contact qui permettent aux différents services d'échanger des informations. Exemple : Le microservice de gestion des produits peut envoyer des informations sur les produits au microservice de gestion des commandes via une API.
Scalabilité Chaque microservice peut être mis à l'échelle indépendamment en fonction de la charge. Cela permet une gestion plus fine des ressources et une meilleure réactivité aux besoins de l'application. Exemple : Si le microservice de gestion des paiements reçoit une charge plus élevée pendant les périodes de forte activité, il peut être mis à l'échelle indépendamment des autres services.
Résilience En cas de défaillance d'un microservice, les autres services continuent de fonctionner. Cela améliore la résilience de l'application dans son ensemble. Exemple : Si le microservice de gestion des promotions échoue, les services de commande et de paiement peuvent continuer à fonctionner normalement.
Pourquoi cela fait débat ?
Certains développeurs adorent l'architecture en microservices pour sa flexibilité, sa scalabilité et la possibilité de développer, déployer et mettre à jour des services indépendamment. Cette approche permet une gestion plus fine des ressources et favorise l'innovation en permettant l'utilisation de différentes technologies pour chaque service.
Cependant, d'autres développeurs détestent cette architecture en raison de sa complexité accrue, notamment en termes de gestion des dépendances, de communication entre services et de surveillance des performances. La fragmentation des services peut également rendre le débeug et la maintenance plus difficiles.
Et d’un point de vue Product ?
L’architecture en microservices va avoir un intérêt pour les Product Managers dans des contextes de très grosses organisations tech avec des produits complexes pour plusieurs raisons :
La scalabilité
L'architecture microservices permet de mettre à l'échelle uniquement les services qui en ont besoin, optimisant ainsi l'utilisation des ressources. Par exemple si on construit une suite de produit qui utilisent tous le même système de gestion de compte on peut augmenter les ressources sur cette partie uniquement.La maintenance
En divisant l'application en services indépendants, on va simplifier les mises à jour et ainsi réduire les risques de perturbations. Une squad qui travaille sur les paiements ne risque plus de casser la brique d’authentification par exemple.La flexibilité
Chaque microservice peut être développé en utilisant des technologies différentes, ce qui permet d’être beaucoup plus flexible côté devs. La core team a développé les principaux microservices en C# mais la nouvelle squad data est experte en Python ? Ce n’est plus un problème.
Merci de m’avoir lu jusque ici 🧡 Si tu as appris quelque chose n’hésite pas à liker cet article et à partager ma newsletter à tes collègues Product.