Quelle architecture de projet choisir entre micro-services ou monolithe modulaire ?
Repoussée de 6 mois en raison de la pandémie liée au Covid-19, l’édition 2020 du Symfony Live s’est fait attendre.
Mais quel plaisir de se poser 2 jours (en physique !) à la cité universitaire pour faire des rencontres autour de l’écosystème Symfony et PHP.
Cette édition semblait avoir comme fil rouge l’architecture de projet. Différentes réflexions et des outils variés nous ont en effet été présentés, autour de l’architecture micro-services et de l’approche monolithique.
Il s’agit d’un sujet assez commun sans cesse remis en question. Et il est toujours très intéressant d’écouter les critiques et les retours d’expérience selon les choix faits par d’autres entreprises. Cela dit, cela n’aide pas toujours à se décider pour ses propres projets !
Micro-services ou monolithe, l’éternel débat
Depuis plusieurs années maintenant, l’architecture de projet est au cœur de nombreuses discussions entre développeurs, architectes et managers. Et cela pour différentes raisons !
D’un point de vue de développeur, bien structurer son projet facilite la compréhension du besoin, mais aussi la prise en main par de nouveaux arrivants sur le projet. Si chacun écrit simplement du code comme bon lui semble, sans cadrage et sans concertation avec le reste de l’équipe, il y a un risque de duplication de code, et à la longue cela engendre de la dette technique.
Côté architecture ou infrastructure, l’organisation et le découpage qui sont choisis pour le ou les service(s), pourront donner lieu à une maintenance plus ou moins facile. Et de ce point de vue, les déploiements et annulations de mise en production sont plus aisés à gérer quand il y a peu de projets qui s’entremêlent.
Enfin, pour les managers, avoir une architecture complexe est souvent synonyme de coûts, qu’il faut être en mesure de justifier et de rentabiliser.
Pour chaque projet, il convient donc de trouver la solution d’architecture la plus adaptée, selon les problématiques de chaque partie.
L’architecture de projet en micro-services
Lors du Symfony Live Paris 2020, Alexandre Salomé nous a expliqué comment migrer vers une architecture micro-services.
Une architecture en micro-services consiste à concevoir un ensemble de services autonomes qui communiquent entre eux via une API. Cela permet de construire des services indépendants, cloisonnés par cercle de responsabilité.
Étonnamment, l’un des principaux conseils d’Alexandre est : ‘ne faites pas de micro-services’. Plutôt déroutant lorsqu’on s’attend à tout savoir sur la migration d’architecture en services finement découpés !
Il s’agissait surtout de souligner le fait qu’il conseille d’abord vivement d’essayer de réaliser son projet sans architecture en micro-services. Ce type d’architecture nécessite en effet une équipe étendue et répond principalement à des enjeux métier complexes. Il convient donc dans un premier temps de mieux connaître le domaine métier concerné et ses attentes avant de se tourner vers cette architecture de projet.
D’autant plus qu’une migration vers le micro-service, nécessite également une réorganisation des équipes au sein de l’entreprise. Chaque équipe doit se concentrer uniquement sur un sujet ou un ensemble de sujets précis (par exemple : le catalogue produit, le SAV, les stocks, …).
Si notre projet n’est pas assez complexe ou si les équipes ne sont pas suffisamment “scopées”, ce type d’infrastructure pourrait alors apporter plus de troubles qu’il n’en résoudrait.
Côté technique, cette architecture peut également entraîner des soucis de performance puisque chaque service peut faire appel à X services et ainsi de suite. Or le temps de réponse, et donc la latence de réponse, est accru à chaque dépendance supplémentaire entre services.
Si après avoir pris connaissance des prérequis et des risques, vous pensez que l’architecture en micro-services est toujours adaptée à votre besoin, Alexandre Salomé vous donne quelques conseils et points de contrôle pour migrer vers cette architecture :
- La préparation et la réflexion sur la découpe des services par univers métier sont primordiales pour répondre au besoin de structuration métier. Et elle doit être le fruit d’un travail d’étude fonctionnelle approfondi, avant de développer l’architecture technique.
Il est également important que la migration soit comprise et acceptée par tous en amont du projet.
- La documentation et la cartographie des services et des échanges (données, modèles, APIs, événements) est capitale pour partager l’organisation des services. De plus avoir établi un format d’échange entre les services permettra certainement d’abstraire certaines couches dans un modèle commun et d’aboutir à des échanges le plus simple possible.
- Veiller à la mise à disposition des packages contenant les modèles utiles à plusieurs API/services (modèle de données, réponses, clients, …). L’utilisation du semantic versioning peut d’ailleurs aider à gérer les différences de version sur ses packages.
- L’utilisation d’ID de corrélation permet de retracer le chemin effectué par une requête. En partant d’un point A, comment sommes-nous arrivés au point F ? Cela permet d’observer et d’analyser les échanges synchrones et asynchrones malgré la hausse des services exploités, et de maîtriser sa chaîne de production.
- Enfin, ne pas hésiter à nommer ses services en rapport avec ce qu’ils font ! Quoi de plus gênant dans un développement que de devoir demander ou comprendre ce que fait le service Macumba ?
Pour conclure, il faut garder à l’esprit, que la mise en place d’une architecture nécessite de solides connaissances en architecture, systèmes et services. Mais nécessite aussi de l’organisation, des capacités de coordination et de l’agilité. Sa mise en place présente donc un coût et est associée à des risques, de performance notamment. Toutefois elle permet d’apporter de la flexibilité et de la simplicité sur des problématiques complexes.
L‘architecture de projet en monolithe modulaire
Un autre type d’organisation a été présenté au Symfony Live Paris 2020 par Timothée Barray : le monolithe modulaire.
Sur le principe, l’architecture en monolithe modulaire est une alternative à l’architecture en micro-services. Elle permet de limiter les coûts tout en ayant des découpages par équipe, organisés en dossiers/modules (mais pas de Bundle !).
Il peut être difficile de définir ce qu’est un module indépendant, il est donc plus intéressant de se baser sur une notion de frontière. Une frontière permet de séparer les limites entre chaque fonctionnalité du développement. De fait, une frontière est traversée quand un concept avec le même nom n’a plus la même utilité. Par exemple : une commande avant paiement opposée à une réservation déjà payée.
L’avantage de l’architecture modulaire est sa simplicité de mise en place avec une unique méthode de déploiement, une unique architecture et une unique technologie.
Cependant, le monolithe “pur” est à proscrire, car il créé une forte dépendance dans le code. Et cette dépendance peut à terme entraîner un coût important lorsqu’il s’agira de faire évoluer une fonctionnalité. On lui préféra donc le monolithe modulaire, avec la conception de modules autonomes.
Ce découpage va permettre la disparition de clés étrangères entre différents modules. À la place, la base de données contient un pointeur vers la donnée initiale. De manière pratique, on peut garder un champ “utilisateur_id” dans une table “réservation” mais sans la contrainte relationnelle.
Puis pour vérifier le découpage entre modules l’outil Deptrac peut être utilisé. Il empêche l’appel de classes dans d’autres modules (à ajouter dans la CI).
Il est également possible d’imaginer que chaque module ait une base de données différente, voire une technologie différente d’enregistrement (mysql d’un côté, PostGré de l’autre, Redis dans un autre module, etc.). La première étape vers une migration micro-services ?
Au fil de la conférence, Timothée a partagé quelques conseils pour mettre en pratique le monolithe modulaire :
- Comme pour l’architecture en micro-services, il est préférable de mettre en place une méthode de communication claire et explicite dès le démarrage du projet. La méthode conseillée consiste à mettre dans un répertoire “public” les entités partagées et les classes de communication.
- Le développeur doit tout d’abord commencer à comprendre les besoins métier et essayer de réduire les temps de feed-back des utilisateurs. Le MCD ne vient que plus tard dans l’élaboration.
- Il est possible de faire évoluer les frontières entre modules au cours du développement. Le but étant d’apporter à chaque mise en production de la valeur aux utilisateurs.
- Par ailleurs, en cas de legacy, la meilleure méthode consiste à recommencer dans une bulle à part, indépendante du code déjà existant, dans laquelle on rajoute le code au fil de l’eau. Pour cela, le nouveau code généré peut servir de proxy pour appeler les anciennes méthodes, en attendant qu’elles soient migrées dans la nouvelle architecture.
- Dernier conseil de Timothée :
“Laissez-vous du temps, vous n’aurez jamais raison du premier coup.”
Mais aussi…
Ces deux conférences sur l’architecture en monolithe modulaire et en micro-services — qui ne sont pas si différentes dans les faits — ont été complétées par d’autres conférences de qualité, sur des sujets tels que :
- l’event streaming pour faire communiquer des (micro) services et des modules ensembles, abordé par Samuel ROZE,
- Lock & Sémaphore pour protéger l’accès aux ressources, de Jérémy Derussé,
- la mise à plats des conceptions de l’API / Hypermédia en prenant en compte la sécurité et l’analyse de résultat par Kévin Dunglas
- l’utilisation de Vulcain et des protocoles HTTP 2 et HTTP3.
De manière plus générale, la conférence est également revenue sur les nouveautés de Symfony 5.2, les différents caches HTTP et Symfony, JIT 8, la cryptographie et Symfony (avec la nouvelle fonctionnalité de migration de méthodes de chiffrements) et les cas d’utilisation de Redis.
Nous attendons maintenant avec impatience le prochain rendez-vous de décembre : une conférence en ligne avec en ligne de mire PHP 8 et Symfony 6.
Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
Les auteurs
Développeur Back & Front
A plus de side projects que d’années d’expérience
Développeur Fullstasck / Expert en bugs débiles
Également co-auteur de l’article : ‘Impact carbone du numérique : mesure des émissions du Web’
