Bruno:
On entend souvent que le dev et l'ops, c'est comme l'huile et le vinaigre séparés par nature, mais ensemble, ça fait la meilleure des vinaigrettes ou la plus grosse des casseroles. Il fut un temps où les ops pilotaient des scripts à la main, enchaînaient les redémarrages, puis l'ingénierie logicielle a débarqué chez eux pour fiabiliser la prod et les scripts sont devenus du code versionné, monitoré, documenté. Mais alors ça veut dire quoi apprendre de la prod pour améliorer le produit, SRE et DevOps c'est du pareil au même ou deux écoles qui s'ignorent et surtout est-ce que si on ajoute des outils c'est vraiment résoudre les problèmes ou juste avoir plus d'outils à surveiller, à minuit à samedi soir pour répondre à ces questions d'équilibre entre simplicité, délivrerie et bienveillance je ne reçois pas Elon Musk mais il s'y connait en fiabilité sous tension Kevin.
Kevin:
Bonjour bonjour Oh, quelle intro !
Bruno:
Alors Kevin, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Kevin:
Oui, alors Kevin Davin, je suis Google Developer Expert sur la partie Cloud et Kotlin. Donc anciennement Kotlin, elle n'existe plus, mais ça veut dire que j'écrivais du code et je le déployais en prod. Fan d'automatisation sur GitLab, contributeur open source quand je peux. Et en plus de tout ça, j'ai un travail chez Gradle, où je travaille sur l'outil qui s'appelle Develocity, qui est un outil fait pour aider à monitorer la qualité de la développeur expérience et à l'améliorer surtout.
Bruno:
Ok, canon. Le sujet pour lequel on se voit aujourd'hui, c'est vrai que c'était l'idée de creuser un peu ce rôle de SRE et de DevOps. Est-ce que dans les grandes lignes, tu pourrais nous dire un peu déjà à quoi correspondent ces différents rôles ?
Kevin:
Alors déjà une jolie remarque tu dis rôle en parlant de DevOps c'est quelque chose contre lequel je me bats depuis des années, je pense que j'ai perdu cette bataille quand les gens cherchent un rôle DevOps, je dis c'est une philosophie DevOps, donc au pire vous allez avoir un philosophe, ce sera un peu chiant pour gérer de la prod mais, la logique le DevOps c'est vraiment une philosophie, c'est le dev et l'ops qui vont travailler ensemble on le voit très souvent avec ce 8 et cette boucle de feedback continue sur de l'amélioration et aller en avant ensemble, tous ensemble. Et après, on a parlé de DevSecOps et autres, puisqu'on s'est dit qu'on allait vraiment mettre tout le monde. Et sur le SRE, SRE, très souvent, c'est montré comme une implémentation de DevOps. Et là, le SRE devient un rôle, puisque c'est a reliability engineer, donc il y a vraiment un humain derrière. C'est celui qui va gérer la prod, mais avec les éléments de l'ingénierie logicielle, comme tu l'as dit en introduction, qui vont permettre de ne pas faire simplement et de se réveiller à 2h du matin pour aller vider un dossier de log, tous les samissoirs parce qu'on sait qu'il doit être planté le samissoir. C'est mettre au service les connaissances de l'ingénierie logicielle pour aider la production.
Bruno:
Mais du coup, effectivement, est-ce que, parce qu'aujourd'hui, on a quand même l'impression que tous ces métiers côté Ops, en fait, ma vraie question, c'est est-ce qu'on fait vraiment des métiers si différents que ça aujourd'hui ? Parce qu'au final, vous avez des métiers où, en fait, de plus en plus de dev, c'est de moins en moins juste du scripting et du rebootage de machines. À quel point est-ce que nos métiers sont si différents encore aujourd'hui ?
Kevin:
Ils sont différents par le but qu'on a, clairement. Quand d'un côté, les devs, on doit livrer de la feature et amener de l'instabilité à un système, parce que plus on livre, plus le système va potentiellement être instable, on a une inconnue. L'Obs, ou en tout cas Obs et CRE, on le nommera de plein de manières différentes, lui, il a une volonté d'avoir quelque chose de stable. Même si tu livres dix fois par jour, il faut que ton système soit stable, parce que toute erreur va te coûter de l'argent. Et si toi, tu perds de l'argent à un moment, peut-être que quelqu'un arrivera à participer à cette idée-là et avoir la même idée que toi, mais avoir plus de stabilité et donc te doubler. Donc l'idée, ça reste réellement opposé quand même, de se dire qu'il y en a un qui amène plus d'instabilité et l'autre qui essaye d'amener une stabilité au système. Mais après, sur les technologies, on commence à se rassembler. On va parler beaucoup, je pense, de Kubernetes, d'infrastructures as-codes, des choses qui deviennent accessibles à tous les niveaux. Et il y a même des équipes aujourd'hui dont le dev et l'ops sont la même personne. Ce n'est pas souvent la meilleure chose, mais grâce à des offres managées par exemple, en termes de dev, moi je suis dev à l'origine, j'adore l'opération, mais je suis tombé dedans parce que j'ai voulu découvrir autre chose, mais en termes de dev, c'est super, tu cliques sur un truc dans une UI d'un cloud provider, deux secondes après t'es un cluster, trois secondes après t'es en prod ça a changé des paradigmes et ça a permis vraiment d'y aller, mais le problème c'est qu'il faut pas garder son mindset de dev quand on fait ça parce qu'on peut avoir les plus gros problèmes possibles.
Bruno:
C'est marrant quand même cette opposition qu'on entend souvent effectivement de se dire que le dev est là pour développer de la feature là où l'op a quand même une volonté de stabilité, ce qui est souvent reproché c'est qu'on a l'impression en fait que il y en a un qui va freiner l'autre, et du coup empêcher l'autre d'avancer t'évoques aussi après sur la fin de ton propos tu disais que, si on garde cette mindset de dev quand on est côté Ops c'est un coup à faire des bêtises c'est à dire que tu perçois vraiment les développeurs comme étant des gens qui font tout et n'importe quoi et qui testent plein de trucs, ou c'est juste, une manière de reformuler le propos.
Kevin:
Il y a deux parties à ta question pour la deuxième partie tout d'abord c'est un dev et je suis dev à l'origine encore.
Bruno:
Une fois.
Kevin:
C'est vraiment mon coeur de métier à l'origine j'aime pas tester les procédures de backup et de disaster recovery j'aime pas ça.
Bruno:
Et ça.
Kevin:
Si t'aimes pas le faire et qu'au final, tu as un produit en prod, il faut le faire. Sinon, demain, ton entreprise peut disparaître juste parce que tu ne l'auras pas fait. Et il n'y a rien de pire que ça. Donc, en fait, c'est en ça que pour moi, malgré tout, il y a quand même cette différenciation et qu'on a quand même des métiers différents. Il y en a un qui va être plus créatif. Il y en a un qui va être plus pragmatique. On va avoir des buts différents. Donc, c'est vrai que mélanger ça au sein du même rôle, pour moi, c'est compliqué parce que c'est cette... Je pense qu'à l'intérieur, il y a deux personnes qui se battent en se disant « je vais livrer cette feature, mais oui, il faut que tu testes le plan de reprise, mais cette feature est plus importante pour mon business. » Et donc, avoir vraiment deux personnes ou en tout cas deux entités qui disjointes peuvent jouer dans le monde SRE. Il y a le fameux SRE Book qui donne des informations pour savoir comment gérer ça. On parle très souvent d'erreur budget. Ça veut dire que plus tu as d'erreur en prod, moins tu vas livrer de features. Et donc, ça va répondre à la première partie de ta question. Donc le SRE il n'est pas là pour empêcher il est là pour faire que ce soit stable ça veut dire que oui il y a 20 ans on avait des ops qui disaient non on ne changera pas la version de la JVM en prod, aujourd'hui c'est plutôt l'inverse, on va dire si votre système est stable et que ce que vous livrez marche et qu'on n'a pas des bugs majeurs à chaque release, livrez tout ce que vous voulez moi je l'ai même fait. J'encourageais les gens à faire des erreurs parce que comme je l'ai dit au début, si tu ne fais pas d'erreur ça veut dire que tu ne prends pas de risque si tu ne prends pas de risque quelqu'un d'autre le fera pour toi et donc potentiellement te doublera et on le sait encore une fois c'est celui qui va vite et plus important que celui qui est gros donc même si tu es la plus grosse boîte du monde tu peux te faire doubler par quelqu'un qui a développé dans son garage quelque chose qui va juste remplir le besoin que ton appli ne gère pas et demain ça deviendra ton concurrent donc moi j'encourage très souvent les gens à prendre des risques. Considérés bien sûr il ne faut pas planter la prod et ne pas pouvoir faire de recovery mais, Il y a un erreur budget, il est utilisé dans les deux sens. Si tu as cramé ton erreur budget, ça veut dire ton quota d'erreur pour la semaine, le mois, l'année, tu vas moins délivrer de features et plus stabiliser l'outil. Stabiliser, ça peut vouloir dire d'autres features, mais features plus orientées stabilité, améliorer l'observabilité, améliorer le monitoring pour qu'on se rende compte que les trucs pètent avant qu'ils pètent, par exemple, plutôt que de faire de la feature qui va rendre le produit potentiellement plus instable. Donc, c'est un trade-off continuel, mais ça, c'est ce que je défends très souvent au PO, et autres PM en leur disant, vous savez que les ops et l'opération c'est un de vos clients c'est à dire que vous avez beau créer le plus merveilleux des produits s'il n'est pas opérable à la fin, vous n'avez pas de prod vous n'avez rien donc en fait c'est un des clients et si ce client n'est pas content je peux vous dire que généralement votre chiffre d'affaires ou le revenu généré par votre appli va être très faible parce que le truc sera tout le temps down et personne ne voudra le maintenir.
Bruno:
C'est hyper intéressant ce concept d'erreur budget que je n'ai jamais vu forcément en application. Est-ce que c'est une pratique qui se développe ? Comment ça se met en place ? C'est quoi un peu l'approche pour ce sujet-là ?
Kevin:
Pour avoir des informations sur l'erreur budget, ne pas hésiter à lire encore une fois le SRE Book. C'est très bien décrit dedans, c'est écrit par des Googleurs. Ça ne représente pas ce que Google fait aujourd'hui puisque comme beaucoup, ils écrivent sur ce qu'ils ont fait dans le passé et ils évoluent. Mais cette erreur budget, c'est vraiment, c'est implémenté dans énormément même d'outils qui vont faire de la gestion de prod, que ce soit les data dog et Grafana et compagnie. Ils mettent ça en place même dans l'outil pour dire à quel point c'est intégré maintenant dans les mœurs. Et l'idée, c'est juste de se dire si ton système plante, tu vas avoir, tu vas définir ce qu'on appelle des SLO, SLI, SLE, donc des indicateurs et des observations et des agreements, donc ton agreement c'est celui que tu signes en contrat avec tes clients généralement et en fait tu vas dire ok j'ai un objectif, cet objectif je dois le remplir et si je ne le remplis pas mon système par exemple est trop indisponible dans la semaine mois ou année et bien je vais devoir faire des choses pour améliorer ça plutôt que d'améliorer les features et donc ça responsabilise et j'aime beaucoup ce que, Ce qu'a présenté des personnes de chez Red Hat, par exemple, où quand l'erreur budget est cramé, ils prennent des devs et les mettent dans l'équipe Ops, ou SRE, peu importe comment on la nomme encore une fois. Ce qui fait que mécaniquement, ça réduit la productivité de l'équipe de devs, donc ils livrent moins de features, et surtout, ça rend un dev, nouvellement Ops. Plus responsable de ce qu'il livre, parce qu'il est de l'autre côté de la fameuse barrière quand ils jettent son binaire et que de l'autre côté, on le récupère. Donc, en fait, ils se disent, oui, mais mon app, si je dois la maintenir et qu'elle doit tourner en prod et qu'à deux heures du matin, je vais être obligé de me lever, j'aimerais bien avoir la métrique qui m'intéresse pour débuguer deux suites visibles en premier lieu sur le dashboard et que je ne sois pas obligé de lire un runbook qui fait des dizaines et des dizaines de pages. Donc, en fait, ça les responsabilise. Donc, quand ils retournent dans leurs équipes, ils ont cette petite partie 2 qui se dit, tiens, si je fais cette feature, maintenant, j'ai la connaissance de l'ops, je vais pouvoir appliquer cette pratique en amont, c'est comme on le dit pour la documentation, quand on décrit une feature on écrit la doc qui va avec et bien là c'est pareil, on met la petite partie observabilité la petite partie maintenance et compagnie, qui permet que quand demain ça plantera, parce que la question c'est pas est-ce que ça va planter, c'est ça plantera donc quand est-ce que ça va planter, et bien qu'à ce moment là, le système tourne mieux pour qu'on puisse faire du troubleshooting et remettre le système sur pied le plus rapidement possible.
Bruno:
Ce qui est du coup hyper intéressant dans cette approche, c'est qu'en fait ça oblige à un vrai travail collaboratif, aussi bien côté Dev que côté Ops, parce qu'en fait l'un ne peut pas aller sans l'autre, et donc ça revient sur la conversation qu'on avait juste avant sur cette opposition. J'entends cette idée comme quoi on a des objectifs qui sont différents, mais au final, est-ce qu'on a vraiment des objectifs qui sont différents ? Parce que, j'ai envie de dire, on fait tous partie en général de la même boîte. Et l'objectif, c'est de fournir un service à nos clients. Et donc, tu vois, quand tu évoquais tout à l'heure que l'Obs est un des clients, aussi bien du produit que du dev, vu qu'il y a quand même cette nécessité d'un travail collaboratif quand même assez fort, est-ce que l'Obs est vraiment un client, mais ne devrait pas être au contraire plus un collaborateur peut-être mieux intégré dans la chaîne de production ?
Kevin:
Tout à fait. Ça peut être vu, moi généralement, j'introduis cette logique de premier client quand vraiment la notion d'opération n'est pas connue du tout des personnes qui développent. Et c'est d'ailleurs comme ça que je suis tombé dans la partie Ops moi-même, c'est que j'en avais marre d'écrire du code et de ne pas savoir comment il allait tourner ou si même il avait été livré. Tu sais le fameux, on fait la V3 alors que la V1 n'est même pas encore en prod. Tes utilisateurs, ils en sont où ? Et en fait, cette logique-là, elle s'applique aussi aux personnes qui opèrent la plateforme parce que si eux ne l'ont même pas lancé une fois, des personnes qui ne savent même pas quelle version de la JVM va être utilisée alors qu'ils ont déjà développé un tiers de l'appli, c'est un petit peu problématique, JVM ou autre. Donc, c'est vrai que j'amène cette idée de client quand au début, il faut quand même amadouer et se dire qu'il faut l'écouter. Il faut au moins l'écouter comme un client. Mais après, comme pour la sécurité, comme pour le FinOps, il faut que ce soit intégré, que ce soit face partie prenante du but. Le but principal, c'est que le produit marche. Après, par quels moyens ? Il y en a un qui va amener de la stabilité, l'autre qui va amener des features. Ça ça va être deux choses différentes mais oui le but global c'est ce que je répète tout le temps que ce soit dans ma boîte actuelle ou quand je travaille avec d'autres boîtes, sur ce genre de choses on a un but commun c'est que la prod elle soit verte et que vous dormiez bien la nuit et que vous puissiez livrer n'importe quand.
Bruno:
Alors justement, ce que vous puissiez livrer n'importe quand, il est intéressant parce qu'il y a une approche que je vois souvent qui est assez intéressante, c'est de se dire que côté SRE, c'est comment je fais pour créer un contexte qui soit le plus maîtrisé possible, dans lequel les devs peuvent faire à peu près n'importe quoi. Mais tu vois, en fait, de mettre des contraintes entre guillemets en amont avec ce côté un peu je te mets à disposition des services, des possibilités enfin tu vois peut-être un cadre dans lequel tu peux... Le fameux platform engineering Le fameux platform engineering exactement qui te permet de dire au dev maintenant vous êtes libre, faites ce que vous voulez, mais en fait tu parlais de barrières tout à l'heure de dire en fait voilà où sont vos barrières et dedans, amusez-vous, vous pouvez pas vous blesser on a mis des tapis en mousse partout C'est ça.
Kevin:
C'est quelque chose de très important. Après c'est vrai que sur cette partie-là je suis un petit peu à la marge et avec le fameux platform engineering parce que pour moi, et venant du dev je le pousse aussi énormément pour moi les devs doivent connaître c'est les fameux T-shaped people on écrivait ça à l'époque du back-end et du front-end il fallait connaître un petit peu le front il ne fallait pas être expert front la même chose avec la database tu utilises une database, sache les problèmes que tu peux causer une database même si tu n'es pas DBA la même chose pour moi doit être fait avec l'infrastructure les méthodes de déploiement et autres parce que le nombre de développements que j'ai vu être fait de manière totalement inutile pour, un exemple, lire sur le file system un secret. J'ai des développeurs qui se sont dit, c'est une super idée, si le secret change, je vais aller faire un watcher qui va le relire toutes les n minutes. Oui, mais si tu avais juste lu ou su que l'aspect de Kubernetes disait que les secrets sont généralement immutables en bonne pratique, et donc que. Ton pot sera redémarré si le secret change, en fait, tu n'aurais pas développé ce truc. il ne sert à rien, c'est du code ? Un, inutile. Deux, qui a généré du bruit en prod parce qu'on voyait des I.O. Toutes les N secondes et on se demandait pourquoi il y avait quelque chose qui consommait de l'I.O. alors qu'on ne devait pas en consommer. Donc, c'est vraiment avoir cette idée de on sait ce qu'on fait même quand on est dev et donc ces fameux tapis en bousse, pour moi, c'est protéger des personnes au lieu de les éduquer. C'est-à-dire que si je les éduque correctement, j'ai un cadre dans mon entreprise où on veut faire, par exemple, du Kubernetes, du PG. Ça, c'est les éléments qu'on a décidé. ok, foncez là-dessus si vous voulez quelque chose d'autre on en discute parce que derrière c'est peut-être nos équipes qui allons les maintenir en prod donc il y a des choses que vous ne voyez peut-être pas les montées de version de n'importe quel outil par exemple, mais par contre on a ce cadre-là. Renseignez-vous, apprenez passez des certifs voyez les bonnes et mauvaises choses à faire avec, venez vers nous si vous avez besoin d'aide, mais par contre c'est le terrain de jeu en question et pour moi il n'y a pas les matelas en mousse il y a juste, voilà, vous connaissez vous devez apprendre parce que vous devez être aussi responsable parce qu'on peut se dire que d'un côté et je l'ai déjà vécu ça a, amène de la charge sur tous les développeurs, donc ça multiplie par le nombre de développeurs cette compréhension nécessaire du système et donc ça, si on met les tapis en mousse, les fameux, ils ne vont pas avoir besoin de la prendre, ils vont être plus productifs. Sauf que le problème, c'est que ça amène cette charge sur de l'incompréhension après sur l'outil qui est mis en prod, le produit. Et donc là, on va se retrouver avec 1, 2, 3, 4 devs, 4 ops qui vont devoir gérer des choses et il n'y a pas de surprise, on développe plus que ce qu'on opère. Ça veut dire que des projets, on les crée une fois, mais ils tournent pendant dix ans. Et après, ça, ça s'accumule. Donc, en fait, il vaut mieux pas faire les erreurs au départ parce que sinon, on les paye pendant dix ou plus si le projet est un succès. Donc, c'est là où vraiment, pour moi, les devs doivent avoir cette connaissance-là pour être capables d'appliquer correctement à l'instant T. En plus, on sait que les technologies évoluent. Donc, si en plus, on se paye un déficit de connaissances en plus d'une obsolescence technique, ça va être dur au fur et à mesure du temps. Donc moi je suis plus de l'avis de former, éduquer les gens, qu'ils apprennent et qu'ils puissent comprendre et clairement, c'est pas Rocket Science les trucs.
Bruno:
De la.
Kevin:
Prod maintenant en tout cas.
Bruno:
Alors c'est pas Rocket Science en même temps moi un propos que j'ai régulièrement sur ce podcast c'est qu'on a quand même des technologies qui se, complexifient beaucoup alors d'une certaine manière on a aussi tu sais si on prend l'exemple de Kubernetes, il y a, je ne sais pas, on va dire il y a 20 ans, monter un cluster qui est capable de scaler de manière dynamique, c'était un enfer, c'était d'une complexité folle. C'était accessible qu'à quelques entreprises.
Kevin:
Et on n'en avait peut-être pas forcément le besoin à l'époque.
Bruno:
Et on n'en avait peut-être pas forcément le besoin. Et effectivement, aujourd'hui, avec Cube, ça se fait de manière beaucoup plus facile. Mais bon, mine de rien, ça reste quand même une technologie de plus qu'il faut maîtriser. Tu vois, côté Dev, il y a aussi beaucoup de complexification sur beaucoup de technos donc il y a toujours cette question de est-ce qu'on peut vraiment, tu parlais des profils anti-shape aussi tout à l'heure, à quel point est-ce que c'est je pense qu'aujourd'hui le concept de développeur full stack n'a plus vraiment de sens parce que c'est difficile de maîtriser une stack avec les niveaux de complexité que ça peut être, et dans quelle mesure est-ce qu'on peut l'appliquer aussi à ces sujets-là, de se dire à quel point est-ce qu'aujourd'hui un développeur peut être aussi, sans être en maîtrise, mais d'être en connaissance suffisamment, complète de ces sujets côté Ops, de la même manière que les gens côté Ops ne peuvent pas être en connaissance totale des sujets côté Dev.
Kevin:
Je te rejoins, c'est compliqué, mais c'est vrai que quand tu en es à avoir des problématiques qui vont t'amener à utiliser des technologies qui vont te permettre de scaler, c'est que potentiellement, tu as un problème qui est à l'échelle aussi. Donc, il vaut mieux avoir des gens qui connaissent un peu. Et encore une fois, je ne demande pas à des devs de devenir des administrateurs kubes, loin de là. Pour moi, c'est quand un dev, et j'ai fait des 101 Kubernetes pour simplifier kubes outrance. Et en fait, Cube, sans le savoir, c'est les bonnes pratiques d'Ops appliquées, de manière extrêmement basique, et encore une fois, ce qui est visible par l'utilisateur et pas ce qui est à l'intérieur. Appliquées de manière extrêmement basique pour tout le monde. Un service qu'on appelle un service, c'est juste un non-DNS. Quand avant, on remplissait un champ dans un serveur DNS quelque part, maintenant c'est juste un bout de DML. La solution, généralement, avec Cube, est toujours un bout de DML. Et tout ça va toujours être là pour nous guider, nous donner. Les fameux, alors ce n'est pas les éléments en mousse, les tapis en mousse, mais c'est plus un guide et un guide et te dire, ben voilà, c'est comme ça que ça fonctionne dans Cube, essaye de rentrer dedans et fais tout pour rentrer dedans et en fait, si tu rentres dedans. Tu vas avoir gratuitement tout ce que la plateforme va t'offrir. Le nombre d'opérateurs qui, encore une fois, redémarraient des JVM à 2h du matin juste parce qu'il y avait un note-off memory et que ça ne redémarrait pas automatiquement, donc kube c'est built in readiness et liveness et ce genre de choses donc en fait si on suit les paradigmes qui pour moi c'est le fameux retour de cette boucle DevOps où les ops sont devenus des ingénieurs ils ont créé kube, Et cette boucle a permis de mettre toute la science de l'ingénierie dans un outil qui va guider et donc aider les personnes qui vont développer des applications. Donc, quand on rentre là-dedans, et aujourd'hui, par chance, les frameworks à la mode et autres, ils fournissent aussi toutes ces intégrations qui vont bien pour exposer des liveness, des readiness, pour scaler correctement, pour dire attention, ne mettez pas du state dans vos applications parce que ça va faire du round-robin entre les instances. Donc aujourd'hui ça va donner les éléments et de mon point de vue c'est comme hier on apprenait comment fonctionner le réseau, comment fonctionner un déploiement, une VM, là on va apprendre comment fonctionne Kube juste pour pouvoir connecter les choses et connecter deux pods, deux conteneurs dans Kubernetes c'est d'une simplicité folle aujourd'hui de mon point de vue. Donc en ça pour moi ça aide énormément.
Bruno:
Tu disais la nécessité pour les développeurs et développeuses d'apprendre et d'essayer de maîtriser un peu plus des sujets côté Ops. Tu as l'occasion à travers cette plateforme justement à t'adresser à un ensemble de développeurs et de développeuses. Je ne sais pas si tu as une liste déjà dispo, mais ce serait quoi pour toi les éléments ou à minima peut-être les pistes sur lesquelles tu pourrais nous mettre en disant quand vous faites votre implème, pensez à tel sujet, tel sujet, tel sujet ?
Kevin:
Pour moi, la première chose, c'est développer dans quelque chose. Quand vous vous développez, ayez une boucle de feedback et de déploiement qui soit extrêmement rapide. Ça veut dire réussir à avoir quelque chose qui tourne dans un environnement similaire à la prod. Ça n'a pas besoin d'être un cluster de 800 nœuds, mais au moins, si on fait du cube en destination, déployez-le en quelques secondes, c'est-à-dire qu'on code localement, cinq minutes après, même pas cinq minutes, cinq secondes après, c'est dans le cluster, ça tourne, et comme ça, on peut le voir vivre. Et, conseil, faites-le vivre, pas de la manière minimale, faites-le vivre de la manière au moins standard, voire un peu plus, parce que le bug d'un état dans une app, ah, tiens, j'ai un truc, une memory, j'ai un token, et ce token, j'oublie de le partager au travers de toutes mes instances. Demain, le client qui va installer le produit, il va mettre 3 parce qu'il veut avoir une réplication multi-région, bizarrement, le truc, vu que c'est du run-robin, il ne va pas tomber sur le bon pod et un coup sur 3, vous n'aurez pas vos informations d'authentification et ça va générer une, tempête de requêtes sur la database parce que les trucs ne sont pas dans le cache parce que le cache se trouve en mémoire. C'est juste essayer toujours d'être très proche du scénario minimal, du scénario standard et pas du scénario minimal de que je déploie. Code une app, donc je vais ne déployer qu'une seule instance. Et ensuite, pour moi, c'est tester d'opérer un peu. C'est déployer et regarder, en fait, si vous mettez en place ce pipeline d'automatisation entre le code et entre guillemets la prod. Encore une fois, ça n'a pas besoin d'être l'environnement de prod. Voyez les différentes choses qui vont vous bloquer, qui vont vous amener à vous poser les questions de qu'est-ce qui est compliqué pour ensuite pouvoir les prendre en compte dans votre développement. En fait, vous devenez un ops sans avoir la prétention de l'être 24-24 et demander aux OBS qui vous entourent ce qu'eux font, ce qu'eux préfèrent et ce qu'eux voient pour la plateforme. Encore une fois, moi j'ai appris la plupart du temps aux contacts de personnes plus douées que moi sur ces sujets-là. Et ça, c'est inestimable.
Bruno:
Après, il peut y avoir des contacts où tu as une équipe OBS qui ne veut pas laisser les devs déployer parce qu'il y a eu trop d'histoires par le passé. Donc qui veulent essayer de préserver autant que possible leur contexte. Mais c'est là où je pense que c'est important justement d'aller renouer le dialogue, ou presque, on pourrait dire, en montrant qu'il y ait une volonté de compréhension du métier et du coup des contraintes pour pouvoir les prendre en compte le plus tôt possible.
Kevin:
Mais tu parles de déployer sur des environnements, dans ce cadre-là, j'entends partiellement distants, mais aujourd'hui, avoir une boucle de feedback extrêmement courte, de l'ordre de quelques secondes dans un cluster Kubernetes, c'est tout à fait possible en full local. C'est-à-dire qu'on peut déployer du cube localement, des K3D, mini-cube, Kind ou ce genre de choses. C'est extrêmement léger, ça ne demande que d'avoir le démon Docker et vous pouvez avoir une centaine de nœuds si vous voulez, surtout que nos machines deviennent de plus en plus puissantes. Ça consomme moins que de l'IA, c'est clair. Et derrière, ça vous permet de voir à l'échelle si ce que vous faites fonctionne vraiment au travers de ce type de déploiement.
Bruno:
Sur le sujet de collaboration aussi entre dev et Ops, un sujet que je disais beaucoup au début de ce podcast mais pour je ne sais quelle raison j'ai arrêté de le répéter à quasiment chaque épisode donc je reprends cette pratique là parce que je pense que c'est une bonne pratique je disais à beaucoup de dev, intéressez-vous au log en fait, allez voir ce qui se passe en prod, allez regarder un peu toutes les différentes stats qu'il peut y avoir, les différentes métriques, intéressez-vous à l'observabilité parce qu'en fait ce qui se passe en prod, est source d'énormément d'apprentissage que ce soit en termes d'usage d'une application ou de service par les clients mais parfois même on apprend des choses, sur des aspects de cybersécurité, sur des aspects de performance enfin de divers et variés, et je pense que c'est une source d'apprentissage qui est vaste et qu'il ne faut pas s'intéresser à la prod seulement quand il y a quelque chose qui quand la prod est down, il y a aussi au quotidien, c'est aussi aller regarder comment les choses fonctionnent, et pas que, qu'est-ce qui se passe quand ça ne fonctionne pas en fait. Je ne sais pas ce qu'il y a aujourd'hui comme solution qui existe pour permettre justement aux développeurs et développeuses d'avoir accès à cette mine d'informations, qui est disponible sur tous vos outils côté Ops.
Kevin:
Il y a une standardisation qui est arrivée avec tout ce qui est open telemetry, ces dernières années et qui se stabilise énormément, ce qui fait qu'aujourd'hui, ça devient beaucoup plus accessible. C'est-à-dire qu'il y a un standard, quand avant c'était Prométhée où se faisaient les choses d'une manière, Datadog le faisait d'une autre manière et autre. Et on était obligé d'avoir la console de l'outil en question avec un langage de query qui était particulier. Aujourd'hui, le langage reste un petit peu particulier. Mais au moins, il y a eu un truc qui s'est uniformisé et ça permet de récupérer au-delà des logs. Parce que les logs sont une très bonne chose. Mais comment ça devient un petit peu, je ne vais pas dire obsolète, mais l'élément d'avant où maintenant, je vois de plus en plus de devs intéressés par les traces distribuées. Et les métriques, bien sûr, mais les traces, parce que quand on a un bug en prod, on ne veut pas aller... Le bug, il est déjà arrivé. Donc, qu'est-ce qu'on va faire ? On va activer les logs sur la feature en question et on va attendre que ça réarrive. Peut-être que ça ne réarrivera pas. C'est un problème de sécu. Quelqu'un a réussi à faire un truc et tant pis, il ne reviendra pas. Ou alors, comment on fait pour récupérer ces datas-là ? Donc, c'est vrai que maintenant, arrive beaucoup l'idée, surtout avec les microservices déployés à plein d'endroits différents. On a besoin d'avoir ça corrélé entre les différents systèmes donc Open Télémétrie aide beaucoup et permet d'avoir un max d'informations et je te rejoins 2000% sur l'idée de s'intéresser à la prod avant qu'elle soit down parce que déjà quand vous le faites quand c'est down il y a une pression de malade donc ça génère en fait une anxiété de la prod c'est dur la prod c'est compliqué la prod c'est les moments oncle qu'on ne veut pas voir, donc on n'y va jamais même quand ça marche. Or, si une fois par semaine, vous allez regarder les métriques, vous allez voir comment votre appli tourne, vous vous rendez compte qu'une fois par jour, l'appli redémarre automatiquement parce que Cube le fait. Donc, ce n'est pas grand-chose. Ça n'a pas alerté la prod parce que ça continue à tourner. Mais elle redémarre parce qu'il y a un truc que vous avez mal configuré dans le garbage collector qui va prendre un petit peu plus de mémoire que prévu. Voilà, ça vous permettra de le savoir, de le voir et ensuite de pouvoir le maîtriser parce que techniquement, local. C'est rare qu'on fasse tourner la JVM pendant 24-48 heures sans avoir redéployé ou fait autre chose. Donc, avoir ces informations-là et les voir, pour moi, c'est... En fait, c'est comme ça que j'ai démarré. Je voulais voir mon appli tourner parce que le meilleur endroit sur la planète, c'est la prod. Si on développe et qu'on ne va jamais en prod, ça ne sert à rien.
Bruno:
J'aime beaucoup la phrase que le meilleur endroit de la planète, c'est la prod. C'est ton avis personnel, ça qu'on n'a pas forcément tous. Le même point de vue mais je prends effectivement c'est une source d'apprentissage qui est folle, tu nous as listé pas mal d'outils dans ce qui est utilisé au quotidien côté Ops, j'ai évoqué la complexification des sujets côté Dev est-ce que tous ces changements de technologie l'arrivée effectivement de, l'infra-as-code, l'arrivée du code de manière globale côté Ops, est-ce que tu penses qu'aujourd'hui, vous avez aussi un métier qui est beaucoup plus complexe que ce que c'était avant, où il est peut-être juste très différent ? Est-ce que vous êtes bardé d'outils ? Comment ça se... Comment ça a évolué, ce métier-là ?
Kevin:
Personnellement, je pense que c'est devenu plus complexe, si on regarde la big picture, parce qu'on fait aussi des choses plus complexes au sens propre, c'est les clusters et les compagnies. Comme tu l'as décrit tout à l'heure, on avait des fois une VM qui faisait tourner tout un service et ça allait très bien. Donc, avant, on n'avait pas cette complexité de se dire d'où vient le flux, où va le flux, où est le problème, tout tourner dans la même VM. Donc généralement ça a passé et on était content donc pour moi oui ça s'est complexifié sur cette partie là mais par contre on a amené un degré de simplification parce que des principes qui sont détaillés dans le SRE book encore une fois c'est le fameux pet versus cattle. Donc où on essaye de faire de l'immutable à outrance parce que si c'est immutable on peut jeter n'importe quoi et on peut le relancer une seconde après ça tournera normalement aussi bien et on encourage même avec le chaos engineering à casser des choses quand on contrôle parce que si on sait ce qu'on a injecté comme erreur, on est à même déjà de le retirer et surtout de comprendre si ça va tout péter ou pas et de voir si les investigations ont mené au même résultat et si notre outil est capable de gérer ce genre de choses donc pour moi ça c'est. Ça a clairement changé. C'est cette boucle d'ingénierie qui est venue dans la danse et qui a amené tout ça. Mais à contrario, je trouve que sur un point, ça s'est simplifié énormément sur l'idée de comment on veut que la prodale tourne. Et j'adore Kubernetes pour une raison, c'est un langage déclaratif. Et ça, c'est quelque chose que je pousse le plus possible, que ce soit dans les présentations, que ce ne soit pas que sur Kubernetes d'ailleurs, mais le SQL, le SQL est un langage déclaratif. On dit ce qu'on ne veut pas comment le faire. Et je trouve pour moi que ce sont les meilleures technologies possibles parce qu'on n'a pas de détails d'implémentation qui apparaissent. On n'a déjà pas de discussion sur comment faire les choses. C'est je veux un pod qui tourne comme ça. Et le système va le faire et c'est tout. Et en fait, ça amène, ça retire de la charge mentale, de la charge cognitive plutôt. Quand on va travailler avec ça, en prod, généralement quand on le gère, mais aussi quand on doit faire du troubleshooting. Quand on fait du troubleshooting, c'est hyper simple de mettre n'importe quel outil ou IA sur un ensemble de YAML et il va lire le système et comprendre les interconnexions entre les systèmes parce que, tiens, on a référencé l'URL de l'un dans le déploiement de l'autre. Et donc, les deux, on va pouvoir déduire qu'il y a un flux. Et avec des outils de monitoring, on va pouvoir les voir, ces flux. Donc, en fait, on s'est vraiment énormément outillés plus que ce que le système s'est complexifié de mon point de vue. Ce qui fait qu'aujourd'hui, pour avoir échangé avec beaucoup d'ops. D'anciens ops, leur pager ils sonnent beaucoup moins la nuit aujourd'hui ils ne se lèvent plus la nuit pour des problèmes de prod où c'est extrêmement rare parce que les systèmes sont plus résilients et plus pensés pour la résilience et ça c'est vraiment un atout.
Bruno:
C'est une tendance qu'on retrouve beaucoup côté tech, il y a des vrais sujets d'automatisation parce qu'en fait, fondamentalement notre métier de dev ou de métier de tech c'est d'automatiser des choses qu'on n'a pas envie de faire et de faciliter la vie donc c'est vrai que, l'apparition des concepts de CICD aujourd'hui c'est quelque chose de, naturel, de complètement naturel mais moi quand j'ai commencé à dev il y a 30 ans les boîtes qui avaient une CI c'était c'était le top du top la majorité, on glissait nos fichiers en FTP sur le serveur et puis on regardait si ça marchait aussi bien que sur la machine en local cette volonté d'automatiser, je pense que c'est un truc inhérent chez nous et je pense que chez Gradle c'est quelque chose que vous maîtrisez bien comme sujet c'est.
Kevin:
Au coeur de l'entreprise l'entreprise a été créée avec cette idée-là et même si je travaille sur un sujet qui est connexe je ne travaille pas avec Gradle le Build Tool mais Gradle vient de là et notre idée c'est toujours d'automatiser et en interne on nous matraque avec cette idée-là on ne répète pas deux, trois fois la même chose allez, on automatise et on améliore pour que comme ça on puisse se focaliser avec le moins de personnes possible on puisse faire le plus de choses possibles et j'ai travaillé avec des grosses boîtes où, grosses ça dépend à quel niveau on y réfléchit parce qu'ils avaient des milliers de clusters cube sur GKE chez Google mais ils n'avaient que 4 Ops, des milliers de clusters, 4 ops et des dizaines de milliers d'applications. C'est-à-dire que quand on n'a que 4 ops et qu'on sait gérer autant de charges, autant d'éléments et eux étaient vraiment à la milliseconde. C'est du retail, donc il ne fallait pas perdre de choses. Mais ils n'avaient que 4 ops. Rien que ça, pour moi, ça montre que quand on optimise les choses, on a vraiment besoin de beaucoup moins d'humains et surtout, je peux te dire qu'ils étaient cool quand ils travaillaient parce qu'ils savaient que leur système était robuste. Et ça, c'est vraiment l'anti-pattern de la prod où il y a du feu tout le temps et on court après les problèmes non-stop et on passe plus de temps à ouvrir des échouques à les clôturer. Pour moi, la prod, ça doit être un sujet qui est relaxant. Comme ça marche bien, c'est relaxant, la prod.
Bruno:
Ça, c'est aussi une phrase à garder. La prod, ça peut être un contexte effectivement relaxant. En ce moment, côté d'Ev, nous, on a beaucoup de questions autour de l'arrivée de l'IA sur le métier de dev qui est en train de bousculer un peu la réalité de notre métier, le quotidien de notre métier, est-ce que c'est la même chose côté ops, est-ce que c'est déjà quelque chose d'ancré avec, des outils qui savent de manière un peu plus automatique anticiper des changements, de trafic ou ce genre de choses je ne sais pas à quel point est-ce que ces métiers là aussi sont impactés par l'IA.
Kevin:
Ils le sont tout autant, puisque de toute façon, dès qu'on a beaucoup de data et qu'on n'est pas capable de les traiter humainement, une IA va pouvoir les traiter beaucoup plus facilement et donc de décider sur certaines choses. Et en prod, c'est là où on a quasiment le plus de données, puisqu'on va collecter énormément de choses. Mais généralement, on avait tendance à arrêter la collection, puisqu'on ne pouvait pas les exploiter correctement. Là, avec de l'IA, on va pouvoir décider et faire des analyses, quelque chose que j'adore, j'adorerais faire, je le fais beaucoup moins aujourd'hui. Mais c'était des tests en prod mais pas avec. Du trafic de prod mais pas avec des utilisateurs de prod pour détailler ça c'est qu'on copiait le trafic trafic mirroring et on testait sur des features où on envoyait le même trafic mais on avait développé quelque chose différemment, l'extrême par exemple c'est d'avoir redéveloppé avec une autre technologie juste pour voir si ça marchait mieux mais ça le problème c'est que ça prend du temps le temps de développement c'est certain mais aussi le temps d'analyse de ça, de le faire tourner pendant, une heure, un jour, une semaine et voir les datas, corréler tous les logs. Là, avec une IA, tu balances tout ça. Oui, il y a du token à payer. Mais l'avantage, c'est qu'on peut avoir le résultat d'une analyse qui peut être fait au travers d'une collecte quasiment de 100% des logs sur trois jours et avoir une décision prise au quatrième jour et le lundi d'après, on sait qu'on peut tourner le flag on par défaut. Le truc est en prod, tout le monde l'utilise parce que on a analysé quelque chose qui nous aurait peut-être pris deux, trois semaines avant parce qu'il ne faut pas oublier que ça, on va le faire pour plein de features en parallèle. Là, l'IA va le faire beaucoup plus facilement pour nous. En tout cas, sur cet aspect-là, pour moi, ça a aussi un game changer.
Bruno:
Mais du coup, ce que tu décris, c'est des outils qui viennent de, vous permettre de faire plus vite des choses que vous seriez en mesure de faire à côté mais qui ne va pas non plus pour autant vous prendre une partie de votre métier.
Kevin:
Je vois où tu veux en venir alors oui sur cette partie là mais après il peut y avoir il y a même déjà des opérateurs dans le monde cube par exemple c'est là où beaucoup de nouvelles choses sont testées pour faire de l'obs avant de l'obs ça veut dire avant de venir te réveiller le système va faire une analyse s'il y a un truc qui est en incident ou en crash pendant trop longtemps, va quasiment créer l'incident de report, l'ouvrir renseigner les informations, potentiellement, exécuter les runbooks qu'un humain aurait fait avant c'est de l'automatisation mais sans avoir écrit l'automatisation, donc encore une fois, oui sur cette partie là, peut-être que moins d'humains seront nécessaires quand il y avait peut-être besoin d'une équipe de 8 personnes pour gérer une prod, il n'en faudra plus que 4 parce qu'on aura 4 personnes qui dorment la nuit versus 8 qui courraient dans tous les sens. Donc, en ça, peut-être que oui, mais par contre, et j'en parlais avec des personnes non-tech récemment, pour moi, ça offre aussi l'opportunité d'avoir plus de choses qui vont être créées et donc potentiellement, s'il y a plus de choses qui sont créées, il va y avoir peut-être plus d'entreprises et donc plus de postes à pourvoir. Et ça, ça va être aussi un changement majeur.
Bruno:
Complètement aligné avec cette vision. Je pense qu'effectivement, ça va permettre à des gens, d'explorer des tas d'idées, des tas de choses et que donc, on va avoir des trucs popés de tous les côtés et que ça va forcément relancer le marché du travail de ce côté-là. Pour terminer, parce qu'on a évoqué le besoin pour ces métiers-là de travailler ensemble, le fait que d'un côté comme de l'autre, il y a des informations qui sont utiles à prendre et qu'il faut... Il faut construire nos applications et nos services en prenant en compte aussi bien, la qualité du code qui est produite que la capacité à l'ensemble de tourner, qu'on a des IA qui popent un peu de tous les côtés, qui permettent en fait de réduire, l'état des équipes, que ça fait des années qu'on a réussi à gérer de plus en plus de complexité dans nos métiers. Est-ce que tu... On a parlé de DevOps, mais on voit apparaître aussi maintenant le DevSecOps, donc on a rajouté encore un métier dans la sauce. Est-ce que tu penses qu'on va réussir peut-être à arriver à un moment où en fait tout ça, ce sera un seul et même métier et que potentiellement, on pourrait avoir des contextes avec... À l'image des devs full stack qu'on avait avant, d'avoir en fait un dev sec ops qui devient réellement une personne et non pas juste une philosophie, mais quelqu'un qui a aussi bien une capacité à gérer la création du produit, son run et sa sécurité.
Kevin:
Tu poses cette question en relation avec l'IA particulièrement ?
Bruno:
Entre autres, avec tous les changements effectivement qui sont en train de popper sur ces différents métiers.
Kevin:
Moi je pense que ce qui va plus aider ce qui a déjà même aidé plus sur cette trajectoire là c'est pas forcément l'IA qui certes va permettre de créer beaucoup plus vite mais pour moi c'est les offres managées qui sont de, qui offrent une meilleure qualité tous les jours et qui vont encore une fois simplifier toutes les choses, tous les éléments dont on a parlé d'erreur budget, il y a des services managés qui te l'intègrent de base, encore une fois tu crées ton cluster, automatiquement il dit tu vas faire un cluster, tu vas faire de la prod je vais te mettre du monitoring distribué je vais te mettre les traces, je vais te mettre un dashboard je vais te faire ça aux petits oignons la seule chose que tu as à faire c'est de dire quelle image tu veux tourner et je vais te la scaler dans tous les sens pour qu'elle tourne et pour information et c'est un outil que j'adore même si je ne l'utilise plus aujourd'hui App Engine côté Google a été créé en 2009, et a été créé sur cette idée là sauf que ça tournait pas dans le cube on fournissait juste nos sources et le truc faisait tourner ou notre binaire et le truc le faisait tourner à l'échelle dans tous les sens, distribués dans le cloud de Google et ça c'était top maintenant on a voulu reprendre un peu plus la main sur la partie infra et autres pour qu'elle soit standardisée aussi comme ça on peut bouger d'un cloud provider à l'autre ça nous libère un peu. Mais en ça pour moi c'est plus ces offres là qui vont enlever, on va même plus poser la question comme dans DevSecOps t'as le sec, potentiellement si t'as un service qui va automatiquement te scanner tes images, voire que tu utilises une image alpine spécifique, que cette alpine elle est, elle a une CVE, et que si on te l'update, ton truc va tourner quand même, il peut te l'updater, changer l'image alpine qui est en dessous de ton appli et la déployer. En fait, si je n'ai même pas y pensé, je n'ai pas besoin d'être DevSecOps, j'ai juste besoin d'être DevOps et la sec, elle est faite par quelqu'un d'autre. Je le paye, c'est certain, c'est à eux de gérer. Mais au moins comme ça, je me focalise sur quelque chose. Pour moi, j'ai peur quand tu évoques l'idée de DevSec, potentiellement FinOps et compagnie. En fait, on a tellement de choses à penser. Pour moi, on est encore limité. Il y a trop et c'est peut-être mon problème mais le contexte switching ou autre ça nous tue c'est-à-dire que quand il faut penser à tout ça à la fin t'es crevé et en burn out donc j'aurais tendance à dire vaut mieux mettre la charge sur quelqu'un ou quelque chose d'autre quand c'est un système externe, ou des IA qui vont le faire mais je pense qu'elles vont cramer pas mal de tokens pour le faire pour nous H24. Plutôt que d'essayer de tout faire soi-même et encore une fois tout à l'heure tu disais tu parlais de personnes qui on peut aller parler à nos ops et des fois il y a des murs, les organisations, les meet-ups et ce genre de choses sont aussi des événements où on peut aller parler à des ops qui ne sont pas nos ops de notre boîte. Et donc ça permet aussi d'avoir des feedbacks et des visions d'autres personnes. Il y a beaucoup d'événements, on a la chance en France d'avoir une communauté de meet-ups et de conférences extrêmement importantes et c'est très souvent pour moi l'occasion de discuter avec des personnes pour leur dire, tiens, tu fais comment les choses, comment tu testes, comment tu vois de ton point de vue de dev, d'ops, de sec ou autre. Donc ça, ça amène une valeur mais tout mettre sur la même personne. Je n'y croyais pas il y a 8 ans. Avec tout ce qu'on peut faire encore plus aujourd'hui, j'ai encore plus de mal à y croire aujourd'hui malheureusement.
Bruno:
Quand tu parles de service manager, on est quand même d'accord que les services managers ça s'adresse à... Il y a des organisations jusqu'à une certaine type, il y a quand même un moment, où tu es obligé de revenir à des systèmes que tu maîtrises pleinement parce que tu as un certain niveau d'échelle, tu as besoin de maîtriser de manière un peu plus précise.
Kevin:
Ça dépend. J'aurais tendance à dire que ça dépend. J'ai bossé pour des boîtes où ils n'ont pas les moyens d'acheter des data centers. Même si tu veux faire cette économie, il y a eu un très bon article de la personne qui est derrière Ruby qui a dit que lui, il sortait du cloud et il allait remettre de l'argent dans des bais réseaux. Ouais, tu peux le faire. Tu peux, c'est un coût. Il faut l'évaluer correctement. Est-ce que ton cœur de métier, c'est de gérer des équipes qui vont mettre des choses dans des data centers, des lames et compagnie ? Peut-être pas. Encore une fois, c'est mon fameux fast et plus important que big. Si tu vas vite et les services managers te permettent de tester vite, d'échouer vite et de passer au truc suivant. Si pour un projet il y a du jour au lendemain tu te dis t'as besoin de faire ton propre modèle tu vas construire ton propre data center pour faire ton apprentissage et une fois que tu l'as fait tu te retrouves avec un data center sur les bras dont tu ne sais plus quoi faire donc pour moi les services managés c'est. Une solution. Peut-être que ce n'est pas la seule solution. Effectivement, si tu veux faire de l'économie d'échelle, mais encore une fois, si ton business model te permet de prendre en charge ce coût et du jour au lendemain de te dire, on arrête, on ne le fait plus et donc on n'a plus besoin de payer ce service, je trouve que c'est une sécurité que le côté financier de payer ses propres machines, payer les gens qui vont les gérer. Parce que du manager, ce n'est pas que payer un système qui tourne, ils vont te faire les patchs, ils vont te mettre à jour c'est d'un confort de se dire mon cluster est-ce qu'il est à jour ? En fait tu ne te poses même plus la question il est toujours à jour, quand tu dois l'installer toi-même l'opérer toi-même, faire les rolling il t'en faut des gens pour faire tout ça et donc pour moi encore une fois si ce n'est pas ton coeur de métier est-ce que tu as envie d'investir là-dedans ? Peut-être pas donc ça va être vraiment dépendant.
Bruno:
Top, merci beaucoup Kevin en tout cas pour cette conversation, j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast, la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Kevin:
Alors, un contenu, puisque tu m'as dit que je pouvais, c'est un contenu de Joker qui n'est pas forcément tech. Donc, moi, ma série préférée que j'aime d'amour, Sense8, que je conseille à tout le monde, que j'adore et que j'ai un plaisir énorme à voir et revoir jusqu'au dernier épisode. Netflix a fait un petit bijou avec les soeurs Wachowski et c'est quelque chose de génial. Je recommande.
Bruno:
D'ailleurs, je suis assez surpris. C'est une série qui a quoi ça a presque 10 ans ? je crois, Sensei, peut-être même 10 ans. J'ai l'impression depuis quelques mois, tu n'es pas le premier à m'en reparler. Je le revois popper partout. Il y a une actu particulière autour de...
Kevin:
Pas à ma connaissance. Il parle, puisque ce sont les Sarwajovski, il parle d'un nouveau Matrix et dans le précédent Matrix, il y a eu beaucoup d'acteurs de Sensei, donc peut-être que ça amène l'idée qu'on va revoir ce que les personnes qui ont fait une oeuvre, ce qu'elles ont fait avant. Mais sinon, passer ça, non, je n'ai pas connaissance d'actualité. Moi, j'ai suivi ça dès les premiers jours. Je l'ai recommandé partout autour de moi. J'ai saoulé beaucoup de gens qui se reconnaîtront avec cette série et qui l'ont adoré après. Et ça m'a fait énormément plaisir. Mais sinon, en dehors de ça, non, je n'ai pas d'actualité précise.
Bruno:
Je recommande aussi Sense8, qui a un travail hyper impressionnant de mise en scène, de coordination de dialogue, de truc qui est absolument hyper… C'est autant le fond que la forme. Oui, ça vaut vraiment le coup. Et la dernière question, Kevin, qui est de loin la plus importante de ce podcast. Kevin, est-ce que tu es plutôt espace ou tabulation ?
Kevin:
On triche maintenant, c'est les IA qui décident, non ? C'est vrai alors personnellement ça va être ça va dépendre du langage en fait dans les langages standards ça va être des tabulations mais avec du YAML que je fais beaucoup trop ça va être des espaces parce qu'ils refusent les tabulations avec Kubernetes donc ça dépend très.
Bruno:
Bien c'est noté merci beaucoup Kevin pour cette discussion.
Kevin:
Merci à toi et.
Bruno:
Merci à tous d'avoir écouté cet épisode voilà je le redis allez regarder vos logs, allez regarder ce qui se passe côté Ops, parce que c'est une source d'apprentissage qui est effectivement colossale. Mais comme le dit Kevin, intéressez-vous à ces métiers-là pour voir un peu comment est-ce qu'au moment où vous commencez votre implémentation, quand vous commencez à structurer vos applications et vos services, de déjà prendre en compte ces sujets-là. Parce que, effectivement, côté Ops, ça peut être aussi un monde serein, un monde agréable dans lequel on a potentiellement peut-être tous envie d'aller. De mon côté, comme toujours, je vous remercie de partager ce podcast autour de vous, n'hésitez pas à aller checker. Les différents liens en description de cet épisode pour profiter des différents services de DIVTTD, je vous remercie beaucoup je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.
