Comment bien organiser un projet microservices

Cet article est le quatrième d’une série rédigée par thomas.ruiz et moi même traitant de l’architecture orientée microservices (retrouvez l’article introductif ici). Il aborde dans un premier temps les enjeux d’organisation liés à la mise en place de telles architectures et dans un deuxième temps les différentes parties prenantes ainsi que leurs responsabilités. Enfin, nous parlerons des outils que vous pouvez utiliser pour faciliter la mise en place d’une organisation efficace tournée vers la réalisation de microservices.

Nous avons vu dans les articles précédents que chaque microservice doit se focaliser sur le cœur de métier et les logiques qui lui sont propres, et non sur les caractéristiques techniques. Néanmoins, pour nous, les aspects organisationnels sont aussi importants que les enjeux techniques, car le domain-driven design (DDD) implique avant tout les collaborateurs, et c’est leur façon de s’organiser pour résoudre un problème qui est déterminante.

En effet, implémenter une architecture en microservices demande un investissement à tous les niveaux pour garantir le succès du projet, en mettant l’accent sur la communication et le partage des responsabilités. Faire confiance uniquement à la technologie et à la qualité de vos développeurs pour construire une brique applicative créera à coup sûr des problèmes sur le long terme.

En nous appuyant sur notre expérience, nous allons voir dans cet article comment concilier enjeux techniques et enjeux métiers.

Comme nous l’avons déjà vu, l’un des enjeux du DDD est de réduire la différence de compréhension d’une problématique entre les métiers dits techniques et les experts du domaine métier, pour éviter d’engendrer des erreurs de conception logicielle. Afin de réduire cet écart, il est nécessaire de créer des équipes dédiées pour renforcer et faciliter la communication. Celle-ci joue justement un rôle capital dans une architecture microservices : des échanges efficaces et facilités entre les équipes amèneront forcément une meilleure communication entre microservices.

Les avantages de l’organisation que nous allons décrire ici sont multiples. D’abord, puisqu’une équipe est orientée vers un domaine restreint, elle est plus à même de le comprendre en profondeur, aux niveaux fonctionnel et technique. Cela engendre une meilleure spécification des besoins, et donc des temps de développement et de recette plus courts. La force de cette organisation réside aussi dans l’importance de la documentation. Puisqu’il faut que les différentes équipes connaissent au minimum les points d’entrée et de sortie des microservices qui leur sont attribués, la production de documentation se fera instinctivement ; vous obtiendrez un système bien plus robuste et plus facile d’accès.

Il vous faudra définir des domaines en segmentant votre business intelligemment. Une fois ces domaines définis, nous vous recommandons de désigner un expert responsable pour chaque domaine, et de constituer des équipes autour de ces experts métiers. Chaque équipe pourra être composée d’un PO, d’un lead développeur, de développeurs, d’un DevOps, ainsi que d’un API Manager. Certains de ces rôles pourront être assumés par une seule personne (il n’est pas rare que l’API Manager joue par exemple également le rôle de Lead Dev de l’équipe), notamment si la taille de votre organisation ne permet pas de déployer de telles équipes.

Les responsabilités

Voici la liste des rôles qui doivent être représentés au sein de chaque équipe.

L’expert métier

Il s’agit de la personne dont les connaissances ou les compétences dans un domaine spécifique sont les plus approfondies. L’expert métier joue le rôle de référent et apporte ses expériences sur un périmètre donné. Pour reprendre l’exemple du domaine de la fidélité en e-commerce, il peut être un opérationnel du marketing. Il est responsable de la bonne compréhension du domaine par toute l’équipe, et son rôle est de répondre à toutes les interrogations que peuvent avoir ses collègues.

Le Product Owner

Sa mission est de faire le lien entre le métier et la technique. C’est lui qui portera la vision du produit, par exemple le module “fidélité”. Il sera chargé de définir les spécifications et les priorités de développement, et d’assurer la bonne avancée des itérations. Il sert également de point d’entrée pour l’équipe, et pourra rediriger vers la bonne personne en cas de blocage. Il n’est toutefois pas considéré comme un chef d’équipe : il est très important qu’il soit sur un pied d’égalité avec ses développeurs, pour que la responsabilité de la tenue des délais et de la qualité soit correctement répartie. Il n’est pas rare que le PO soit lui-même expert métier, mais dans ce cas, il faut être doublement vigilant à ce que l’équipe s’approprie correctement le métier, et que le long-terme soit toujours bien pris en compte.

L’API Manager

Comme son nom l’indique, cette personne sera responsable de la rédaction, la publication, la promotion et la supervision des échanges de données au sein de l’équipe. Il devra aussi s’assurer que la vision du domaine soit cohérente et interopérable avec les autres domaines. Il devra rédiger les spécifications OpenAPI (ou tout du moins approuver les modifications). Son objectif est d’obtenir des APIs qui s’intègrent facilement à la plateforme d’API Management de l’entreprise.

Développeurs & DevOps

Ce sont les collaborateurs qui vont matérialiser leur compréhension de la problématique sous forme de code. L’un d’entre eux devra être identifié comme Lead Dev. Ils sont chargés d’estimer correctement les différentes tâches à effectuer, de produire du code maintenable et testé, d’automatiser au maximum ce qui peut l’être, d’opérer et de monitorer les microservices, et de rédiger la documentation technique du produit. Leur objectif est, évidemment, d’avoir un projet qui contienne le moins de bugs possibles et qui réponde aux spécifications rédigées par le Product Owner.

Les outils

Nous avons vu que la démarche de communication des informations aboutit à la mise en place d’un référentiel commun, afin que toutes les parties prenantes aient le même niveau d’information. La prochaine étape est de retranscrire ces informations sous forme de code. Pour cela, nous utilisons plusieurs outils chez Neoxia.

Bonnes pratiques pour les réunions

La première étape que nous suivons est la mise en place de bonnes pratiques pendant les ateliers de découverte. Ces derniers vont permettre d’identifier les exigences fonctionnelles et techniques pour définir la cible. Ainsi, lors de la co-construction d’un état des lieux, les questions adressées au domaine métier pour la compréhension de son activité sont d’ordre général. Les autres interlocuteurs (Devs/PO/DevOps/API Manager) doivent bien sûr prendre des notes. Ensuite lors d’une seconde réunion, les notes permettront d’approfondir les points de détails en posant plus de questions. Il faudra renouveler ces ateliers jusqu’à une compréhension partagée du domaine métier. Mais comment considérer que l’on a atteint une définition métier suffisante ? Il existe plusieurs méthodes pour mesurer le niveau de compréhension. L’une d’elles consiste à proposer à l’équipe d’évaluer sur une échelle allant de 0 à 5, d’un atelier sur l’autre, leur niveau de compréhension métier et d’avancer uniquement lorsqu’une certaine note a été atteinte. Une autre méthode consiste à organiser des ateliers de restitution hebdomadaires par les apprenants, pour établir et améliorer si nécessaire leur compréhension du domaine métier.

Il est très important de faire des ateliers courts (maximum 1h30) car le niveau d’information collectée est très dense.

Définissez au préalable l’objectif de la réunion et le rôle de chacun(e). Allez chercher les informations dont vous avez besoin auprès des bonnes personnes avant la réunion, et prenez des notes pour en tirer un compte rendu à partager aux intéressés. Limitez le temps passé dans les réunions ; beaucoup d’entre elles peuvent être réduites à un simple échange d’e-mails. Limitez également le nombre de personnes décisionnaires pour éviter les débats interminables. Enfin, faites confiance aux experts techniques quant à leurs estimations et leurs remarques. Il existe de nombreux livres très intéressants à ce sujet.

Spécifications API

Lorsque nous développons des projets chez Neoxia, que ce soit pour des microservices ou pas, la première étape que nous suivons est d’écrire les spécifications OpenAPI pour chaque pièce du système. Cette étape est primordiale pour s’assurer d’une communication efficace autour d’un périmètre précis. Nous identifions au sein des différentes équipes un API Manager qui, comme expliqué au préalable, aura la charge de spécifier tous les modèles et endpoints de l’API.

Il est également important de mettre en place des outils comme Dredd, Prism et Pact pour garantir que les APIs développées respectent les spécifications OpenAPI. Cette étape permet non seulement la génération de documentation automatique mais elle impose également une forme de rigueur dans le développement et contribue à rendre l’ensemble du système plus robuste. Tout cela s’inscrit dans une démarche API First que nous essayons et que nous vous invitons à suivre.

Agilité (scrum/kanban)

L’agilité n’est pas une méthode, contrairement à ce que l’on pourrait penser, mais bien un outil au service de l’équipe. Celui-ci doit être privilégié au cycle en V, car il correspond plus à la vision du DDD. En effet, les individus et leurs interactions sont ici au cœur des deux méthodes.

Automatisation

Comme nous l’avions évoqué dans l’article 2 de notre série, les problématiques DevOps doivent être considérées dans votre processus de création dès le départ du projet. Le fait de faire intervenir le DevOps dans la modélisation va lui permettre de répondre aux différents enjeux métiers, comme par exemple la scalabilité à gérer en fonction du volume d’appels, ou la gestion des configurations en fonction des besoins backend du domaine métier. C’est le DevOps qui choisira les outils les plus adaptés aux enjeux, mais nous pouvons d’ores et déjà parler d’outils basiques tels que les différents environnements dans la chaîne d’intégration continue, ou de Kubernetes et Docker pour la conteneurisation.

Conclusion

Comme vous l’avez constaté, nous nous sommes forgés au gré de nos expériences un certains nombre de convictions sur ce qui fera le succès de la mise en oeuvre d’une architecture orientée domaine. En synthèse, nous regroupons deux familles d’enjeux :

• Les enjeux d’organisation d’équipe. Une bonne définition du rôle et des responsabilités de chacun(e) va de pair avec la mise en place de méthodes de travail adaptées. Évident ? Oui, mais attention à bien dimensionner votre organisation en fonction de la taille et de la nature du business de l’entreprise. Même si vous mettez en place une plus petite équipe, veillez à ce que l’ensemble des rôles évoqués dans cet article soient pris en charge, chaque membre pouvant donc être amené à cumuler plusieurs casquettes.
• Les enjeux de compréhension du métier. Gardons en tête que la définition et la compréhension du besoin métier est bien sûr la clé principale pour construire avec succès une architecture orientée domaine. Pour augmenter vos chances de réussites, prenez le temps de bien choisir chaque référent métier en veillant à ce qu’ils disposent d’une bonne capacité à transmettre en étant pédagogue. Puis il faudra que le reste de l’équipe prenne véritablement conscience de l’importante d’assimiler ces connaissances métiers afin de répondre au mieux aux besoins exprimés.

En espérant que cet article vous a plu, nous vous donnons rendez-vous prochainement pour vous éclairer sur un autre sujet qui concerne les “données de référence et leur définition”. Cela fera l’objet d’un 5e article et dernier article qui viendra très vite conclure notre série.