Pourquoi l’article?
Eh bien parce que c’est à la mode. Microservice, ça commence à faire un moment que les gens en parlent et que le sujet est en vogue. En revanche, quand on creuse, le principe d’une architecture microservice est souvent mal compris.
Microservice, c’est passionnant mais c’est aussi beaucoup de complexité souvent sous-évaluée. On va commencer avec une petite citation :
« If you can’t build a monolith, what makes you think microservices are the answer? »
source : http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
Et, je vais résister à la tentation de lister les avantages et inconvénients d’une architecture microservice, le risque de faire une « distributed big ball of mud », les avertissements sur « n’est pas netflix qui veut », la qualité des membres de votre équipe et la passion des développeurs…
Non!
Aujourd’hui on se concentre sur ce qu’est un microservice dans une architecture microservice ?
**Note : ** Il est très probable que cet article (si lu) provoque des réactions, je n’apporte qu’une clé de lecture et non une vérité absolue.
C’est quoi une architecture microservice ?
D’après https://microservices.io/: une architecture microservice est la structure d’une application comme une collection de services :
- Hautement maintenables et testables
- Découplés (ou faiblement couplés)
- Déployables unitairement
- Orientés autour d’une partie du domaine (Organized around business capabilities)
- Sous la responsabilité d’une petite équipe
Dans cet article, je vous propose de regarder ces 5 points pour essayer de décrire ce qu’est une architecture microservice ? et peut-être, ce qui n’en n’est pas une ?
Hautement maintenables et testables
Comme tout projet de développement ! … mais là c’est pire mieux.
Maintenables
La maintenance d’un applicatif ou bout d’applicatif ou produit va bien plus loin que juste la vision du code.
La maintenance d’une application peut prendre plusieurs aspects :
- le déploiement ou le redéploiement
- la reprise en cas d’interruption
- le monitoring et l’alerting
- la capacité à réaliser des tâches de maintenances
Mais aussi, combien de temps faut-il pour :
- ajouter une fonctionnalité
- corriger un bug
Testables
Ah ! en fait c’est lié à la maintenance.Si on veut pouvoir déployer, redéployer et développer rapidement, il faut pouvoir vérifier que l’application fonctionne et que les évolutions n’apportent pas de régressions.
Ça veut dire : tester unitairement le fonctionnement de l’application mais également les APIs synchrones et asynchrones que le (micro)service expose.
Avec la pyramide des tests:Image not found
Mais aussi pour ceux qui veulent aller plus loin avec « agile testing »:
Hautement
Vu que dans une architecture microservice il y a beaucoup de services… et chaque service se doit d’être maintenable, et testable.
Exemple sur les APIs exposées :
Dans une application web en SPA classique, nous avons un frontend qui communique avec un backend via une REST API. Le client est connu, le fournisseur aussi. Quand on met à jour le fournisseur, c’est plus facile de mettre à jour le client.
ALORS QUE, dans un contexte microservice c’est plus compliqué car on se retrouve avec une quantité plus grande de clients potentiels pouvant communiquer de manière synchrone ou asynchrone.
DONC, les tests d’intégration et end-to-end sont plus difficiles à mettre en place.
Note: outils intéressant pour valider la cohérence des APIs : https://pact.io/
Et la cohérence entre l’API exposée et l’API attendu par le client est beaucoup plus difficile à garantir, l’application doit être hautement testable.
En cas de pépin il faut que l’application soit hautement maintenable pour corriger au plus vite.
Découplés
« Découplés » ou « faiblement couplés » signifie que le service nécessite le moins de dépendances possible pour fonctionner.
Dans l’idéal, aucune dépendance.
Prenons l’exemple d’une application permettant de faire de la location de voiture.
Imaginons que le découpage en service s’accorde autour :
- d’un service « CustomerRelationship » responsable des informations de communication avec le client : (email, numéro de téléphone, adresse postale, numéro d’urgence, etc.)
- d’un service « CarAvailability » permettant de gérer la disponibilité des voitures (réservation, disponibilité, etc.)
- d’un service « CarPark » permettant de gérer le parc automobile (modèle, options, année de construction, immatriculation, …)
Chacun de ces services sont dits « statefull » car ils conservent un état, de la donnée.
Avoir des services découplés signifie que les fonctionnalités de chacun des services sont accessibles quel que soit l’état des deux autres :
Il est possible de faire la réservation d’une voiture pour un client via « CarAvailability » sans que « CustomerRelationship » ni « CarPark » ne soient disponibles.
Mais ce découplage soulève plein de questions !
- Comment garantir que mon client existe lors de la réservation d’une voiture ?
- Comment être certain que, si la voiture est envoyée à la casse, toutes les réservations soient annulées ? et les clients notifiés ?
Bien qu’il n’y ait pas de réponse universelle à cette question quelques éléments sont communément présentés :
- Avoir de la communication asynchrone via un broker de message
- Embrasser l' »eventual consistency »
- Mettre en place des SAGAs par orchestration ou par chorégraphie
- note personnelle : même si plus simple à mettre en place, l’orchestration force un point de couplage.
- Ajouter des services fonctionnels par interface frontend (Backend For Frontend)
Également quelques fausses bonnes idées sont à éviter:
- Laisser les services communiquer entre eux directement par des appels synchrones
- Utiliser une base de données commune (Shared Database)
Déployable unitairement
Avoir des services découplés permet de déployer de manière indépendante chacun des services.
Il est possible de réutiliser le service « CustomerRelationship » dans beaucoup d’autres contextes que la réservation de voiture : pour vendre des produits sur internet.
Qu’est-ce que ça veut dire : l’application est l’agrégat de tous les services qui la compose.
Et donc l’ajout, la mise à jour ou la suppression d’un service doit être réalisable unitairement.
- Chaque service peut ou non être modifié entre deux itérations de développement.
- Le développement d’un service peut être réalisé par une autre équipe puis intégré au reste de la solution.
- L’évolution des numéros de version de chacun des composants va donc évoluer indépendamment.
- Le déploiement de l’application dans son ensemble se fait par composition et configuration des services pour une version donnée.
- l’usage d’outils GitOps (buzzword) type ArgoCD permet de gérer cette composition.
Une solution de simplicité consiste à packager tous les services en même temps avec le même numéro de version. Mais cette technique n’est qu’un workaround et les versions de certains logiciels vont être incrémentées sans qu’il n’ait reçu d’évolution.
Orienté autour d’une partie du domaine (Organized around business capabilities)
Cette partie n’est pas que technique.
Les points précédents ne parlent que d’architecture logicielle et de bonnes pratiques et sont implémentables quelques soit le découpage des services.
Pour ce point on se pose la question : « comment réaliser le découpage de l’application en service indépendant ? »
Et Conway nous aide :
« les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation.»
- M. Conway
Sur cette question, pas de réponse universelle non plus.
Ce qui est sûr : l’analyse fonctionnelle du métier de l’application apporte des réponses.
Dans DDD (Domain Driven Design) le métier auquel répond l’application est décrit dans une context map via des bounded context, un shared kernel, des agrégats, etc.
Une approche naïve mais potentiellement efficace est de découper les services autour des bounded context ou des agrégats racines.
Pour DDD
Sous la responsabilité d’une petite équipe
Finalement on parle aussi d’agilité.
Hein, mais ça n’a rien à voir !
Regardons la définition d’une équipe Agile:
In SAFe, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box.
https://www.scaledagileframework.com/agile-teams/
An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product.
https://www.leadingagile.com/2015/02/what-is-an-agile-team-and-how-do-you-form-them/
An Agile team is a group of employees, contractors, or freelancers responsible for executing an Agile project. Agile teams are typically co-located and often wholly dedicated to the project during its timeline, with no obligations to other projects.
https://www.wrike.com/project-management-guide/faq/what-is-an-agile-team/
Et donc vu que nos services sont indépendants et orientés business, chaque service constitue un produit. Et donc pour construire un produit, il faut une équipe, colocalisé, entre 5 et 11 personnes, …
Bref.
Une équipe agile !
Je vous laisse vérifier : https://www.google.com/search?q=agile+team
En conclusion
Je voulais vous laisser avec quelques questions (j’ai mes réponses mais ne vous les donnes pas) :
- Un découpage trop fin mènerait au FaaS, est-ce qu’une fonction peut être considérée comme un microservice ?
- Où se place le curseur entre SOA et microservice ?
- Plein de progiciels connectés par un ESB peuvent-ils être considérés comme une forme de SOA ? d’architecture microservice ?
- Finalement est-ce qu’un backend avec des workers asynchrones, autoscalables et déployés unitairement est une approche microservice ?
Et pour finir, un petit jeu : Faites-vous du microservice ?
- Hautement maintenables et testables
- Découplés (ou faiblement couplés)
- Déployable unitairement
- Orienté autour d’une partie du domaine (Organized around business capabilities)
- Sous la responsabilité d’une petite équipe
Une case non cochée implique que … peut-être pas à mes yeux.
Retour aux articles