Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brondin Bernard et aujourd'hui on va parler de développement backend et plus spécifiquement
du concept de microservice.
Alors c'est important de se dire que dans les 30 dernières années, le concept de développement
backend, il a énormément, énormément évolué puisque aujourd'hui on est parfois amené
à construire des environnements justement sur un serveur ou plusieurs serveurs évidemment
pour maintenir une charge d'utilisateur de parfois plusieurs millions d'utilisateurs
par jour, ce qui est énorme et donc ce qui va mettre de vraies contraintes à la fois
sur la performance évidemment du logiciel qu'on est en train de construire mais aussi
des méthodes de développement puisque ça va avoir un impact sur notre vitesse d'amélioration
de ce logiciel de mise à jour et de correctif.
Donc justement pour répondre à ces besoins, il y a plusieurs approches qui se sont fait
concurrence et l'approche dont on va parler aujourd'hui et qui est en train de s'imposer
petit à petit dans le monde du développement justement logiciel sur des gros projets,
eh bien c'est l'architecture en microservice.
Alors c'est un modèle architectural qui s'oppose directement au système qu'on va
appeler monolithique plutôt traditionnel et c'est vrai que c'est une architecture
qui apporte des avantages vraiment non négligeables mais pour les projets de grande ampleur.
On en reparlera tout à l'heure mais ça sert à rien d'avoir un microservice si vous
servez trois utilisateurs, enfin une architecture en microservice.
Donc c'est quoi un microservice exactement ? Un microservice c'est une petite application
autonome qui gère un ensemble de fonctions qui sont liées à un domaine métier spécifique,
le tout évidemment au sein d'un système beaucoup plus large.
Dans une architecture en microservice, une application complète, elle est décomposée
justement en une série de services indépendants.
Ces microservices, ils communiquent entre eux par le réseau, souvent grâce au protocole
HTTP mais ça peut être d'autres protocoles de messages ou d'événements et chaque microservice
est conçu pour accomplir une tâche bien définie.
Cette tâche, ça peut être la gestion des utilisateurs, la facturation, l'authentification,
le traitement des commandes par exemple pour un e-commerce, etc.
Contrairement à une architecture monolithique justement où dans laquelle toutes ces fonctions
elles sont regroupées dans une seule base de code et qui est déployée sur un seul serveur.
Et justement nous, le point clé des microservices c'est leur indépendance.
Le microservice qui va gérer les utilisateurs, il ne va faire que ça.
Chaque service, il peut être développé, testé, déployé et mis à jour indépendamment
des autres.
Ça permet notamment à une équipe de développement d'itérer rapidement sur une partie du logiciel
sans affecter les autres parties mais il y a aussi d'autres avantages.
Alors avant de passer aux avantages et aux inconvénients, on va juste faire un petit
monolith versus un système à microservice.
Dans un monolith, on va avoir un client qui fait appel à une API qui est hébergée sur
un serveur et ce serveur va en général discuter avec une base de données où vont se situer
toutes les entités de données, donc les utilisateurs, les produits, les commandes, etc.
Ça, c'est un petit peu le schéma qu'on a classiquement.
Alors évidemment un serveur, il peut être derrière un load balancer et cet API va pouvoir
être répliqué éventuellement sur plusieurs serveurs mais on aura toujours le même code
qui tourne sur plusieurs serveurs différents.
Dans une architecture à microservice, c'est différent.
On a toujours notre client qui appelle évidemment.
En général, il va faire appel à une passerelle qu'on parle d'API Gateway.
Donc en général, c'est un T-serveur qui va permettre de récupérer toutes les requêtes
qui sont faites par le client et qui va les distribuer ensuite sur les différents microservices
en fonction de ce qu'il a besoin d'être exécuté.
Et ensuite, on va avoir par exemple trois petits serveurs, un serveur avec une API pour
les utilisateurs, un serveur avec une API pour les commandes, un serveur avec une API
pour les produits.
Ces serveurs, ils vont renvoyer les données qui leur sont propres à la API Gateway mais
si jamais ils ont besoin d'avoir accès aux données qui sont sur les autres serveurs,
ils vont pouvoir discuter entre eux également.
Et la grande différence, c'est que chaque serveur, donc chaque microservice va avoir
sa base de données avec les données dont il a besoin uniquement.
Donc une base de données pour les utilisateurs, une base de données pour les commandes et
une base de données pour les produits.
Voilà.
Et donc, c'est là où est la vraie différence, c'est qu'on a vraiment un cloisonnement
entre chaque entité métier.
Après évidemment, le cloisonnement, c'est au développeur ou à l'architecte, peu
importe, de définir comment il va se passer et où il va se passer et quelle va être la
responsabilité de chaque microservice.
Alors les avantages justement d'avoir des microservices, d'abord, il y a la modularité
et la maintenabilité.
Le principal avantage des microservices, c'est justement d'être très modulaire.
Chaque service est responsable d'une tâche spécifique, comme on l'a dit, alors une
tâche spécifique ou un ensemble de tâches spécifiques liées à un domaine, ce qui facilite
la compréhension, la maintenance et l'évolution du code.
Si vous avez à toucher un microservice, vous savez exactement ce qui se passe dedans normalement
puisque c'est très spécifique.
Ensuite, il y a le passage à l'échelle.
L'un des défis majeurs d'une architecture monolithique, c'est les volitivités.
Si vous voulez passer à l'échelle d'une architecture monolithique, vous avez deux
choix.
Soit vous prenez un plus gros serveur et tout avoir dedans, soit comme je l'ai dit tout
à l'heure, vous divisez, enfin pas vous divisez, vous cloné votre serveur pour que tous les
serveurs puissent répondre aux requêtes, mais c'est un peu plus compliqué.
Il y a des enjeux justement où selon le nombre de serveurs de code et le nombre
de serveurs de base données que vous avez, il peut y avoir des petits problèmes.
Faire évoluer un microservice, c'est plus simple puisque c'est possible de dimensionner
individuellement chaque service en fonction des besoins spécifiques.
Par exemple, si jamais admettons que vous êtes Google et que vous avez un service de gestion
des connexions puisque vous proposez la connexion avec Google, ce service va peut-être appeler
par vous vos logiciels, mais aussi énormément d'autres sites sur le web, là c'est un service
qui va devoir gérer énormément de requêtes à la seconde et donc il va falloir qu'il
soit beaucoup plus performant que les autres.
Donc il peut être mis à l'échelle indépendamment des autres services.
Ensuite, on a la flexibilité technologique.
Les microservices, ils permettent aux développeurs et développeuses de choisir la meilleure technologie
pour chaque service.
Si vous développez entièrement votre logiciel, enfin votre backend en Java, mais que vous
avez besoin par exemple de faire l'intelligence artificielle sur un de ces services, vous
allez pouvoir utiliser au choix du Python ou du Node.js ou les choses comme ça.
Cette flexibilité, ça permet de tirer justement partie de toutes les forces d'un
langage ou d'un environnement spécifique.
Ensuite, il y a le déploiement indépendant.
Chaque microservice, on l'a dit, il peut être déployé de manière indépendante.
Donc ça permet des mises à jour plus fréquentes et plus sûres.
Alors ça évidemment, ça dépend vraiment aussi beaucoup de la manière dont vous versionnez
le code de chaque microservice parce qu'un mauvais microservice peut être beaucoup moins
efficace et beaucoup moins facile à gérer qu'un très bon monolithe.
Il ne faut pas se le cacher non plus.
Mais par contre, quand c'est bien fait, que c'est bien versionné, ça peut très, très,
très bien marcher en termes de gestion de projet.
Et surtout, si une partie du système échoue ou doit être modifiée, ça n'affecte pas
nécessairement l'ensemble de l'application.
Ça va affecter les autres microservices qui sont dépendants de ce microservice-là,
si jamais il tombe et qu'il ne marche plus, mais tous les autres continueront de fonctionner.
Et la dernière chose, c'est un petit peu lié à ce que je disais, c'est la résilience.
Donc, si une partie de votre application tombe en panne, le système global continue
de fonctionner.
Ensuite, il y a les inconvénients parce qu'il y a des vrais inconvénients qui sont non
négligeables.
D'abord, il y a une complexité accrue.
Développer et maintenir une architecture de microservice, ça peut être vraiment complexe.
Surtout quand il s'agit de la gestion des communications entre les services.
D'ailleurs, il est souvent un peu nécessaire d'utiliser des outils supplémentaires pour
pouvoir orchestrer et surveiller les interactions entre les différents microservices.
Et voilà, tout simplement, il ne faut pas se dire que ça va être plus facile parce
que c'est découpé en plein de petits services.
Non, non.
En général, la complexité est accrue.
Surtout si vous avez des développeurs et des développeuses juniors dans vos équipes.
Ça peut avoir un vrai impact sur l'embarge de progression.
La gestion des données distribuées, comme on l'a dit, chaque service peut avoir sa
propre base de données.
Et donc si vous avez besoin de faire des transactions, quand on parle de transactions,
on parle de transactions en base de données, le concept d'acide et garder la cohérence
des données à travers les services, ça peut vraiment être beaucoup plus compliqué.
Et il va falloir potentiellement faire des choix et perdre un petit peu de cohérence
de données pour de la performance.
Ensuite, on a le débugge et l'attracéabilité.
C'est débugger un système qui est distribué comme ça sur plusieurs microservices.
Évidemment, c'est beaucoup plus compliqué.
Et suivre le flux d'une seule requête au travers des différents microservices, c'est
pareil, ça peut être un enjeu.
Et la dernière chose, c'est le déploiement.
On l'a dit, c'est vrai que c'est sympa de pouvoir déployer chaque microservice indépendamment
parce que ça offre des vrais avantages.
Mais si vous avez 50 microservices à déployer et parfois à déployer justement de manière
plus ou moins synchronisée, ça peut devenir très complexe.
Et en plus, les coûts d'infrastructure peuvent vite augmenter.
Mais ça, je vous l'ai dit au début, si jamais vous utilisez une architecture microservice
sur un trop petit projet et que ça n'a pas vraiment de sens, ça va aussi engendrer
des coûts d'infrastructure qui ne seront pas vraiment utiles.
Alors, un des exemples d'utilisation qui est le plus connu, on va dire, dans le monde
aujourd'hui, et c'est parmi les géants de la tech, évidemment, et c'est le cas de Netflix.
Netflix, comme toutes les plateformes VOD, ils ont des très gros besoins de puissance
de calcul, mais sur des modules très spécifiques, comme par exemple l'encodage vidéo.
Alors que de l'autre côté, la gestion de leurs autres APIs, les catégories de films,
enfin les catégories, les films, les paramètres, etc.
Bon, ça, c'est une application classique qui est assez peu, c'est assez peu demandeur
en ressources.
Mais du coup, l'architecture microservice, ça leur permet d'avoir plein de petits
services provisionnés sur juste des serveurs assez puissants pour tenir la charge d'utilisateur
et quelques énormes services qui sont répartis sur des datacentres complets pour justement
pouvoir traiter de la vidéo.
Et plus on augmente de qualité de vidéo, plus ça sera long à traiter.
Et donc, une architecture microservice, ça faisait sens vraiment dans le cas de Netflix
et c'est ce qu'ils ont fait.
D'ailleurs, il y a énormément de ressources sur la partie ingénérique chez Netflix.
Ils ont un blog qui est très complet.
Si jamais ça vous intéresse, vous mettez les liens dans les notes de cet épisode.
Bon, en conclusion, on en a déjà un petit peu parlé, mais les microservices, ils apportent
évidemment plein d'avantage, l'évolutivité, la résilience, le passage à l'échelle
de services ciblés et d'autres choses.
Mais les microservices, ils introduisent surtout une couche de complexité à ne vraiment
pas minimiser dans les gestions du projet.
Et je le rappelle comme pour toute architecture, pardon, la décision de prendre une architecture
ou une autre, ça doit se faire en fonction des contraintes et des besoins du projet et
non pas de la popularité de l'architecture en Christian.
Alors évidemment, quand vous êtes sur un petit projet perso et que vous avez envie
de découvrir l'architecture en microservice, même si ça ne fait pas vraiment de sens par
rapport à la taille de votre projet, ça peut être intéressant.
Et ça, c'est vraiment un très bon moyen pour apprendre.
Mais ne partez pas forcément sur un vrai projet professionnel et qui doit être mis en
prod sur l'architecture microservice si vous n'en avez pas besoin.
J'espère que cet épisode vous aura appris quelque chose.
C'était une petite introduction au microservice parce que le monde est bien bon.
Bien, bien plus vaste.
Mais en tout cas, j'espère que vous aurez appris quelque chose.
Moi, je vous donne rendez-vous la semaine prochaine pour un prochain épisode du podcast
ou directement sur code-tarigarage.fr pour retrouver tous nos anciens épisodes, évidemment
tous les articles de blog, les tutoriels et surtout tous les cours pour apprendre 2.0
des techno ou simplement pour arriver à trouver un boulot, se lancer en freelance.
On a vraiment des cours sur toutes les thématiques et des cours qui sont très, très bien notés.
Je vous invite à aller faire un tour sur code-tarigarage.fr.
Et moi, je vous dis à la semaine prochaine.
Salut !