Jusqu’à l’AFUP Day 2024, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Microservices, maxi supplice Sur notre projet, comme souvent, la dette technique a commencé au jour 1. Après 2 ans avec une dizaine de devs, l’application, découpée depuis son commencement en micro-services (7 puis 4), souffre de problèmes de couplages entre services, et donc, de gros problèmes de performances, comme des requêtes essentielles qui répondaient en plus de 44sec (p95). Elle est déjà utilisée en production par de gros clients et cet enjeu de performance freine son développement. Dans ce contexte, nous allons orchestrer une task force de 4 devs et Ops sur environ 3 mois pour fusionner ces micro-services en un monolithe. Cette fusion doit s’inscrire dans la roadmap d’un projet en évolution constante et gêner le moins possible les ajouts fonctionnels. Dans ce talk, nous parlerons de pourquoi et comment détruire une archi micro-services pour retourner vers un majestueux monolithe : Pourquoi un découpage en micro-services nécessite une maturité technique et métier que nous n’avions pas Comment nous avons commencé par instrumenter pour détecter les bugs ou variations de performances Comment nous avons analysé l’existant pour en déduire un plan avec des itérations régulières et moins risquées Comment nous avons utilisé des outils visuels pour embarquer et synchroniser les autres équipes Comment nous avons géré les problèmes rencontrés en cours de route Avec ce talk nous espérons vous montrer qu’il est toujours possible de résorber ce genre de dette technique. Si nous l’avons fait, vous pouvez y arriver sur votre projet et bénéficier de notre retour d’expérience.

La Comédie 24/05/2024 15:10-15:50

Si j’ai deux API pour mon application, c’est déjà un peu du microservice ?

Oui et non, ça va dépendre beaucoup du couplage (et à l’inverse de l’indépendance) de ces deux services :

• Ces deux services ont ils des ressources séparées ou partagées (base de données, serveurs, containers, etc) ?
• Sont-ils déployables de manière autonome ?
• Puis-je scaler facilement mon système en multipliant les instances d’un service, indépendamment de l’autre ?
• Les deux APIs peuvent-elles évoluer fonctionnellement de façon indépendante ?
• Les deux APIs/services ont-ils des domaines métiers bien différenciés ? Ou bien sont-ils juste une porte d’entrée lecture/écriture vers des bases de données ?

Sans la plupart de ces points, on peut difficilement parler d’architecture distribuée ou de microservices. C’est d’ailleurs un peu le cas de l’application dont on parle dans le talk : on est plus proche d’un « monolithe distribué » que de microservices.

Le couplage entre les briques est très fort, certains services ne sont que des « entity services » (en gros: du CRUD) qui gravitent autour d’un monolithe, et même le déploiement est difficile à orchestrer à l’échelle d’une seule API : on ne peut pas vraiment parler de microservices.

Dès que j’entends micro-service, mon cerveau visualise les mots circuit-breaker, saga, orchestration, blast-radius… et ça fait peur. Pourquoi selon vous, les entreprises qui se lancent dans cette architecture n’ont pas eu peur, alors qu’elles auraient dû ?

Pour nous, il y a plusieurs raisons :

• Cet effet a été amplifié par le fait qu’à cette période, beaucoup de scale-ups fondées quelques années auparavant ont eu à se structurer avec des équipes tech plus importantes qui ont dû apprendre à se structurer.
• Plusieurs technos avec un cold start plus faible et des frameworks plus légers comme Node.js ou Flask gagnent en popularité à ce moment

Vous allez nous parler d’une migration d’une architecture microservice vers du monolithe. Quel que soit le sens de la migration, cela a un coût. Auriez-vous des retours sur comment en parler, comment communiquer sur ce genre de projet auprès du management et du business ?

Effectivement, ce genre de projet de migration a un coût absolument pas négligeable. En fait, on peut même ramener ça au sujet de la dette technique au sens large: comment valoriser des refactorisations qui peuvent être coûteuses, et comment s’assurer et prouver qu’elles seront moins coûteuses que le statut quo ?

Ici, le rôle du CTO a été primordial, il est le relais des enjeux tech remontés par l’équipe, mais également bien au fait des enjeux business de l’entreprise, son adhésion à cette migration est la clé pour évangéliser ce projet.

On a essayé d’avancer des arguments les plus factuels possible:

• Le couplage entre les microservices pesait très lourd sur la performance. La gouvernance avait besoin de comprendre que des chantiers « optimisations » lancés régulièrement sur une architecture bancale allaient coûter encore plus cher que cette fusion de services, que respecter les SLA, assurer une bonne disponibilité mais aussi résoudre rapidement des bugs en production ne sera que de plus en plus douloureux tant que l’architecture n’est pas remise à plat.
• Ce qu’on explique aussi dans le talk, c’est qu’on a cherché à minimiser les risques de chaque étape du process, et éviter au plus possible de geler les évolutions fonctionnelles pendant l’opération, ce qui est rassurant pour la gouvernance.
• Documenter les alternatives (ne rien faire/ faire cette fusion d’une manière/ d’une autre, etc) et les critères qui ont mené au choix (ADR) est un bon levier pour convaincre également.
• Prévoir un plan de bataille à l’avance et orchestrer les étapes pour restreindre le plus possible le chantier dans le temps (3 mois dont près de 2 mois de planification).
• Évangéliser aussi qu’une partie de la dette technique (et donc du coût de maintenance) de la plateforme est liée à ce fort couplage, avec à l’appui des schémas expliquant les interactions permanentes entre les services. On a pu montrer que le manque d’ownership des équipes sur les microservices créait de la friction et ralentissait la correction de bug. La fusion des microservices s’inscrit comme une première étape pour y voir plus clair, avant d’identifier les domaines métier et procéder à un re-découpage. Autrement dit, ne pas avoir peur de vulgariser l’aspect technique et de matérialiser le problème, est plus efficace pour convaincre que de se mettre en position d’expert à qui il faut forcément accorder une confiance aveugle.

En bref, cela repose sur notre capacité d’une part à montrer le coût de la dette existante à chaque itération, chaque bug, et d’autre part rassurer sur la durée, le risque du chantier et le fait qu’il ne bloquera pas la roadmap business pendant un temps indéterminé.

Une conférence présentée par

Yann JACQUOT

Yann est architecte et coach chez Theodo depuis 5 ans. Il aime résoudre des problèmes et développer des applications, d'autant plus quand les deux vont de pair ! Ses principaux hobbies sont le cinéma, la moto et des jeux de toutes sortes.

Alexis STEFANSKI

Tech lead chez CircularX, et développeur depuis 8 ans, Alexis a travaillé principalement en start-up sur des projets SaaS souhaitant exposer une API à leur clients. Passionné de photo, vidéo et d'humour, c'est avant tout l'humain et les interactions qui le motivent.

Autres intervenants