Microservices et bataille d'ownership
Les défis humains en microservices : quand aligner les équipes devient plus dur que coder. Découvrez pourquoi l’humain est la vraie complexité du dev.
En ce moment, au boulot, je travaille sur une feature qui s’étale sur plusieurs services. Ce genre de tâche est assez complexe à intégrer, non pas à cause du code ou de l’architecture, mais surtout à cause… de l’humain.
Ce qui est compliqué, c’est de mettre tout le monde d’accord sur le procédé. Chacun a ses règles, ses pratiques, ses enjeux… et son égo !
Mais optimiste (et naïf ?) que je suis, je m’aventure dans les couloirs sombres du développement.
Je fais mes modifs, je soumets mes changements. J’aime bien être serein sur ce que je livre, donc je prends toujours le temps de tout backer avec des tests (unitaires et end-to-end).
C’est alors que je m’élance fièrement sur le channel Slack d’un des owners pour lui partager mon travail. Et là… patatras. Tout s’effondre.
Ne voulant pas assumer la responsabilité de ces changements (comprenez : la charge machine et base de données liée à mes besoins), il me renvoie vers la brique B.
Souhaitant avancer, je prends sur moi, je refactor tout, et je soumets une nouvelle PR aux owners de ladite partie, avec les tests, les explications, etc.
Eh ben non. Lui non plus ne veut pas intégrer les modifs… et me renvoie sur le repo A.
Comprenez que les deux se sont renvoyé la balle comme ça pendant 3 jours.
Vous vous dites sûrement que le plus simple serait de réunir tout le monde autour d’une table. Histoire que tout le monde se mette d’accord une bonne fois pour toutes, pour éviter les revirements ensuite.
On sait tous qu’un expert déteste se contredire lui-même, donc une fois qu’il a dit "go", il continue à le dire ensuite, par principe.
Eh bien… sachez que tout ça a déjà été fait. Il y a bien longtemps, d’ailleurs !
Et c’est probablement là, mon erreur.
En réalité, on avait débriefé de ce sujet… il y a deux ans. Mais entre-temps, tout est sorti de leur tête, chacun a avancé sur ses sujets.
Et moi, quand je reprends le truc, je ne me dis pas une seconde que les mentalités ont changé… Et qu’au final, ce qu’on avait décidé n’est plus faisable.
Un sacré cafouillage !
Bref, si vous êtes en architecture microservices, et que vous bossez sur une feature cross-service :
la première chose à faire, ce n’est pas de coder… mais de réconcilier l’humain. 🤣
On atteint ici ce que je pense être les limites d’une trop grosse équipe découpée en feature leads.
Je suis intimement convaincu qu’une petite équipe de brutes va bien plus vite qu’une grosse équipe de devs.
Et l’histoire m’a donné tellement d’exemples : des startups avec de gros financements, un projet prometteur, de bons devs… Mais trop de monde, trop de contradictions… et au final, aucun produit.
Quand on lutte chaque jour pour sa survie, on ne peut pas se permettre de faire dans la dentelle.
FAQ
Pourquoi les features cross-service sont-elles si compliquées dans une architecture microservices ?
La difficulté vient rarement du code lui-même, mais de la coordination entre les équipes qui ont chacune leurs propres règles, priorités et sens des responsabilités. Quand personne ne veut assumer la charge liée à un changement, les PR restent en suspens indéfiniment.
Comment éviter que les owners se renvoient la balle pendant des jours ?
Avant d'écrire la moindre ligne de code, il vaut mieux aligner tout le monde explicitement sur qui prend quoi en charge. Une réunion de cadrage en amont, même courte, évite les allers-retours épuisants.
À quoi ça sert de réunir les équipes si les décisions prises sont oubliées deux ans plus tard ?
Une décision collective non documentée ou non rappelée régulièrement a une durée de vie très courte. Il est utile de consigner les choix d'architecture quelque part de visible et de les remettre sur la table dès qu'un sujet connexe ressurgit.
Les grandes équipes sont-elles vraiment moins efficaces que les petites ?
L'auteur en est convaincu : plus l'équipe est grande, plus les frictions de coordination s'accumulent et ralentissent la livraison. Une petite équipe soudée, contrainte par la nécessité, prend des décisions plus vite et les assume pleinement.
Alexandre P.
Développeur passionné depuis plus de 20 ans, j'ai une appétence particulière pour les défis techniques et changer de technologie ne me fait pas froid aux yeux.
Poursuivre la lecture
