Bienvenue sur le podcast Artisan Developer,
l'émission dédiée au programmeur qui parle de techniques, bien sûr, de codes durables,
mais aussi du métier en lui-même, de recrutement, de développement personnel,
ou encore d'entrepreneuriat pour t'accompagner dans une vie de développeur épanouissante.
Alors, est-tu prêt à passer au niveau supérieur ?
C'est parti !
Je sais que les monolithes sont un petit peu en disgrace en ce moment
et que la mode c'est de faire des microservices.
Ok, les microservices c'est vachement bien, ça a plein de vertus, notamment entre autres,
ben tu peux découpler ta scalabilité si certains modules ont besoin d'être plus péchus que d'autres.
Tu peux aussi simplifier potentiellement le travail en équipe,
en séparant les zones de responsabilité avec plusieurs équipes.
Tu peux utiliser plusieurs langages et ça c'est quand même top,
parce que du coup tu peux vraiment utiliser le langage le plus adapté pour réaliser la tâche qui est à faire.
Et puis parfois aussi, c'est là qu'il s'est un piège certain,
il voit une manière de réduire la complexité,
comme si le monolithe était intrinsèquement complexe
et que ça devait inexorablement terminer en une espèce de boule de bout incontrôlable.
Eh bien, je suis désolé mais les microservices, ça fait longtemps que je le pense,
et que je le dis, ce n'est pas la solution magique.
Cela apporte des solutions certes, mais cela apporte aussi son lot de défis.
Et maintenant, ce qui est intéressant, c'est que je vois de plus en plus d'équipes qui commencent à avoir du retour d'expérience
et qui globalement disent à peu près la même chose que ça.
Bon, c'est bien, mais ce n'est pas la panacée,
parce que, encore une fois, avec le microservice,
vient tout un tas de nouveaux problèmes qu'il faut gérer.
En fait, le microservice apporte des solutions à certaines choses,
mais dans le compromis, tu amènes des challenges et des nouveaux défis.
Et en substance, le message que j'entends de plus en plus,
c'est si tu ne sais pas déjà faire un monolithe propre, ne fais pas de microservice.
Parce que, encore une fois, ta complexité va exploser.
Au lieu d'avoir un seul serveur à lancer, tu en as plusieurs.
Regardes, on devre rien que ça, déjà, tu complexifies ton système.
Tu dois gérer toute l'orchestration des services,
savoir qui appelle qui, même quelque soit,
t'en approches que tu sois en orchestration ou que les services soient eux-mêmes, s'appellent mutuellement.
Tiens, tout un enchaînement de choses à gérer,
qui est quand même beaucoup plus complexe à faire que dans un simple enchaînement de code.
Ce dont un autre exemple, suivre tes logs n'est plus du tout aussi simple que ça,
parce que tout le process se passe sur plusieurs endroits,
il faut tout centraliser à un seul endroit.
Et puis, comment est-ce que tu vas gérer les aspects transactionnels ?
Si tu as besoin qu'un use case soit transactionnel
et que soit il aboutisse et tout se fasse,
soit à un moment donné il y a un problème et puis un rollback,
tout ça, c'est à gérer à la main.
Alors tu vas me dire que le crud c'est pas terrible,
mais au moins avec le crud, tu as la transaction de la base de données,
c'est simple, c'est efficace et ça marche.
Donc tu vois, tu n'as pas forcément besoin de toutes ces avancées
et si jamais tu vas vers du microservice, il faut vraiment que ce soit justifié.
Parce que tu peux très bien faire un monolithe propre
avec des contextes séparés dans tes namespace par exemple.
Tu n'es pas obligé de faire une espèce de monster spaghettie.
Si ton problème actuel, c'est la complexité de ton code,
la réponse n'est pas de faire du microservice.
Si tu n'arrives pas à comprendre l'existence
ou que ton gramme de dépendance ressemble à un plat de spaghettie,
eh bien, viens dans la maison des compagnons
à prendre à écrire du code durable.
C'est sur maison.artisandeveloper.fr.
Je te dis à demain.