Alors vous qui cherchez une bonne protection, je peux vous prêter mon armure.
La Gladiatus.
C'est sympa, mais c'est pas un peu grand pour un enfant de quatre ans ?
Oui, mais il va bien grandir, non ?
Oui.

Une seule protection pour tous, c'est du passé.
Chez Aysio Mutuelle, les garanties sont adaptées aux besoins de chacun, à toutes les situations familiales,
et certaines médecines complémentaires peuvent être prises en charge.
Aysio Mutuelle, c'est ça la Mutuelle d'aujourd'hui.
Rendez-vous en agence au suraysio.fr pour découvrir nos offres promotionnelles.
Les microservices sont-ils partout ?
Est-ce que cela a finalement révolutionné notre manière de concevoir des applications ?
Mais attends, c'est quoi un microservice ?
Tu l'auras compris, aujourd'hui on va se demander si c'est vraiment si simple un microservice.
Bonjour à toi chers compagnons, et bienvenue dans ce 21ème numéro de Radio DevOps.
Et avec moi pour parler de microservice, excusez-moi, il est tard, c'est plus que je dis, pourtant je n'ai pas vu.
Aujourd'hui, j'ai Damir.
Bonsoir Damir.
Bonsoir ou bonjour.
J'ai aussi Mathieu.
Bonsoir Mathieu.
Bonsoir.
Et enfin, et non des moindres, René.
Bonsoir René.
C'est gentil, bonsoir à tous.
Ben tu es un peu notre papa à tous René.
C'est pas comment je dois le prendre.
Oh c'est beau.
C'est magnifique.
L'épisode commence bien.
Oui, il commence super bien.
Mais avant qu'on commence vraiment, permettez-moi de rappeler à notre auditeur qu'il peut s'abonner au podcast ou à la chaîne YouTube,
s'il a envie de voir nos belles bouilles et de voir si René est vraiment notre papa à tous ou pas.
Et surtout, il peut être notifié s'il active la cloche sur YouTube.
Bon, on va vraiment commencer sur les microservices, on va rater d'importe quoi.
Même si c'est intéressant de dire d'importe quoi, enfin intéressant je sais pas mais agréable.
Et on va définir les microservices.
Enfin, on.
Damir va commencer puis on va y tirer après sur sa définition à la méthode DevOps.
Allez Damir, je te laisse ça par là.
Alors, je vais essayer de définir cette notion assez complexe.
Je vais passer par l'historique parce que tel un Percat Store, j'aime bien raconter une petite histoire.
Donc du coup, il faut voir que pendant longtemps, globalement, ce qui se passait dans la formatique,
c'est que quand on avait une application, on faisait une grosse application qui faisait un peu tout.
Par exemple, si vous prenez un City Commerce, votre application gérait les achats,
gérait les commandes, gérait le stock, gérait l'espace client, gérait tout ça,
en fait faisait ça dans un langage quelconque du PHP ou autre.
Là, ce n'est pas le propos spécialement.
Et vous avez cette application-là qui était un gros bloc.
Donc, c'était super cool parce que ce n'était pas très complexe en fait comparé.
Ce n'était pas très complexe. Tout était à un même endroit pour s'y retrouver.
Par contre, ça avait des problématiques et on y reviendra un peu après.
Et pour répondre à ces différentes problématiques sur lesquelles on va s'étendre un peu plus tard,
on s'est dit que ça pouvait être intéressant de découper cette application.
Donc, comment la découper ?
C'est par exemple, pour la découper, de se dire, mon site web effectivement qui était un site de Marketplace
avec son espace client, etc., je vais découper ça en fonctionnalité.
Par exemple, avant mon monoluite, gérer tout, ici je vais faire des services
pour chaque chose d'où le terme microservice.
En réalité, c'était service à part entière, ils ne sont pas réellement de micros.
Mais ils ont un périmètre bien défini.
Et par exemple, j'ai un service qui va permettre de gérer les stocks,
qui va être un service stock que je vais pouvoir interroger et avoir des résultats de stocks,
savoir combien il y a de stocks disponibles, etc.
J'ai un service qui va être le service, par exemple, de commande,
qui va me permettre de renvoyer vers des services de paiement, etc.
Donc je vais découper tout ça en petits morceaux, en petits services,
et ça va avoir pas mal d'avantage, mais aussi des inconvénients,
et ça je pense qu'on y reviendra plus tard.
Mais globalement, le microservice, ça va être ça.
Ça va être plutôt que penser ça en un bloc,
on va découper ça en fonctionnalité, ou en d'autres choses,
il y a d'autres manières de découper.
Mais en tout cas, on va découper notre programme pour faire des plus petits programmes,
pas forcément des petits programmes,
vous avez des services de microservice qui peuvent être un peu plus gros,
mais vous allez découper pour les rendre un peu plus indépendants.
Et après on rentrera dans le détail, je pense pour tout ce qui est de pourquoi on fait ça,
quel problème ça, etc.
Parce que sinon je vais déborder, je vais faire tout le podcast,
mais ça va être un monologue et vous allez vous emmerder.
Et les auditeurs aussi.
Je sais pas si vous avez quelque chose à rajouter.
Je pense que t'as tout dit.
Je pense que c'est vraiment ça.
Le microservice, c'est plein de services avec des responsabilités bien claires,
faiblement couplées.
Voilà, après chacun aura sa définition
sur à partir de combien de services dans une architecture
ont fait du microservice ou autre,
on pourra en reparler.
Et on en reparlera d'ailleurs, mais l'idée est là en tout moins.
René, t'as pas gros chose à dire comme moi.
Non, je vais m'abstenir.
Bon, alors on va pouvoir entrer dans le dur du dur.
Alors c'est quoi les problèmes finalement
qui sont résolues par les microservices
et pourquoi on en a venue à faire des microservices.
Est-ce que l'un d'vous veut commencer?
Je peux prendre la parole.
Parce que pour moi, c'était inventé pour ça
et je pense que c'est toujours l'uscaise majoritaire.
C'est inventé dans les grands groupes tech
pour des problématiques organisationnelles.
Parce qu'on a des entreprises avec des centaines
ou des milliers de développeurs maintenant
et on veut faire travailler ces développeurs
dans des petites équipes,
ce qu'on appelle souvent des pizza teams.
On peut nourrir avec une pizza finalement.
Une équipe qu'on peut nourrir tout le monde avec une pizza.
Et donc les microservices, c'était là
pour répondre à un problème organisationnel.
Comment je fais travailler tous ces gens ensemble
sur un même produit, mais dans des petites équipes.
Et donc le but, ça a été de découper le produit,
quand je dis le produit, ça peut être une Marketplace
par exemple ou autre, en plusieurs services
et attribuer ces services finalement à des équipes
qui vont travailler en isolation
et parler avec les microservices du voisin
avec un système de contrat.
C'est ça, on définit des contrats avec le voisin,
avec les services du voisin et c'est comme ça
qu'on fait communiquer les services.
Pour moi, c'est vraiment ça le premier point.
C'est régler un problème organisationnel
qu'on a beaucoup beaucoup beaucoup de développeurs et d'équipes.
Je précise quand même la pizza team
parce qu'on pourrait se dire avec nos pizzas européennes
mais comment tu nourris une équipe avec ça ?
C'est les pizzas américaines dont on parle.
Vous savez, il y a des trucs énormes
qui peuvent nourrir 6 à 8 personnes.
C'est ça les pizzas team.
Moi je vois un truc justement pour aller dans ce sens-là
c'est finalement quand on a ces grandes boîtes
avec plein de développeurs,
il y a des services avec des responsabilités différentes.
Tu as un peu dit mais finalement elles ont des vitesses
de développement et de scalabilité différentes.
Elles traînent sur des fonctionnalités
qui ont peut-être besoin de scaler plus rapidement
et d'autres plus faiblement.
Et donc passer sur des microservices
ou en tout cas séparer les bases de code,
on reviendra mais séparer les fonctionnalités
ça peut être intéressant dans ce sens-là
parce qu'au niveau de l'infrastructure dont on para tout à l'heure
et au niveau de la manière de développer,
ça peut changer les choses.
Pour rebondir sur le scaling,
si on reprend l'exemple que je disais tout à l'heure,
souvent le microservice va pouvoir changer la manière de scale
et parfois la simplifier.
Tout simplement si on reprend l'exemple du début que j'ai donné
vous rappelait avec le joli application e-commerce
vous allez avoir dans la première version
une base de données, une application qui va tout gérer.
Si vous avez un pic de commande, vous êtes obligé de scale tout votre application
si vous avez un scale à monolithe c'est rarement le cas
et votre base de données va se prendre beaucoup d'interrogations
vu qu'il gère aussi les stocks et tout ça.
Le microservice va pouvoir vous permettre de déconnecter un peu tout ça
et de regrouper par fonctionnalités
et par exemple vous pouvez imaginer que la base de données,
quand je dis la pays c'est le service qui va gérer
par exemple les commandes et le stock,
le pronom de stock c'est plus logique,
il va être dans un service à part sa propre base de données
donc on va voir s'il y a beaucoup d'interrogations sur stock
juste scale cette partie, on va pouvoir cibler les parties qu'on scale
et pour le coup avoir moins de choses un peu bloquantes
on sait qu'une base de données à un certain niveau c'est très dur de scale
et vous commencez à avoir des problématiques un peu embêtantes à gérer
même si en réalité on peut scale relativement haut avec.
Je ne sais pas si on l'a abordé
mais c'est des fois aussi des problématiques de cycle de vie sur l'application
des fois ça peut simplifier la gestion de parties qui vont plus ou moins vite
dans la manière de le développer etc.
Donc au-delà parfois des équipes il y a aussi des parties qui peuvent bouger plus vite
et donc ça peut simplifier ces aspects-là.
Et bien puisqu'on est dans la simplification il arrive un moment
ou parfois même si on travaille sur une seule et grosse application
l'application devient tellement énorme que finalement on n'a pas d'autre choix que de la découper
parce que sinon à la maintenir avec même une pizza team ça devait être compliqué
et souvent quand c'est très très grosse application c'est pas des pizza teams
donc quand notre application commence à devenir trop grosse et surtout trop complexe
on peut commencer à réfléchir et avoir besoin de micro-service
ou de service.
Il y a un autre aspect intéressant c'est des micro-services
souvent c'est aussi pour la résilience ça permet d'avoir de séparer et de faire par exemple
certaines parties qui sont plus critiques versus d'autres et aussi de mettre en place
justement des systèmes de fusibles.
C'est-à-dire par exemple un exemple assez souvent pris c'est chez Netflix
il y a on va dire trois grosses parties il y a la partie streaming, le catalogue et puis les commentaires
et ça permet par exemple si un défaut c'est un exemple un peu simpliste
mais si il y a un défaut sur la partie de commentaires ça n'a pas tout le reste
donc ça paraît mieux séparer les choses et avoir une meilleure résilience
et l'application peut continuer de fonctionner même si une partie est défectueuse
donc ça c'est vraiment ça c'est un des bénéfices des micro-services.
Pour le coup on peut effectivement avoir plus de moins, arrête moins impacté par un service qui plante
que si notre monolithe plante, là on a tout, je reviens à mon exemple
si jamais vous avez tout votre programme qui est votre cité commerce qui plante
si c'est le monolithe votre cité indispañible
si jamais c'est du micro-service vous avez un des services qui va planter
potentiellement j'engeur bloquer au niveau de la commande ou autre
ce qui est en merdant aussi mais qui est quand même un peu moins grave au niveau impact
et du coup il y a un autre point aussi c'est que dans une grande équipe
sur un programme un peu complexe vous avez des fois des besoins différents
qui vont nécessiter des langages spécifiques ou des techno spécifiques
ou même des compétences par exemple de l'authentification ou des choses comme ça
donc on va pouvoir séparer ça en fait sur des services à part avec des équipes dédiées
qui auront une meilleure spécélisation là dedans et qui vont utiliser des langages différents
on va dire et ils seront pas obligés de se mettre tous d'accord sur un langage
même si on en reparlera il y a un peu des limites aussi
ça peut aussi limiter un peu les coûts parfois parce qu'on peut aussi moduler un petit peu l'infrastructure
sur des parties qui sont plus critiques ben là on peut mettre le paquet
renondance, 3Z etc. on peut passer des meilleurs
et puis sur des parties qui sont peut-être un peu moins critiques sur l'application
avoir une infrastructure un peu plus légère et peut-être un peu moins fiable
mais sur des parties qui sont moins vitales
justement on reviendra un petit peu sur l'infrastructure tout à l'heure
sur la mise en oeuvre des microservices et du coup est-ce que c'est pour tout le monde
un micro service enfin une application en micro service
pour qui c'est et pour qui ça n'est pas
qui veut se lancer dans ce beau débat
je peux commencer pour moi c'est des entreprises
une certaine taille comme je le disais au début avec beaucoup d'équipes
et avec une grande maturité technique parce qu'on en reparlera mais
les microservices ça mène beaucoup de problématiques également
moi je comprends pas quand je fais des fois des startups avec deux devs
on est en micro service, ah ok, j'ai du mal à comprendre
donc pour moi il y a quand même, voilà il y a une vraiment une notion
d'une nombre de développeurs
sur le projet et de la maturité technique
pour résoudre les problématiques dont on va parler
pour le coup je rebondis là dessus parce que c'est vrai que je vois
on voit trop souvent quand vous êtes une startup votre but c'est de faire un MVP
vous en foutez que le truc soit escalable à un milliard d'utilisateurs
parce que vous les avez pas actuellement et si vous mettez 6 ans à construire
votre truc vous aurez cramé tout votre budget vous les aurez pas vos utilisateurs
donc faites un MVP, faites un monolithe bien sale c'est pas grave
l'idée c'est juste d'avoir des clients et quand vous aurez les moyens
quand vous allez scale c'est là que vous allez pouvoir vous poser des questions
au début c'est pas votre but, votre but c'est pas de faire du microservice
ou un truc qui va scale à l'infini, il faut arrêter avec cette connerie
je suis désolé du coup de gueule mais je le vois beaucoup
si je peux prendre un exemple c'est comme demain vous voulez fabriquer des voitures
une voiture avant vous faites un premier modèle de test
quand vous voulez construire une voiture de test
vous allez la faire chez vous dans un atelier avec un ingé qui va la fabriquer
manuellement, artisanalement
vous allez tester et si ça fonctionne vous allez construire des usines pour la fabriquer
vous ne faites pas l'inverse vous n'avez pas à perdre, vous y maluches
une marque perdait le temps à construire une usine dédiée pour sa nouvelle voiture
elle va passer 3 ans à construire l'usine
elle va sortir la nouvelle voiture et elle se rend compte au pro...
c'est super elle peut en construire 100 par semaine
par contre elle se rend compte que ça correspond à rien et que sa voiture
elle ne pourra pas être produite à grand nombre parce qu'elle ne vendra pas
et elle doit tout recommencer
c'est exactement le même cas, il ne faut pas mettre la chèvre avant les beaux
d'abord commencer avec un monolithe évolué
après vous poserez la question comme Mathieu l'a dit
il faut quand même en une certaine taille pour qu'une vraie utilité sur le micro-service
il ne vraient plus valuer et surtout pas le faire un peu à la rage
pour dire juste on a fait du micro-service
je confirme ce que tu dis et j'ai le parfait exemple
c'est ce qu'on fait
nous pour Freudgeat on a décidé de ne pas faire de micro-service
parce que Geekla peut être hébergée en micro-service
on a décidé d'utiliser le gros monolithe
sur un gros serveur qui n'est pas redondé et qui n'est pas au-de-dispos
par contre notre MVP sait on ne veut pas perdre les données des clients
donc on fait tout pour pouvoir, quoi qu'il arrive s'il y a un problème
pouvoir remonter toute l'infrastructure rapidement sans perdre les données
donc on se focalise sur ne pas perdre les données mais pas là-haut de dispose
donc pas de micro-service
et pourtant ça fait longtemps qu'on a en beta fait un an
parce qu'on est toute petite équipe comme tu disais
donc ça sert à rien d'aller vouloir le top du top alors qu'en fait on n'a pas de clients
moi je pensais à un truc
il y a des grosses sociétés par exemple qui peuvent avoir envie de mutualiser des services entre applications
des sociétés qui ont plusieurs applications
mais qui ont des services communs à toutes ces applications
plutôt que de dupliquer ce service là dans toutes les apps
elle pourrait utiliser des micro-service et mutualiser ces services là au niveau des apps
je sais pas si ça se fait
je pense que oui
est-ce que vous avez des exemples de ce type là ?
les services d'authentification généralement
je dirais, ils sont partagés au sein d'une même plateforme
par exemple
moi je pensais au service mail aussi qui pouvait être partagé entre toutes les apps par exemple
oui ou tout simplement
si on prend exemple de Google qui a quand même beaucoup de services
et sûrement beaucoup de micro-service derrière
qui doit être plutôt des big micro-service
pour le coup le service de paiement on s'imagine bien qu'ils vont pas recoder à chaque fois
c'est le même service qu'ils appellent à chaque fois sur la différente plateforme sur laquelle ils font des paiements
après du coup on parle de... bon on dit c'est pour qui
mais il faut pas oublier que ça peut aussi engendrer
je pense des problèmes en fait les archis micro-service pour le coup
c'est si on l'utilise, comme on disait pour des entreprises qui ont trop de petites
ça peut être beaucoup trop cher en fait en termes humains et en termes financiers
pour être efficace en fait par exemple il y a aussi d'autres raisons
je sais pas si vous envoyez d'autres... moins d'autres problèmes qui peuvent se créer en fait en faisant de mauvais choix
moi j'ai un bon exemple
tu veux y aller Christophe ? ok merci
très rapidement j'ai travaillé sur un projet avec quand même 60 personnes
et pour le coup c'était pas une petite entreprise c'est une très grosse entreprise française que tout le monde connait
c'était sur un projet micro-service où j'ai vite quitté le navire
c'était un échec complet parce que les gens voulaient faire du micro-service
pour faire du micro-service, découper, pour découper
il n'y avait aucune raison technique derrière et c'était mais n'importe quoi
mais n'importe quoi je veux dire c'était des gros problèmes de gestion de données
c'était un énorme système distribué, c'était un monolithe distribué comme on dit souvent
ça n'avait aucun sens mais bon c'était des grands groupes ils ont de l'argent à cramer
les 16-20 du coin vous sont contents voilà ça permet de placer 50 personnes
mais au final le projet a été un échec complet
et c'est une appli qui aurait très très bien fonctionné en monolithe
en monolithe très très très bien donc c'est pas une solution magique
c'est vraiment le monolithe ou même avoir quelques services on en parlera à la fin
c'est très bien on n'est pas obligé d'avoir 50 de découper pour découper
il faut bien réfléchir à sa donnée, il y a plein plein plein plein plein de problèmes
qu'apporte les micro-services pour moi
encore une fois tout le monde n'est pas Amazon parce que Amazon a la réputation d'avoir 150 micro-services
il ne suit pas de bêtises sur son sur son implication
voilà effectivement éviter de se comparer à ces géants là parce que
il y a plein d'entreprises qui peuvent s'en sortir sans ça
moi pas assez échelons en tout cas
c'est un peu ce que j'appelle les fait conférences quand on voit des conférences de gens chez Google
ou chez Red Hat ou whatever de moins moins Red Hat mais plus chez Google, chez Microsoft
qui vous explique leurs problématiques c'est super intéressant
mais après il faut arriver à rentrer dans la réalité de se dire
est-ce que j'ai vraiment besoin de mettre en place un truc hyper complexe ça
et ça j'ai moyen, est-ce que j'ai la force technique de le faire
pour bien que ces entreprises là sont pas comparables en fait elles sont sur des marchés très spécifiques
et ont une organisation et une manière de faire qui est très différente
mais surtout au final, ah désolé je vais finir
au final on était, non dans mon exemple on était 40 devs
et en fait on était donc 20 fonctionnels on va dire
mais en fait on était 40 devs parce que c'était une archi micro-service
on serait dans le monolithe classique on aurait été 5 devs ça aurait été suffisant
c'est-à-dire que c'est le micro-service qui tirait le besoin
ou d'inventer l'archi qui amenait qui faisait, qui était tellement complète
qu'il fallait embaucher des gens pour la maintenir et tout
enfin bref ça avait plus de sens, ça avait plus aucun sens
et c'est vraiment ça qu'il faut dire, avoir en tête c'est qu'en fait
il faut pas que ce soit en gros l'architecture qui fasse venir les gens
parce qu'on a des problèmes avec et donc on rajoute des gens etc
enfin bref il faut que ce soit l'inverse, il faut que ce soit raisonner ce qu'on fait toujours dans une entreprise
Ouais alors là de manière globale, là dans ton exemple clairement
il y avait un pour moi il y a un défaut stratégique et entrepreneur
il y a la personne qui a la vision stratégique
ou la vision entrepreneuriale elle aurait dû dire
mais attendez on peut pas faire ça, on peut pas embaucher 40 devs pour un tel truc
bref mais de manière générale c'est le besoin qui doit guider
l'applémentation technique et pas le contraire en effet
c'est pas parce qu'on veut faire du micro-service qu'on fait du micro-service
c'est parce qu'on a besoin d'en faire qu'on en fait
parce qu'on a besoin d'aller vers les conteneurs qu'on va vers les conteneurs
après je pense que par contre pour un truc peut-être un peu plus positif
parce que là on a un peu critiqué
c'est je pense très valable qu'on a une application qui a beaucoup de variabilité
parce que là effectivement ça s'y prête bien donc beaucoup de variabilité
ça veut dire quand même peut-être beaucoup de clients
mais voilà c'est souvent des applications qui vont
ce qu'on a dit ça aide à se quitter entre guillemets
à mettre à l'échelle
et du coup là dans ces cas là une forte variabilité
on va pouvoir démarrer plus facilement les micro-servistes
pour améliorer la performance
on va avoir peut-être une granularité plus fine
bref ça va aider dans ce type de cas
donc si il y a 10 utilisateurs c'est peut-être pas la peine
après maintenant quand on est un site marchand qui a pignon sur rue
là ça peut faire du sens clairement
mais d'autolibre est un monolithe
donc faut s'asquêner aussi les monolithes si bien fait
c'est bien fait ça peut se quitter loin surtout avec les performances des machines aujourd'hui
oui en fait il ne faut pas oublier que le micro-service
comme on disait au début il est là pour répondre à certains problèmes
mais si vous n'avez pas ce genre de problème a priori
vous n'avez pas vraiment de raison d'y aller
surtout si vous êtes une petite équipe
là je confirme si vous êtes une petite équipe ne faites pas de micro-service
ça ne sert à rien
vous allez en effet augmenter la tête de vos équipes de dev pour rien
Franchement avoir une équipe de 15 ops pour un world press qui est sur un cul bernet
ça me paraît pas dégonnant
en plus c'est exactement ça le pire
mais parfois c'est presque ça
je veux dire c'est vraiment
moi j'ai des exemples comme ça clairement
oui alors on pourrait faire un site statique hébergé sur s3 par exemple
bon bref
donc il y a un autre truc dans notre petite note c'est
le micro-service plus message bus
c'est un peu cryptique pour moi quelqu'un veut m'expliquer
c'est moi qui ai mis
tu peux y aller d'ailleurs je vais essayer de répondre
je vais essayer d'expliquer globalement en fait
il y a une architecture micro-service qui est pas mal utile
qui était pas mal en vogue il y a quelques années qui l'a encore
c'est de se baser sur le message bus
en fait globalement qu'est ce qu'on va se dire c'est que plutôt que mon appel
mon API par exemple
la personne elle a fait un achat
elle doit aller prévenir du coup sur mon site marchand que dans le stock il y a moins un
le service va peut-être mettre de temps à scale
où on va pas pouvoir le scale etc
on va passer en fait plutôt faire un appel HTTP sur un API reste
on va passer par un message bus dans lequel on va dire un message
on va dire nouvelle commande et ensuite elle va venir consommer
en fait ces messages
l'API plutôt qu'elle est appelée directement
ça permet de réduire la latence
ça permet aussi de scale d'une manière différente
c'est tout simplement que vous allez pouvoir avoir autant de workers
que vous voulez derrière le message bus qui va venir consommer vos messages
donc ça a ses avantages là souvent qui sont plus de féxibilité
de faire de la synchrone donc du coup vous avez moins de latence
au niveau de ce qui arrive en bout
vu que c'est traité de manière à synchrone
et pour le coup ça peut être plus simple de scale dans certains cas
mais ça rajoute un peu plus de complexité
c'est surtout une autre manière de concevoir les choses
et ça c'est... j'ai rarement vu la maturité complète là dessus
et souvent c'était un peu plus en rentrer au forceps dans des use case
où on aurait pu faire une méthode bien plus classique
je sais pas si c'est ça que t'entendais par ce message là
c'est ça ton exemple est bon et je l'étendrais parce que finalement j'ai ma commande qui exécutait
j'ai mon micro service de stock qui consomme et va décrémenter le stock
mais j'ai aussi mon micro service d'email qui va faire un email au client pour dire
on a bien reçu faute commande et votre micro service
au contact techno, le fournisseur par exemple
envoyer un message sur le lacide du fournisseur, peut dire voilà prépare la commande
bref ça permet à un seul message peut être consommé par plusieurs services également
ce qui serait compliqué à faire en synchrone bien sûr
et de façon il faut que les services communiquent de manière ou d'une autre
le message bus c'est une solution, le synchrone avec des appels HTTP s'en est une autre
mais qui a aussi ses problématiques donc il y a toujours une problématique quelque part
il y a toujours des avantages, des inconvénients avec les techniques
on en reparlera un peu après parce qu'on a une section dans notre note sur le sujet
mais voilà c'est ça l'idée c'est que tout ça après il y a de la théorie
des systèmes distribués donc comment ça fail
enfin quand ça plante il va avoir des problèmes
si je fais un message qu'est ce qui se passe bah voilà c'est à dire que je fais pas d'email à mon customer
ça comment des perdus ou pas j'ai des mécanismes de reprise
ou pas si ça plante en plein milieu c'est consommé par un service mais par un autre
qu'est ce que je fais pareil sur du synchrone
enfin bref il y a plein de problématiques ça rajoute du réseau
ça rajoute de la latence en bref c'est après ça peut vite devenir un ferme d'arri
c'est comme Kubernetes dans la théorie c'est magique dans la réalité c'est un peu plus compliqué que ça
il y a quand même deux trois problématiques il faut résoudre avant mais effectivement
comme tu disais c'est il y a plein de fonctionnaires en fait on peut étendre
il y a eu plein de théories aussi là dessus il y a eu beaucoup de théories que j'ai l'impression
de théorie crafting entre guillemets sur qu'est ce qu'on peut faire avec des architectures
un peu des fois tirés par les cheveux on va se dire
des fois on sent que dans les exemples que j'ai vu sur internet
ils avaient plus cherché à faire un use case qui fitait avec ce modèle là
que réellement on prend un use case quotidien et se dire tiens ça va pile poil au bon endroit
oui enfin je veux juste je vais faire parler mon âge et mon expérience
moi je viens je suis développeur à l'origine et j'ai travaillé chez un leader français
et qui doit être européen maintenant de logiciel de préparation de stock et de gestion de commandes entrepôts
et ce côté micro service message bus etc c'était déjà implémenté à l'époque
pas sous forme de micro service mais sous forme de démons qui tournaient sur un serveur unique
enfin je veux dire il y avait un démon qui faisait une seule chose
et on n'avait pas de message bus on avait une base de données au râcle
et il y avait des tables de demande et il y avait donc les démons qui inscrivaient leurs demandes
sur ces fameuses tables et puis d'autres démons qui n'avaient des crémontes
et donc c'est pas si récent que ça c'est ce chose là
enfin je veux dire la théorie elle existe depuis longtemps
la théorie oui après là c'est très différent parce que tu as beaucoup de choses qui sont attachées
on va te vraiment voir que l'idée est de s'entrer tout autour de ces nouvelles solutions
et par exemple pour la table de données ça demande de faire de bricolage d'air
il faut que tu prévois ta table, ça a toi de bricoler
quand je dis bricoler c'est à toi de concevoir un système
ou comme tu dis tu as une table pour préparer les commandes, tu as des statuts des commandes
ça roue à l'ennec etc
tandis que dans un message bus l'idée c'est que tu as un serveur du coup par exemple
un rabitemq ou autre qui va avoir les messages
et derrière ils vont juste venir consommer ces messages et tu vois plein de mécanismes
qui découlent de là comme disait Mathieu
tu as des mécanismes où on peut consommer les messages plusieurs fois
tu as des mécanismes où tu vas pouvoir scale en fonction du nombre de messages dans la queue
des choses que tu aurais dû implementer en fait toi même dans une base de données
donc c'est sûr c'est possible mais après ça aurait pris plus de temps
et ça aurait aussi engendré de la latence
c'est à dire une base de données
on sait tout ce qu'une base de données relationnelle
c'est pas tout ce qu'il y a de plus fun à gérer
et c'est surtout quelque chose qui est en train des problèmes de scaling
assez rapidement aussi
donc là c'est une solution différente
après c'est comme tout on n'a jamais réinventé totalement la roue
depuis le début il y a eu des monolithes qui s'appellent d'autres monolithes
sauf que là on découpe un peu plus
mais il y a toujours eu un minimum de découpe de fait entre certaines choses
faut pas penser qu'on invente en permanence non plus toutes zéro
très rapidement la donnée c'est très important
et c'est vrai que dans la théorie du microservice
chaque microservice à sa base de données
indépendante
c'est quelque chose qu'on voit beaucoup comme paterne
ça a des avantages, ça a des inconvénients
parce que forcément
il n'y a pas de transaction entre...
il n'y a pas de transaction
parce que voilà c'est entre plusieurs bases de données
donc c'est la galère par exemple on parlait des commandes et tout
mais si je supprime mon rote utilisateur
et si je supprime ces commandes et tout
il ne faut pas que je perte des messages parce que sinon je vais avoir des data
un valide
on peut avoir très vite des pertes de consistance
entre bases de données
c'est vrai qu'à l'époque
même maintenant aujourd'hui avec un monolithe
ou une base centralisée
on a des transactions et des locks
et c'est aussi très bien parfois
et donc comment est-ce qu'on met en oeuvre tout ça
comment est-ce qu'on va les apprémenter
alors c'est là où je sors notre truc merveilleux
dans mon courseur à presque tous les épisodes maintenant
c'est les fameux 12 facteurs
je crois qu'on vous en a parlé longtemps
mais si vous voulez mettre en place des microservices
qui donc vous voyez dans le cloud
il faut absolument que vos applications et que vos services
soient cohérents avec les 12 facteurs
parce que c'est des bonnes pratiques que vous pouvez mettre en place
sans aucun problème sur vos microservices
ça vous assèche et apparemment
vous êtes pas d'accord ou vous êtes d'accord ?
non c'est toujours une bonne pratique de les mettre en place
c'est vrai qu'on l'a déjà répété une paire de fois
dans les épisodes où je n'étais pas là aussi
j'avais entendu qu'on s'en aille à parler
donc je pense que tout le monde est d'accord là-dessus
c'est un fait aujourd'hui
mais pour le coup il y a aussi d'autres choses
notamment je pense qu'on pense moins
c'est l'organisation
on se dit c'est pour régler un problème d'organisation
mais si vous réglez ce problème
au niveau technique avec le microservice
il faut régler le niveau humain
il faut organiser les équipes pour qu'elles soient efficaces
et là-dessus il y a un REX
il y a quelques années maintenant que je trouvais intéressant
c'était le REX d'Expedia
ils expliquaient qu'ils étaient passés en full microservice
parce qu'ils étaient des équipes dans plusieurs pays etc
des équipes qui tenaient conséquentes
donc on s'imagine bien que ça a donné compliqué de travailler sur des monolithes
et en fait ce qu'ils étaient passés
c'est tout simplement qu'ils avaient défini
vraiment une organisation
pour travailler comme ça
et quand je dis une orgasme
ça avait aussi des choses qui étaient
un peu liées à la technique
c'est par exemple des trucs très cons
mais je lui trouvais très intéressant
c'est qu'ils se sont dit même si on est tous des équipes des pizzas team indépendantes
on veut tous utiliser la même stack techno
donc en fait ils avaient voté pour une stack techno entre eux
et une stack qui soit assez flexible
et que toutes les équipes avec tous les problèmes puissent utiliser
pourquoi ?
parce qu'en fait ils voulaient que les équipes puissent
pouvoir basculer rapidement si demain
il y a un nouveau produit
qui réclame une augmentation que quelqu'un de la team
puisse ficher dans le team pour donner un coup de main
ou autre chose tout simplement si demain vous êtes une équipe A
et parce que ça on n'en parle pas
mais niveau organisation c'est quelque chose qui peut être très vite
une horreur à gérer en microservice
dans une grosse entreprise
vous êtes l'équipe vous implementez une nouvelle feature
vous avez votre nouvelle feature dans votre application
elle est très bien par exemple la personne
elle peut votre site était très basique
et maintenant vous pouvez commander en fait plusieurs articles
en même temps
ou un an plus vous avez une nouvelle feature
vous pouvez avoir une adresse de facturation qui est différente de la réseau de livraison
de livraison
si jamais vous n'aviez pas ça avant
vous avez beau l'implémenter sur votre service
vous allez devoir gérer ça en fait avec les appels aux autres services
donc vous êtes indépendants parce que d'autres services
on doit être au courant et supporter cette modification
et pour faire ça en fait
qu'est ce que vous allez faire ? vous allez devoir organisationnellement
dire à l'autre team ouvrir un ticket
lui dire bah il aurait besoin de cette implementation etc
sachant qu'elle même à son propre backlog
son propre cycle de vie
une organisation comme celle qu'ils avaient fait Expedia
ce qui était intéressant
c'est qu'en fait vu qu'ils étaient tous sur la même stack technique
ils n'avaient pas à faire de ticket
ou quelque chose comme ça qui galeraient de traiter
ou ça à partir je pense qu'on a tous connu en guerre entre product towner
de différentes équipes
ou il va dire hey priorise moi ça parce que j'en ai besoin pour telle feature etc
là vous allez pouvoir dire que enfin une margerie cohesque
qui va être acceptée beaucoup plus facilement
donc c'est ça que je pense en orgasme
c'est alors une vraie cohérence
et une vraie homogénéité là dessus
l'idée c'est pas de faire quelque chose
en se disant c'est la technique
y'a pas du tout d'organisation à gérer
tout va se faire magiquement
on va commander des pizzas chez domino's pizza au pizzahead
pour citer encore une fois une sollicité américaine histoire de changer
et on va commander des pizzas
on va voir comment les gens se réunissent autour de la table
on va dire cool bah vous allez gagner des microservice
c'est pas comme ça y'a un vrai côté organisationnel à penser
et je pense qu'aujourd'hui
sur une grande entreprise on peut faire des choses super intelligentes
et super efficaces
en fait c'est vrai qu'après le microservice
y'a une défense
c'est effectivement de pouvoir mixer les technologies
de database on a dit une database
par microservice mais du coup on peut
faire des choses assez
enfin si ça a du sens on peut faire du
SQL à des endroits enfin du transactionnel
d'hier dbms
et de notre côté
d'une SQL etc on peut aussi
mixer les langages
ça c'est super cool mais il y a aussi
ça amène son lot de complexité aussi
et du coup
attention à ce travers là
parce que ça finit
à la fin il peut avoir aussi un problème de compétences
et ça c'est ce que disait Damir
très justement
si c'est trop spécifique
les gens peuvent forcément basculer
d'une équipe à l'autre ça entraîne des problèmes
du coup plutôt organisationnel
RH
ou de compétences
assez dramatiques je pense
du coup si
on veut rester dans l'organisation
et comment est-ce qu'on met en oeuvre
les microservices est-ce qu'on ne parlera pas
justement de la gestion des depogites
pour gérer nos fameux
microservices j'imagine on ne va pas tout mètre
dans un seul depogite ou alors si on met tout
dans un depogite il faut peut-être faire
des répertoires qui veulent nous parler
de ça qui a des expériences là-dessus
ça encore une fois je vais
reparler rapidement à-dessus
ça dépend vraiment des équipes ça dépend
d'une autre chose je pense qu'il est important
quand on fait une migration comme ça
entre guillemets qu'on passe du monolithe
au microservice ou au niveau opérationnel
des techniques c'est comme g c'est
d'inclure tout le monde dans la démarche et de voir
ce que les équipes préfèrent en fait
parce que si vous commencez à forcer des modèles
qui ne sont peut-être pas adaptés à l'entreprise
ou que les gens du terrain ont plein de problèmes
avec ça n'a pas fonctionné
ça vous de voir après personnellement j'ai une préférence
pour découper ça en répertoires
avoir un repo par équipe
après il y a des autres structures qui peuvent se défendre
ça dépend du cas ça dépend des techniques
qui vont être dessus
ça dépend beaucoup de choses à mon sens
moi je serai aussi partisan du 1dp par service
pour plusieurs raisons la première
c'est que déjà ça permet de
séparer les droits
et donc comme ça on a
des droits différents en fonction des dépôts
donc on va on va dire
telle équipe elle a tel droit sur tel dépôt etc
mais surtout comme on est dans un cycle micro service
les cycles de vie des applications
ne sont pas les mêmes
et en fonction de l'implémentation qu'on va choisir
et dont on para peut-être après
eh ben on va pouvoir
si on fait du GitOps
aller chercher ce dépôt là plutôt que celui-là etc
alors que si tout est dans même dépôt
on va potentiellement tout récupérer
et donc pourquoi je préfère séparer les choses
et comme on est
de toute façon dans des grosses sociétés
avec plein de pizzas à team
on peut se permettre de gérer plusieurs dépôts
pour moi c'est une question d'outillage
plusieurs dépôts ou un seul dépôt
c'est vraiment une question de
j'ai plein de services
je ne fais pas 10, 50, 100 etc
il faut monter les dépendances
régulièrement
de manière automatique si possible
pour éviter les failles
les images de base de mes conteneurs etc
il faut pas oublier un service
ça fait que celui-là je ne l'ai pas mis à jour depuis 2 ans
parce qu'il tourne et puis on l'a oublié entre guillemets
bref pour moi c'est vraiment comment je gère
mes dépendances même entre librairies
ce qu'on va avoir des librairies communes
généralement entre services on peut parler de socles communs
mais c'est un peu ça aussi
parce que plusieurs services peuvent utiliser un socle commun
de librairies pour interagir
avec le SI ou même entre services
voilà on parle des messages muscels
mais forcément des libes pour communiquer
il faut monter à jour tout ça etc
il ne faut pas que des services se retrouvent derrière
et ça c'est vraiment de l'outillage
des botes pour faire les PR
pour mettre à jour
bref il faut des choses il faut vraiment réfléchir
à l'outillage je pense que c'est le plus important
après la manière de faire ça va dépendre des entreprises
comme disait Damir pour moi
mettre à raison d'insister soit la sécurité
c'est que c'est beaucoup plus complexe de gérer la sécurité
quand il y a plein d'équipes qui gèrent plein de projets
dans tous les côtés et dont on en parlait tout à l'heure
je suis plus t'aiguille qui en parlait mais des cycles de vie différents
il y a peut-être des programmes qui vont quasiment pas bouger de l'année
d'autres qui vont bouger tous les jours
c'est pas pour ça qu'il faut pas les mettre à jour et on a très vite fait de mettre un micro service de côté
donc comme Zetre est très chiant en matière
il y a beaucoup d'outils aujourd'hui notamment avec l'avènement du conteneur
il y a eu beaucoup la mode
des tests statiques etc
notamment des dépendances
après il faut pas aussi faire des pen tests
réguliers
voire du bug bounty
on en a déjà parlé
pour le coup c'est des choses il faut pas c'était à faire
et il faut alors l'épisode précédent
pour ceux qui n'ont pas écouté je vous invite à l'écouter
je parlais de la théorie capitaliste appliquée à Qbernet
là je vais appliquer la théorie du ruissellement
de la sécurité
du coup à l'informatique
donc il faut vraiment que la sécurité en fait ruisselle du top
en fait de la gestion
vers les différentes équipes en fait pour expliquer
pour avoir un vrai contrôle
et une vraie vérification de sécurité
dans toutes les équipes et pas juste centraliser
sur des parties d'applications
qui vont spécialement évoluer
alors je reprends la parole
Samuel parce que tu parles de l'épisode précédent
mais je connais le planning
de publication donc l'épisode dont tu parles
c'est ActuDevops d'octobre 2021
qui est quand même sorti il y a plusieurs mois
parce que même si on enregistre ces deux épisodes
à la suite
le RadioDevops que vous êtes en train d'écouter
sort plusieurs mois après ActuDevops
My bad
Ce n'est pas grave
et donc du coup
oui en effet l'outillage est super important
j'ai développé il y a pas très longtemps
pour une grosse société en effet
un socle
de pipeline de CICD
pour GeekLab
qui vont utiliser
je l'espère je croise les doigts dans beaucoup de leurs projets
et notamment on a standardisé
les pipelines
et maintenant ils vont devoir maintenir tout ça
et les utiliser dans tous leurs projets
et on a développé
tout ce qui est scan de sécurité etc
build of computer
et autres petites choses donc c'est super important
en effet de faire
ce genre de choses
et tant que j'ai encore la parole je vais parler
des bonnes pratiques de développement
si vous avez des micro services
et donc des équipes de développement
différentes
il est bon aussi de penser
à quel est le flux de développement adapté
à votre service
parce que vous ne pourrez pas
souffre cas exceptionnels
mais avoir le même flux de développement
surtout vos microservices pour toutes vos équipes
ça ne va pas marcher je pense
donc c'est à chaque équipe de choisir
son bon flux de développement
et ses bonnes pratiques de développement
mais ça ne vous empêche pas
de penser
à des pratiques de code
ou autres qui sont partagées à toute l'entreprise évidemment
sur ça pour moi c'est vraiment aussi
les pratiques de devs c'est une chose
le flux de devs aussi mais c'est aussi
ce qu'on va avoir en fait on va beaucoup travailler
avec les services des autres équipes donc
il y a vraiment une notion
comme je vous disais avant de contrat entre équipes
dans le sens où il faut que
on va se retrouver avec une matrice de compatibilité entre services
si quelqu'un fait un breaking change dans la chaîne
il faut que tous les services qui consomment
ce service
soient également changés donc on évite
c'est vraiment ça la complexité
organisationnelle et même en flux de devs
c'est à dire si quelqu'un pète un truc
ou on fait
un breaking change dans un service
comment on fait pour que les autres
teams qui interagissent avec ce service
sortent
un service compatible
dans les temps et pas qu'on met en pro
d'un truc qui n'est pas compatible avec le reste
parce que voilà comme je le dis
c'est une matrice de compatibilité entre services généralement
et donc il faut faire vraiment
faire évoluer ces contrats ce qui n'est pas facile
parfois
pour ça il y a des solutions
moi je l'ai vu chez un de mes clients
il y a quelques années
on avait 2 devs
chacun travaillait sur une partie du code
l'un pour la pays et l'autre pour le front
ça ressemble au micro service
parce que du coup il y en a qui consomment la pays
qui est fourni l'autre
et pour travailler
parce qu'ils travaillent en parallèle ils sont mis d'accord
sur les spécifications
il y en a un des deux
qui a fourni des bouchons
des
exemples en fait de réponses d'API
ce qui fait qu'il y en a qui pouvait développer
dans son coin
avec les exemples de réponse
API et l'autre qui pouvait développer
quelque chose qui fournissait ces réponses
API là et à la fin ils sont tous retrouvés
sur
le commun comme tu dis en effet
le contrat qui du coup était
des bouts de code
et ça comme je dis ça peut être réglucine mais organisationnel
sur le point d'exemple d'expedia du coup ils faisaient une mergécoise
donc c'était l'équipe qui pouvait gérer
en fait ça dans différentes équipes
pour mettre à jour un peu partout ce qui était nécessaire
car en plein de manière de gérer
à différents niveaux
du coup on a parlé
de pentest et de sécurité
et évidemment quand on parle de pentest et de sécurité
on ne peut pas
ne pas aborder l'intégration continue
et dire que si on veut passer
au microservice il faut absolument qu'on ait
des tests
de l'intégration continue
du déploiement continue aussi
parce qu'on va gérer les cycles de vie de nos services
et donc il faut une certaine maturité
avec les outils de déploiement
ou d'intégration continue
pour ça d'ailleurs si je me rappelle bien on a fait un épisode
de Radio DevOps sur l'intégration continue
donc je vous mets le lien en description
de l'épisode
mais du coup en parlant
d'intégration continue
c'est aussi pour une simple question
de coup c'est que si jamais vous avez
votre monolithe c'est pas ultra grave
si vous le faites à la main et si vous le déploiez à la main
parce que ça reste déploier un monolithe
vous déploiez une application par exemple
si vous faites du microservice et que vous avez
sans équipe dans la semaine qui déploient un microservice
là humainement ça devient un peu compliqué
de justifier de le faire à la main donc c'est là aussi
où avoir une vraie maturité
une vraie forge avec un vrai système de CICD
est important parce que si vous avez pas ça
en fait votre approche
microservice va se planter parce que le coup humain
va exploser et vous avez des coups de maintence horrible
en fait ça rejoint tout à fait ce que tu disais
justement c'est à dire que
pour pouvoir entrer là dedans faut quand même avoir une
usine qui marche bien
et ça reprend
les bonnes pratiques que tu veux on connaît
dans le DevOps
c'est ça, c'est clairement il faut prévoir votre usine
et faut construire votre usine
en fait dans l'idéal faut penser
construire votre usine avant de commencer vraiment
à l'utiliser auquel cas sinon vous allez perdre beaucoup de temps
à des choses manuelles ou d'autres choses
c'est ce que j'allais dire il faut une culture
de DevOps dans l'entreprise parce que
vous pourrez pas passer au microservice si vous avez pas
une bonne culture DevOps dans votre entreprise
parce que vos apps
qui vont gérer l'infrastructure
vous ne laissera pas déployer
sans microservice tous les jours
tout le temps, toutes les heures ça c'est pas possible
ou alors
il faut partager automatiser etc
donc commencer par diffuser la culture DevOps
automatiser les déploiements
mettre en place les tests
aller faire de l'intégration continue puis
du déploiement continue
puis peut-être que vous pourrez penser
à faire du microservice
pour le moment on voit qu'on tire un peu la ficelle
mais en fait ce qu'il y a c'est qu'on a des microservices
on comprend qu'il faut du CICD
il va falloir l'esquer du lait
il va falloir une solution comme Kubernetes
qui est peut-être pas la plus simple du monde
et du coup il faut aussi
en termes de ressources humaines
des personnes pour gérer ça
justement
t'as lâché le mot peut-être qu'on pourrait parler d'architecture
parce que des microservices
ça sert à architecture que ce soit
en termes de logiciels ou d'infrastructure
Mathieu tu voulais nous dire un petit mot là-dessus
on en a déjà parlé
on parlait au début du message bus
versus communication synchrone etc
c'est des choses à avoir en tête
c'est un système distribué
ça apporte plein de problématiques
c'est vraiment une façon particulière de travailler
et il faut des gens capable de monter
ce genre de système
il faut avoir une certaine expérience
selon moi
donc que ce soit au niveau de logiciels
Damir parlait tout à l'heure de soccer commun
ou pas mais sur le choix des langages
sur comment construire les contrats entre services
les formats
ce que je fais du jizon, du proto-buff
comment je spécifie mes services
tout ça
et au niveau infra
René mentionné Kubernetes
comment je fais communiquer mes services
services mesh
tout ce qui vient avec
comme vous l'avez dit c'est les bonnes pratiques
de dev et d'ops
de manière générale qu'il faut implémenter
mais à l'extrême
il faut vraiment que ça tourne bien
donc
et alors
est-ce qu'on peut faire du micro service
sans Kubernetes
on a justement fait un épisode de radio de DevOps
sur Kubernetes je vous renvoie à cet épisode-là
mais est-ce qu'on peut
sans sortir
sans conteneur à votre avis
sans même parler de Kubernetes, sans conteneur
sans conteneur oui, sans Kubernetes aussi
après aujourd'hui on peut faire
vraiment quelque chose de moderne aussi
avec des VM on peut build automatiquement
avec du packer, des choses comme ça
faire du réalis automatique ça a changé peut-être un peu
le modèle de gestion mais c'est tout à fait possible
après c'est sûr qu'on aura peut-être
les CFP dans les conférences
passeront moins bien quand on expliquera
qu'on a tout fait sur de la VM
ça c'est sûr mais pour le reste c'est tout à fait techniquement possible
pour le coup de le faire
ouais mais je me fais l'avocat du diable
mais là tu parles plutôt de service
que de micro service de petits trucs
minuscules tu prends des micro VM
si je veux
sur les mots je pourrais dire ça
après le vrai
la vraie chose aujourd'hui qu'apporte Kubernetes
même si c'est pas le produit que je préfère
au monde faut quand même l'avouer
c'est qu'aujourd'hui tu veux faire une infrastructure
micro service avec derrière
du github, des choses comme ça
souvent tu as plein de produits
qui sont bien documentés, bien connus
qui marchent globalement bien
je ne dis pas que c'est des choses les plus propres
qui sont parfaites mais c'est aujourd'hui la solution
pas clé en main mais en tout cas c'est un peu plus guidé
c'est toujours pas la solution par défaut
parce que tu n'auras jamais vraiment tort ça fonctionnera
et c'est pas Netflix
c'est une époque qui faisait de la VM comme ça
il buildait avec un outil comme ça
il s'est installé leurs apps avec du RPM
et hop, on s'est ça dans un groupe d'auto scaling
et puis ouais
et finalement c'était...
bah y'en a plein qui font ça mais ça marche en fait
et oui ça marche super bien
c'est juste que après en fait les gens
des fiscues bernettes parce qu'il y a plein de choses qui sont
y'a la RAID mais aussi plein de choses qui
y'a plein de choses qui existent dessus
aujourd'hui tu cherches un outil, tu fais un déploiement et tout
bah tu as un truc comme Argo
ils sont totalement liés à cube donc tu te dis
oh bah je fais un cube que ça je mets un Argo
c'est bon, c'est fait aussi
tu mets du Prom et Téus avec du Grafana
avec un opérateur cube
ça passe très bien aussi et tu vas le gérer facilement
c'est toujours... entre guillemets
tu as vraiment beaucoup de solutions qui sont orientées
cubes aujourd'hui donc bah forcément
il y a entre guillemets le marché
à demander du cube
le marché a développé des solutions pour cubes
donc pendant les gens prennent du cube
oui alors
je suis assez d'accord avec ça
néanmoins
récemment il y a les rapports
donc il y a le rapport Dora qui est sorti
sur le DevOps en 2021 dont j'en ai fait une vidéo
justement et on s'aperçoit
qu'il y a une correlation
entre la vélocité
des équipes
qui déploie le plus vite
qui déploie le plus fréquemment
etc et le fait qu'ils utilisent
Kubernetes et des orchestrateurs
de conteneurs ou des conteneurs
c'est à dire qu'en fait les équipes les moins avancées
celles qui déploient le moins vite
et moins souvent
elles n'utilisent pas
des conteneurs je dis pas que
il y a un lien
je dis juste que c'est un constat que les équipes
les plus rapides et celles qui déploient le plus souvent
utilisent des conteneurs
est-ce que le lien c'est pas plutôt que les équipes
qui ont le plus de maturité sont souvent
sur du Kubernetes proportionnellement
et les autres équipes sur des infralégacies
c'est peut-être ça aussi
c'est exactement ce que je viens de dire en fait
ouais donc je pense que c'est vraiment ça
pour le coup le vrai truc
je sais pas si
il y a un truc là dessus
mais bon en tout cas c'est un constat qu'on peut faire
et bah du coup
si on veut implémenter
et mettre en oeuvre les microservices
qui dit microservice, dit service de partout
dit log de partout
dit vous pourrez pas vous en sortir
sans centraliser vos logs
donc il faut dans votre infrastructure
penser à centraliser vos logs
il y a plein d'outils qui existent
on a parlé de Grafana Prometerus
donc si vous utilisez la stack Grafana Prometerus
vous pouvez utiliser Loki
qui permettra de centraliser vos logs
sur Grafana
vous pouvez utiliser d'autres services
et parce que ça vous évitera justement
d'aller gratter ce que je faisais il y a plusieurs années
vous connectez sur un serveur
allez voir telle log de la telle machin
et puis c'est pas là donc allez sur
bref vous garderez du temps
la centralisation juste si je peux acheter un petit point
c'est aussi une question de sécurité
c'est qu'en fait si jamais demain vous avez une machine qui est corrompu
en fait la personne elle a accès à votre machine
elle peut très bien effacer les logs locales
et marquer qu'il ne sait rien passer
en fait qui soit centralisé les logs ça vous permet aussi
de pouvoir faire l'analyse d'incidents
étant sûr que les logs bah ils ont pas transité
spécialement sur la machine au repos entre guillemets
et ça vous permettra aussi par exemple
de déclencher des alertes en cas par exemple
d'actions étranges
exactement et dans une philosophie
d'evox vous pourrez partager
les logs avec les développeurs
sans forcément qu'ils aient accès à la machine
en SSH par exemple
c'est une bonne chose
et si vous voulez corréler, puisque tu viens de parler de corrélation
il vous faut une supervision
et un monitoring
ça vous pourrez pas vous en passer
si vous centralisez les logs vous avez déjà votre monitoring
et vous pourrez justement avec
si vous utilisez Grafana, Loki et etc
dans la même interface
vous pourrez corréler les choses en plus
c'est vraiment super bien je trouve
et je dirais aussi une chose
je t'ai essayé de lire les
ok d'accord non non
je voulais juste dire que pour moi
c'est indispensable parce que à l'échelle
enfin si on parle justement
de microservice
on en a risque d'en avoir beaucoup
sans centralisation
c'est juste un problème
enfin le moins de trouble shooting
va devenir un truc
complètement délirant donc c'est absolument indispensable
pour ce que disait Christophe
faire les corrélations et trouver
où il y a les problèmes
par contre c'est aussi ce qu'on disait
c'est qu'on vient de tirer la ficelle
et il y a des trucs qui viennent
ça veut dire aussi qu'il faut une stack
Prometheus Grafana, VLK
n'apporte la solution
mais ça c'est un con en plus
c'est une décompetence en plus
et là pour le coup ça c'est vraiment
enfin ça va être difficile d'y couper
c'est pour ça que Mathieu disait
que le microservice ça coûte cher
en termes de développeurs mais du coup
ça coûte cher aussi en termes d'ops du fait
c'est ça et parce qu'il faut
des ops pour héberger tout ça
des ops ou des services cloud
qui coûtent aussi à un certain prix
et moi je dis en fait au genre si vous avez déjà pas
de centralisation de log et de supervision
faites déjà pas de microservice je veux dire
commencer par la base sinon vous allez dans le mur
et je dirais même que les microservices
apportent des nouvelles pratiques de monitoring
on parle beaucoup de
observabilité, de tracing maintenant
même de traces, pas forcément
de log et métrique parce que vos
messages entre microservice vont se balader
de services en service, il faut pouvoir les suivre
et c'est à ça que c'est le tracing
mesurer la latence entre les services
pour avoir un ID
de traces on va dire pour que le message soit suivi
entre services et voire vraiment
dans quelle ordre s'exippiter etc etc
et c'est tout un outillage
nouveau
enfin nouveau qui est en train de se
standardiser avec des choses comme open tracing
des outils, voilà il y a plusieurs outils
de tracing et c'est des nouvelles pratiques
il faut commencer déjà par la base
avant de se lancer là dedans
clairement mais je rajoute un petit truc
là dessus parce que je vois ça souvent
le tout n'étant pas de récolter justes et métriques
parce que c'est très facile avec Prometerus
de récolter des millions et des millions de métriques
c'est de savoir un peu les exploiter parce que si c'est pour sûr
on a fait un grave graphana
on a mis 300 métriques mais on ne sait pas
vraiment à quoi ça correspond
ou ça se trouve c'est pété mais bon le graph est joli
c'est ça qui est plus compliqué
je dirais aujourd'hui c'est pas temps de mettre en place
tout ça parce que du Prometerus tout ça c'est logique
assez simple au final qu'on y réfléchit
le plus dur pour moi c'est vraiment aujourd'hui
de savoir interpréter tout ça
et en tirer une information intéressante
en application elle marche ou pas
parce qu'on récolte de plus en plus
sans forcement se poser cette question
je vous dirais un petit truc
un peu là on va revenir
deux grands sourds bien terrataires
jusqu'à même avoir des paternes de log
qui sont les mêmes pour un peu tous les micro services
c'est un truc vraiment de base
mais voilà il faut réfléchir un petit peu sinon
ça devient un peu la foire dans les logs
standardiser toutes les approches
d'arraison, toutes les approches communes
que ce soit sur les logs
ou sur les manières d'implementer sur des outils
ça peut quand même être bien
par exemple truc tout con
mais si jamais la force CSID est commune
à toutes les équipes
que tout le monde nomme par exemple
les jobs ou les workers d'une manière standardisée
pour s'y retrouver et pas être un jour en mode
ah du coup il a acquis ce projet là etc
tu lits dans mes pensées
c'est merveilleux
dans ce type d'organisation
les grosses organisations
on a souvent même des gens spécialisés dans ça
c'est à dire dans les grands groupes
des grands groupes tech du moins
on a l'équipe alerting par exemple
on va avoir
ou alors l'équipe
stream processing etc qui fait en sorte
que tout soit standardisé
sur ces sujets et donc c'est pas du micro-service
mais quelque part c'est du
côté ops aussi on va dire on découpe
en équipe de cette manière c'est pas quelque chose qui se fait que côté DEV
en fait comme beaucoup de choses faut trouver aussi un équilibre entre
l'indépendance de chaque équipe
pour qu'elles utilisent les meilleurs outils pour eux
mais aussi une certaine rationalisation
pour éviter de partir
dans la stack
pokémon on va tous les attraper
parce que à la fin ça devient un truc de dingue
bon ben justement
puisqu'on parle de pokémon et de tous les attraper
on peut peut-être parler des problèmes qu'on
pourrait avoir si on passe au micro-service
quel genre de choses
parce que j'ai vu la section popé
du coup je me dis donc à faire on va en parler
quel genre de problème
on peut avoir avec des micro-services
alors là je vois plein de trucs
qui s'est ajouté je sais pas qui m'avait ajouté
mais je vous laisse la parole
c'est moi qui ai ajouté un petit peu en live
mais en fait c'est des choses qui ont été abordées
en gros
en gros ce parti par Mathieu en fait
il en a déjà
dit pas mal
notamment
le premier point
un petit peu délicat c'est que
ces micro-services ils parlent tous à travers le réseau
et qui dit réseau dit potentiel panne
du moins plus de panne
que si on parle
sur une machine unique
à travers la mémoire
voilà
justement
si tu avant de parler
c'est un point suivant
c'est intéressant
justement
si tu as besoin
de parler à un service
mais qui n'a pas d'interface réseau
et que tu ne peux lui parler que
au travers d'un socket unix
du coup tu peux pas faire le micro-service
avec ces trucs là
en fait si tu as des solutions
qui ne exposent pas du réseau
tu peux pas les mettre dans des micro-services
ça c'est un autre des problèmes
oui je pense que
tu peux toujours faire du polling
comme à l'ancienne
quand tu parlais de base de données qui était polée régulièrement
avec une table de jobs
après on est en train de se répartifier
sur le réseau je parlais aussi d'authentification
je pense comme ça
TLS
authentication même des services faut pas que
une fois qu'on est dans le réseau c'est la fête
tous les services il n'y a plus d'authentes
il n'y a plus de TLS
dans l'idée il faut que la connexion entre chaque service
soit chiffrée, soit authentifiée
et soit logée
pour pouvoir tracer les attaques
pour garantir que
ne puisse pas être espionné et garantir que c'est bien légitime l'accès
donc dans l'idéal
il faut respecter ces trois facteurs sur chaque application
dans la réalité, malheureusement
c'est pas le cas, on va pas se mentir
j'ai jamais vu une infrastructure vraiment micro-service
avec beaucoup de micro-service
ou ça c'était respecté partout
il y a toujours des exceptions
c'est dans la backlog
en fait c'est une question de coût aussi
de retour sur investissement
c'est qu'on a l'idéal
sauf que pour atteindre l'idéal
le coût va être trop élevé par rapport
au retour sur investissement que tu peux avoir
en tant qu'entrepreneur ou en tant que boîte
il y a ça aussi
qu'il faut garder en tête
parce que ce truc là
il nous sort peut-être de la tête
régulièrement mais il y a un côté business
aussi dans ce qu'on fait
je pense qu'il y a un côté humain
qui fait que nous on veut toujours faire le meilleur
et en fait je sais pas si on serait un jour satisfait
on aurait été et pour moi je vois
vraiment les bonnes pratiques et tout
je sais qu'on a déjà un miroir déformant
on attend savoir des beaux clients
en tout cas dans mon métier je sens avoir plutôt
des beaux clients qui ont quand même envie de faire des choses bien
je sais que la réalité est beaucoup moins joyeuse
souvent et je me dis aussi
qu'on voudrait avoir un truc
parfait qui soit tip top, qui est zéro souci
tout soit bien pensé etc
mais on sait que c'est pas vrai
pour beaucoup de boîtes c'est pas vrai non plus
le but pour moi c'est vraiment de faire
une exponentie à des essais en rapprocher le plus possible
en sachant que plus on veut s'en rapprocher
plus à la fin ça devient dur
aussi bien en termes de coût qu'en termes
de moyens de l'entreprise
mais c'est surtout qu'est ce qui est parfait
parce qu'au final aujourd'hui
il y a aussi un problème, là on va partir en HS
mais très rapidement
aujourd'hui
R.Cruteur Lambda reçoit un CV
où le premier CV c'est ouais j'ai fait du micro service
sur du cube machin super complexe et tout
ça a peut-être coûté 50 millions de euros
le projet mais j'ai fait des trucs super cool
et l'autre qui dit je fais un projet
un peu équivalent mais on était juste
de dev sur des vème classiques
et ça marchait très bien et par contre ça coûtait que dalle
et ben le profil qui va être intéressant
pour le R.Cruteur au niveau des compétences
ça va être le premier donc il y a aussi ça
dans le métier c'est qu'aujourd'hui pour se vendre
il faut pousser de la techno etc
mais c'est une autre question mais voilà
quelque part du micro service c'est en lien
en parler des conférences tout de tout à l'heure
on le voit parfois aussi des
architectures apparaître pour construire le CV
mais ça c'est la question des besoirs
ça revient tout le temps
je vous propose qu'on ne passe pas
en sujet surtout que ça dépend des recruteurs
et que le prochain épisode de Radio DevOps
est sur ce sujet donc
concentrons-nous sur les problèmes
qu'on peut avoir en micro service
j'ai coupé René tout à l'heure
René tu veux reprendre ?
je peux continuer la liste un petit peu
je finis juste sur le réseau
je continue sur le réseau mais je vous laisserai
sur le réseau donc bien oubli on a dit
qu'il faut forcément, c'est pas forcément fiable
il faut des retry par exemple
il faut je parlais un moment des fusils
pour en cas de défaillance
d'un des services
avoir une contre mesure
tout ça c'est des nouvelles choses à mettre en place
l'autre aspect c'est la
synchronisation alors moi j'appelle ça synchronisation
c'est ce que ce nom m'a tué parler
c'est que le cas typique c'est
souvent on entend parler parfois du pattern saga
c'est donc
l'exemple classique c'est un site de
réservation de voyage
où on commande l'avion
l'hôtel et la voiture de location
et du coup on voit plein de problèmes
de synchronisation qui vont apparaître
si par exemple lors de cette commande là
donc chaque item là c'est un micro service
si au moment où on réserve la
voiture de location il y a
un souci il faut faire le rollback
de 2 transactions d'avant entre guillemets
sur les autres micro services
donc ça amène un certain nombre
de problématiques de synchronisation dans les applications
qui sont moins d'être très bien
donc voilà ça c'est
des choses qu'on voit apparaître
assez vite qui ont fait du micro service
je sais pas si vous voulez rajouter des choses
par rapport à ça
sinon je poursuis
tu peux poursuivre je pense
voilà après il y a le découpage
alors ça c'est aussi super rigolo
parce que faire des micro services
comment est-ce qu'on les découpe
juste en soi c'est mon expérience
à moi c'est que c'est déjà un challenge
parce que j'avais
vu une conférence il y a assez longtemps
où les personnes disaient faut faire les micro services
les plus petits possible
ouais pourquoi pas
mais c'est pas si évident que ça
et puis c'est d'autant moins évident
je pense qu'on parle
sur une application
qu'on ne connait pas
c'est plus facile de découper quelque chose qui existe
déjà je pense que partir sur quelque chose
de complet
quand on part sur une application et qu'on développe au fur et à mesure
cette problématique
de comment on découpe et devient
quand même pas évidente
et voilà
et puis après on en a parlé aussi
c'est les contrats d'interface
c'est quand même un des problèmes
de génie logiciel
les plus
triquille entre guillemets
et enfin
voilà se mettre d'accord pour un contrat
d'ertre face alors quand on est deux ça se passe bien
mais quand il commence à avoir
ce qu'en ces deux entités différentes c'est pas si évident que ça
et sachant que c'est quand même
une des raisons pour lesquelles
enfin c'est de bug
les plus courantes
bon je vais passer sur l'aspect
aussi quand on commence à partager
des choses et ce qu'on partage des taux
etc je vais pas rentrer trop dans le détail
mais ça apporte aussi
un certain nombre de complexité à ce niveau-là
voilà ben je crois que j'ai fait un peu le tour
de ce que je voulais dire
c'est que c'est pas tout
tout
voilà c'est pas une, c'est une architecture
qui apporte pas mal de bénéfices
mais enfin comme l'adimature encore une fois
il y a tout n'est pas parfait
il y a des pours et des contre
et il faut bien mesurer
quand on l'utilise
si je peux rebondir juste sur un point c'est le découpage
espère pas tout découper d'un coup
faut y prendre
partie par partie vous découpez petit à petit
parce que comme un gâteau vous ne fenez pas
avec trois couteaux et vous s'est d'enfoncer
trois couteaux en même temps vous découpez une part
c'est pareil pour une application
il y avait un bon tour que du coup
de loup de tech sur Twitter
qui avait fait OSF pot
mais elle n'a pas été filmée je crois
donc du coup au meet-up symphonie
à Paris ça n'a pas été filmé malheureusement
mais globalement c'est ce qu'il faut retenir
faut pas essayer de tout découper en même temps
parce que c'est aller droit dans le mur
faut pas découper pour découper
pour juste pour avoir plein de services
moi j'ai eu le cas, moi j'étais dans une équipe
à l'époque on avait un service
le manager au dessus a forcé le découpage
tout le monde était contre
ok on a fait de la merde
parce qu'il voulait faire du micro service
il était dans le dogme
enfin bref aucun sens
les fameux managers qui donnent des habités
enfin ouais, managers ou archi
tu sais, les cortes, y marchis
moi ça m'a toujours bien soulé en entreprise
c'est les spèces dans leur tour d'hivoire
enfin bref j'ai arrêté de rager mais vous voyez l'idée
c'est le bureau
au fond d'openspice c'est un bureau d'archi
tu sais pas trop ce qu'ils font mais ils vont te dire
comment bosser
je te rassure eux même ne savent pas ce qu'ils font
on trollera peut-être sur les archis une autre fois
et comme le monde n'est pas binaire
et qu'il n'y a pas les monolithes
d'à côté et les micro services de l'autre
j'imagine qu'il y a une infinité de solutions
entre les deux
peut-être qu'on pourrait parler de ça
pour finir cet épisode
dire que c'est pas parce que
vous ne pouvez pas tout de suite passer au micro service
que vous pouvez forcément garder votre monolithe
il y a peut-être d'autres alternatives
je crois que j'ai déjà parlé justement
de cette conférence
sur le monolithe micro service ready
c'est à dire penser votre monolithe
comme si plus tard
vous alliez aller dans un micro service
et donc l'idée c'est de pouvoir
vous avez votre monolithe
et il a des fonctions à l'intérieur qui sont différentes
et vous pouvez le lancer
pour avoir un service différent
c'est la même base de code
c'est le même truc mais vous pouvez le lancer
avec des commandes différentes
et il va vous fournir des services différents
c'est en gros
le monolithe micro service ready
et moi j'aimerais dire
un truc que je conseille au start up
qui commence et qui font appel souvent
à mes services c'est
si vous voulez implémenter
un truc que vous savez pas faire
commencer par utiliser un service
externe ou un SAS d'abord
qui est fait pas partie du coup
sur les parties qu'il faut pas partie
de votre carnet métier
ça vous permet d'aller plus vite
d'avoir des services externes
qui sont pas des micro services mais qui sont des services
et de réduire votre base de code
et ça pour moi c'est une voie entre les deux
pour réduire la taille
de notre monolithe
sans forcément faire du micro service
mais en consommant des services externes
qu'est ce que vous en pensez
question un peu des tournesques
c'est pas du micro service en soi ou toi-même
tu n'éberges qu'un service
je voulais pas le dire
je voulais pas le dire
c'est du...
c'est à des débuts de micro service
c'est à dire que tu as des services externes
qui sont hébergés partout
micro service à de services
c'est une solution c'est sûr
c'est toujours bien du service
externe si c'est pas du coeur de métier
et que le coup est raisonnable
et après moi ce que je voulais dire également
c'est
il n'y a pas le monolithe un monolithe
et de l'autre côté de la pièce
300 micro service il y a un monde entre
les gens peuvent très bien avoir
une architecture orientée service
avec 2, 3, 4 micro services
moi c'est ce que je conseille à tout le monde
pour la majorité d'entreprises c'est l'archi qu'il faut
pour moi c'est quelques services, vient des coupés
pas du micro service
moi je suis pas ça de micro service
mais quelques services d'air, une API à get way généralement
ça permet déjà de travailler en équipe
avec plusieurs équipements parallèles
d'avoir un peu de scaling indépendant etc
et après pour le reste on voit au fur et à mesure
je pense c'est encore une fois c'est une question d'équilibre
faut éviter les extrêmes
essayer de trouver le bon ratio
et le faire surtout quand ça fait du sens
en fait
pas agir par dogme
comme le disait Mathieu
dans tous les cas quand on commence à agir
comme ça ça peut pas signer vraiment bien
en fait cette discussion moi
je la trouve intéressante
parce que après
souvent
moi j'ai assisté à pas mal de conférences
ou quand le micro service
était peut-être un peu plus
dans la phase
early adopters
adoption etc
et ce que je trouvais un peu dommage
c'est effectivement ce côté un peu trop silver bullet
souvent on dit ça
où ça répond à tout
et en fait
je trouvais
les interventions dans les conférences pas forcément
très
enfin équilibré justement
voilà je pense qu'il faut montrer
les avantages mais pas dire qu'il n'y a que des avantages
il y a quand même un certain nombre
de contraintes
importantes
ça c'est le monde de la conférence aussi
il y a la conférence et la réalité
et c'est souvent, moi c'est un truc que je vois beaucoup même aujourd'hui
même sur les choses
hors du micro service
généralement le niveau
enfin les confs
ça va jamais
il faut vendre
ça dépend vachement
des confs mais bon c'est vrai qu'il y a un effet
un effet mode entre guillemets
et montrer que ce que tu as fait est génial
des fois pour te convaincre aussi toi-même que tu n'as pas battu
tout seul dans ton coin
je pense que ça joue aussi mais
effectivement ça dépend des confs
mais il y a des confs qui sont peut-être un peu plus
un peu plus comme tu le décris que d'autres
je crois que nous avons un peu fait le tour
de la question
et il est temps de conclure
surtout que nous en sommes à plus d'une heure de discussion
je trouve que ça a encore une fin
un bel et long épisode
moi je me permets de rappeler
à notre cher auditeur que s'il veut discuter
avec nous que ce soit de micro service
ou d'autres et il peut nous rejoindre
sur la communauté des compagnons de DevOps
le lien est en description
et on y discute
on échange sur les micro services
sur Kubernetes, sur les conteneurs
et sur plein d'autres choses
en ce moment ça discute de
packaging piton
si je me souviens bien
et je vais laisser le mot de la fin
à mes chers co-animateurs
et on va commencer par Mathieu
alors mon mot de la fin c'est
j'espère que s'il y a des gens au début de podcast
qui voulaient faire du micro service
maintenant ils sont un peu froidis
voilà, il faut bien y réfléchir
parce que clairement pour moi
c'est vraiment pas toujours
une bonne idée, ça peut l'être
mais faites très très attention
et réfléchissez bien avant de faire du micro service
René, quel est ton mot de la fin ?
eh ben j'ai pas forcément mieux
je vais utiliser mon droit
je sais pas au début t'as dit que j'étais le plus jeune
donc je vais souhaiter
une bonne écoute à tous les auditeurs
et pas en dire plus
c'est le droit des nesses je crois qu'on dit
eh ben
d'habire le mot de la fin, est-ce que t'as un petit mot de la fin
un petit peu positif pour que tu restes épisodes ?
ouais, qu'il n'y a pas
d'informatique comme dans tout
il n'y a pas de solution magique qui vont régler tous vos problèmes
le micro service est quand même là
pour régler des vrais problèmes qui arrivent
et qui sont de plus en plus nombreux
à mesure que les organisations grandissent
c'est pas pour ça qu'il faut en mettre partout
il faut francer dans son rêve le chien