1. Partir de domaines fonctionnels
Le découpage initial des applications doit s’appuyer sur des domaines métier bien définis. Dans le cas concret des médias, il y aura des domaines en charge de la préparation des vidéos, de la gestion des métadonnées ou encore du pilotage des utilisateurs. Chaque domaine sera pris en charge par une équipe dédiée, responsable des différents microservices associés. Par exemple pour le player vidéo, il s’agira de services d’autorisation ou encore de delivery pour gérer les formats adéquats.
Selon Olivier Mansour, cette approche d’architecture en microservices est essentielle pour gérer la montée en charge des équipes de développement. Toutefois, il déconseille cette architecture pour des équipes réduites, car la complexité des microservices pourrait dépasser leurs avantages. « Plus l’équipe sera importante, plus la logique en domaines et microservices sera pertinente. Si elle ne compte que quelques développeurs, ce sera une erreur de partir dans cette voie. On prendra en pleine face le coût et la complexité des microservices sans bénéficier de leurs gains » conclut-il.
2. Procéder par étape
Pour une start-up, il vaut mieux commencer par une application monolithique. Une fois la croissance amorcée, avec des équipes plus nombreuses de développeurs, alors seulement il deviendra pertinent de migrer vers une architecture en microservices. « C’est là que la logique de travail en microservices prend tout son sens, insiste Olivier Mansour. On basculera alors dans une phase de découpage applicatif via l’extraction de domaines et de fonctionnalités qui permettra d’embarquer de nouvelles équipes avec une structure de gouvernance cadrée ».
3. Éviter le sur-découpage
Un microservice doit être suffisamment précis sans être trop fragmenté. « Toute la question est de savoir jusqu’où aller en termes de découpage », souligne Olivier Mansour. Chez 20 Minutes, un microservice se présente sous la forme d’une petite tâche précise et répétitive encapsulée dans une fonction Amazon Lambda. Il peut s’agir par exemple de gérer l’envoi d’e-mails ou de notifications. Ou encore de gérer des photos, depuis leur enregistrement dans la médiathèque du site jusqu’à la génération de métadonnées par reconnaissance d’image en passant par le recadrage des portraits sans couper les têtes des sujets. D’autres microservices prennent en charge la gestion des blocs sur les pages, etc.
Cependant, il est crucial d’évaluer si une nouvelle fonctionnalité peut être intégrée à un service existant, pour traiter un nouveau cas d’usage avant de créer un nouveau microservice, conseille Aurélien Capdecomme, CTO de 20 Minutes. « En cas de fonction trop volumineuse, on pourra être amené à la découper en sous-services. »
4. Prioriser les échanges standards
Les interactions entre microservices doivent être suffisamment neutres et standardisées pour garantir leur interopérabilité et faciliter les évolutions futures. Par exemple, en 2020, chez 20 Minutes, une fonctionnalité d’analyse de texte a été conçue dès le départ pour intégrer de nouvelles possibilités, comme c’est le cas il y a quelques moi via l’IA générative avec une fonctionnalité de résumé d’articles. « Nous cherchons à laisser un maximum de portes ouvertes pour nous permettre de venir brancher de nouvelles fonctions au regard de l’évolution des besoins », commente Aurélien Capdecomme.»
Olivier Mansour ajoute que « Les microservices pourront fonctionner de manière autonome pour peu qu’ils respectent leur contrat d’interface. »
5. Éviter les sur-dépendances
Du fait de leur interopérabilité l’évolution d’une fonctionnalité peut influencer directement celle d’un ou plusieurs microservices. Ce qui implique une coordination entre plusieurs équipes, toutes intégrées dans une feuille de route commune. « Ce type de situation se produit notamment lorsqu’un microservice joue le rôle de fournisseur pour un autre, comme dans le cas où une nouvelle fonctionnalité dépend d’une authentification à double facteur. Dans certains scénarios, un microservice peut devenir dépendant d’une multitude d’autres microservices. Une situation à éviter, sous peine de recréer une architecture monolithique », explique Olivier Mansour.
Ainsi, la question de l’architecture devient un enjeu central. Elle se doit de minimiser ces interdépendances, tout en permettant une gouvernance claire et une coordination efficace des équipes.
On passe de la gestion d’un unique monolithe à celle de plusieurs services indépendants. « Cela soulève des problématiques DevOps importantes. Adopter une architecture en microservices implique de rendre les développeurs autonomes dans la création et la gestion de leur infrastructure, chacun étant responsable de sa propre base de données », ajoute Olivier Mansour. « Par ailleurs, la surveillance des systèmes devient bien plus complexe. Il est essentiel de mettre en place des outils d’observabilité pour centraliser les logs, les traces et les métriques, permettant ainsi d’avoir une vue d’ensemble et de localiser rapidement l’origine des problèmes. »
6. Architecturer ses microservices
L’architecture de l’application est fondamentale et une architecture bien pensée garantit la résilience du système. Dans l’application mobile de 20 Minutes, c’est un microservice unique qui gère les appels en base de données pour l’application mobile, favorisant ainsi la maintenabilité et la sécurité des appels. « Car en cas de multiplication des flux, on multiplie aussi le risque de bugs », souligne Aurélien Capdecomme.
Sauf que si l’architecture est bien conçue, un incident n’impactera pas l’ensemble de la stack. « C’est ici que se trouve le principal avantage comparé à une application monolithique, qui elle cédera dans son intégralité en cas de pic de trafic trop important. Alors qu’avec les microservices, on répartit la charge et on ajuste la puissance machine pour chacun d’eux », explique Aurélien Capdecomme.
Et Olivier Mansour complète l’explication en expliquant que « À chaque microservice pourra être allouées des ressources machines ad hoc ou encore un CDN en fonction des pointes de trafic. Si la charge ne peut être encaissée, certains microservices moins critiques pourront être désactivés pour permettre à la plateforme de continuer à fonctionner. Dans le cas d’un site média, il pourra s’agir par exemple de désactiver la personnalisation pour permettre au player vidéo retransmettant un grand événement sportif de continuer de fonctionner. »
7. Allouer une base de données pour chaque domaine applicatif
Au sein d’une architecture en microservices, chaque domaine applicatif doit disposer de sa propre base de données. Bien que cela augmente la complexité et les coûts, cette approche garantit l’autonomie des services, comme pour un microservice de géolocalisation de fonctionner en toute autonomie.
8. Maintenir une cohérence technologique
Bien que des microservices développés dans des langages différents pourront dialoguer et coexister ensemble, l’uniformité technologique simplifie tout de même largement la gestion.
Chez 20 Minutes, l’ensemble des microservices sont développé en langage unique appelé NodeJS. « Ce qui permet de rationaliser les équipes en termes de formation et de recrutement, mais aussi d’appliquer les mêmes standards et librairies de sécurité, les mêmes règles et les mêmes normes de codage. Cependant, à chaque étape, il faudra vérifier que le service qui interroge le suivant a bien l’autorisation de le faire », conclut Aurélien Capdecomme. »