Transcription de l'épisode : "Achille Monga, Comprendre les principes de l’approche DevOps"
Terry : Salut Achille, merci de prendre du temps aujourd'hui pour échanger autour du DevOps. Donc on va parler un peu de cette pratique, de comment ça s'intègre aussi avec le monde du produit qui est un sujet que je traite évidemment plus sur ce podcast. Mais l'idée c'est de faire communiquer un peu aussi le monde de la tech et du produit avec ce podcast. Donc d'où l'intérêt d'échanger autour de ces pratiques. Avant de rentrer dans le vif du sujet, est-ce que tu peux te présenter et nous dire ce que tu fais ?
Achille : Oui, merci de m'avoir invité sur ton podcast Terry. Pour me présenter rapidement, je m'appelle Achille Monga. Je suis actuellement architecte de cloud et DevOps, un ancien développeur backend qui a suivi la mouvance du DevOps il y a quelques années. Et du coup, je suis tombé également dans cette mouvance-là.
Terry : Très clair, du coup par rapport à qu'est-ce que c'est que ce métier-là pour toi, comment tu le définirais en termes, tu vois, des missions derrière ça ? Qu'est-ce que ça veut dire pour toi que de faire du DevOps ?
Achille : Déjà, le DevOps en base zéro, je dirais que ce n'est pas un métier en fait, c'est d'abord une philosophie. Si on veut faire l'analogie avec le produit ou la gestion de projet, on peut faire facilement l'analogie avec l'agilité. Le DevOps en fait c'est une façon de penser, c'est un état d'esprit je dirais, qui a pour but d'amener l'agilité qu'il y a dans le développement logiciel sur la partie opérationnelle, la partie déploiement, monitoring des applications.
Terry : Ok, donc par rapport à cette première définition autour de ça, comment tu... D'un point de vue très concret, on va prendre un logiciel type logiciel SaaS, qui se déploie dans le cloud, donc qui n'a pas besoin d'être installé physiquement sur des machines pour pouvoir être utilisé. Là, où est-ce que tu positionnes le DevOps dans la construction de logiciels comme ça ?
Achille : Je positionnerais le DevOps bien en amont du logiciel final que l'utilisateur peut commencer à manipuler. Le DevOps, comme je le disais, c'est une philosophie qui, à partir des différentes techniques qui sont appliquées, va permettre à ce que l'utilisateur final ait un logiciel le plus stable possible et qui répond à ses attentes. Quand je dis le plus stable possible, c'est que si par exemple un utilisateur détecte une erreur sur le logiciel final à l'utilisation, il faudrait que grâce au DevOps, le correctif qui sera appliqué au logiciel va se faire dans un temps très court. grâce à plusieurs techniques. Donc parfois même lorsque l'équipe est mature, l'utilisateur final n'aura pas le temps de se rendre compte qu'il y a eu une erreur. Il y aura déjà tout un ensemble de mécanismes qui ont été mis en place pour détecter cette erreur-là et pouvoir la corriger le plus rapidement possible.
Terry : Et donc là-dessus, premier point, je trouve hyper intéressant sur ce sujet justement de bugs qui sont même pas visibles en fait d'utilisateurs, même pas visibles du coup si je prends la cascade plus produit de l'équipe produit parfois, parce que côté tech ça a été géré quasiment automatiquement grâce à différentes mises en place de monitoring et derrière de correctifs de patch. à la volée pour comprendre du coup comment ça s'est mis en place en fait, comment tu peux mettre en place ce type de mécanisme.
Achille : Je parlais des techniques tout à l'heure, donc le DevOps c'est une philosophie qui est appuyée par ses techniques, donc généralement quand on parle DevOps, la première technique c'est l'automatisation. Il faudrait que la plupart des actions qui sont mises en place sur le logiciel pour le déployer soient automatisées. Quand on parle de DevOps, la première base c'est d'automatiser toutes les actions manuelles de release de l'application. Cette automatisation passe par la mise en place de ce qu'on appelle des pipelines CICD pour Continuous Integration et Continuous Deployment ou Delivery en fonction de comment l'application est réalisée. C'est le premier socle. donc automatiser tout le déploiement de l'application via des pipelines CI/CD. Et du coup dans ces pipelines là qui sont le socle de l'approche DevOps, on peut mettre en place plusieurs techniques aussi. Donc comme pipeline, il faut le voir exactement comme dans une usine de voiture par exemple, il y a des chaînes pour assembler la voiture. C'est pareil lorsqu'on parle de DevOps et d'automatisation de release de l'application. Dans les pipelines, c'est où va se jouer une bonne partie de l'approche DevOps. Dans ces pipelines-là, on va mettre en place ce qu'on appelle des tests d'intégration continue. C'est vrai que ces tests-là dépendent bien évidemment de ceux qui ont développé l'application. Ils doivent mettre en place des tests robustes. Donc du coup, dans la pipeline, on va pouvoir les déclencher de façon automatique lorsque le code change. côté de ça aussi on peut mettre en place toutes les techniques pour checker les erreurs ou des virus dans le code ou la librairie qui sont utilisés par l'application. Donc on va faire ce qu'on appelle des scans de l'analyse statique de code ou de l'analyse dynamique de code Donc.
Terry : Déjà, sur cette première phase, c'est-à-dire que le socle technique des suites CI-CD qui permettent de contrôler en fait le code à l'intégration et ensuite de déployer de manière automatique, le premier point je pense qui est important à comprendre, c'est sur cette phase de CI, d'intégration en continu. Donc tu as parlé de deux choses, tu as parlé des tests d'intégration qu'on pourrait relier aussi avant même les tests unitaires également à ce niveau-là. et de l'analyse statique de code. Donc ces deux choses, par exemple, c'est des choses qui, pour être mises en place, pour bien comprendre, vont nécessiter un travail en amont. C'est-à-dire que les tests, ils ne viennent pas tout seuls, il faut les écrire, il faut les coder.
Achille : Il faut qu'ils soient à jour, qu'ils soient versionnés, c'est aussi une des choses que je n'ai pas parlé. Le versionning, c'est capital, versionner le code et versionner les tests. Généralement, ce que l'on fait dans la pratique, c'est que le code et les tests sont dans le même repository, du coup. Donc tout est bien versionné et les tests doivent évoluer en même temps que le code. Et sur ça, il y a également ce qu'on appelle une approche pour développer les logiciels et prendre en compte les tests, le TDD, Test Driven Development, qui va permettre en fait, lorsqu'il est bien appliqué, cette pratique là, va permettre en fait de développer un code qui est soutenu par des tests à côté.
Terry : Là-dessus, tu touches du doigt le TDD qui est en fait une façon de penser un peu inverse, c'est-à-dire que tu écris tes tests avant d'écrire ton code, ou en tout cas tu écris ton code pour que les tests et ensuite tu écris ton code pour qu'ils répondent aux tests. Je sais pas toi comment tu... si tu devais compléter ce que je viens de dire.
Achille : Oui, c'est vrai que le TDD fait beaucoup de débats dans la communauté, comment il doit être vraiment utilisé et appliqué. D'autres vont dire que c'est du test-force, mais ce n'est pas vraiment de mon point de vue. Comme je t'ai dit, c'est ASN, en tout cas c'est clivant dans la communauté. Il n'y a pas une définition claire et nette. Donc je dirais que le TDD, c'est construire un logiciel testable, pour moi. Peu importe que les tests viennent avant ou après le code vu que ton code que tu produis puisse être testable.
Terry : Très, très, très clair. Par rapport, pour revenir sur la phase d'écriture des tests et d'écriture également de configuration de plus, on va dire, des outils d'analyse statique de code, pour prendre la casquette là, je reprends une casquette plus produit, pour comprendre le temps aussi nécessaire aux équipes techniques pour mettre en place ces bonnes pratiques. Si tu devais, je ne sais pas, donner un peu un ordre de grandeur, tu vois, entre j'ai une fonctionnalité à développer qui va me prendre, par exemple, deux semaines de travail de mon équipe, Par rapport à ces deux semaines de travail, sachant que je n'ai pas encore en place tout cet environnement, quel est le temps nécessaire à mettre en place un environnement dans un premier temps CI-CD et dans un deuxième temps à coder les tests qui vont correspondre à ces nouvelles fonctionnalités qui devraient prendre en théorie deux semaines à être implémentées ?
Achille : Généralement, et aussi basé sur mon expérience d'ancien développeur, généralement si une fonctionnalité a développé, il fallait rajouter 50% si on voulait avoir une bonne couverture des tests déjà. Et en fait lorsqu'on chiffrait, que ce soit en points, en journée, en travail, généralement le développement de la fonctionnalité plus les tests Si tu dois développer la fonctionnalité en un jour, tu dois mettre un jour de test aussi pour avoir un code assez propre.
Terry : Donc ça fait x2 par rapport à...
Achille : Oui, ça dépend aussi de la séniorité de la personne qui développe. Un développeur senior pourra mettre moins de temps, mais c'est généralement sur cette gamme de temps-là. Donc les tests plus la fonctionnalité, c'est... C'est x2.
Terry : Et donc ce qu'on peut voir, déjà le premier point là-dessus, les gains, tu les as mentionnés au tout début, mais pour comprendre aussi les gains qu'il y a derrière ça, c'est-à-dire que grâce à ces tests, tu vas pouvoir anticiper des bugs avant même qu'ils n'arrivent. C'est ça, oui. Et surtout, éviter les régressions lorsque tu fais des évolutions.
Achille : Exactement, parce que moi, dans le début de ma carrière, j'ai eu intervenu dans des projets où il n'y avait pas ces tests. Et le développeur se retrouve à avoir peur de faire une simple modification et de casser l'existant. Pourtant quand tu arrives dans un projet où il y a des tests, toi en tant que développeur c'est la plage, tu es à l'aise, tu sais que les modifications que tu vas faire dans le code il n'y aura potentiellement pas de régression parce qu'il y a des tests qui valident des fonctionnalités et si ta modification casse une fonctionnalité, tu le sais au commit directement par exemple.
Terry : Yes, donc ça, pareil, pour bien imager ce que tu viens de dire, quand tu vas faire une modification de code qui va avoir un impact sur l'existant, cette modification de code, ton code est versionné, c'est-à-dire que tu suis les évolutions, tu vas commit, donc tu vas dire j'ai fait une modification sur ce bout de code-là, et automatiquement, quand tu as configuré ton pipeline d'intégration continue, ce commit va être vérifié par le pipeline, il va aller du coup refaire tourner les tests précédents qui avaient été écrits, et se rendre compte là qu'effectivement il y a peut-être un breaking change, et donc te forcer à ne pas te laisser fusionner, donc merger ton commit sur la branche tant que tu n'as pas corrigé le bug.
Achille : Exactement, c'est exactement ça.
Terry : Et là effectivement, il y a vraiment un gain derrière sur la maintenabilité dans le temps de ce qu'on construit.
Achille : Sur la robustesse aussi de l'application du coup. Donc si on est sûr qu'on a des tests pertinents sur l'application, on est sûr que notre projet, que l'application fonctionne, on est plus enclin de rajouter des nouvelles features parce que j'ai déjà vu chez certains clients L'application fonctionne, on ne veut pas toucher. Sachant qu'il y a des nouvelles features, on a peur de rajouter de nouvelles features parce qu'il n'y a pas de tests qui valident déjà ces features qui étaient existantes.
Terry : Donc là, ça me fait penser, enfin ce que tu viens de dire, il y a deux sujets que j'aimerais aborder par rapport à ça. Tu viens de parler donc chez certains clients, du coup t'arrives et on te dit non, touche pas parce que ça marche mais on sait pas ce qui se passe si tu touches à ça. Ça c'est du vécu et c'est vrai que c'est vécu quand même de beaucoup de monde dans la tech parce qu'en réalité, entre les nouveaux produits qu'on crée versus la maintenance corrective ou évolutive, la majeure partie du travail, en tout cas côté tech, c'est très orienté sur de la maintenance corrective évolutive. Et donc sur des produits existants. Donc j'aimerais dans un second temps qu'on... Enfin, on peut aller sur ce sujet-là, c'est-à-dire que pour ces contextes-là, c'est-à-dire bah t'as déjà une très grosse base de code existante, pour autant il va falloir faire des évolutions, faire de la maintenance, tu n'as malheureusement pas encore tes tests unitaires, t'as pas la capa de temps et de ressources pour aller tout réécrire, et en même temps il va falloir faire des évolutions. Donc c'est quoi un peu, toi, les bonnes pratiques, les stratégies que t'as pu voir mettre en place, ou des choses qui marchent ? pour réussir à faire le mieux du moins bien, entre guillemets, et quand même pouvoir commencer à mettre en place des bouts de bonne pratique sans rentrer dans le faut-tout ou faire hyper carré.
Achille : Oui, je vois très bien. Et c'est une problématique que j'ai eue chez un client. Et ce que j'ai mis en place, c'était de, au fur et à mesure, d'essayer déjà de documenter l'existant. Parce que parfois, tu arrives chez le client, il n'y a pas la documentation. Donc, c'est documenter l'existant, et commencer à intégrer par partie en fait de l'application, donc généralement isoler, essayer de voir dans l'application les parties les moins critiques et c'est sur cette partie-là de commencer à faire une mise à jour du coup. Donc sur cette partie moins critique, commencer à réécrire des tests d'intégration pour cette partie-là et ainsi de suite. Donc avancer par petit bout, vu qu'on a un existant qui est généralement qui fonctionne, Donc avancez pas petit bout et essayez de rajouter de nouveaux tests à ces parties qui existaient déjà.
Terry : Et du coup, quand tu vas cibler, donc ce que tu dis c'est que les tests que tu vas rajouter, au départ, cibler les parties qui sont effectivement, si jamais elles devaient être cassées, ça a moins d'impact sur le produit.
Achille : C'est ça, c'est ça. Ok.
Terry : C'est intéressant ce que je réponsais au contraire, du coup d'aller tout de suite chercher les parties importantes, mais pour toi, pourquoi du coup tu considères qu'il vaut mieux faire Déjà c'est pour limiter le.
Achille : Risque parce que si tu as une application qui est en production, qui est utilisée par des utilisateurs finaux, l'idéal ce ne serait pas de casser en fait l'existant parce que ça va aussi entraîner des changements de l'autre côté. Donc l'idéal c'est de partir plus des petits bouts et ainsi de suite jusqu'à ce que tu arrives à ouvrir ton application.
Terry : Ok, très clair. Est-ce que, du coup, par rapport à ça, comment tu le fais rentrer dans une roadmap existante, ce travail-là ? Parce que ce n'est pas toujours évident de réussir à évangéliser pour dire qu'il faudrait qu'on prenne un peu de temps pour écrire du test unitaire sur cette partie. qu'est-ce que toi t'as pu vivre comme situation ou en tout cas essayer d'éduquer les clients à justement la pertinence de mettre en place ce type de test sur du code existant qui fonctionne déjà ? Parce que moi je me mets post sur client, je pourrais dire bah en fait mon application elle fonctionne, je ne te demande pas de faire deux semaines juste pour faire du test sur un truc où à la fin je ne verrai rien de nouveau, je préférerais juste qu'au bout des deux semaines j'ai quelque chose de nouveau quoi.
Achille : Oui, généralement dans ce cas-là c'est lorsque le client il rencontre des pain points, il voit en fait qu'il y a quelque chose qui ne marche pas bien. et l'idée c'est généralement de lui faire comprendre qu'il faut par exemple rajouter 20% de temps pour faire du test et généralement aussi avoir l'appui de ton PO pour pouvoir discuter avec le client pour qu'on essaye de rajouter déjà un petit temps pour pouvoir écrire ces tests là.
Terry : Ok. Ouais, donc aller chercher du support aussi à ce niveau-là.
Achille : Ouais, c'est ça.
Terry : Très clair. Du coup, le point auquel ça me faisait penser tout à l'heure quand tu parlais de ce travail d'écriture, de couverture des tests, c'est dans un contexte très, très early. Donc, tu vas avoir une boîte qui est en train de chercher son marché, qui va travailler sur un logiciel SaaS, on va dire B2B, quelque chose d'assez commun dans le milieu des startups. Et du coup, la volonté tu vois d'aller très vite pour tester des choses et donc si tu dis à un fondateur ben en fait là on estime la charge à une semaine si on le fait à l'arrache versus deux semaines si on le fait bien, puisqu'on fait x2 pour y ajouter du test et je parle même pas de bien faire le code, je parle juste de mettre une couverture de ce test propre derrière. Comment trouver un équilibre là-dedans ? C'est-à-dire qu'on pourrait se dire, bah en fait, ça ne vaut pas la peine. Enfin, on pourrait se dire, même moi je me le dis, c'est-à-dire que sur quelque chose qui peut-être aura une durée de vie de deux mois, pourquoi s'embêter à aller faire un code ultra bien couvert d'un point de vue test pour une pseudo-maintenance qui n'arrivera jamais ? Puisqu'en fait, c'est un code qu'on va acheter dans deux mois versus tester des choses et itérer rapidement.
Achille : Comment toi tu... De mon experience... Chaque fois qu'on a dit qu'on va ajouter le code dans deux mois, c'est devenu en fait l'application finale, c'est devenu le cœur de l'application finale. J'ai rarement vu chez un client où on a dit on va partir sur un code sale sur deux mois et ensuite on va recommencer à zéro. Généralement le client lui il est content quand tu lui dis oui on va faire vite tu auras un truc qui va sortir mais dans la réalité c'est généralement ce petit truc qui sort c'est lui c'est celui qu'on commence à itérer pour pouvoir avoir le produit final. Et là par exemple sur ma dernière émission on a eu le même cas où le client voulait une fonctionnalité rapidement pour faire une démo avec son client à lui Et il voulait un truc jetable littéralement, il dit c'était ses propres propos, il veut un truc jetable pour aller vite. Mais on lui a dit non, ça fait pas longtemps que ça marche. En plus le client lui-même déjà il était en... Il avait des soucis de trésorerie et il voulait allouer du temps pour faire un truc jetable. Et ensuite recommencer à zéro pour pouvoir faire un truc plus propre. Et on lui a démontré qu'en faisant un truc jetable, tu vas déjà cramer du budget. pour faire ce truc de jetable et ensuite il faudra encore débloquer du budget pour recommencer à faire un truc beaucoup plus propre.
Terry : Donc pour toi, la situation du jetable, elle n'est jamais bonne ?
Achille : Non, elle n'est jamais bonne. Toujours partir sur des bonnes bases, pas forcément mettre dès le départ ceinture, bretelles, tout ça.
Terry : Donc là-dedans, j'aimerais bien que tu creuses ça, c'est-à-dire plutôt que de mettre ceinture et bretelles, comme tu dis, quels sont alors du coup dans cette base de se dire, non, on part pas sur quelque chose de jetable, en revanche, on va pouvoir nuancer à quel niveau tu pourrais mettre ces curseurs ?
Achille : Ouais. Tu sais que ceux-là, je peux les mettre au niveau déjà de la couverture des tests. Tu n'es pas forcément obligé d'avoir un code de couvert à 100% parce qu'il y a aussi des développeurs qui sont fans de couverture des tests à 100% alors que ça ne veut pas dire grand-chose. Tu peux juste tester le cœur de ton application et ça, ça se fait rapidement. Ça ne va pas... Je dis aussi si le développeur est quelqu'un d'un peu senior, il saura en fait isoler la partie critique de l'application à tester et ensuite partir sur cette base là. On n'est pas obligé d'avoir un code couvert à 100% pour qu'il soit testable et maintenable.
Terry : — Là-dessus, donc, sur cette couverture de test, comment... Donc là, tu identifierais clairement à l'inverse de quand tu arrives sur un code existant où tu vas aller essayer de mettre du test sur les fonctionnalités mineures. Quand tu es sur un nouveau code et que tu veux limiter la charge représentée par l'écriture de test, là, tu vas aller cibler l'écriture de test sur les fonctionnalités majeures.
Achille : Oui c'est ça, il faut aussi faire les tests sur les fonctionnalités majeures et les fonctionnalités qui sont la colonne vétérale du produit. C'est sur eux qu'il faudra mettre un peu plus d'accent. Les autres parties on peut on peut évoluer sans...
Terry : Très clair. Donc là, on a fait un bon tour sur la partie CI, donc sur la partie intégration continue, c'est-à-dire avant que ton application se trouve en production et avant même... Oui, enfin voilà, avant qu'elle se trouve en production, c'est-à-dire que ce dont on vient de parler permet de prévenir de bugs en amont.
Achille : Oui, c'est ça.
Terry : Mais tu prenais l'exemple au début de la philosophie autour du DevOps qui va permettre de résoudre des situations parfois avant même qu'elles aient été découvertes par les utilisateurs finaux ou même d'autres équipes en interne, l'équipe produit par exemple. Donc ça, c'est des situations qui peuvent intervenir aussi en aval quand l'application est en production. Après la partie CI, il y a la partie CD, continuous deployment ou continuous delivery en fonction de comment... Donc là-dessus, sur la partie SIDI, quelles sont les bonnes pratiques ? Parce que moi, mon expérience que je vois surtout, c'est juste qu'il faut être capable de réussir à déployer de manière assez simple, de mettre en place une structure par exemple sur un tag spécifique, sur un commit, tu sais que c'est ça qui va déclencher le déploiement. Et peut-être après du différent... Toi, c'est quoi un peu là-dessus les recommandations, les bonnes pratiques ?
Achille : Oui, comme tu l'as dit, essaye de faire au plus simple. Déjà, bien choisir la plateforme cible où sera déployée l'application. Ça, c'est aussi un élément clé en fonction du trafic. Il faut prendre cela en compte. Est-ce qu'on aura des releases assez rapides ? Est-ce qu'entre deux releases, le temps entre deux releases, ce genre de choses, il faut les prendre en compte et essayer d'avoir une chaîne CD la plus simple possible. Aujourd'hui dans l'approche DevOps, il y a plein d'outils qui permettent de le faire. ou juste le plus simple, c'est des scripts de batch qui vont aller déployer sur la plateforme cible.
Terry : Là-dessus, tu parles de plateforme cible, ça me fait penser aux plateformes, on parle souvent d'environnement, il y a l'environnement des développeurs sur leur machine, il y a l'environnement d'intégration qu'on peut appeler Qt qui va être là où on intègre le code. et ensuite tu vas avoir un environnement de prod, ou parfois il y a la pré-prod même entre les deux. Combien d'environnements déjà, on va dire, quels sont un peu les projets que tu trouves qui ont le mieux fonctionné ? Il y avait déjà combien d'environnements intermédiaires entre la machine du développeur qui travaille à la journée, jusqu'à l'application qui est dans les mains de l'utilisateur final ?
Achille : Généralement on passe sur trois environnements. Généralement on a trois environnements, on a un environnement de dev, un environnement de pré-production, ou QA, et un environnement de production. Généralement, les pipelines de CD ont l'essai de partir du dev, ensuite de la pré-production vers la production.
Terry : Et au niveau du déclenchement de ces pipelines-là, du coup, tu vas avoir de l'automatique à tous les étages, ou tu vas essayer de... Ou par exemple, tu vois, moi, ce que j'ai pu vivre, c'était que la partie production, on déclenchait uniquement à la main. C'est-à-dire que le déploiement en production n'était pas fait par l'automate.
Achille : Généralement, sur la partie production, on fait un déploiement manuel, généralement. 90% des projets sur lesquels je travaille, c'était ça. Sur les autres environnements, c'était automatisé, mais pour réaliser un prod, il fallait juste cliquer sur un bouton pour réaliser l'application.
Terry : Et donc ça, ça permet de limiter les erreurs humaines, pour comprendre aussi l'intérêt de ça, au-delà du temps gagné, c'est-à-dire que tu vas éviter, ah oui, j'ai oublié de configurer telle variable, ou j'ai oublié de changer tel fichier, puisque c'est tout automatisé, à partir du moment où c'est bien configuré, sans risque humain à ce niveau-là. En revanche, ça ne couvre pas encore la problématique de j'ai un bug en prod, et j'ai réussi à le corriger avant même qu'il ait été détecté.
Achille : Et là, c'est toute la partie monitoring, parce qu'il y a la même partie super importante dans la prod de DevOps, il y a la partie monitoring de l'application. Et ça, ça se passe via d'autres outils. ces outils là qui vont permettre par exemple d'aléter lorsqu'il y a un log d'erreur qui remonte ou par exemple lorsqu'on se rend compte qu'il y a des pics de consommation de ressources matérielles qui peut déclencher une alerte à l'équipe qui se charge de suivre l'application.
Terry : Et ça, pour toi, tu le mets dans l'approche DevOps ?
Achille : Oui, la partie monitoring. Logging et monitoring généralement. Ces deux parties-là également sont vitales dans l'approche DevOps.
Terry : Et donc là, pareil, sur des bonnes pratiques, qu'est-ce qu'il y a un peu le standard, on va dire, pour toi, qui fonctionne bien, toujours dans une typologie produit, tu vois, SaaS, B2B ? Est-ce que tu vas te reposer vraiment sur du système de monitoring existant sur ta plateforme cloud par exemple qui va héberger ton application ? Qu'est-ce que tu trouves qui fonctionne bien ? Un des travers autour du monitoring, la pertinence n'est pas... à prouver, puisque évidemment ça te permet de remonter des choses en temps réel, et du coup de détecter beaucoup de problématiques. En revanche, la question qui se pose quand tu mets en place ce type de process, c'est souvent jusqu'à où je pousse les logs, jusqu'à où je pousse l'information que je remonte, parce que des fois, trop d'infos, ce n'est pas bon. En même temps, parfois quand tu as certains bugs, il te manque des infos pour aller investiguer ce qui s'est passé. Où est-ce que tu mets le curseur là-dessus ?
Achille : Généralement, en ce qui concerne déjà les logs, il faut avoir des logs qui sont structurés. Et du coup, pour avoir des logs structurés, c'est à utiliser du JSON, par exemple, pour pouvoir encoder ta chaîne de caractère de logs, pas juste du plain text. Parce qu'avec du JSON, il y a des outils qui vont te permettre de facilement parser ton JSON et de pouvoir, par exemple, détecter facilement qu'il y a eu une erreur. donc c'est avoir des logs structurés et en ce qui concerne la quantité de logs c'est à l'équipe de pouvoir définir en fait par exemple en production on veut juste des logs qui génèrent au niveau erreur par exemple et aussi avoir un outil qui va nous permettre de requêter facilement ces logs là aujourd'hui on a plein de stacks techniques qui permettent de le faire et aussi si par exemple l'application est déployée chez un cloud provider généralement ces cloud providers proposent déjà des services managés tout fait qui ont.
Terry : Ces features là Très clair, du coup, sur ce sujet du log, ça me fait revenir au développeur, c'est-à-dire que là, pour loguer de manière structurée, ça veut dire qu'aussi dans le code, il faut que ça soit logué de manière structurée.
Achille : C'est vrai que c'est au développeur, bien sûr, de pouvoir bien construire sa chaîne de log, d'utiliser la bonne bibliothèque pour faire ses instructions de log.
Terry : Et ça pareil sur un travail de développement, pour toi est-ce que c'est quelque chose en fait qu'il faut considérer de la même manière que l'écriture des tests ou est-ce que c'est juste que ça doit faire partie des bonnes pratiques de développement et donc ça doit être intégré juste dans la charge de base d'un ticket ?
Achille : Ouais pour moi en fait c'est l'écriture du code, ça doit être énormément transparent sur la partie estimation.
Terry : Yes, très clair là-dessus. Du coup, maintenant ça me fait penser, là je vais volontairement challenger un peu le rôle du DevOps, c'est-à-dire que tu.
Achille : As expliqué au début que c'était une.
Terry : Philosophie au-delà d'être juste un métier, et là on vient de voir quand même sur pas mal de points qu'il y avait pas mal de tâches qui retombaient côté développeur en fait, pour pouvoir avoir cette chaîne DevOps bien en place. Du coup, Pour toi, quel est le rôle des profils DevOps qu'on peut voir dans certaines boîtes ? Est-ce que c'est en fait un rôle intermédiaire qui vient, enfin on va dire « éphémère » entre guillemets, qui doit venir le temps de tout mettre en place, mais ensuite quand ça roule en soi, tu n'as pas besoin de DevOps engineer puisque tout est déjà en place et que normalement ça devrait tourner ? Ou est-ce qu'il faut toujours avoir quelqu'un qui va permettre de maintenir tout ça ? C'est quoi un peu toi ta vision là-dessus sur ce métier-là ?
Achille : Pour moi, ça va dépendre de la typologie du produit. Là, on a parlé d'un produit en mode SaaS, donc une application. Là, je dirais généralement sur ce type de produit-là, le rôle de DevOps peut être facilement pris par un développeur qui est un peu curieux. Par exemple c'est mon cas, je me dis que je suis DevOps, en fait je suis développeur à la base et du coup cette technique pour automatiser le déploiement de mon code je l'ai appris du coup de facto parce que je développe une application, je veux savoir la déployer, je veux que mon client ait l'application lorsqu'il se connecte à sa page web. Donc du coup, naturellement, tu apprends les techniques qui te permettent de pouvoir facilement déployer l'application et tout ça. Mais il y a également de notre côté ceux qui s'occupent des serveurs, qui hébergent nos applications. Ceux qui étaient en ce moment des admins SIS, qui eux également commencent à être dans cette mouvance DevOps là pour automatiser par exemple tous les scripts qui sont nécessaires pour configurer les serveurs qui hébergent nos applications quand on déploie. C'est eux qui vont monitorer également ses serveurs. Je dirais que ça dépend. Si tu es dans un squad produit qui développe un logiciel SaaS qui est hébergé sur un cloud provider, sachant qu'aujourd'hui les cloud providers proposent des services qu'on appelle les services managés, où il n'y a pas forcément besoin d'Ops pour opérer la plateforme. Là, le DevOps, en fait, ça peut être même de l'équipe de dev qui, naturellement, c'est à chercher, c'est documenté, c'est auto-formé généralement. Mais du côté gestion des serveurs, c'est beaucoup plus, comment dire ça, c'est vraiment un rôle dédié parce qu'il y a toute cette partie administration des systèmes, des serveurs qui entre en jeu aussi.
Terry : Oui, là-dessus, c'est bien que tu fasses la distinction entre les deux. Et effectivement, il y a un monde entre les applications SaaS que l'on va pouvoir déployer sur des AWS, des Azure de chez Microsoft, Google ou autres, ou OVH, ou Scaleway.
Achille : Et encore, je peux te dire aussi, si par exemple on déploie sur du cloud, Généralement il faut, c'est vrai que là potentiellement il faut un rôle à plein temps de DevOps pour gérer toute cette partie cloud là. Parce que aussi avec le cloud ça entraîne plein de nouvelles missions à réaliser. Parce qu'instancier par exemple une VM sur un cloud provider pour déployer une application SaaS, ça implique que la personne, le DevOps, sache comment manipuler ce cloud provider-là. Donc généralement oui, là il faut vraiment une personne dédiée dans l'équipe qui va permettre de gérer cet aspect cloud. Parce qu'il y a aussi toute la partie finance du cloud qui entre en jeu.
Terry : Tout à fait, ouais, et tu fais bien de le mentionner là-dessus, c'est-à-dire que le cloud, on peut avoir tendance à penser que c'est moins cher, mais en réalité, effectivement, la donnée, quand tu veux la récupérer, ça peut coûter vite très cher. Ça coûte pas cher à l'envoyer, mais quand tu veux la rechercher...
Achille : Si on a parlé des serveurs dans le cloud, il faut les monitorer pour checker la facture à la fin du.
Terry : Mois si... Oui, c'est un très bon point de vue.
Achille : Que ce soit les serveurs ou même les services managés, parce qu'il y a des services managés par exemple out of box pour faire du logging, du monitoring qui sont là, mais ces services ont un coût qu'il faut monitorer aussi et parfois il faut faire des ajustements côté cloud pour pouvoir baisser la facture client.
Terry : Yes, très bon point là-dessus. Et du coup, pour revenir sur l'autre aspect, donc là, ce que tu expliques, c'est que même sur ces cloud managers, en fait, effectivement, ils abstraient, il y a beaucoup d'abstractions en termes de complexité, mais il y a des nouveaux métiers qui sont créés de facto parce qu'il y a beaucoup de configurations à faire pour ne pas ensuite se retrouver avec une facture beaucoup plus salée qu'attendue.
Achille : C'est vrai que dans l'émission, on va te parler de DevOps, mais je dirais plus un cloud engineer. Celui qui va manipuler le cloud et permettre de l'utiliser de façon la plus efficace possible.
Terry : Et après, donc pour toi, la partie DevOps reste un rôle à part entière dans le cas des services plus IT infra d'une boîte qui va avoir des.
Achille : Serveurs... Oui, là, aujourd'hui, on ne parle même plus, je ne pense pas qu'on parle plus trop d'Admin 6, on parle de DevOps, parce que toute cette partie automatisation est également rentrée côté Admin 6. Donc aujourd'hui, de leur côté, l'Admin 6 font pas mal de scripts, que ce soit des scripts Terraform ou des scripts Ansible pour automatiser la gestion de leurs serveurs. Et aussi, ces scripts-là sont versionnés, l'usine logicielle est ramenée aussi côté Admin 6.
Terry : Très, très clair là-dessus. Et pour toi, c'est quoi du coup l'évolution de ce métier-là, dans les deux aspects ? Sur la partie peut-être de cloud manager, alors comme tu disais, c'est plus un cloud engineer que devops, mais il y a quand même toute la philo derrière, versus dans le cas d'infrastructures où il y a beaucoup de serveurs on-premise, beaucoup de choses à monitorer, et où du coup l'ancien administrateur système est devenu un peu le devops. C'est quoi pour toi l'évolution de ces deux profils dans les prochaines années avec l'évolution des techno aussi ?
Achille : L'évolution des deux profils, pour moi je pense que Ce sont des profils qui vont émerger par la suite parce qu'on se rend compte qu'aujourd'hui, que ce soit côté cloud ou côté adminsys, la plupart du temps on a à peu près des problématiques similaires. Donc les problématiques de monitoring comme on disait tout à l'heure, les problématiques de déploiement de serveurs, parce que côté cloud aujourd'hui on fait beaucoup de déploiement de machines virtuelles qui sont des serveurs qu'il faut pouvoir configurer à la volée, qu'il faut pouvoir monitorer. Donc pour voir l'évolution Ça serait un rôle hybride entre le cloud manager et le on-premise. Ça serait une personne qui est capable de faire les deux, de joindre les deux mondes du coup, parce qu'aujourd'hui on parle aussi beaucoup de cloud hybride. et plein de ces cloud providers sont en train de pousser des solutions qui vont permettre facilement aux administrations de faire ces administrations en mode hybride, que ce soit côté cloud, que ce soit côté enterprise, et de les faire communiquer ensemble.
Terry : Hyper intéressant là-dessus, moi ça fait écho à pas mal de discussions que j'ai pu avoir avec d'autres de mes pairs, et ça me fait penser du coup sur, pour toi, ça me fait rebondir sur une autre question, plutôt pour clarifier ce que tu entends par cloud hybride, moi ma compréhension que j'en ai c'est qu'on est en train de revenir un petit peu en arrière sur de tout mettre sur le cloud, c'est-à-dire de se rendre compte que parfois ça coûte très cher de mettre sur le cloud et c'est pas nécessaire, et du coup maintenant on a de plus en plus des organisations qui font un peu des deux, c'est-à-dire que Certaines données qu'elles soient stratégiques ou très importantes et besoin d'accès fréquent vont rester sur des serveurs physiques chez soi parce que ça va coûter moins cher de maintenir ces serveurs-là, et l'usage du cloud va être fait peut-être de.
Achille : Manière plus sporadique pour certaines applications, pour certaines workloads. C'est vrai que c'est une tendance qui émerge aujourd'hui et c'est vrai que tous les principaux fondateurs de cloud aujourd'hui proposent en fait des outils clés en main qui vont permettre en fait à l'administrateur de pouvoir facilement à la fois gérer son pack sur le cloud et en on-premise. Donc c'est vraiment une mouvance qui a vraiment le vent pour actuellement. où on ne dit plus, migrez tous vers le cloud, fermez vos serveurs, c'est trop cher, mais plutôt utilisez les deux mondes.
Terry : Ok, très très clair. Mais je pense qu'on a fait du coup un bon tour autour du sujet de DevOps. Est-ce qu'il y a des points en particulier avant d'aller vers les questions de fin d'épisode que tu aimerais mettre en avant, dont tu trouves qu'on n'a pas assez parlé ?
Achille : Pour moi, si on veut parler de la philosophie du DevOps, je dirais qu'aujourd'hui c'est incontournable. Si tu veux faire un produit qui aura du succès, il faut que tes équipes intègrent cette approche DevOps dès le début pour que ce soit plus facile ou qu'on essaie d'intégrer ces différentes pratiques du DevOps dans la chaîne de création de valeur de l'application.
Terry : Très clair, yes. Sur l'importance du DevOps aujourd'hui, ça devient effectivement incontournable. Après pour un peu aussi prendre de la hauteur par rapport à ce que tu disais, en fonction des produits, ça peut juste vouloir dire parler justement en plus de philosophie DevOps et faire en sorte que son équipe de dev fasse bien les choses de ce point de vue-là, sans rentrer dans un surcoût additionnel d'une personne nécessaire en plus. Mais par contre, déjà commencer à poser des premières briques avec, comme tu le disais, s'il faut rationaliser au début, se concentrer sur les choses les plus importantes, les plus impactantes avant d'avoir un panel complet.
Achille : Oui, et je dirais pour une application, pour moi ce serait déjà consolider sa pipeline CI-CD. Parce qu'on sait qu'aujourd'hui l'application sort en fonction du marché, il faut être en avant-garde, donc c'est consolider sa pipeline CI-CD qui va permettre de facilement réaliser les nouvelles versions de l'application. Une fois que ça c'est fait, ensuite rajouter toutes les autres techniques du DevOps, le monitoring, le logging. Donc déjà se concentrer sur cette partie-là de pipeline CI-CD une fois qu'elle est faite, rajouter d'autres concepts au-dessus.
Terry : Top, très très clair. Du coup, pour aller vers mes deux questions de fin, donc la première c'est est-ce que tu as une position forte, un sujet climat sur lequel tu te retrouves en général en désaccord avec tes pairs ?
Achille : Oui, c'est l'utilisation, on a parlé tout à l'heure de cloud et aujourd'hui sur les principaux cloud providers on peut instancer des machines virtuelles ou on peut faire ce qu'on appelle du serverless c'est à dire que tu es payé, aujourd'hui les cloud providers parlent de pay as you go Donc tu n'es par exemple facturé qu'à la requête. Et pour moi, là par exemple dans ma dernière mission, j'ai eu une grosse discussion pour passer en serverless. Je sais que beaucoup de personnes n'aiment pas le serverless parce que tu ne sais pas forcément ce qui se passe derrière. Mais pour moi, pour une application qui va être lancée et pour laquelle on a fait le choix d'aller vers du cloud, mais où on ne sait pas encore quelle sera la charge, le nombre d'utilisateurs qui va consommer l'application, Pour moi c'est au lieu de passer sur des VM, l'idéal c'est de passer sur du serverless et le plus tôt possible faire ce qu'on appelle des containers docker. Ce docker aujourd'hui c'est la technologie on peut dire la technologie phare pour réaliser des applications. et avec du serverless par exemple c'est du google tu es capable si ton application ne reçoit pas de requêtes depuis quasiment zéro à la fin du mois alors que si tu instances des serveurs où tu vas déployer ton application en mode classique tu vas payer le coût CPU, tu vas payer le coût des disques sans que oui tu peux mettre en place des politiques où tu peux éteindre tes serveurs à certaines heures de la nuit ou de la journée en fonction du trafic mais pour moi une approche serveur si c'est d'application est l'idéal.
Terry : Assez intéressant là-dessus sur l'aspect serverless, le coût quand tu payes à la requête, est-ce que je vois l'intérêt, c'est-à-dire que si tu n'as pas de requête, tu ne vas pas payer. Oui, il y a ça. Mais moi je vois le risque aussi que si d'un coup tu as un pic, tu vas payer très cher.
Achille : Ça dépend du service que tu vas utiliser. Par exemple, quand je prends le cas de Google, aujourd'hui, l'offer serverless pour faire du compute, donc pour faire du calcul, elle a mieux d'adapter du marché. Ça s'appelle Cloud Run et avec ce service-là, il suffit juste d'avoir ton application sous forme d'image Docker et automatiquement, tu as du scaling automatique, tu as du logging, du monitoring déjà installé, il fait que même pour quelqu'un qui veut lancer une application rapidement, tu n'as pas besoin forcément de quelqu'un qui est.
Terry : D'Un DevOps.
Achille : Chevronné pour arriver à le faire. Donc, tu peux facilement aller sur le marché avec ton application en suivant quelques bonnes pratiques de DevOps. Donc, il y a ce gain-là déjà que tu peux avoir côté, si tu utilises du serverless et aussi si tu, par exemple, tu utilises des bases de données aussi serverless managées. Je prends toujours le cas de chez Google. aussi tu auras des coûts, généralement je prends le cas de Google parce que je maîtrise bien, les coûts sont assez limités par exemple sur du Cloud Run tu es littéralement payé 0 pour le million de requêtes Pour avoir un million de requêtes, il faut quand même avoir du trafic sur ton site. Ça dépend, je comprends bien ton point de vue. Parfois le serveur se retrouve à être beaucoup plus... beaucoup plus coûteux que si tu avais par exemple instancié tes propres machines directement mais pour moi pour un produit qui est en early stage et qui veut prendre des pas du marché ce genre d'approche là est l'idéal sachant que si tu es sur des conteneurs tu peux facilement switcher quand tu te rends compte que la charge devient importante. Tu peux maintenant passer sur des machines virtuelles qui sont managées sur un Kubernetes par exemple.
Terry : Ouais, donc à suivre et comme ça tu peux éviter de tomber après de te dire... Oui, c'est ça.
Achille : D'où l'idée d'avoir un cloud engineer qui maîtrise un peu de FinOps pour pouvoir voir et savoir quand passer sur des technologies un peu plus robustes si je peux dire.
Terry : Très clair du coup pour aller vers ma dernière question, c'est un peu les choses qui te nourrissent intellectuellement, comment toi tu t'inspires pour progresser dans ta pratique professionnelle ?
Achille : Pour progresser, c'est vrai que moi je suis un fait avant des farceurs de Google, donc du coup c'est beaucoup de lectures sur le blog technique, donc ils vendent plein de ressources qu'ils mettent à disposition, des labs aussi pour pouvoir bien manipuler les services qu'ils proposent. Donc eux aussi, pas mal de veilles technologiques en suivant des podcasts ou en suivant des conférences comme DevOps par exemple, qui a lieu chaque année où il y a plein de nouvelles thématiques qui apparaissent.
Terry : Ok, top, je mettrai les liens du coup dans la note. Et puis je te remercie encore pour ton temps et ton partage.
Achille : Merci à toi de m'avoir invité.
