7 + 1 bonnes pratiques pour en tirer pleinement les bénéfices

Par Anis Bessa, Directeur Harington OS et Emmanuelle Parnois, CMO

Des monolithes à la modularité

Selon IDC, neuf nouvelles applications sur dix devaient reposer sur une architecture microservices à l’horizon 2022. L’estimation était sans doute optimiste, mais elle illustre bien une tendance de fond : la généralisation des architectures distribuées, découplées et scalables.

Née dans les entrailles de Netflix à une époque où le mot microservices n’existait pas encore (le terme a été popularisé en 2014), cette approche a depuis conquis les géants du numérique (Amazon, PayPal, eBay, Uber) avant d’envahir l’ensemble de l’écosystème IT.

Le principe est simple : contrairement à une architecture monolithique, les microservices reposent sur un ensemble de modules autonomes et faiblement couplés qui communiquent via des API standardisées, indépendantes du langage ou du framework utilisé. Chaque service est responsable d’un processus métier bien défini et peut évoluer sans impacter les autres.

En théorie, c’est l’architecture rêvée : souple, scalable, résiliente et alignée sur les besoins métier. En pratique ? Seulement si elle est pensée, gouvernée, bien déployée puis industrialisée

Voici donc 7 + 1 bonnes pratiques pour construire une architecture microservices robuste, performante et réellement évolutive. À lire en complément « Microservices vs. Serverless, quelle est la meilleure approche pour votre application ? » :

Quels sont les principaux avantages d’une architecture microservices ?

1. Plus de productivité. Les développements sont faits plus rapidement car ils sont concentrés sur la réalisation de petits modules qui peuvent être développés en parallèle.
2. Time-to-market avec mise sur le marché très rapide de nouveaux services. On peut rajouter, mettre à jour ou changer des services existants sans impacter l’ensemble du système. Les mises en production de chaque nouvelle fonctionnalité sont plus rapides et comportent moins de risques car on n’a pas besoin de mettre à l’arrêt le système, ni de redéployer l’ensemble de l’application.
3. Flexibilité technologique ! En fonction de vos ressources disponibles, de leurs compétences et des fonctionnalités attendues, ils peuvent développer leur nouveau microservice dans le langage qu’ils souhaitent, Java, Python, Javascript …
4. Plus de qualité. La logique de modules indépendant des uns des autres permet d’identifier, d’isoler et de résoudre des bugs ou des défaillances bien plus rapidement que dans un système monolithique. Et surtout, un problème ou une défaillance sur un module en particulier ne met pas en danger le fonctionnement du système tout entier !
5. Reusabilité. Certains modules qui supportent des processus récurrents peuvent être bien entendu réutilisables sur d’autres applications.

1. Le Domain-Driven Design : concevoir à partir du métier

Tout repose sur la capacité à diviser une application en petits modules autonomes pouvant être déployés de manière autonome et indépendante. Ne pas réussir à respecter ce principe de base revient à retomber dans les travers des systèmes monolithiques.

L’objectif : diviser votre application en domaines métier cohérents, puis en services indépendants capables de se déployer et d’évoluer de manière autonome.

Le piège classique ? Construire des microservices “techniques” plutôt que “fonctionnels” : Autrement dit, reproduire un monolithe… mais distribué !

Le Domain-Driven Design (DDD) permet d’éviter ce travers en replaçant le domaine métier au centre de la conception logicielle. L’architecture devient le reflet du modèle métier, et non l’inverse.

Autrement dit : avant de penser code, pensez business.
Comprenez les contextes, les sous-domaines, le langage partagé entre équipes, les context maps et les agrégats métier. Une fois ces frontières bien définies, il devient possible de découpler intelligemment vos microservices et de réduire la dette technique future.

Souvent, en tant que professionnels du développement, nous avons tendance à nous concentrer sur la technologie, le code… et souvent, on en oublie le fonctionnel ! Or, dans une logique de microservices, la conception doit rester centrée sur le domaine métier qu’elle sert, l’objectif business.

Anis Bessa

La compréhension du métier et la logique associée sont centrales dans le développement de tout microservice. Dans ce type d’architecture, la conception logicielle est pilotée par le domaine et son abstraction qui en devient le modèle. Ainsi, les métiers et les équipes (architectes et développeurs) doivent collaborer ensemble dès la conception stratégique pour délimiter précisément le contexte, le langage, les sous-domaines et les cartes de contextes (Context Maps). Puis, décomposer le domaine en entités plus fines qui représentent les objets du domaine (attributs, identité, persistance dans le temps, comportements, agrégats, objets de valeur, etc.) dans chaque contexte ainsi limité. Il « ne vous reste plus » qu’à coupler vos modules de microservices pour obtenir votre application !

Pour approfondir ce sujet, quelques pistes de lecture :

• Domain-Driven Design de Eric J. Evans
• Implementing Domain-Driven Design 1st Edition de Vaughn Verno

2. Les bases de données : un choix stratégique

Un autre challenge à relever, et non des moindres, repose sur le choix en termes de base de données. Faut-il partager la base de données entre les microservices ou non ? Faut-il partager une base entre plusieurs services ou isoler complètement la persistance de chacun ? Un choix cornélien sur lequel il convient de se pencher car les enjeux sont de taille. Effectivement, si le choix se porte sur le partage de la base de données entre les microservices, ceci mènera à l’instauration d’un fort couplage entre ces derniers … ce qui est en opposition avec le principe même de l’architecture microservices ! Les efforts de synchronisation et de communication resteraient conséquents, même pour une mise à jour ou une modification très minime dans la base de données.

À l’inverse, si chaque microservice dispose de sa propre base de données, les échanges de données entre microservices ouvrent la porte à d’autres problématiques. C’est pourtant en théorie un choix naturel pour les micro-services qui utilisent un modèle de données différent pour chaque service. Le bon sens technique voudrait que chaque microservice ait sa propre base de données, afin de préserver le découplage et la résilience du système. C’est le principe de la persistance polygotte : chaque service choisit le modèle de stockage adapté à sa fonction : relationnel, clé-valeur, document, colonne, graphe, etc. Un service peut s’appuyer sur une base de données relationnelle, une autre sur une base de données tabulaire (Cassandra par ex) puis un autre sur une base clé-valeur pour les valeurs de référence, un autre sur un entrepôt type Document, etc. On peut également se retrouver dans un cas de figure où un service repose sur plusieurs bases de données.

Mais dans la réalité, cette indépendance totale a un coût : complexité de synchronisation, multiplicité des technologies, maintenance accrue et coûts d’exploitation explosifs.

Une approche pragmatique consiste à adopter des bases multimodèles, capables de supporter plusieurs schémas de données dans une même plateforme. On conserve ainsi la souplesse du microservice tout en limitant le chaos technologique.

Dans les faits, même s’il est entendu que chaque microservice devrait se limiter à une base de données, on constate que les choix d’une base de données partagée entre microservices est plus raisonnable en termes de coûts, coûts qui deviennent vite exponentiels si on doit supporter plusieurs technologies de bases de données. C’est pourquoi, les fournisseurs de bases de données (DataStax, Couchbase notamment) commencent à créer des bases de données multimodèle qui représentent une alternative intéressante, véritables plateformes de traitement de données, elles supportent plusieurs modèles de bases (relationnels, document, hiérarchiques et orientés objets, colonnes, etc.). L’architecture microservices n’interdit pas la raison. Parfois, une base partagée bien conçue vaut mieux qu’un zoo de technologies mal gouverné.

L’architecture microservices n’interdit pas la raison. Parfois, une base partagée bien conçue vaut mieux qu’un zoo de technologies mal gouvernées.”

Anis Bessa

3. La livraison continue (CI/CD) : industrialiser le changement

L’une des caractéristiques clés de l’architecture microservices est l’indépendance de la déployabilité de chaque microservice. L’intérêt est que l’on peut modifier ou mettre à jour un microservice sans toucher aux autres. Un des principaux avantages des architectures microservices est l’accélération des cycles de mise en production. C’est ce qui garantit l’agilité, la rapidité et la résilience de votre système.

Mais imaginons que vous ayez des dizaines de microservices à déployer de manière indépendante ? Cela peut être tourner en un cauchemar. Ainsi, il est indispensable d’adopter une organisation adaptée et un processus efficace en intégration / livraison continue (DevOps, CI/CD) et d’automatiser un maximum de tâches avant de vous lancer dans ce type de projet.

Sans stratégie CI/CD (Continuous Integration / Continuous Deployment) solide, le rêve tourne vite au cauchemar.
Gérer des dizaines de pipelines, d’environnements et de dépendances manuelles devient ingérable sans automatisation complète.

Migrer vers les microservices implique donc :

• une culture DevOps partagée,
• des outils d’orchestration (GitLab CI, Jenkins, ArgoCD…),
• une intégration continue testée, surveillée, traçable,
• et des équipes pluridisciplinaires autonomes (développement, QA, déploiement).

L’organisation devient un écosystème vivant, où chaque cellule produit, teste et déploie ses propres services en continu.

4. La stack technologique : liberté contrôlée

L’un des avantages souvent mis en avant des microservices, c’est la liberté technologique.
Chaque équipe peut choisir le langage, le framework ou la base qui convient à son service.

Mais la liberté sans gouvernance, c’est le chaos.
Trop de langages, trop de frameworks, trop de versions — et vous vous retrouvez avec une spaghetti-architecture impossible à maintenir.

Ce principe d’architecture suppose en effet que vous devez choisir le langage de programmation et le framework le mieux adapté à chaque microservice. Mais ce percept n’est pas sans conséquences ni exceptions ! Parfois, un microservice peut avoir besoin d’une nouvelle stack technique et nécessiter un langage de programmation comme C++/Rust pour des missions lourdes ou des exigences fortes en terme de performance du CPU. Si un microservice s’appuie sur du Machine Learning, Python peut s’avérer être le meilleur choix.

Mais attention, multiplier les langages de programmation et frameworks sans réelle nécessité n’apporte aucun bénéfice au final, bien au contraire. Imaginons un environnement technique où un microservice est développé en utilisant Kotlin, Spring Boot, PostgreSQL, et un autre avec Scala, Play Framework, VueJS et Oracle et le suivant avec JakartaEE, JAVA, MySQL et Angular ? Il peut certes y avoir de nombreux avantages …. Mais imaginer les efforts et les ressources qu’il va falloir fournir pour maintenir à jour ces différents langages de programmation, framework et autres bases de données ?

Certes, Les équipes peuvent choisir la technologie qui convient le mieux à leur service à l’aide de diverses piles technologiques et l’approche décentralisée de création de microservices a de nombreux avantages … mais cela demande de mettre en place une gouvernance rigoureuse pour que vous ne vous retrouviez pas avec pléthores de langages et de frameworks impossibles à gérer dans la durée. Nous vous conseillons chez Harington de mettre en place des standards à l’échelle de votre projet.

Anis Bessa

Le secret ? Standardiser sans uniformiser. Définissez un cadre : un nombre limité de langages, un socle technique commun (par ex. Spring Boot, Node.js, Python), des bonnes pratiques de versioning et de documentation.

Cela permet de concilier autonomie des équipes et cohérence globale du SI.

Le multi-tech est une richesse quand il est gouverné. Sinon, c’est un cauchemar de maintenance.

anis bessa

5. La communication entre microservices : l’art du dialogue

Avant de vous lancer dans les microservices, vous devez concevoir une architecture robuste qui permet de les orchestrer, les contrôler et de les faire évoluer car s’ils restent indépendants, ils n’en doivent pas moins travailler ensemble vers un but commun (Kubernetes est en ce sens une solution intéressante).

Si la communication est importante entre les équipes comme vu précédemment, il en est de même pour les microservices. Effectivement, l’une des décisions de conception la plus complexe à prendre au sujet d’une architecture en microservices, est la manière dont ses services vont communiquer et échanger entre eux. Tel les maillons d’une chaîne, chaque microservice échange des données et déclenche l’activité d’un autre microservice pour effectuer une mission.

L’API http REST synchrone peut paraitre une solution pragmatique à mettre en place à court terme. Le service A appelle le service B qui appelle le C et ainsi de suite. Cela suppose que B et C soient disponibles et les temps de latences s’additionnent… Et comme les microservices sont généralement des systèmes distribués, ils peuvent tomber en panne. Ainsi, dans le cas de microservices synchrones où les services sont fortement interdépendants entre eux, cela entraine inévitablement des défaillances en cascade. C’est le fameux effet domino.

Pour en optimiser leur fonctionnement, les microservices doivent pourvoir effectuer leurs traitements et remplir leurs missions propres, sans dépendre de la disponibilité d’autres services. Les microservices devraient communiquer entre eux de manière asynchrone via événements ou files d’attente des messages (Kafka, REST, ATOM). Cette « conversation » constante entraîne en effet une baisse des performances en raison de la latence du réseau et du temps nécessaire au traitement des messages. Si l’approche asynchrone est plus complexe, elle bénéficie d’une latence plus faible.

En bref, Le synchrone est simple à mettre en place mais introduit un risque de dépendances en cascade : si un service tombe, tout le flux peut être bloqué. L’asynchrone, plus complexe à concevoir, améliore la tolérance aux pannes et la scalabilité en découplant les appels. Dans la pratique, une combinaison des deux approches s’impose : REST pour les interactions simples, événements pour les processus métier longs ou critiques.

“-Les microservices doivent dialoguer, pas s’interrompre.

6. Le frontend : le grand oublié du découplage

Il est courant de se retrouver dans un projet avec un backend 100% microservices et parfaitement modularisé … et un front monolithique. Erreur classique mais coûteuse : à quoi bon découpler le back si le front reste figé ?

La raison est que la plupart des développeurs de backend ont une vision rétrospective du développement de frontend et le voient comme un développement plus « accessoire ». Et comme la plupart des architectes logiciels sont des développeurs de backend, ils nourrissent peu d’intérêt pour le frontend qui se retrouve souvent négligé dans la conception de l’architecture.

Dans le meilleur des cas, ils développent le front avec des technologies de webcomponents (composants en HTML JS, CSS sous forme de librairies) ou des frameworkd based components (basés sur React, Angular ou Vue).

Si votre frontend est conçu avec une approche monolithique, on se retrouve avec les mêmes travers lorsqu’on doit le moderniser ! De la même manière, il convient de le découper en différents modules (ou composants) indépendants et réutilisables dans plusieurs applications afin de pouvoir les faire évoluer, les enrichir ou les mettre à jour indépendamment des différentes applications qui les utilisent. Pour exemple, les composants de sign-on, paiement ou de panier sont communs, il n’y aucune utilité à les redévelopper à chaque fois. Les équipes de développement n’ont plus qu’à intégrer ces composants (microfrontend) sans avoir à en maîtriser les domaines métiers.  

Anis Bessa

L’approche microfrontend consiste à appliquer la même logique de modularité au front : chaque composant (authentification, panier, paiement, dashboard) devient un module autonome et réutilisable dans plusieurs applications.

C’est un changement culturel : le frontend n’est plus “le vernis du back”, mais un pilier de l’architecture à part entière.
Les frameworks modernes (React, Angular, Vue.js) et les webcomponents facilitent cette approche.

Résultat : un front plus rapide à mettre à jour, à faire évoluer, et à intégrer dans différentes expériences utilisateurs.

7. Une organisation adaptée à la décentralisation

Si une organisation a pour objectif de développer une architecture de microservices, elle doit adapter la taille de ses équipes en conséquence. Votre équipe doit être polyvalente. C’est-à-dire rassembler toutes les compétences en développement de frontend/backend, en test, en production… Le management doit lui aussi changer. Effectivement, l’architecture de microservice ne fonctionne que si l’organisation pour la supporter et la faire vivre est en place … et cela suppose une certaine décentralisation de la prise de décision.

Cela implique une gouvernance repensée :

• Moins de contrôle centralisé,
• Plus de délégation et de responsabilisation,
• Des cellules pluridisciplinaires capables de livrer en continu.

En somme, une architecture microservices ne vit que si votre organisation est aussi distribuée que votre code.

8. Se faire accompagner : le pragmatisme avant toutompagner

Les architectures microservices font couler beaucoup d’encre et sont aussi un véritable bouillon d’innovations technologiques. Pourtant, elles ne sont pas adaptées à tous les projets. Ne foncez pas aveuglément 😉 Tout le monde s’accorde aujourd’hui sur le fait que c’est une architecture intéressante et rentable lorsque votre système est devenu très lourd et qu’il se révèle impossible à maintenir et à faire évoluer. Si ce n’est pas le cas, une architecture monolithique conçue avec la bonne modularité est toujours d’actualité !

Si vous souhaitez construire une solution simple ou planifier un lancement rapide pour valider une idée ou un nouveau service, l’approche monolithique classique conviendra mieux à vos objectifs. À contrario, une architecture microservices est particulièrement adaptée aux grandes entreprises ou départements qui doivent fournir un grand nombre de services, qui ont besoin d’évoluer rapidement et de procéder régulièrement à des changements en fonction de l’évolution de leur écosystème concurrentiel. On retrouve beaucoup d’architectures microservices aujourd’hui dans le retail, dans la distribution et derrière des sites marchands e-commerce. 

Anis Bessa

L’avantage d’un système monolithique c’est qu’il est par nature simple à surveiller contrairement aux microservices. Avec une architecture microservices, vous avez des dizaines voire des centaines de modules dans des environnements différents et utilisant des langages, des API, des bases de données, des fichiers de configuration différents, etc.

Le support de votre application dans le temps n’est pas simple. Car si, en théorie un changement sur un microservice n’est pas sensé impacter les autres, dans la pratique il n’est pas rare qu’une modification à un endroit nécessite des interventions sur plusieurs autres services pour qu’ils restent opérationnels. Une telle diversité rend le support de l’application délicat. Et oui, dans un monde idéal, les modifications apportées à un microservice ne devraient pas avoir d’impact sur les autres composants indépendants. Pourtant, dans la pratique, une mise à jour à un endroit nécessite parfois la reconstruction de plusieurs services à la fois pour préserver leur compatibilité.

Les microservices incarnent une promesse : celle de la souplesse, de la scalabilité et de la rapidité.
Mais cette promesse n’est tenue que si elle s’accompagne de discipline, de gouvernance et de culture d’équipe.

En d’autres termes : les microservices, oui, mais pas à n’importe quel prix.

Pour conclure, il est fort à parier qu’architecture monolithique et microservices continueront à coexister comme le font SQL et No SQL.

Besoin d’accompagnement pour concevoir, structurer ou moderniser votre architecture logicielle ?
Harington vous guide vers la solution la plus adaptée à vos enjeux techniques et métiers.

Sources :

• https://www.forbes.com/sites/louiscolumbus/2018/11/04/idc-top-10-predictions-for-worldwide-it-2019/#74fb62207b96
• https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee2
• https://www.capitalone.com/tech/software-engineering/10-microservices-best-practices/
• https://www.lemagit.fr/definition/Base-de-donnees-multimodele
• https://fr.wikipedia.org/wiki/Microservices
• https://medium.com/@jbgisbert/microservices-overview-30e505316a8