Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Nicolas Verrino, Nicolas bonjour.
Salut Benoît.
Salut salut.
Bon aujourd'hui on va se faire un petit troll.
Microservice or not microservice.
Ha ha ! Très bonne question.
Ça dépend.
Ah ! Ça me fait plaisir déjà d'entendre ça.
C'est une super hétante.
Je t'avoue que là où je me sens un peu seul dans le désert,
c'est que je vois tous ces gens se faire des petits plaisirs solos sur les microservice,
mais moi j'en ai jamais eu le besoin quoi pour l'instant.
C'est à dire que tant que ton application, elle n'est pas hyper complexe, hyper tofu,
surtout en fait au-delà de la complexité de l'application,
si t'as pas une équipe qui dépasse les 10-15 développeurs,
moi je trouve que le monolithe c'est parfait quoi.
Ouais alors je suis assez d'accord mais en fait ça dépend pas tant de la taille de l'équipe,
ça dépend plus du problème à résoudre et des contraintes de performance et de déploiement.
Parce que finalement, découper son monolithe en microservice,
c'est se dire ok, il y a des morceaux du service que je rends à l'utilisateur
que je veux découper, que je veux déployer et faire évoluer de manière séparée.
Ouais je suis d'accord, j'aime ça aussi.
Mais est-ce que tu as déjà travaillé sur des projets qui avaient des volumétries qui justifient ça ?
Non, après, je n'ai jamais bossé sur des projets avec des volumétries comme ça.
Moi ce qui me gêne c'est les gens qui vont, par exemple dans notre épisode,
quand un marteau tout les problèmes ressemblent à des clous,
qui vont venir appliquer ce parten d'architecture à tout va, voire moi sur un projet,
il y avait plus de 128 microservices.
Ah oui d'accord.
Mais pas un seul n'était terminé, ils étaient tous working progress.
Là on a tenu des niveaux qui me semblent peut-être ridicules,
mais là-dessus, les microservices, la promesse c'est tu vas voir ça va être beau,
ça va être scalable, ça va être tout ce que tu veux,
mais c'est introduit une complexité qui est quand même moins d'être déngligeable.
Ah oui non, c'est clair, de toute façon,
je lis en ce moment le bouquin de Sam Newman, Building Microservices,
qui est d'ailleurs très bien, que je vous conseille,
surtout avant de vous lancer dans les microservices.
Où il dit faire le choix des microservices, c'est rajouter de la complexité.
Et c'est effectivement non négligeable,
parce que effectivement des microservices, c'est plus compliqué, plus complexe,
que comme le lit.
On a des problématiques de déploiement,
on a des problématiques de communication entre les différents services,
le réseau échoue, ça, il y a beaucoup de gens qui l'oublient,
parce qu'ils lancent leur docker, leur vagrante sur leur machine,
alors ils ont leur dizaine de services qui tournent en même temps,
il y a tout qui fonctionne toujours, c'est très bien,
mais il faut en prod quand le réseau tombe, il se passe quoi.
Ça c'est une autre histoire.
Donc quoi faire des microservices, ça demande une grande expérience,
une grande expérience technique et un grand savoir-faire avant de se lancer là-dedans.
Donc moi ce que je conseille, et ce que je conseille d'ailleurs Sam Newman aussi,
c'est d'abord de faire d'un monolithe découplé,
donc on va coder correctement son monolithe,
on va essayer d'identifier les services dans notre monolithe,
et une fois qu'on a bien réussi à faire les séparations,
on va commencer à séparer ça dans des exécutables différents,
des artefacts différents, qui sont déployables et scalables de manière indépendante.
Les microservices, c'est un impact énorme aussi sur l'organisation de l'entreprise.
Si vous faites des microservices par spécialité,
genre un microservice de base de données,
ça se voit des fois, tu vas peut-être déjà rencontrer.
J'ai un microservice qui gère l'accès à la base de données,
j'ai un microservice qui gère la communication avec un SAP, par exemple, ce genre de choses-là.
Le problème c'est que pour mettre dans les mains des utilisateurs la solution finale,
il va falloir faire intervenir une pléthore d'équipe.
Donc votre temps de... je dois rajouter une fonctionnalité,
mais ça impacte 5, 6, 7 équipes,
parce que ça impacte tant et tant de microservices différentes
qui ne sont pas gérées par la même équipe,
le temps de développement va être exponentiel, plus il y a d'équipes.
Ça me paraît assez évident, mais ça fait du bien de...
C'est une bonne chose de le dire,
j'aurais tendance à découper des équipes et des micros fins.
T'as toujours dans le scrum le principe d'équipe autonome.
Donc d'une manière générale,
une équipe si elle a des dépendances tierces pour livrer de la valeur,
tu rajoutes des problèmes là où il n'y a pas lieu d'aide.
J'aurais tendance à m'organiser en équipe capable de produire la file sur seuls,
mais effectivement, le microservice peut inviter à faire autrement.
Il y a deux pièges,
le premier c'est qu'il faut bien découper ces services
pour garder cette agilité, cette réactivité là.
De, je dois développer une nouvelle fonctionnalité,
de qui je dépend pour la mettre dans les mains d'utilisateurs.
La réponse idéale, c'est que je ne défend de personne.
Donc si l'équipe en question gère des microservices
qui peuvent répondre à un produit donné
et qu'ils ont besoin de personnes pour travailler pour avancer,
c'est que vous avez fait un bon découpage.
Un mauvais découpage, c'est qu'on commence à dépendre de plein d'équipes.
Et ensuite, l'autre problématique, c'est comment bien découper ces microservices-là.
Si on part direct sur des microservices, on a de grandes chances de se rater.
Intéressant.
Sauf à connaître le métier,
à avoir déjà un legacy monolithe
et à se dire, ok, je connais parfaitement le métier
et donc je sais quelles sont les bandits de contexte,
les différents contextes qui vont permettre de découper
mes monolithes en services cohérents.
Quand tu parles de bandits de contexte, tu fais référence à du DDD ?
Oui, tout à fait.
Avec que tu as sous-entendu que l'approche microservice
calme bien avec des bandits de contexte de DDD, donc les deux...
Clairement, clairement, on ne peut pas...
Dans une démarche convergente.
Ouais, c'est ça.
C'est exactement ça.
Il ne faut pas découper les services n'importe comment.
Il faut faire bien attention.
Ce que je trouve intéressant, mon intuition, c'est qu'il va aller mieux,
toujours commencer par un monolithe,
et je trouve intéressant qu'un expert du microservice le mentionne.
Je t'avoue que moi, je n'ai jamais travaillé,
je n'ai jamais éprouvé le besoin d'introduire cette complexité,
parce que finalement, avec de la scalabilité horizontal ou verticale,
on s'en sortait déjà très bien, bien souvent,
il suffit d'augmenter un peu la machine déjà,
on règle beaucoup de problèmes.
C'est un petit peu le code, on règle encore beaucoup de problèmes.
Le jour où il y a besoin, tu en mets 2 ou 4 en parallèle,
tu règles encore beaucoup de problèmes.
Tout ça avec un monolithe, jusqu'à maintenant, on marche très bien.
Franchement, on a 95% des cas.
En mon avis, il n'y a pas besoin de dépasser le monolithe,
ou alors on va sortir un service qui prend du temps
ou faire des choses en tâche de fond.
J'avais entendu parler d'une boîte trendline,
je ne sais pas si tu connais, qui est comment ça,
Captain Train.
Captain Train.
Si toi, tu es auditeur, cher auditeur,
si tu es ou tu connais quelqu'un de chez Captain Train,
qui peut invalider ou valider ce que je vais dire,
ça m'intéresse.
Mais tu sais que Captain Train a été racheté par trendline,
et les échos que j'avais eus, c'est que Captain Train a été resté
sur un monolithe, il était une trentaine de devs,
et il géré un truc de ma boule,
et les gars en face, Captain Train, quand ils les ont rachetés,
ils étaient en microservice,
et pour gérer la même chose, ils étaient à plus de 100 personnes.
Ah ouais, non, c'est sûr.
Il y a toute une complexité.
Moi, un rapport de 4, ça ne me choque pas.
Tu vois, un rapport de 4 pour faire la même chose,
en termes de valeur client, c'est juste que d'un côté,
c'est en microservice, et donc potentiellement plus facilement scalable.
Je mets bien des guillemets potentiellement.
Versus un monolithe qui est quand même tout à fait scalable,
dans beaucoup de mesures,
il faut pouvoir le justifier de payer un facteur 4.
Ouais, clairement.
Après, ce facteur 4 n'est pas forcément uniquement dû au microservice,
mais oui, il y a des problématiques importantes avec le microservice,
notamment en termes de monitoring.
Parce que qu'est-ce qui se passe quand le utilisateur clique sur un bouton ?
Ça va appeler ce service, lui, il s'inscrit là-dessus,
qu'est-ce que ça déclenche comme chose ?
On ne peut pas avoir le code sous les yeux tout de suite,
donc ça demande...
Il y a une complexité qui fait que le monitoring est plus difficile,
le logging est super important,
il faut bien faire ses logs, avoir quelque chose d'unifié,
ça pose quand même des soucis importants.
Après, oui, en termes de bénéfices,
si c'est bien découpé,
ça fonctionne très bien, il n'y a rien qu'à voir Amazon par exemple,
qui fonctionne comme ça,
et qui fait des choses magnifiques.
Mais voilà, il ne faut pas carbosculter.
Ce soit le mot de la fin.
Ce qui est cool, c'est que si on refait cet épisode dans 6 mois,
j'aurais peut-être plus de pays,
puisque je suis en train de travailler sur un projet qui pourrait bien m'en donner,
justifier ce genre de choses.
En tout cas, si on en reparle dans 6 mois.
Ça va ?
C'est un inconné devenu ?
Merci à toi de m'avoir invité.
Oui, quant à toi, cher auditeur,
j'espère qu'il y a aimé cet épisode,
et si ce n'est pas déjà fait,
je t'invite à rejoindre la communauté des développeurs passionnés
sur artisan-developpeur.fr
et je te dis à demain.