Electro Monkeys

Le podcast pour découvrir et comprendre les concepts et les technologies cloud natives ! Des interviews techniques sur Kubernetes, les technologies cloud natives et la communauté open source.

C'est la rentrée d'Electro Monkeys, et l'équipe s'agrandit : Nicolas, Shérine et Thomas sont désormais trois aux commandes. Pour ouvrir cette nouvelle saison, nous recevons Guillaume Lours, ingénieur chez Docker sur Docker Compose, et Philippe Charrière, solution architect chez Docker, autour d'une question qui brûle les doigts de tous les développeurs : jusqu'où peut-on vraiment laisser un agent IA travailler seul ?Le mode YOLO a déjà coûté quelques machines réinstallées et quelques bases de production. La réponse de Docker s'appelle Docker Sandbox (SBX) : une micro-VM qui embarque l'agent et son propre engine, et surtout un proxy en sortie qui filtre ce que l'agent peut atteindre et lui cache les secrets grâce à des placeholders. Guillaume et Philippe détaillent les profils par défaut, la gouvernance d'entreprise, les templates et kits, l'exécution déportée dans le cloud de Docker, et les façons de garder son IDE ou Claude Desktop tout en restant dans la sandbox. Ils racontent aussi comment ils travaillent au quotidien avec leurs agents, et pourquoi la sandbox change tout pour relire une pull request externe sans risquer ses clés SSH.La seconde partie élargit le cadre : où en est WebAssembly chez Docker, pourquoi Swarm n'est plus un projet Docker, et comment Compose Bridge transpose un fichier Compose en manifestes Kubernetes ou en charts Helm pour relier le poste du développeur à la production. Philippe termine sur les petits modèles locaux, ce qu'ils savent déjà faire sur un laptop et ce pour quoi il faut encore un modèle distant, avant que nos invités ne donnent leurs prochaines dates de conférences.

Dans le contexte actuel, Les entreprises croulent sous les données qui se multiplient à la vitesse de sortie de frameworkjs et se retrouvent éparpillées dans tout le SI. C'est ici qu'intervient l'orchestration de données. Elle permet de centraliser, de transformer et de charger des informations, offrant une vision unifiée de l'ensemble. Au premier abord, Kestra est une startup française, mais c'est bien plus. Sa mission est de révolutionner l'orchestration de données grâce à son projet open source. Sur GitHub, la plateforme a déjà conquis des milliers d'utilisateurs, témoignant d'un intérêt marqué pour ses fonctionnalités innovantes. Nous recevons aujourd'hui Loic Mathieu non pas comment sur faire une extension quarkus mais bien parler de Kestra et des son violon d'Ingres pour l'opensource.

Dans cet épisode, nous abordons des questions cruciales sur la sécurité dans l'environnement cloud native et Kubernetes. Pourquoi parle-t-on tant de cloud native security de nos jours? Quels sont les nouveaux défis et vecteurs d'attaques que nous sous-estimons lors de l’adoption des containers ou de Kubernetes? 🔍 Explorez avec nous: Les nouveaux challenges de la sécurité Cloud Native. Comment Kubernetes a-t-il radicalement modifié la gestion de la sécurité? Comment fournir des environnements sécurisés sans créer de frustration aux différentes équipes? 🎤 Animé par notre architecte cloud Imad Bensisaid, ce podcast met en lumière les perspectives précieuses de nos invités de marque: ✨ Maxime Coquerel, Microsoft MVP Azure & Security, Lien vers son blog : https://zigmax.net ✨ Mathieu Benoit, CNCF Ambassador & GDE Cloud Lien vers son blog : https://medium.com/@mabenoit ✨ Vincent Ledan, Leader en Cloud Native Security (point base) Lien vers son blog : medium.com/@vincn.ledan et https://pointbase.hashnode.dev/series...

Lors du premier KCD France, nous avons eu la chance de pouvoir interviewer Solomon, un monsieur qui compte beaucoup pour nous tous. Car sans lui et sa talentueuse équipe chez Docker, beaucoup ne seraient pas là à pousser du container par monts et par vaux. Aujourd'hui nous ne parlerons pas de Docker (même si...) mais de son dernier bébé très prometteur qui révolutionnera peut-être à nouveau le monde IT et plus précisément celui de la CI/CD. C'est tout le mal que nous lui souhaitons car pour avoir travaillé avec, c'est rafraichissant et assez disruptant. Merci à toi, Solomonstre

Aujourd’hui nous aurions pu recevoir Philippe Charrière pour nous parler de Framework JS, de Golang, de Golo, de Gitpod, d’IoT, de la recette de la potée auvergnate au chou ou même encore de tout l’immense univers Gitlab pour qui il travaille en tant que Senior Customer Success Engineer. La liste des sujets possible avec Philippe est une liste à la Prévert. Et bien ce sera un sujet très hype dont le nom cache de nombreuses surprises et pose des questions que Philppe va tenter de nous éclarcir. Merci à toi de nous faire part de ton expérience autour de WebAssembly.

Pour nous parler de R2Devops, hub open-source et collaboratif de ressources CI/CD pour GitLab, nous recevons aujourd'hui Thomas Boni un des deux cofondateurs de ce projet OSS et de la société R2DEVOPS derrière le projet. Thomas nous parlera du pourquoi de la solution mais aussi de son parcours d'entrepreneur et des leçons à en retenir. Ils seront sur le stand de Vivatech courant Juin à Paris. Bonne écoute à toutes et à tous.

Aujourd’hui Nous allons parler de Fairphone, une entreprise qui s’est lancé le défi gigantesque de changer en profondeur le marché des smartphones. Pour parler de longévité de produit chez Fairphone je reçois avec plaisir leur tech lead Agnès Crepet dont le nom ne doit pas vous être pas inconnu. En effet j’ai été fort grand consommateur des livres et tutoriaux de l’équipe de Ninja Squad, belle petite société lyonnaise autour de Angular, Vue... dont Agnes est une des fondatrices parmi les 4 ninjas. Agnes, Java Championne en 2012 est une grande activiste et pas seulement dans le monde Java avec le LyonJug, les Duchess, MixIT conf lyonnaise autour de la mixité dans l’IT mais aussi dans la vie associative et culturelle lyonnaise. Elle est présente aujourd'hui pour nous parler de la société atypique Fairphone et de ses enjeux. Aurore Stéphan à l'USI, Paris 2022 Ruée minière au XXIè siècle : jusqu'où les limites seront-elles repoussées ? : https://www.youtube.com/watch?v=i8RMX8ODWQs Podcast Neotravail : https://soundcloud.com/user-23653367/rencontre-avec-agnes-crepet-militante-engagee-pour-une-tech-ethique-et-decoloniale

Team topologies est un sujet important pour quiconque s’intéresse à construire la meilleure organisation possible pour ses équipes tout en conservant des valeurs comme l’autonomie, l’auto organisation et la responsabilité. Ce sera le coeur même du sujet du jour avec Julien Topçu. Julien, coach technique chez Shodo et membre de la fondation OWASP, est venu aujourd'hui nous parler de Team Topologies ainsi que de la loi de Conway. Quelques références citées dans l'épisode Organizing business and technology teams for fast flow https://teamtopologies.com/

Fin 2022, Google a annoncé de nombreuses nouveautés et évolutions sur les services Cloud durant l'événement Next. Que faut-il en retenir ? Pour ceci, nous avons le plaisir de recevoir Alexis Moussine-Pouchkine, responsable des relations développeurs chez Google. Il aide les utilisateurs de la région EMEA à tirer le meilleur parti de Google Cloud sous toutes ses formes.

La gestion de la donnée est ce pourquoi nous développons la plupart de nos applications. Un site marchant en est le parfait exemple. Cependant il semblerait que dans ce domaine la programmation orientée objet montre ses limites. Le data oriented programming est une autre manière d’apprehender notre approche de la donnée dans notre code. Et dans ce domaine, Yehonathan Sharvit, mon invité aujourd’hui, en connait un rayon, puisqu’il est l’auteur de Data-Oriented programming au edition Manning. Avec lui nous allons discuter des concepts du data oriented programming, à quoi il sert, quels sont ses cas d’usage, mais nous allons aussi tenter de savoir s’il s’applique a tous les langages avec lesquels nous prenons plaisir à programmer. Notes de l'épisode Le livre Data-Oriented Programming:https://www.manning.com/books/data-oriented-programming Le blog de Yehonathan Sharvit :https://blog.klipse.tech/ L'article de Brian Goetz sur Data-Oriented Programing in Java:https://www.infoq.com/articles/data-oriented-programming-java/

Nous sommes, William et moi-même, ravis aujourd’hui de recevoir dans le podcast Clément Escoffier et Julien Ponge, ce dernier pour la seconde fois. Tous deux émérites universitaires et Principal Software Engineer chez Red Hat, ils ne vont pas se contenter d’itérer les avantages de la programmation réactive mais aussi répondre à nos questions sur Quarkus et Mutiny.

Un plugin réseau est une brique cruciale au sein Kubernetes, car c'est grâce à lui qu'il est possible de créer un réseau au niveau du cluster. Depuis l'arrivée de la Container Network Interface, ou CNI pour faire court, il est très facile de brancher n'importe quel plugin qui réponde à cette interface ; et ces plugins sont légions ! Dans ce domaine, Calico est le couteau suisse des CNI. On le retrouve dans différentes configurations que ce soit des distributions on premise ou chez les Cloud Providers. Pour nous parler de l’écosystème Calico, nous avons le plaisir de recevoir Stéphane Reytan. Stéphane est directeur général sécurité de Blue Trusty et ensemble nous discuterons de Calico dans sa version Open Source qui permet de créer une plate-forme active de protection et d'observabilité des applications , mais aussi de l’offre Enterprise proposé par Tigera.

En matière de marketing, comme dans l’immobilier, les trois choses les plus importantes sont l’emplacement, l’emplacement, l’emplacement. Un des emplacements incontournables pour mettre en valeur son site internet et son produit, c’est dans les résultats des moteurs de recherche. Les internautes privilégient les premiers résultats de leurs recherches qui bénéficieront de plus de trafic que les résultats plus bas dans la première page. Figurer sur la deuxième page, c’est quasiment synonyme de l'inexistence. Tout ce qui peut être fait pour grappiller quelques places peut améliorer considérablement le trafic qui arrive sur les pages de son site web. Dans l’épisode d’aujourd’hui, Stéphane reçoit Jean-Marc Courtiade pour discuter de SEO, Search Engine Optimization. Jean-Marc est consultant en SEO et en analytique du numérique. Il aide différentes organisations à augmenter le trafic sur leur site, à optimiser la performance de leur offre numérique et à se mettre en conformité avec la RGPD. Il a travaillé avec des acteurs dans différents secteurs. Stéphane et Jean-Marc parleront des différents critères connus utilisés par les algorithmes d’arpentage et de classement des pages web. Ils discuteront des actions incontournables, de pourquoi ces actions sont utiles et des pistes à explorer pour améliorer son positionnement.

Un plugin réseau est une brique cruciale au sein Kubernetes, car c'est grâce à lui qu'il est possible de créer un réseau au niveau du cluster. Depuis l'arrivée de la Container Network Interface, ou CNI pour faire court, il est très facile de brancher n'importe quel plugin qui réponde à cette interface ; et ces plugins sont légion ! Il y en a UN cependant qui se démarque du lot : Cilium. En effet, Cilium a pris le parti depuis le jour 1 d'utiliser eBPF pour gérer le réseau, la ou les autres reposent le plus souvent sur Netfilter. Or si Cilium a su tacler la concurrence en tirant le meilleur parti d'eBPF pour la mise à l'échelle, son voyage au cœur d'eBPF ne s'est pas arrêté là. L'Observabilité, les capacités de Service Mesh et de Sécurité sont autant d'aspects d'eBPF qui peuvent être intégrés à un network plugin. Pour nous dévoiler la magie qui se cache derrière eBPF, j'ai le plaisir de recevoir Robin Hahling, mon invite de l'episode 20 sur Hubble qui est Software Engineer pour Isovalent, la société derriere Cilium, et Raphaeël Pinson, Solutions Architect également chez Isovalent. Ensemble nous discutons bien évidemment de Cilium et d'eBPF, mais aussi de toutes les nouveautés qui ont été apportées ces deux dernières années a Cilium. Notes de l'épisode What’s new in Cilium 1.11? How Cilium Protects Against Common Network Attacks Isovalent announce Tetragon , an eBPF-based Security Observability & Runtime Enforcement Quelques nouvelles de My Little Team Les 50 meilleures équipes B Corp pour qui travailler en 2022

Ces dernières années, on fait vraiment grand cas de la donnée. Mais ne vous êtes-vous jamais demandé de quoi était faite la donnée, ou en d'autres termes : qu'est-ce qui constitue la donnée ? Une fois les data points établis, que faire de la donnée ? Est-ce qu'elle est stockée, transformée, manipulée ou analysée ? Et si oui comment, par qui et à quelle fin ? Pour répondre à toutes ces questions, je reçois Aurélien Allienne. Aurélien est Head of Data pour SFEIR Lille, et ensemble nous allons brosser le tableau des pipelines de données, de l'ingestion à la restitution.

Nous sommes tous, à différents niveaux, des utilisateurs Linux, et nous pourrions même aller jusqu'à dire d'une ou de plusieurs distributions Linux. Le concept même de distributions, ou de familles de distributions peut paraître étrange à première vue, puisqu'elles utilisent toutes le même noyau. Si ce qui distingue principalement les familles est le système de packaging des binaires, ce qui distingue les distributions est plutôt les outils qu'elles intègrent par défaut ou qu'elles choisissent de maintenir. Mais vous êtes-vous jamais posé la question de la complexité que pouvait représenter la création d'une distribution Linux ? Dans cet épisode, je reçois Kevin Chevreuil qui est le créateur de Kaisen Linux. C'est pour lui un side project, puisqu'il est ingénieur GNU/Linux spécialisé dans la sécurité, mais c'est pour nous l'occasion d'en découvrir un peu plus sur le monde fascinant des distributions Linux.

L'univers des startups est un univers fascinant. Partir d'une idée pour en faire un produit, quel voyage palpitant, mais qui ne s'arrête jamais en cas de succès ! Le produit ne cesse d'évoluer, la stack logicielle change et se diversifie, et les fondateurs qui ont souvent pris les postes clé dans l'entreprise doivent aller vite, s'adapter et évoluer eux aussi. Aujourd'hui, je reçois Jean Lebrument. Jean est actuellement le CPO de Brigad, et c'est une évolution récente de son poste, puisqu'il n'y a pas longtemps encore, il en était le CPO et le CTO. Jean nous raconte les choix qu'il a dû faire, par rapport à l'évolution de Brigad, et pourquoi il a décidé de se retirer de son rôle de CTO.

Les jeux rétro sont pour beaucoup un chouette souvenir d'enfance, que vous ayez été jeux d'arcade, console ou pc. Mais étrangement, ils ont survécu, ils ont passé l'épreuve du temps et ils sont toujours là, sur les consoles rétro, sur les Raspberry Pi ou qui sait ou encore ! Il y toujours autour d'eux une communauté de bidouilleurs passionnés qui les font revivre, presque intacts après toutes ces années. Aujourd'hui, j'ai le plaisir de recevoir David Hecq. David est le créateur de la très populaire chaîne Youtube Gunhed TV, mais aussi l'auteur des Chroniques de Gunhed, que vous pouvez retrouver sur Amazon. Une merveilleuse occasion de parler des jeux d'hier, d'aujourd'hui et de demain ! Notes de l'épisode Gunhed TV : https://youtube.com/c/GunhedTV Chroniques de Gunhed TV - Volume 1 : https://amzn.to/34JmCjv Au programme de ce livre damné : la terrible confrontation entre les firmesAtari, Mattel et Colecoà la fin des années 70 et qui s'est achevée avec le crash des jeux vidéo.Pourtant au départ, on y croyait en ces machines. Elles nous vendaient du rêve en pixels et nous promettaient mille et une merveilles vidéoludiques. On évoquera également la rocambolesque histoire duKonix Multi System, tout simplement un système d'arcade à domicile avec siège monté sur vérins. En lieu et place, on a eu droit à une explosion en plein vol, suivie d'une absorption par le trou noir de l'histoire des jeux vidéo où l'on a parfois la fâcheuse tendance de ne retenir que les succès. Malgré tout, derrière ces flamboyants échecs, il y a des hommes (et un peu de femmes) qui ont porté ces projets à bout de bras et qui a force de persévérance et de passion, ont réussi à les commercialiser. Vous en conviendrez, ces personnes méritent à minima qu'on raconte leur histoire... Chroniques de Gunhed TV - Volume 2 : https://amzn.to/35Y9LKP Au programme de ce second tome : laVectrex, l'O.V.N.I. des années 80, l'Amiga CD32et la mort (terrible) deCommodore, laJaguarou le dernier rugissement d'Atariet enfin,NEC PC-FX: la grande désillusion.

Les tests de charge sont une étape importante du développement d'une application et de son cycle de vie. En effet, ils permettent de tester les limites de certains composants, de valider une architecture et de s'assurer qu'elle se met à l'échelle correctement, mais aussi parfois d'éliminer des bugs de l'application elle-même. Mais avoir un bon outil, capable de vraiment tester l'application au travers de parcours utilisateur et de remonter des données fiables n'est pas chose évidente. Et même Wikipedia a une définition erronée du test de charge. Aujourd'hui, je reçois donc celui qui fait mentir Wikipedia, j'ai nommé Stéphane Landelle. Stephane est le CTO de Gatling, une solution de test de charge open source écrite en Scala et fournissant un DSL Java permettant de créer du test as code. Notes de l'épisode A quoi sert le test de charge: https://gatling.io/2020/03/what-are-the-objectives-of-a-load-test/ Pourquoi la moyenne et l'écart type ne servent pas à grand chose: https://gatling.io/2018/11/metrics-analysis-load-testing-deviations/ Pourquoi on ne doit calculer les moyennes de centiles: http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-you-cant-average.html https://www.circonus.com/2018/11/the-problem-with-percentiles-aggregation-brings-aggravation/ https://orangematter.solarwinds.com/2016/11/18/why-percentiles-dont-work-the-way-you-think/

Peut-être ne nous en rendons-nous pas compte, mais aujourd'hui la plupart des outils SaaS que nous utilisons sont américains. Il n'y a évidemment aucun mal à cela, du moins de mon point de vue, mais qu'arriverait-il si pour une quelconque raison la France ou l'Europe n'étaient plus en bons termes avec les Etats-Unis ? Pourrions-nous toujours accéder non seulement à nos outils, mais également aux données qui y sont hébergées ? Ce sont ces réflexions qui ont amené Christophe Chaudier, mon invité du jour, à concevoir Froggit : un ensemble de services permettant d'héberger sa base de code de manière souveraine. Christophe, que j'ai déjà eu l'occasion de recevoir ici est un mentor DevOps, fondateur des compagnons du DevOps, podcasteur, youtubeur, j'en passe et dernièrement le créateur de Froggit dont il vient nous parler plus en détails. Notes de l'épisode Le Linkedin de Christophe : https://www.linkedin.com/in/cchaudier/ Le site de Froggit : http://froggit.fr/ Le concept de SaaS Libre : https://youtu.be/qTlqL89UmsQ La neutralité du Net s’effrite ! (embargo des US sur l'iran) :https://www.linkedin.com/feed/update/urn:li:activity:6579664951630196736/ L'article de Shahin Sorkh https://shahinsorkh.ir/2019/07/20/how-is-it-like-to-be-a-dev-in-iran Lydra : http://lydra.fr/ La chaîne YouTube des Compagnons du DevOps : https://www.youtube.com/c/LesCompagnonsduDevOps La chaîne YouTube sur l'entreprenariat de Christophe : https://www.youtube.com/channel/UCvZFN6J1okCiIG4LKIXqSpg Docusaurus : http://docusaurus.io/ Les Lives Docusaurus et GitLab pages : https://www.youtube.com/watch?v=OwXsEiQTdmo&list=PLR2-Y4yF_vcgK4BeImt4SUy7izAvYrMBX

Il ne vous arrive jamais de ne pas comprendre en quoi consistait un poste en lisant son intitulé ? Autant lorsqu'on parle d'un dev ou d'un ops les choses sont à peu près claires, mais ce n'est pas toujours aussi simple. Aujourd'hui, j'ai la chance de recevoir l'un de ses oiseaux rares, puisque son job à lui c'est field engineer. David Blaskow est en effet field engineer chez Traefik, et dans cette discussion nous allons en apprendre un peu plus sur son métier et sur son quotidien.

Au fil du temps, VMware a su se construire un écosystème entier autour de son produit phare : vSphere. J'ai déjà eu l'occasion ici de parler de Tanzu, bien évidemment, et aussi d'Antrea. Et aujourd'hui, pour nous aligner avec une des top tendances de 2022, nous allons parler de sécurité notamment au travers de deux produits : NSX-T et CarbonBlack. Pour parler de ces sujets tout aussi complexes que passionnants, j'ai le plaisir de recevoir Tuan Nguyen, Chef de produit technique et expert sécurité réseau chez VMware, et Stéphane List, expert VMware en sécurité des endpoints, workloads et containers. Notes de l'épisode: NSX-T et Container Networking: 2022 update- NSX:https://www.youtube.com/watch?v=6ErlfFmaoSg Lightboard: NSX Container Networking vision:https://youtu.be/HxwmBV3eGfE Deepdive Antrea container networking: https://www.youtube.com/watch?v=7Xpq-GVp2Qo Carbon Black security: Introduction pour Carbon Black: https://www.youtube.com/watch?v=DkEqgdBRUDs Container security with CarbonBlack DevSecOps: https://www.youtube.com/watch?v=d_RhLLssYXo Plus de détails sur le sujet (1000+ articles publiés et a jour): https://nsx.techzone.vmware.com/ https://carbonblack.vmware.com

Dans certains secteurs comme notamment l'IT, le temps est au changement. Peut-être est-ce dû à la pandémie, peut-être est-ce seulement le cycle naturel des choses, mais aujourd'hui beaucoup de personnes ont fait le choix de repositionner leur carrière en fonction de leur style de vie. Travailler moins, travailler différemment, travailler pour une cause digne d'être défendue, mais ne plus travailler comme un automate, jour après jour, juste pour percevoir son salaire a la fin du mois. Cependant, ce n'est pas un changement si simple à effectuer : comment en effet trouver l'entreprise en mesure de nous apporter ce que l'on recherche ? Comment savoir qu'une entreprise est potentiellement la bonne pour être alignée avec nos choix personnels ? La bonne nouvelle, c'est que c'est désormais possible. My Little Team est une plateforme de recherche à dimension humaine qui vous permet d'étendre vos critères de recherche, comme les valeurs que défend une entreprise, les rythmes de travail qu'elle permet ou son style de management. Et pour en discuter plus en détail, j'ai le plaisir de recevoir Paul Gratian. Paul est co-fondateur de My Little Team et ensemble nous discutons de ce projet au cœur de ce qui sera peut-être une véritable révolution sociale dans les années à venir.

Pour ce dernier épisode de l'année, j'ai eu envie de revenir, mais également d'approfondir, le sujet d'un code soucieux de sa consommation énergétique. Y a-t-il des langages meilleurs que d'autres, des manières d'écrire et d'exécuter le code qui sont préférables à d'autres ? Et encore une fois, se pose la question de la mesure de la consommation énergétique d'une application, selon qu'elle est monolithique ou en microservices, conteneurisée ou non. Pour parler de toutes ces épineuses questions, j'ai le plaisir de recevoir Jérémie Drouet. Jérémie est Remote Senior Software Engineer chez Datadog, et plus précisément sur Vector, car comme vous le verrez, c'est un choix qu'il a fait pour se mettre en accord avec ses propres convictions.

Les cloud providers ne se limitent pas à AWS, GCP ou Azure, loin s'en faut. L'offre européenne, si elle ne rivalise pas en taille, a souvent d'autres atouts pour tirer son épingle du jeu, notamment en termes de réversibilité ou de souveraineté de la donnée. Parmi ces acteurs encore trop souvent méconnus du grand public, il y a Scaleway, un cloud provider a la pointe de l'innovation, surtout quand on pense à Kapsule, Kosmos, ou aux Function as a Service. Mais alors, quelle stratégie adopter lorsqu'on grandit dans l'ombre des géants du secteur ? C'est une question à laquelle Gaspard Plantrou n'a pas eu de mal a me répondre. Gaspard est VP PaaS products chez Scaleway, et aujourd'hui il nous partage sa vision sur le présent et l'avenir des produits de Scaleway. Notes de l'épisode Soumettez vos besoins a Scaleway: https://feature-request.scaleway.com/

Alors que les préoccupations sur le climat sont de plus en plus présentes dans notre quotidien, le Green IT lui ne semble être qu'à ses balbutiements. Ne me faites pas dire ce que je n'ai pas dit, je ne dis pas que personne ne s'en soucie, mais bien que nous sommes très mal outillés pour bien comprendre l'impact de nos systèmes d'information sur l'environnement. Heureusement, les choses changent (même si ça va doucement). Benoît Petit, mon invité du jour, est le fondateur de Hubblo, une société de monitoring des services techniques et de leur impact sur le climat. Une conversation qui s'annonce déjà palpitante ! Notes de l'épisode Scaphandre, pour mesurer la consommation électrique de vos SI : https://github.com/hubblo-org/scaphandre Mesurer, comprendre et réduire l'impact des services numériques sur le climat et l'environnement : https://hubblo.org/fr Mesure d'impact environnemental du numérique des organisations : https://boavizta.org/

Traefik est un software open source populaire, aussi bien pour sa simplicité d'utilisation que pour ses fonctionnalités. Et si vous ne le connaissez pas encore, je vous encourage vivement à écouter l'épisode 9 de ce podcast sur Traefik et Maesh. Mais aujourd'hui, ce n'est pas tellement du produit que nous allons parler, mais du parcours d'un homme, parti d'un projet open source, et qui au fil du temps a créé une entreprise à la renommée internationale. Cet homme c'est bien entendu Emile Vauge, fondateur et CEO de Trafik Labs, et ensemble nous retraçons son parcours, des débuts de Traefik jusqu'à aujourd'hui.

La persistance de la donnée a toujours été compliquée, notamment lorsqu'il s'agit de tacler des problèmes aussi délicats que la disponibilité ou la mise à l'échelle. Longtemps on s'est appuyé sur le modèle master/slave pour la haute disponibilité, mais si ça venait résoudre plus ou moins le problème, ça ne résolvait pas celui de la mise à l'échelle. Puis il y a eu l'arrivée des bases de données NoSQL : distribuées, "facile" a mettre a l'echelle, on pensait tenir la solution, mais c'était sans compter sur le fait qu'elles n'étaient souvent que peu appropriés pour du transactionnel. Aujourd'hui, on assiste à l'essor des bases de données SQL de nouvelle génération, comme Google Spanner, Cockroach DB ou encore Yugabyte. Et quoi de mieux pour en bavarder, que de recevoir Franck Pachot, développeur Advocate chez Yugabyte ?

Vous savez que la formation et même souvent l'auto-formation sont clés dans les métiers de l'IT, car avec un paysage aussi changeant, nos connaissances deviennent de plus en plus rapidement obsolètes. Mais comment trouver la formation qui couvre nos besoins, si au moins elle existe, tant parfois ils sont spécifiques ? Pour en parler, je reçois l'un des grands acteurs le l'autoformation : Xavier Pestel. Avec sa chaîne Youtube Xavki, il rassemble près de 30000 followers, preuve s'il en faut que les tutos sont un précieux support à notre besoin de connaissances quotidiennes.

L'observabilité est un sujet passionnant, et vous devez vous douter qu'il me passionne particulièrement puisque j'ai rejoins Datadog il y a peu. J'en ai parlé récemment, L'observabilité s'appuie sur les trois grands piliers que sont les logs, les métriques et les traces. Or une des difficultés avec l'observabilité, c'est qu'on utilise souvent plusieurs outils pour capturer toutes ces données, alors qu'elles ne prennent vraiment du sens que lorsqu'elles sont corrélées les unes avec les autres. Unifier les trois piliers de l'observabilité pour briser les silos a toujours été au cœur des préoccupations de Datadog. Et c'est avec plaisir que j'en discute aujourd'hui avec mon confrère Nicolas Narbais, Sr. Technical Account Manager chez Datadog.

Le stockage dans Kubernetes a longtemps été complexe et laborieux, et vous êtes peut-être de ceux qui l'ont appris à leurs dépens. Mais tout cela est maintenant loin derrière nous, et nous tirons aujourd'hui tous les avantages d'un stockage dynamique et distribué. Mais il reste encore à tacler un certain nombre de challenges, de portabilité de la donnée à sa sécurité, sans oublier les performances. C'est justement ce dont nous allons parler aujourd'hui en compagnie de Gabriel Ferreira. Gabriel était déjà mon invitérécemment pour nous parler de Pure Storage, puisqu'il en est le Directeur Technique France, mais cette fois, c'est Portworx qu'il vient nous présenter.

Qui ne connaît pas Doctolib ? C'est sans doute la licorne française qui a été le plus mise sous lesfeux de la rampe ces derniers temps, crise du covid aidant. Et tout le monde connaît ce cas d'école : qu'arriverait-il si soudainement on parlait de votre startup au journal de 20h ? Est-ce que votre infra tiendrait la charge ? Est-ce que votre application resterait disponible ? Ça n'a pas été un simple cas d'école pour Doctolib, mais une réalité. Mais alors, comment a-t-elle résisté ? Pour le savoir, quoi de mieux que de le demander directement au Chief Architect de Doctolib, j'ai nommé David Gageot ? Dans cette discussion, il sera bien entendu question de scalabilité, de cloud provider et de Kubernetes, mais aussi de mono repo et de boring architecture.

C'est l'épisode 100, et pour cet épisode, j'ai choisi de parler d'un projet qui me tient à cœur depuis longtemps, et ce projet c'est OpenStack. Je sais que ces dernières années, l'attention s'est terriblement tournée vers Kubernetes, mais avant l'arrivée de Kubernetes, tous les regards étaient tournés vers OpenStack. Il est légitime de se demander où en est le projet aujourd'hui ? A-t-il disparu, est-il toujours aussi actif ou a-t-il simplement atteint le stade de la large adoption ? Pour répondre à ces questions, j'ai le plaisir de recevoir Thierry Carrez, VP of Engineering at the Open Infrastructure Foundation, et Christophe Sauthier Directeur du conseil pour LinkByNet Amérique du Nord. Ensemble, nous revenons sur l'origine du projet, avant de parler plus en détails de son évolution, ce qu'il est aujourd'hui, et ce vers quoi il se dirige demain.

Le stockage des données est le B A-BA de nos infrastructures, et il a longtemps été un domaine coûteux et complexe, où obtenir une LUN pour y mettre ses données prenait un temps considérable. Mais, en partie sous l'impulsion du cloud, les usages et les attentes ont considérablement changés ces dernières années. En effet, là où nous avions pris l'habitude de faire les choses manuellement, comme d'étendre un système de fichier, de mettre en place du raid, ou encore de chiffrer la donnée, nous attendons aujourd'hui que toutes ces choses soient faite de manières automatiques, en jouant simplement sur des paramètres de configuration. Par ailleurs, les systèmes distribués, qu'il s'agisse de bases de données ou de Kubernetes, poussent encore plus loin ces exigences, notamment en termes de performances. Qui aujourd'hui voudraient voir son débit ou ses I/O limiter l'expérience utilisateur de son application ? Pour en parler avec moi, je reçois Gabriel Ferreira, Directeur technique chez Pure Storage France, qui met également en lumière un autre aspect du stockage : le stockage ever green.

VMware est une société bien connue pour ses outils d'infrastructure tels que ESX, vSphere ou NSX. Mais ce qu'on connaît moins sans doute, c'est le virage vers l'open source qu'a pris VMware ces dernières années. Et Kubernetes n'y est peut-être pas pour rien dans cette histoire. En effet, si elle s'appuie toujours sur son cœur de métier, l'offre Tanzu fait aussi la part belle à des projets open sources tel que Spring, Harbor ou Antrea. Bien sûr, ce virage s'appuie en partie sur le rachat de Pivotal, d'Heptio et de Bitnami, mais il semblerait qu'il est en train de changer l'ADN même de VMware pour en faire une société plus tournée vers sa communauté, même s'il elle n'en délaisse pas pour autant les entreprises qui lui font confiance depuis des années. Dans cet épisode je reçois Alexandre Caussignac, Senior Solution Engineering Manager chez VMware et Alexandre Roman, Tanzu Senior Solution Engineer, qui me parlent de l'offre Tanzu et du virage de VMware vers l'open source. Notes de l'épisode Spring : https://electro-monkeys.fr/41-les-defis-de-java-et-du-cloud-natif-spring-boot-avec-stephane-nicoll/ Cloud Native Buildpacks : https://buildpacks.io/ Open Policy Agent (OPA) : https://www.openpolicyagent.org/ Antrea : https://electro-monkeys.fr/65-antrea-un-sdn-dans-votre-kubernetes-avec-antonin-bas/

On entend souvent dire que les données sont le nouveau pétrole. Pourtant, certaines de ces données ont besoin d'être représentées pour être compréhensibles et interprétées. La visualisation de données, plus communément appelée dataviz est l'ensemble des méthodes qui servent à représenter ces données. C'est un domaine très particulier qui allie la créativité de l'artiste à la rigueur du mathématicien. Cependant la dataviz a deux visages : celui qui permet d'éclairer un jeu de données en nous le rendant compréhensible, et celui qui manipule ces mêmes données pour n'en faire ressortir que certains motifs. Victor Baissait, mon invité dans cet épisode, est à la fois développeur front end, web designer, journaliste musical et spécialiste des données et de la dataviz. Et c'est un vrai plaisir d'en discuter avec lui pour mieux comprendre ce sujet passionnant. Quelques liens utiles pour aller plus loin sur la Dataviz https://datavizcatalogue.com/ http://visualizationuniverse.com/ http://hereistoday.com/ http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html Vous pouvez également suivre Victor sur Youtube ou Twitch

Même s'il est là depuis longtemps, le edge est actuellement le monsieur sexy de l'IT, car il est le point de convergence entre l'IoT, le machine learning et le cloud. Aujourd'hui, le moindre appareil peut contenir un nombre incalculable de sensors, mais il n'a pas nécessairement la capacité de calcul pour prendre une décision en fonction de ces données ; et c'est donc au niveau du edge que des décisions peuvent être prises ou relayées. Mais il y a un revers à la médaille : la gestion d'un parc de plusieurs milliers de machines décentralisées pose des problèmes de maintenabilité et de sécurité. C'est pourquoi le edge tend à adopter les mêmes technologies que le cloud pour sa gestion de configuration ou son cycle de releases. Nicolas Barcet est Senior Director Technology Strategy à Red Hat, et s'intéresse particulièrement aux technologies du edge. Avec lui, je dresse l'état des lieu du edge tel qu'il est aujourd'hui, et ce vers quoi il tend à être demain. Notes de l'épisode Kubevirt était le sujet de l'épisode 82 avec David Szegedi : https://electro-monkeys.fr/82-kubevirt-avec-david-szegedi/

Le marché est en manque de développeurs, et malheureusement les écoles à l'ancienne peinent à former des devs ayant les compétences requises pour être rapidement autonomes et opérationnels. En effet, force est de constater que le monde du développement n'est plus celui d'il y a 10 ans, et moins encore celui d'il y a 20 ans. Je ne parle pas ici de l'évolution des langages de programmation, mais de celle des entreprises. Celles-ci sont de plus en plus mondialisées, de plus en plus distribuées, de plus en plus en quête des meilleurs candidats pour grossir leur rang. Et dans ce paysage, les hard skills ne font pas tout. Parler anglais, savoir comment travailler en remote ou être contributeur à l'open source sont des avantages significatifs. C'est justement ce paradoxe qui a poussé mon invité, Franck Jeannin, à créer une école d'un genre nouveau. Franck est le fondateur d'Algosup, et avec lui, je discute de ses motivations, des différences entre cette école et les écoles plus traditionnelles, mais aussi des challenges qu'il a dû relever tout au long de sa création. Notes de l'épisode Algosup, Une école d'informatique unique en son genre : https://www.algosup.com/fr/index.html DevOps D-Day : https://www.2021-devops-dday.com/ Retrouvez Franck sur LinkedIn : https://www.linkedin.com/in/franck-jeannin/

Ces dernières années, l'infrastructure as code s'est largement démocratisée, portée notamment par l'adoption du cloud. Elle consiste à gérer une infrastructure uniquement à base de code, au lieu de le faire manuellement. Un des points clé de l'infrastructure as code est certainement qu'elle permet un passage à l'échelle, ce qui n'est pas possible avec des procédures manuelles. Aux vues de la taille de nos infrastructures actuelles, il est difficile de s'imaginer pouvoir faire l'impasse sur ces technologies. Pourtant l'infrastructure as code présente des faibles et il n'est pas toujours simple d'adresser tous les cas d'usage auxquels nous pouvons être confrontés. Doit-on mettre ça sur le compte de la jeunesse des outils ou sur leur mauvaise utilisation ? Séven Le Mesle, mon invité dans cet épisode, a son opinion sur la question, et a publié il y a quelque temps un article intitulé Pourquoi votre infrastructure-as-code ne tient pas ses promesses ? Séven est le président et cofondateur de WeScale, et ensemble nous parlons bien évidemment d'infrastructure as code, mais également des retours d'expérience qu'il a en la matière et qui l'ont conduit à écrire cet article. Notes de l'épisode Pourquoi votre infrastructure-as-code ne tient pas ses promesses ? https://blog.wescale.fr/2021/06/17/pourquoi-votre-infrastructure-as-code-ne-tient-pas-ses-promesses/ Infrastructure as Code’s Broken Promises: https://levelup.gitconnected.com/infrastructure-as-codes-broken-promises-4c9dc86f909c

S'il est vrai que le software mange le monde, il est tout aussi vrai que les APIs mangent le software. Les APIs font tourner le web, et ce n'est pas les exemples qui manquent de Facebook à Google en passant par Twitter ou Netflix, au point que c'est un sujet incontournable lorsqu'il s'agit de créer une application. Mais créer une API ne se fait pas sans beaucoup d'efforts, et parfois pas mal de douleur. En effet, au-delà du code qui est un sujet qui nous passionne tous, il y a d'abord un design ; l'implémentation ne vient qu'ensuite. Et dans ce domaine, les erreurs sont fréquentes, pénibles et ont même parfois des conséquences catastrophiques. Mon invité, Arnaud Lauret aka API Handyman, y consacre un blog et vient de publier un livre sur le sujet : le Design des Web APIs aux éditions Manning. Arnaud est Leader API et Architecture chez Natixis, et le moins que l'on puisse en dire, c'est qu'il a travaillé son sujet. Avec lui, je reviens sur ce qui fait une bonne API, mais nous parlons aussi de sécurité, de cycle de vie, et des erreurs qu'il est facile d'éviter quand on prend le temps de faire un bon design. Notes de l'épisode : Générer une documentation à partir d'OpenAPI : https://github.com/Redocly/redoc Akita est un outil vous permettant d'améliorer le développement de vos APIs, notamment en scannant le traffic entrant et sortant : https://www.akitasoftware.com/ Le blog d'Arnaud : http://apihandyman.io/ Bénéficiez de 37% de réduction sur The Design of Web APIs ou sur n'importe quel autre livre du catalogue de Manning en utilisant le promo code podelmonk21 : http://mng.bz/l2wB Pour gagner un exemplaire numérique de The Design of Web APIs, retweetez simplement le tweet qui mentionne cet épisode du postcast https://twitter.com/k8Monkeys avec un commentaire sur ce que vous en avez pensé ; le gagnant sera tiré au sort et contacté via Twitter

La protection des données est presque aussi vieille que l'informatique elle-même, et pour une bonne raison : elle est indispensable à la survie de notre business, que ce soit contre une erreur, un désastre ou une attaque. Cependant, les outils ont dû s'adapter à un monde en perpétuelle évolution. Là où hier nous sauvegardions notre travail sur une disquette ou une bande magnétique, nous lui préférons aujourd'hui un bucket s3 ; là où nous sauvegardons les données d'un système de fichiers, nous devons maintenant composer avec des systèmes distribués et des volumes dynamiques. Mais il n'y a pas que les techniques qui ont changé, et avoir une copie de ses données peut servir de nombreux cas d'usage, sans mentionner le fait que ça réponde également à des impératifs légaux. Pour en parler, je reçois Stéphane Berthaud et Gatien Gheza. Stéphane est Senior Director Technical Sales, France & Africa chez Veeam, et Gatien Senior System Engineer EMEA pour Kasten. Veeam est un acteur incontournable sur le marché de la protection des données, et il est classé par Gartner comme leader depuis 5 ans dans le Magic Quadrant des solutions et backup et de recovery.

Léo Benkel est un développeur expérimenté qui a travaillé dans la Silicon Valley pour des startups ayant été rachetées par des entreprises pesant plusieurs millions de dollars. Fort de ces 10 ans d'expérience à San Francisco, il est venu au Luxembourg créer sa propre société : Pure Lambda. Aujourd'hui Léo conseille les entrepreneurs afin qu'ils améliorent leur produit, leurs processus, et de manière générale leurs entreprises. Ce qui m'a frappé de mes conversations avec Léo, c'est cet esprit novateur qu'il insuffle aux entreprises. Ses conseils sont pour le moins déstabilisants, voire contre-intuitifs, et le moins que l'on puisse en dire, c'est qu'ils vont à l'encontre de beaucoup de principes de gestion d'entreprise qu'on pourrait prendre pour acquis dans notre bonne vieille Europe. Notre conversation nous amène aussi bien sur les aspects culturels de la vie dans la Silicon Valley que sur la pandémie et ce qu'elle a changé dans notre façon de travailler au quotidien. Note de l’épisode Retrouvez le blog de Pure Lambda: https://pure-lambda.medium.com/

L'observabilité est une des composantes essentielles de nos infrastructures, car elle nous permet de comprendre ce qui s'y passe. Elle s'appuie sur trois piliers, la gestion des logs, des métriques et des traces applicatives, auxquels on peut ajouter un quatrième pilier : la visualisation par des dashboard. Mais l'observabilité est un sujet complexe, d'autant plus que nos systèmes se sont eux aussi complexifier avec les conteneurs, Kubernetes ou le serverless. C'est pourquoi c'est un secteur d'innovations, où des technologies telles que le machine learning ou eBPF ont tout à fait leur place. Pour nous en parler, je reçois Gregory Ouillon qui est le CTO EMEA de New Relic. Ensemble nous évoquons le but de l'observabilité, de quoi elle se compose et à qui elle s'adresse. Mais nous discutons également de New Relic, de son modèle SaaS, et des acquisitions qui ont permis de repousser encore plus loin les barrières de l'observabilité.

Le machine learning consiste à laisser la machine générer un code informatique plutôt que ce dernier ne soit écrit par un humain. Il est encore souvent supervisé, c'est-à-dire que le jeu de données utilisé pour entraîner l'algorithme est étiqueté, mais on rencontre de plus en plus souvent des modes d'apprentissage non supervisés. D'après Emmanuel Benazera, mon invité dans ce podcast et Senior Research Engineer in Artificial Intelligence à Jolibrain, le machine learning sert principalement deux objectifs : automatiser les tâches récurrentes, comme par exemple modérer les contenus d'un réseau social, et à rendre possible des choses qui ne l'étaient pas jusqu'à maintenant. Avec Emmanuel, nous parlons de ces réseaux de neurones qui de manière invisible ont transformé notre quotidien. Notes de l’épisode TinyML: Machine Learning With Tensorflow Lite on Arduino and Ultra-Low-Power Microcontrollers chez O’Reilly sur Amazon: https://www.amazon.fr/TinyML-Learning-TensorFlow-Ultra-Low-Power-Microcontrollers-ebook/dp/B082TY3SX7/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1627247939&sr=8-1

Choisir un cloud provider c'est un peu comme choisir une nouvelle voiture : on sait que cette décision va nous engager sur le long terme, et nous ne voudrions pas laisser ça au hasard. C'est pourquoi nous nous intéressons aux bancs d'essai, aux comparaisons entre les marques, à la performance de chaque véhicule. Anthony Monthe est le fondateur de Cloud Mercato, une plateforme de benchmark pour le cloud. Anthony aime profondément le cloud, et il est pour son adoption à large échelle. Mais pour que les entreprises aillent vers le cloud, il sait qu'elles ont besoin de transparence, et de voir plus loin que de simples discours marketing. Fournir aux consommateurs de la donnée sur les cloud providers est justement la mission de Cloud Mercato.

Dans des architectures distribuées, les applications s'appuient sur des messages brokers pour communiquer les unes avec les autres. Cela permet à l'émetteur d'un message et à son ou à ses consommateurs de ne pas communiquer directement, rendant par là même le système plus résilient aux pannes. Il existe quantité de messages brokers, dont deux sont tout aussi populaires que différents : RabbitMQ et Kafka. Afin de parcourir leurs différences et leurs cas d'usage, je reçois Pierre Larboulette. Pierre est Software Engineer chez iAdvize, et il est quotidiennement confronté à des applications utilisant soit Kafka, soit RabbitMQ. Au point même d'envisager peut-être Pulsar, pour tenter d'unifier les deux modèles.

L'intelligence artificielle est depuis des années une source d'inspiration pour la littérature et le cinéma, mais comme le disait Azimov, elle est souvent le véhicule de fantasmes assez sombres, où les humains se retrouvent sous le joug d'une IA malveillante et toute puissante. Pourtant les IA gouvernent déjà notre quotidien : assistants vocaux, filtres anti-spams, voitures autonomes, jusqu'à la sélection de films qui nous est proposée par Netflix. C'est un terrain de jeu sans limites, capable d'adresser les problématiques les plus inédites. Christophe Tricot est CEO de Larforge, un incubateur pour les startups qui cherchent à donner une autre dimension à leurs produits avec l'intelligence artificielle. Ensemble nous discutons des cas d'usage, des techniques, mais aussi des solutions que peuvent trouver les startups dans l'IA.

Tester son code est un sujet qui divise et rassemble tout à la fois la communauté des développeurs. Si chacun s'accorde à reconnaître qu'il est indispensable de s'assurer que son application fonctionne comme attendu, les méthodes pour arriver à cette fin diffèrent largement d'une équipe à une autre, quand elles ne s'opposent pas totalement. Alors que certains sont adeptes du l'extrême programming et du test driven development, d'autres testent directement leur code en production. Il y a ceux qui considèrent que les tests sont une perte de vélocité, tandis que d'autres trouvent que c'est une réduction drastique de temps dans la boucle de feedback. S'il y a une approche meilleure qu'une autre, comment le savoir ? C'est pour répondre à cette question épineuse que je reçois Fabrice Nourisson. Fabrice est lead developer chez Servebox, et un partisan modéré de l'extreme programming. Nous parlons ensemble des différentes situations qui amènent à réfléchir sur la meilleure manière de tester son code.

Depuis plus d'un an et demi maintenant, la covid fait partie de notre quotidien. Elle nous impose ses règles et nous dicte nos comportements. Cependant, elle n'est pas la première pandémie de ce type à nous frapper de plein fouet, et rien qu'au siècle dernier il y a également eu la grippe espagnole, la grippe asiatique, la grippe de Hong Kong et le sida. Et pourtant, c'est la première fois dans l'histoire que nous nous voyons imposer des règles de distanciation physique. Alors qu'est-ce qui a changé ? Nous n'allons bien évidemment pas parler politique dans ce podcast, mais bien de machine learning. En effet, face à cette pandémie, la création de modèles de propagation du virus nous a aidé à y voir plus clair parmi les conséquences que pouvaient entraîner la mise en place de tel ou de tel autre scénario. Pour nous en parler plus en détail, je reçois Bertrand Delvaux. Bertrand est consultant freelance en data engineering et artifical intelligence, et il a eu l'occasion, dès le début de la pandémie, de réaliser plusieurs travaux pour l'African Risk Capacity. travaux dont il vient nous parler aujourd'hui. Petit clin d'œil aux travailleurs remote avant de commencer, Bertrand était au Costa Rica quand j'ai fait cet épisode, et plus précisément dans le hall d'un hôtel, ce qui explique les bruits de fond que vous ne manquerez pas d'entendre sur cet enregistrement.

Si le mouvement DevOps a été initié en 2007, il fait encore couler beaucoup d'encre aujourd'hui. Il semble de manière général mal compris et mal intégré en entreprise. Mais la problématique qu'il vient adresser n'est pas simple : unifier deux mondes que tout oppose. D'un côté les devs qui veulent pouvoir livrer rapidement et continuellement de nouvelles fonctionnalités, et de l'autre les ops, qui recherchent un maximum de stabilité pour la production. Les silos, comme on les appelle, sont encore monnaie courante en entreprise. Et si ils ont prouvé depuis longtemps leur inefficacité, ils restent des endroits confortables où chaque entité peut rejeter la responsabilité d'un incident sur l'autre, celle qui se trouve derrière "le mur", comme il est de coutume de l'appeler. Yannick Grenzinger est Coach Flow and Craft chez BENEXT, mais il est avant toute chose un dev, qui connaît sur le bout des doigts l'agilité. Yannick est également le co-organisateur de la conférence Flowcon France, et ensemble, nous discutons du DevOps, tel qu'il est perçu par les devs. Notes de l'épisode : Container security made open-source Meetup with Pierre Debenais and Itay Shakury https://www.meetup.com/Luxembourg-Kubernetes-and-CNCF-Meetup/events/278396387/

Si Kubernetes est aujourd'hui un enjeu stratégique pour beaucoup d'entreprises, ça ne signifie pas pour autant qu'il est simple de transformer nos applications legacy en conteneur. Peut-être que le workload ne s'y prête pas, ou que les équipes ne sont pas prêtes, ou tout simplement que les outils qui nous servent à le gérer ne sont pas adaptés à ce mode conteneurisé. Mais dans cette hype autour de Kubernetes, qui veut être la personne laissée de côté pour gérer les workloads legacy ? Fort heureusement, il existe un entre-deux : un outil hybride en mesure de créer des machines virtuelles dans des pods. Et cet outil c'est Kubevirt. Pour nous en parler, je reçois David Szegedi. David est Principal Cloud Solution Architect chez Red Hat, et avec lui je discute des enjeux de porter des machines virtuelles dans des pods, au lieu des classiques conteneurs.

Les APIs ont connu un réel engouement ces dernières années. Elles sont également au cœur du paysage cloud natif et des micro-services, car elles permettent de développer des applications scalables, résilientes et distribuées. Cependant, créer une application en micro-services à base d'APIs peut poser quelques challenges aux développeurs, notamment parce que chaque équipe évolue à son propre rythme. Comment valider l'intégration d'une API quand celle-ci n'est pas encore prête ? Comment s'assurer qu'elle réponde bien à nos attentes, ou comment tester qu'elle ne va pas induire de comportement inattendus ? Pour nous en parler, je reçois Laurent Broudoux. Laurent est Cloud-native AppDev Solution Architect chez Red Hat, mais il est également l'auteur de Microcks, un outil "Kubernetes natif" et open source pour mocker et tester ses APIs. Notes de l'épisode Apicurio, tout ce qui concerne les API, car les API sont le remède. : https://www.apicur.io/ AsyncAPI, des outils open source pour créer et maintenir facilement votre architecture événementielle : https://www.asyncapi.com/ Luxembourg CNCF Meetup, Container security made open-source with Aqua: https://www.meetup.com/Luxembourg-Kubernetes-and-CNCF-Meetup/events/278396387/ Tech Ethic, Le podcast tech qui parle de sujets éthiques comme l'accessibilité, l'écologie ou la #tech4Good. Animé par Emmanuel Demey et Fanny Demey : https://anchor.fm/techethic

Windows et Linux ont longtemps suivi deux trajectoires bien distinctes. D'un côté comme de l'autre, nous trouvons des utilitaires pour les faire coexister, comme Wine sur Linux ou MobaXTerm sur Windows, mais aucun outil natif. Mais depuis que Linux est devenu le système d'exploitation du cloud, la stratégie de Microsoft sur ce point a radicalement changé. En 2016, Windows Subsystem for Linux, ou WSL, fait son apparition. Puis en 2019, WSL est annoncé dans sa version 2. Pourquoi Microsoft a soudainement décidé d'inclure Linux à son propre système d'exploitation ? A qui et à quoi sert-il ? Et finalement, comment fonctionne-t-il ? Pour tenter de répondre à quelques-unes de ces questions, je reçois Nuno do Carmo. Nuno est Senior IT System Analyst pour Ferring Pharmaceuticals, et est un passionné de WSL depuis la première heure. Au travers de son expérience personnelle, nous plongeons dans l'univers passionnant de Linux sur Windows.

Le cloud n'est plus aujourd'hui le terrain de jeu des seules startups, mais aussi et plus que jamais celui des entreprises qui sont de plus en plus nombreuses à entamer leur migration vers le cloud. Ce qui distingue une entreprise d'une startup, c'est notamment sa topologie, et les relations entre les différentes équipes de cette organisation. Pour elles, migrer vers le cloud à partir d'un simple compte racine n'est pas une stratégie adaptée, et elle pourrait même s'avérer risquée. C'est pourquoi ces dernières années ont vu l'émergence des landing zones, que nous pourrions considérer comme la configuration de base sous-jacente à tout environnement cloud d'entreprise. Les landing zones couvrent principalement quatre aspects : la sécurité, la standardisation, les accès et le réseau. Pour mieux comprendre les tenants et les aboutissants des landing zones, je reçois Thomas Perelle. Thomas est Senior consultant Cloud/DevOps chez Linkbynet, et il a eu a plus d'une occasion l'opportunité de se frotter au concept de landing zones. Avec lui, nous discutons des bonnes et des mauvaises pratiques de l'adoption du cloud pour les entreprises. Notes de l'épisode L'article de Thomas sur les Landing Zones (en anglais) : https://medium.com/linkbynet/landing-zone-head-in-the-clouds-keeping-feet-on-the-ground-9909780110a3

Nous l'entendons souvent dire : une fondation est un endroit neutre pour les projets open sources. Mais concrètement, que signifie cette neutralité, comment est-elle mise en œuvre, et surtout quels problèmes cette neutralité soulève-t-elle ? D'un autre côté, puisque nous avons l'occasion de visiter les coulisses d'une fondation, pourquoi ne pas en profiter pour jeter un œil sur les challenges techniques qu'amène la gestion du cycle de vie des projets, du code source au CI. Car bien évidemment, héberger plus de 400 projets se révèle être un véritable tour de force. Pour découvrir tous ces aspects de la fondation Eclispe, je reçois Gaël Blondelle et Mikaël Barbero. Gaël est Vice President, Ecosystem Development et Mikaël Senior Developer à la fondation Eclipse. Et ce ne sont pas les sujets de conversation qui vont nous manquer. Notes de l'épisode Quarkus : https://quarkus.io/ Java Enterprise Edition : https://www.oracle.com/java/technologies/java-ee-glance.html Adoptium : https://adoptium.net/ Mosquitto : https://mosquitto.org/ Eclipse Vert.x : https://vertx.io/ Eclipse Theia : https://github.com/eclipse-theia/theia CodeReady Workspace : https://developers.redhat.com/products/codeready-workspaces/overview Eclipse Che : https://www.eclipse.org/che/

OpenShift est une plateforme de gestion du cycle de vie des applications créée par Red Hat. Depuis sa version 3, il s'appuie sur Kubernetes pour sa couche d'orchestration. Mais puisqu'OpenShift n'est pas simplement un orchestrateur de conteneurs, il embarque également un grand nombre de composants pour faciliter le développement d'applications, leur déploiement ou leur monitoring. Pour nous en parler plus en détail, je reçois Didier Wojciechowski et Madou Coulibaly. Tous deux travaillent chez Red Hat, où Didier est EMEA Principal Openshift Specialist Solutions Architect, et Madou Senior Specialist Solution Architect. Avec eux, je discute de la genèse d'OpenShift, des décisions stratégiques qui ont été prises pour son élaboration, ainsi que des composants qui le constituent aujourd'hui. Notes de l'épisode L'endroit où trouver les opérateurs de la communauté Kubernetes : https://operatorhub.io/ Red Hat OpenShift Container Storage : https://www.redhat.com/fr/technologies/cloud-computing/openshift-container-storage CodeReady Workspaces : https://developers.redhat.com/products/codeready-workspaces/overview Eclipse Che, l'IDE natif pour Kubernetes : https://www.eclipse.org/che/ Odo,: l'interface en ligne de commande (CLI)qui aide les développeurs à itérer sur leur code sur Red Hat OpenShift et Kubernetes : https://developers.redhat.com/products/odo/overview Thanos, le Prometheus en haute disponibilité : https://thanos.io/v0.10/thanos/getting-started.md/ Submariner permet de gérer la connectivité entre différents clusters Kubernetes : https://catalog.redhat.com/software/container-stacks/detail/5f0c67b7ce85fb9e399f3a12 Didier ne croyait pas si bien dire en parlant de Kubernetes ++, voici l'annonce d'OpenShift plus : https://www.openshift.com/blog/just-what-is-red-hat-openshift-platform-plus

Que connaissons-nous vraiment du mode de fonctionnement des applications que nous utilisons au quotidien. Est-ce nous qui leur accordons des droits sur nos données personnelles, ou elles qui nous privent de ces mêmes droits à leur égard ? Après tout, rares sont encore les applications qui aujourd'hui ne nous demandent pas notre consentement pour accéder à telle ou telle autre partie de notre vie privée. Il est difficile en effet, dans un secteur aussi innovant, de comprendre exactement comment nos données peuvent être utilisées, et dans quel contexte de sécurité. Doit-on compter sur la loi pour nous protéger des abus, ou doit-on s'en remettre à la morale ou à l'éthique d'une société, d'une équipe ou d'un individu ? Ces questions sont le lot quotidien de Marie-Jean Meurs et de Sébastien Mosser, qui travaillent tous deux sur une application médicale dans le domaine de la santé mentale. Marie-Jean est professeure au département de computer science de l'Université du Québec à Montréal où Sébastien est également professeur en ingénierie logicielle. Avec eux, je reviens sur le sujet épineux de la gestion de la donnée personnelle. Notes de l'épisode The Great Hack : https://fr.wikipedia.org/wiki/The_Great_Hack HumanIA : https://humania.uqam.ca/ La page de Sébastien Gambs, qui a une chaire de recherche au Canada en "Privacy-preserving and Ethical Analysis of Big Data” : https://sebastiengambs.openum.ca/ Marc-Olivier Killijian, professeur en sécurité logicielle à l'Université du Québec à Montréal : https://kirija.github.io/

La gestion des logs applicatifs a profondément évolué ces dernières années sous l'impulsion des micro-services et des conteneurs. Et à l'instar de Prometheus pour les métriques, il nous a fallu trouver de nouveaux outils en mesure de s'adapter à des environnements distribués fortement volatiles. Or si Elasticsearch est depuis longtemps une solution particulièrement plébiscitée, elle n'est peut-être pas exactement taillée pour ces cas d'usage. C'est pourquoi Grafana a créé Loki. Loki est en quelque sorte le Prometheus des logs, car il a été conçu spécifiquement pour ce type d'usage. Pour nous en parler plus en détail, je reçois Cyril Tovena. Cyril est software engineer pour Grafana Labs, et il nous explique pourquoi Grafana a ressenti le besoin de créer son propre outil de gestion de logs, et en quoi il est pertinent dans le paysage de l'observabilité aujourd'hui. Notes de l'épisode Le meetup CNCF Luxembourg sur l'Infrastructure as Code avec Pulumi : https://www.meetup.com/fr-FR/Luxembourg-Kubernetes-and-CNCF-Meetup/events/277518075/ Keynote de Cyril à l'ObservabilityCon : https://grafana.com/go/observabilitycon/keynote-what-is-observability/ Slack de grafana : https://slack.grafana.com/

ArgoCD est un outil de livraison continue pour Kubernetes qui fonctionne en suivant les pratiques GitOps. C'est-à-dire que pour lui, les définitions d'applications, aussi bien que les configurations, doivent être déclaratives et versionnées, afin que le déploiement et la gestion du cycle de vie des applications soit automatisé, auditable et simple à comprendre. Mais n'est-ce là qu'une promesse alléchante, ou bien est-ce une réalité ? Pour en discuter en détail, j'ai le plaisir de recevoir Thomas Labarussias et Victor Boissière. Thomas et Victor sont tous les deux SRE pour Qonto, une néo banque créée en 2016, et ont eu l'occasion d'implémenter ArgoCD pour remplacer Jenkins dans une entreprise en pleine expansion. Ensemble, ils nous font un retour d'expérience sur les aspects positifs comme sur les aspects négatifs de cette migration. Notes de l'épisode : Un article que Victor a publié sur Medium sur les pratiques de déploiement à Qonto : https://medium.com/qonto-way/how-we-scaled-our-staging-deployments-with-argocd-a0deef486997

Que ce soit au travers de Facebook, d'Amazon ou de Netflix, nos interactions avec les bases de données orientées graphe sont innombrables. Il faut dire que c'est un modèle de données particulièrement adapté à des cas d'usage aussi variés que les moteurs de recommandations ou à la détection de fraudes.Dans ce type de bases de données utilisant la théorie des graphes, les données sont stockées sous forme de nœuds et d'arcs. C'est grâce à ce type de représentation qu'il est possible de tirer de l'information non pas des données elles-mêmes, mais des relations qu'elles entretiennent les unes avec les autres.Pour mieux comprendre les bases de données graphes et la manière dont elles sont utilisées aujourd'hui, j'ai le plaisir de recevoir Arnaud Castelltort. Arnaud est Maître de conférences à Polytech Montpellier, et la personne la plus enthousiaste pour parler bases de données graphe que j'ai jamais rencontré.Notes de l'épisode :Graph Powered Machine Learning : https://www.manning.com/books/graph-powered-machine-learningLa base de donnée orientée graphe la plus célèbre : https://neo4j.com/Le site d'Open Cypher : http://www.opencypher.org/Neptune, la base de données orientée graphe d'AWS : https://aws.amazon.com/neptune/Apache Gremlin : https://tinkerpop.apache.org/gremlin.htmlSAP Hana : https://saphanajourney.com/hana-cloud/Orientdb : https://www.orientdb.org/Indradb : https://indradb.github.io/Arangodb : https://www.arangodb.com/Age : https://age.apache.org/Et quelques notes supplémentaires de la part d'Arnaud :Pour comparer des bases de données graphe, ce benchmark est pas mal: https://graphbenchmark.com/ + https://db-engines.com/en/ranking/graph+dbmsAutres bases que j'ai oublié d'évoqué: TigerGraph https://www.tigergraph.com/ (sur laquelle j'ai pas beaucoup d'information)Neo4j sandbox: https://neo4j.com/sandbox/Un livre chez Manning pour les bd graphes (explique bien l'utilisation de Gremlin): https://www.manning.com/books/graph-databases-in-actionUn livre gratuit (un peu dépassé mais pas mauvaise pour se donner une idée en feuilletant) sur les bases de données graphes (suffit de donner son email): https://neo4j.com/graph-databases-book/ c'est un O'Reilly Graph DatabasesBy Ian Robinson, Jim Webber and Emil EifremPrint Length: 224 pagesSupport the show (https://www.patreon.com/electromonkeys)

Casser un monolithe pour créer des micro-services vient aussi bien avec son lot de bénéfices que de problèmes. Parmis ceux-ci, il est facile de se représenter que les logs, par exemple, ne seront plus nécessairement formatés de la même manière entre les différents services, ou que la communication entre ces mêmes services nécessitera désormais un chiffrement, ou encore que configurer les stratégies de sécurité ne va pas être une partie de plaisir.C'est dans ce contexte que le service mesh a fortement gagné en popularité, car c'est à ce dernier qu'incombe la tâche de résoudre bon nombre de ces problématiques. Pour nous en parler plus en détail, j'ai le plaisir de recevoir Nicolas Muller, qui est CTO, Kubernetes Solution Architect et formateur pour Treeptik, et Joël Takvorian, qui est Software Developer pour Red Hat, et qui travaille notamment sur le projet Kiali, une console de gestion pour Istio.Support the show (https://www.patreon.com/electromonkeys)

Flutter est un framework pour la création et le développement d'applications mobiles multiplateformes. Dès le début, Flutter a eu pour objectif principal d'améliorer l'expérience du développeur, ce qui n'est pas anodin quand nous y opposons la fatigue de JavaScript ressentie par beaucoup d'entre eux.Cependant, en comparaison de React Native, de Swift ou de Kotlin, Flutter se fait discret. Est-ce un problème de maturité, de marketing, ou est-ce parce qu'il s'appuie sur Dart, un langage dont le moins que nous puissions dire est qu'il soit resté très confidentiel jusqu'à aujourd'hui ?Pour en savoir plus, je reçois Horacio Gonzalez. Car Horacio n'est pas seulement devrel pour OVHcloud, il est également Google Developers Expert sur Flutter. Avec lui, nous parlerons des origines de Flutter, de ses cas d'usage, et de ses points forts aussi bien que de ses points faibles en comparaison d'autres frameworks mobile.Notes de l'épisode :La showcase des applications Flutter : https://flutter.dev/showcaseSupport the show (https://www.patreon.com/electromonkeys)

Dans les technologies de l'information, nous avons l'habitude d'être confrontés à l'opposition entre logiciels libres et logiciels propriétaires. Pourtant ce débat du libre ne touche pas seulement la sphère des logiciels. Elle concerne quasiment chaque aspect de notre vie, que ce soit nos outils de travail, notre santé ou notre alimentation.Dans cette confrontation entre le monde du libre et celui des brevets, il est difficile de rester neutre ou indifférent. Mais pour prendre position, bien évidemment il convient d'être bien informé. Philippe Borrel est le réalisateur, entre autres films documentaires, de La Bataille du Libre, qui justement traite de ce sujet. Dans cet épisode, j'ai le plaisir d'échanger avec lui à propos du libre, de l'open source mais aussi d'autres enjeux sociétaux.Notes de l'épisodeLa bande dessinée de Raphaelle Macaron et de Noël Mamère, Les Terrestres : https://editionsdufaubourg.fr/livre/les-terrestresLa Bataille du Libre sur Vimeo : https://vimeo.com/philippeborrelSupport the show (https://www.patreon.com/electromonkeys)

Même s’il a rapidement gagné en maturité, Kubernetes reste une pièce d’infrastructure relativement récente. Qui plus est, comme il est modulaire et extensible, avoir des retours d'expérience sur la manière dont il a été déployé puis configuré est riche d'enseignements.Par exemple, un endroit où Kubernetes n’est peut-être pas encore suffisamment éprouvé, c'est lorsqu’il est mis à l’échelle jusqu'à atteindre ses limites. Connaissez-vous alors les impacts sur son control plane, le comportement de son data plane, où la réaction des divers outils qui y sont intégrés ?Laurent Bernaille lui, en a vu passer des vertes et des pas mûres, puisqu'il gère l'infrastructure de Datadog. Dans cet épisode, il nous raconte les joies et les peines de travailler sur des clusters Kubernetes de plusieurs milliers de nœuds.Support the show (https://www.patreon.com/electromonkeys)

La sécurité est un domaine qui n'échappe pas à la tendance au shift left. Certes, les bénéfices de ce décalage sont évidents, mais pour autant, il n'est pas simple d'en demander toujours plus aux équipes de développement. D'autant plus que la sécurité est un domaine complexe, qui demande du temps et des connaissances spécifiques.Snyk est une plateforme de développement faite pour adresser ces problèmes de sécurité lors de la création d'applications cloud natives. Pour en parler plus en détail, je reçois Philippe Stemberger. Philippe est Solutions Engineer chez Snyk, et dans cet épisode, il nous fait découvrir les solutions que Snyk met à disposition des développeurs.Notes de l'épisodePour s'inscrire à la présentation d'Aurélien Violet et Jérôme Petazzoni : https://app.livestorm.co/enix/traefik-cert-manager-lets-encrypt-kubernetes-par-jpetazzo-lightning-talk-communaute-frSupport the show (https://www.patreon.com/electromonkeys)

HashiCorp est un éditeur logiciel bien connu par les équipes de dev, d'ops et de sécurité pour des outils comme vagrant, terraform ou encore vault. Ce que ces outils ont en commun, c'est d'une part d'être simples à utiliser, et d'autre part, de répondre à une problématique bien précise, et une seule.Or ces dernières années, ce ne sont pas les problématiques qui ont manqué ; entre l'explosion de nouvelles solutions dans l'écosystème cloud natif d'un côté, et le travail à distance de l'autre, difficile de savoir où donner de la tête.Fort heureusement, chaque problème à sa solution. J'ai justement le plaisir de recevoir cette semaine Nicolas Ehrman, qui est Solution Engineer chez HashiCorp, et ensemble, nous discutons des deux dernières nouveautés qui ont été annoncées en fin d'année dernière par HashiCorp: Waypoint et Boundary.Notes de l'épisodePour s'inscrire à la présentation d'Aurélien Violet et Jérôme Petazzoni : https://app.livestorm.co/enix/traefik-cert-manager-lets-encrypt-kubernetes-par-jpetazzo-lightning-talk-communaute-frSupport the show (https://www.patreon.com/electromonkeys)

Dans des environnements distribués et hautement volatile, les logs, les métriques et les traces sont nos yeux et nos oreilles quand il s'agit de diagnostiquer la raison d'un incident. Et si c'est le cas pour un problème applicatif, ne pourrions-nous pas tout aussi bien en tirer avantage concernant la sécurité ?C'est la proposition que fait aujourd'hui Datadog. Pour en discuter, je reçois Marc Tremsal. Marc est Director of Product Management pour Datadog, et avec lui j'ai l'opportunité de discuter de la détection des menaces, des différent aspects du monitoring de la sécurité, mais aussi des technologies innovantes qui y sont employées, telle que eBPF.Notes de l'épisodeBlog de Justin Massey de Datadog sur le monitoring des audits logs de Kubernetes : https://www.datadoghq.com/blog/key-kubernetes-audit-logs-for-monitoring-cluster-security/Support the show (https://www.patreon.com/electromonkeys)

Il n'a fallu que trois ans à Kubernetes pour devenir fin 2017, le standard des plateformes d'orchestration du marché. Et tandis que les conteneurs enflammaient le cœur des développeurs, Kubernetes lui partait à la conquête des entreprises.Il est rare, pour ne pas dire inédit, qu'un produit jouisse d'une adoption aussi rapide, et il y a fort à parier qu'un tel succès ne doive rien au hasard. Dès lors, qu'est-ce qui justifie cet engouement pour Kubernetes et pour les conteneurs ? A quelles problématiques apportent-ils une réponse, aussi bien pour les devs que pour les ops ?Cette semaine je reçois Alexis Ducastel. Alexis est architecte infrastructure freelance, et fondateur d'infraBuilder, et avec lui j'aborde les différents points qui expliquent la popularité de Kubernetes, et pourquoi il a définitivement changé la donne.Support the show (https://www.patreon.com/electromonkeys)

Apprendre à coder est désormais enseigné à l'école. Et si nous ne pouvons voir cela que d'un bon œil, nous savons aussi pertinemment que cela introduit un biais : les enfants sont rarement passionnés par une discipline scolaire, et cela en dépit des aspects ludiques et créatifs d'un Scratch ou d'un Python.Par ailleurs, un autre problème a vu le jour ces dernières années : les ordinateurs, smartphones et tablettes font maintenant partie de notre quotidien, et de celui de nos enfants. La aussi, c'est une bonne chose, à condition que la protection de la vie privée et des données personnelles ne soit pas mise de côté, et que les réseaux sociaux ne se transforment pas en un lieu de harcèlement scolaire.Dans cet épisode, je reçois Morad et Rabah Attik. A eux deux, ils sont non seulement les auteurs de plusieurs livres de la collection "pour les kids" de chez Eyrolles, mais aussi les fondateurs d'Evolukid, une société spécialisée dans l'enseignement du numérique auprès des jeunes publics. Ensemble, nous discutons de l'apprentissage du code et de l'identité numérique.Support the show (https://www.patreon.com/electromonkeys)

L'une des forces de Kubernetes est d'être extrêmement modulaire. Et lorsque cette modularité s'étend jusqu'à laisser le choix du plugin réseau, alors la porte est grande ouverte à une multitude de possibilités.Or, malgré une grande diversité de plugins dès ses débuts, Kubernetes voit encore aujourd'hui de nouveaux plugins faire leur apparition, comme Cilium, Multus ou Antrea. Dès lors, nous pourrions nous interroger sur la nécessité de créer de nouveaux plugins, et sur les besoins spécifiques auxquels ils viennent apporter une réponse.Cette semaine, je reçois Antonin Bas. Antonin est développeur pour VMware, et travaille plus spécifiquement sur le projet open source Antrea. Avec lui, nous partons à la découverte de ce plugin réseau encore méconnu, et nous parlons en détails de ses spécificités et de ses cas d'usage.Support the show (https://www.patreon.com/electromonkeys)

Webassembly est une technologie que nous associons fortement avec un usage dans nos navigateurs. Parce qu'il est effectivement considéré comme "le langage assembleur pour le web", mais aussi parce qu'il a été créé pour surpasser certaines limitations de JavaScript.Mais, comme pour JavaScript, les cas d'usage ne se limitent pas au front, et vous seriez surpris d'apprendre tout ce que peut réaliser Webassembly au niveau du backend : filtres pour le proxy Envoy, blockchain, function as a service, et bien d'autres encore.Pour en parler plus en détails, je reçois Geoffroy Couprie, qui est ingénieur en sécurité pour Clever Cloud et qui utilise Webassembly dans des fonctions, et Ivan Enderlin qui développe une machine virtuelle pour Webassembly chez Wasmer. Leurs approches complémentaires nous permettront de brosser un tableau assez précis de l'utilisation de Webassembly pour le backend.Support the show (https://www.patreon.com/electromonkeys)

En seulement quelques années , Prometheus s'est imposé comme le standard des outils de monitoring cloud natif. Cependant, un certain nombre de fonctionnalités manquent à Prometheus, comme le stockage longue durée, le multi-tenancy ou, dans une certaine mesure, la haute disponibilité. Mais ce n'est pas un défaut pour autant, mais un choix d'architecture : Prometheus fait une seule chose, la collecte de métriques, et il la fait bien.Or ce choix pourrait être pénalisant pour une adoption en entreprise, car Prometheus ne permet pas, par exemple, de faire du capacity planning. Pour palier ce manque, de nouveaux projets ont vu le jour, comme Thanos ou Cortex. Mais ceux-ci ne sont pas là pour concurrencer Prometheus, mais bien plutôt pour l'enrichir.Dans cet épisode, je reçois Simon Pasquier. Simon est Senior Software Engineer pour Red Hat où il travaille principalement sur Prometheus. Mais à l'occasion, il lui arrive aussi de contribuer à Thanos. Avec lui, je discute de ce qu'apporte un projet comme Thanos à Prometheus, de son mode de fonctionnement et de ses fonctionnalités.Support the show (https://www.patreon.com/electromonkeys)

Container Security est un livre écrit par Liz Rice et paru aux éditions O'Reilly en avril 2020. Je l'attendais avec impatience, et je l'ai dévoré dès sa sortie. Il est bourré d'informations utiles. Après un rappel des rudiments de Linux, tous ce qu'il y a à connaître sur la sécurité des conteneurs y est abordé, de l'isolation, au cycle de vie des images jusqu'à la gestion des secrets.En bon podcaster, je me suis tout de suite jeté sur Twitter en espérant trouver dans mon réseau quelqu'un pour parler de la sécurité des conteneurs et des différents aspects que j'avais pu découvrir au travers de ce livre. Il se trouve que c'est Liz elle-même qui m'a répondu, et a accepté sans hésiter d'être mon invitée, même si elle ne se sentait pas totalement en confiance avec son français. Et je tiens d'ailleurs à la remercier très chaleureusement d'avoir fait cet effort, car nous avons bien plus souvent l'occasion de voir des français répondre à des interviews en anglais, que l'inverse. D'ailleurs, c'est son tout premier podcast francophone.A-t-on encore besoin de présenter Liz Rice ? Liz est VP Open Source Engineering chez Aqua Security, mais elle est également Présidente du Comité de Contrôle Technique à la CNCF, et j'imagine que beaucoup d'entre vous ont déjà eu l'occasion de la croiser dans une KubeCon ou une autre. Ensemble nous discutons de la sécurité des conteneurs, en prenant comme point de départ le livre qu'elle vient de publier.Notes de l'épisodeAqua Starboard https://github.com/aquasecurity/starboardSupport the show (https://www.patreon.com/electromonkeys)

etcd est une base de données bien connue de toutes les équipes opérationnelles, puisqu’elle est au coeur de Kubernetes. Cependant, mis à part sa documentation en ligne, c’est une base de données sur laquelle il n’existe aucune littérature. Et c’est une chose que j’ai peine à comprendre pour un projet de cette importance qui a un tel impact sur notre quotidien.Par chance, nous ne sommes pas les seuls à devoir opérer etcd. Qui plus est, certains cloud providers l’utilisent à bien plus grande échelle que nous, ce qui est notamment le cas pour OVHcloud. Leur connaissance du modèle opérationnel d’etcd et leurs retours d’expérience nous sont d’une aide précieuse.Dans cet épisode, je reçois Pierre Zemb. Pierre est leader technique des systèmes et du stockage distribués chez OVHcloud, donc la personne idéale pour parler d’etcd. Dans cet échange, nous évoquons les bases de données de nouvelle génération et leur fonctionnement, les raisons pour lesquelles etcd a été choisie pour Kubernetes, mais aussi ses limites et ses alternatives.Notes de l’épisodeLes notes personnes de Pierre sur etcd : https://pierrezemb.fr/posts/notes-about-etcd/Les bases de données orientées colonnes : https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_colonnesOLAP : https://fr.wikipedia.org/wiki/Traitement_analytique_en_ligneOLTP : https://fr.wikipedia.org/wiki/Traitement_transactionnel_en_ligneWhite Paper sur Google Spanner : https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46103.pdfWhite Paper de Google sur BigTable : https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdfLe site officiel de CoakcroachDB : https://www.cockroachlabs.com/Le site officiel de TiKV : https://tikv.org/Le site officiel d’etcd: https://etcd.io/Raft : https://raft.github.io/Raft un consensus distribué compréhensible : http://thesecretlivesofdata.com/raft/Raft lab : https://pdos.csail.mit.edu/6.824/labs/lab-raft.htmlPaxos vs Raft : https://www.youtube.com/watch?v=0K6kt39wyH0Documentation en ligne d’etcd : https://etcd.io/docs/v3.4.0/rfc/v3api/Interagir avec etcd : https://etcd.io/docs/v3.4.0/dev-guide/interacting_v3/etcd par rapport aux autres bases de données clés-valeurs : https://etcd.io/docs/v3.4.0/learning/why/Le site officiel de grpc : https://grpc.io/Les protobufs : https://developers.google.com/protocol-buffersSupport the show (https://www.patreon.com/electromonkeys)

Créer une application ne consiste pas à écrire un code source immuable auquel plus personne ne prêtera attention. Au contraire, c'est un code fait pour être relu, maintenu et modifié. Or si les choses sont très claires en théorie, la pratique est comme toujours beaucoup plus complexe.Aujourd'hui, que nous soyons développeur ou SRE, nous sommes tous confrontés à l'écriture de code. Mais un code qui fait le job est-il nécessairement un bon code ? Est-ce que mon code est clair et compréhensible pour être maintenu par quelqu'un d'autre que moi ? Et en définitive, comment puis-je m'améliorer ?C'est sur ce terrain miné et riche de polémiques que Nicolas Frankel a accepté de me suivre. Nicolas est developer advocate pour Hazelcast, et ensemble nous discutons des propriétés qui font d'un code un code de qualité.Support the show (https://www.patreon.com/electromonkeys)

Kubernetes permet de résoudre bon nombre de problèmes dans la gestion des micro-services, comme par exemple leur passage à l'échelle, ou la vélocité de leur déploiement, ou encore leur fiabilité. Mais Kubernetes s'est fixé des limites, et la gestion du trafic ne fait pas partie de son périmètre.Or, que ce soit lors de son entrée dans le cluster, entre les différents services, ou même entre différents clusters, ce trafic réseau est tout ce qui nous préoccupe lorsque nous parlons de micro-services. Et c'est ici précisément que le mesh entre en scène. Mais de quel "ici" parlons-nous exactement ?Pour répondre à mes nombreuses questions, j'ai le plaisir de recevoir pour la seconde fois Denis Jannot. Denis est Director of Sales Engineering pour Solo.io, un société spécialisée dans le réseau entre applications, de l'edge jusqu'au service mesh. Avec lui nous évoquerons les API gateways, le service mesh, et même la fédération de mesh entre clusters.Notes de l'épisodeSi vous souhaitez participer aux workshops de Solo.io en janvier :https://www.eventbrite.com/e/128722074189https://www.eventbrite.com/e/128722096255Support the show (https://www.patreon.com/electromonkeys)

L'infrastructure-as-code permet d'utiliser un langage de programmation pour définir son infrastructure. L'utilisation d'outils de gestion d'infrastructure comme Puppet, Chef ou Ansible avaient amorcé cette tendance, qui s'est confirmée par la popularisation du Cloud et de langages permettant la mise en place d'infrastructures comme CloudFormation pour AWS.Puis Terraform d'Hashicorp a enrichi cet écosystème en y apportant un modèle déclaratif open source, sous la forme d'un domain-specific language. Par ailleurs, les fichiers YAML de Kubernetes ne sont pas autre chose. Mais ce modèle a ses limites, et ne correspond pas nécessairement aux attentes des développeurs.Pulumi est une société qui a une autre approche, permettant de faire de l'infrastructure-as-code avec des langages de programmation bien connus des développeurs, comme .Net, Python ou TypeScript. Kevin Kotecki est vice-président sales pour Pulumi, et avec lui nous discutons des enjeux et de sa vision des outils d'infrastructure-as-code.Support the show (https://www.patreon.com/electromonkeys)

Le chaos engineering est une pratique, un état d'esprit, une attitude bien avant d'être un ensemble d'outils. Simuler une panne, un incident, ou l'absence du meilleur élément d'une équipe est facile ; l'outillage ne vient qu'ensuite, lorsqu'il s'agit d'automatiser toutes ces tâches.Mais l'outil doit-il s'arrêter là, ou doit-il aller plus loin pour permettre de réellement capitaliser sur les conséquences d'un problème, aussi bien pour les devs que pour les ops, mais aussi pour observer l'impact qu'il entraîne au niveau des utilisateurs d'un service.Dans cet épisode, je reçois Sylvain Hellegouarch. Sylvain est cofondateur et CTO de ChaosIQ et nous discutons ensemble de cette chaîne de valeurs que constitue le chaos engineering.Notes de l'épisodeChaos Monkey https://fr.wikipedia.org/wiki/Chaos_MonkeyLitmus https://github.com/litmuschaos/litmusPowerfulSeal https://github.com/powerfulseal/powerfulsealGremlin https://www.gremlin.com/Chaos Toolkit https://chaostoolkit.org/Support the show (https://www.patreon.com/electromonkeys)

Le SRE, pour site reliability engineer, est généralement un ingénieur software mettant à profit son expérience pour gérer l'infrastructure. Mais bien que ce rôle ait déjà fait l'objet de plusieurs publications (et je vous invite d'ailleurs à retrouver les liens dans les notes de l'épisode), son quotidien reste flou et mal défini.Tout d'abord, il est responsable de la production. Mais afin que son temps soit harmonieusement partagé entre cette tâche et ses travaux d'automatisation, il doit d'abord définir un budget d'erreur avec les développeurs. Ce budget est une sorte de contrat décrivant combien de temps une application peut être en dessous de son objectif mensuellement. Et pour définir cet objectif, bien évidemment, il faut des points de mesure précis, qui sont appelés des indicateurs. Une fois ce carde mis en place, le SRE devrait pouvoir consacrer 50% de son temps à la production, et l'autre moitié à ses tâches d'automatisation. C'est la théorie.Mais qu'en est-il réellement ? Pour le savoir, j'ai le plaisir de recevoir Tony Fouchard. Tony est aujourd'hui chef de l'infrastructure chez Prevision.io, mais il a aussi occupé d'autres rôles similaires pour Blablacar et Qwant. Il a une riche expérience de SRE, et il nous invite à partager son quotidien le temps de ce podcast.Notes de l'épisodeLa collection de livres sur le SRE de Google : https://landing.google.com/sre/books/Support the show (https://www.patreon.com/electromonkeys)

Github est un dépôt de code bien connu des développeurs open source. Le code y est stocké et versionné. Par ailleurs, Github est également bien connu pour être le réseau social des devs. Mais aujourd'hui, est-ce seulement ça Github ?Au fil du temps, beaucoup de nouvelles fonctionnalités sont venues s'y ajouter : des outils de gestion de projet et de sécurité, les gists, Github actions, pour n'en citer que quelques unes. Il y a aussi eu le rachat par Microsoft, qui a sans doute changé la donne.Du 8 au 10 décembre prochain aura lieu GitHub Universe, et à cette occasion, j'ai le plaisir de recevoir Alain Hélaïli. Alain est solution engineer pour Github, et avec lui nous partons faire le tour du propriétaire pour encore mieux connaître Github.Notes de l'épisodeQu'arrive-t-il lorsque notre clé AWS est poussée par inadvertance sur Github : https://twitter.com/AlainHelaili/status/1325022828710809600Github Universe : https://githubuniverse.com/Support the show (https://www.patreon.com/electromonkeys)

Tout change constamment : les langages, les frameworks, les outils, les technologies, les coéquipiers, et inévitablement, nous aussi. Pourtant changer ne paraît jamais simple. Chaque fois que nous voulons un changement, nous avons l'impression de vouloir déplacer des montagnes.C'est d'ailleurs paradoxal quand nous y pensons, car nous sommes là à regarder un système qui ne marche pas, ou simplement mal, ou une organisation, ou un service, et bien que nous le constations, nous avons le sentiment d'être poings liés et de ne rien pouvoir y faire. D'où est-ce que cela vient, et comment y remédier ?Cette semaine j'ai le plaisir de recevoir Alexis Monville. Alexis est chef de cabinet du directeur général EMEA chez Red Hat, et le moins que nous puissions dire, c'est qu'il s'y connait en changement. Il est en effet l'auteur de Changing Your Team From The Inside, et plus récemment de I am a Software Engineer and I am in Charge. Il nous partage sa vision du changement, et nous donne le secret sur comment changer efficacement !Notes de l'épisodeRetrouvez les livres d'Alexis : https://alexis.monville.com/en/books/Support the show (https://www.patreon.com/electromonkeys)

Le bug bounty, ou chasse aux bugs ou encore prime aux bogues, est un programme de récompenses pour les personnes qui découvrent et rapportent les bugs d'un site web. En d'autres termes, une entreprise, telle que Facebook ou Google, permet aux hackers bienveillants (souvent appelés white hats ou chapeaux blancs) de lui rapporter les vulnérabilités qui l'affectent en échange d'une récompense.La méthode n'est certes pas nouvelle : elle a été bien éprouvée et a pu démontrer toute son efficacité. Alors pourquoi n'avons nous pas encore de programme sur tous nos sites web ? C'est à dire que tout le monde n'est pas Facebook ou Google, dans le sens où il n'a pas une communauté de personnes prête à répondre à leur propre campagne de bug bounty.Autre point : il faut créer un cadre légal pour entourer cette pratique, aussi bien pour se protéger d'abus, que pour protéger ceux qui donnent de leur temps à traquer les bugs. Et tout cela pour quels bénéfices au juste ? Est-ce qu'une telle chasse est vraiment nécessaire dans notre univers cloud natif ?Pour répondre à toutes ces questions, j'ai le plaisir de recevoir le chef de l'Internet : Korben. Manuel Dorne, alias Korben, est en effet le co-fondateur de YESWEHACK, une plateforme de bug bounty bien connues des spécialistes en sécurité. Il nous emmène à la découverte de ces pirates en quête des trésors du web !Support the show (https://www.patreon.com/electromonkeys)

Parmi l'arsenal des différents outils mis à notre disposition pour notre veille technologique, il y a le podcast. Bien évidemment, je ne serais pas là si je n'en étais pas persuadé, et peut-être que vous non plus. Mais qui sont ces fous qui se mettent chaque semaine derrière un micro pour créer des contenus toujours nouveaux ? Qu'est-ce qui les fait avancer ? Où vont-ils chercher leurs idées ?Chaque podcast à sa propre identité et son propre style, non seulement au travers de ses thématiques, mais aussi par la personnalité de celui qui l'anime. Bruno Soulez, que vous connaissez peut-être déjà, est le créateur de If This Then Dev, un podcast que je suis depuis ses débuts, et qui m'a décidé à me lancer à créer mon propre show.Si vous êtes curieux de partager l'espace d'une heure l'intimité d'un podcaster, vous êtes les bienvenus ! Vous y apprendrez comment IfTTD a été créé, quels sujets tiennent vraiment à coeur à Bruno, ce qu'il espère transmettre au travers de ses épisodes, et surtout la réponse à cette grande question : pourquoi ne mange-t-il que des yaourts qu'il fabrique lui-même ?Notes de l'épisodeIf This Then Dev https://ifttd.io/Cosa Vostra https://www.cosavostra.com/Big Bang Media https://www.facebook.com/BigBangMediaIncubateur/Génération Do It Yourself https://www.gdiy.fr/2h de perdues https://www.2hdp.fr/No Limit Sécu https://www.nolimitsecu.fr/Les Cast Codeurs https://lescastcodeurs.com/The Mature Dev https://www.themature.dev/Tech Rocks https://www.tech.rocks/Artisan Développeur https://artisandeveloppeur.fr/Episode #5 Comment regarder Netflix depuis l'espace ? https://ifttd.io/5-raphael-goldwaser/Episode #10 Coder pour guérir les autres https://ifttd.io/10-coder-pour-guerir-les-autres-dominique-sauquet/Episode #14 Coder peu, coder mieux https://ifttd.io/14-coder-peu-coder-mieux-dimitri-baeli/Episode #20 beta.gouv quand l'état se met en mode start-up https://ifttd.io/20-beta-gouv-quand-letat-se-met-en-mode-start-up-julien-dauphant/Episode #21 Une organisation libre où prime innovation et bonheur https://ifttd.io/21-une-organisation-libre-ou-prime-innovation-et-bonheur-quentin-adam/Episode #46 De l'ordinateur beige au numérique vert https://ifttd.io/46-de-lordinateur-beige-au-numerique-vert-frederic-bordage/Episode #52 Le veilleur de nuit https://ifttd.io/52-le-veilleur-de-nuit/Support the show (https://www.patreon.com/electromonkeys)

Les API, pour Application Programming Interface, ont totalement bouleversé la manière d'écrire un service Web. Aujourd'hui, elles sont quasiment incontournables, d'une part parce qu'elles simplifient le développement d'applications, et d'autre part, parce qu'elles établissent un contrat documenté avec leurs consommateurs. Créées aux début des années 2000, elles se sont popularisées par la suite, jusqu'à voir leur nombre exploser avec l'arrivée des micro services.Mais à mesure que nous développons des API, nous nous rendons vite compte qu'elles ont toutes des points communs, comme l'authentification, le throttling ou le rate limiting. Réécrire ce tronc commun serait non seulement long et pénible, mais aussi il offrirait une expérience utilisateur différente pour chaque API. C'est à ce moment qu'entre en jeu les gestionnaires d'API, tel que Kong, qui est sans doute le plus populaire à ce jour.Dans cet épisode, j'ai le plaisir de recevoir Thibault Charbonnier. Thibault est principal engineer pour Kong Inc., et il n'est pas seulement le mainteneur de Kong, mais il a également participer à sa création ! Avec lui, je reviens donc sur Kong, de ses origines à aujourd'hui, sur son fonctionnement et sur ses cas d'usages.Support the show (https://www.patreon.com/electromonkeys)

Java est un langage populaire apprécié de nombreux développeurs. Certes, il est là depuis des lustres, et certains pourraient le penser obsolète face à Go ou à Rust. Pourtant, bien loin de cette hype, Java continue à faire son chemin et à se réinventer lui-même jour après jour.Pour évoquer les défis de Java face au cloud natif, j'ai déjà eu l'occasion de parler de Spring et de GraalVM native image. Cette fois, la discussion se porte sur Quarkus, que Red Hat décrit comme étant un framework Java natif pour Kubernetes, et Eclipse Vert.x une librairie Java qui facilite l'écriture de micro services.Pour évoquer ces sujets, je n'ai un, mais deux invités : Thomas Segismont et Julien Ponge. Thomas et Julien travaillent tous deux pour Red Hat, où ils sont respectivement senior software engineer et principal software engineer. Ils nous emmènent à la découverte de Quarkus et de Vert.x sur fond de GraalVM.Notes de l'épisodeVert.x in Action, Manning Publications : https://www.manning.com/books/vertx-in-action?a_aid=vertx-in-action&a_bid=22152024Le dev mode Quarkus:est supporte la plupart des protocoles, dont les outils en ligne de commande, gRPC et Kafka (update depuis l'enregistrement de l'épisode)Red Hat supporte activement Quarkus : https://quarkus.io/support/Pour ce qui concerne le mode natif, du point de vue du support Red Hat c'est Tech Preview pour l'instant (best effort). Mais la prochaine version produit devrait venir avec le support de Mandrel (https://github.com/graalvm/mandrel). Mandrel est un sous-projet de Graal qui fournit un compilateur native-image taillé pour Quarkus.Mandrel (https://github.com/graalvm/mandrel) est supporté par Red HatLa roadmap Vert.x : https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap#vertx-4La roadmap Quarkus : https://github.com/orgs/quarkusio/projects/5Support the show (https://www.patreon.com/electromonkeys)

Les Progressive Web Apps sont des sites web qui, d'un point de vue de l'utilisateur, peuvent être perçus comme des applications natives. Elles sont avant tout destinées aux mobiles, car elles ont l'avantage, par leur nature, d'être multi plateformes. Elles ont également un autre avantage : celui de ne pas dépendre des contraintes d'un app store.Tous ces aspects sont attractifs pour les entreprises, qui peuvent ainsi réduire leurs coûts de développement. Mais alors, comment fonctionnent ces applications ? Sont-elles facile à développer ? Quels inconvénient ont-elles vis à vis des applications natives ? Car on peut légitimement s'interroger sur la sécurité ou la stabilité d'une telle application.Dans cet épisode, je reçois Emmanuel Demey. Emmanuel est consultant Angular indépendant, et il vient récemment de publié un livre, simplement appelé Progressive Web App aux éditions ENI. Avec lui, non seulement nous allons en apprendre un peu plus sur ces applications web d'un genre nouveau, mais vous aurez aussi peut-être une chance de repartir avec un de ses livres.Support the show (https://www.patreon.com/electromonkeys)

GraalVM native image est un projet très attractif pour les équipes de développeurs Java qui veulent créer des microservices, et peut-être les utiliser dans des conteneurs. GraalVM native image permet en effet de compiler du code Java en code natif. Mais cela ne va pas sans soulever bon nombre de questions :Quelles performances pouvons-nous attendre de ce code comparé à cette même application exécutée par une JVM ?Quels outils sont à notre disposition pour le debugging et le monitoring ?Faut-il changer la façon dont le code doit être écrit ?Quel est le niveau d'intégration de GraalVM native image dans les différent frameworks Java ?Et aussi : où en est le projet, est-il déjà prêt pour la production ?Dans cet épisode, j'ai le plaisir de recevoir Sébastien Deleuze. Sébastien est ingénieur Spring dans l'équipe VMware, et travaille à l'intégration de GraalVM native image dans le framework Spring. Qui mieux que lui pourrait répondre à mes nombreuses questions sur le sujet, et nous donner un aperçu exhaustif de l'avancée des travaux ?Support the show (https://www.patreon.com/electromonkeys)

Docker est un outil apprécié des développeurs pour sa simplicité. Docker compose emprunte cette même philosophie en permettant de démarrer une stack applicative avec une simple commande UP. Mais l'arrivée de Kubernetes est venue changer la donne, et la bien connue "developer experience" n'est plus du tout comparable à ce qu'elle était.Il n'est pas surprenant dans ce contexte de voir certains développeurs se tourner vers Fargate ou Cloud Run qui enlèvent totalement la complexité de l'orchestrateur de l'équation. Mais les fournisseurs de cloud ne sont pas réputés pour simplifier la vie des développeurs.Dans cet épisode, je reçois Nicolas de Loof. Nicolas se qualifie lui même de bricoleur dangereux, et travail pour Docker Inc sur la nouvelle mouture de compose : une version capable de fonctionner aussi bien en local que dans le cloud. Avec lui je reviens sur l'intérêt qu'apporte un outil tel que compose, mais aussi sur les raisons qui l'ont contraint à évoluer.Support the show (https://www.patreon.com/electromonkeys)

Les conteneurs nous permettent plus que jamais d'accélérer le déploiement de nos applications. Elles sont désormais portables, prêtes à l'emploi et il est possible d'en exécuter des centaines, voire des milliers, sur une même machine. Mais il y a un revers à la médaille : comment être sûr qu'une application n'exécute que le code pour lequel elle est conçue ? Comment repérer un shell malicieux lancé par un tier ? Plus la densité de conteneurs sur un noeud augmente, et plus cette tâche pourrait sembler se complexifier.Bien sûr, il existe depuis longtemps des outils pour nous protéger, comme SELinux, AppArmor ou Seccomp. Ils ne nous mettent pourtant pas à l'abri d'une règle mal écrite ou trop laxiste. Alors comment s'assurer que la règle définie ne contiennent pas de faille qui permette de s'en échapper ? La réponse semble évidente : par l'audit nos systèmes. Et Falco est justement un outil nous permettant de nous acquitter facilement de cette tâche.Dans cet épisode, je reçois Thomas Labarussias. Thomas est Site Reliability Engineer pour Qonto, mais il est avant tout le mainteneur de Falco Sidekick. Avec lui, je discute de Falco et de ce qu'il apporte en terme de sécurité à nos applications, mais aussi de Sidekick, de ses cas d'usage, et des raisons qui ont poussé Thomas à s'investir dans un tel projet.Notes de l'épisodeCaptations et les compte-rendus de la communauté de Falco : https://github.com/falcosecurity/communitySupport the show (https://www.patreon.com/electromonkeys)

La sécurité est un aspect fondamental et pourtant souvent négligé de nos systèmes d'information. Pourquoi ? Qui n'a pas trouvé les exploits de Mr Robot palpitants ?... Alors qu'est-ce qui cloche ? Serait-ce parce que cette fois nous ne sommes pas du même côté de la barrière ? Probablement. Avoir une bonne hygiène de sécurité demande beaucoup d'efforts, de temps et de connaissances. Et avec tout ce qui "shift left" ces dernières années, il est difficile, mais vraiment difficile, de trouver le temps nécessaire.Cependant, nous ne pouvons pas nous permettre de passer au travers ou de simplement l'ignorer. J'ai donc décidé de faire une série sur les différents aspects de la sécurité, en commençant tout naturellement par la chaîne d'approvisionnement. Le code est la base de code sont aujourd'hui au coeur de toute entreprise technologique, et même les équipes d'infrastructure n'y échappent plus depuis l'avènement de l'infrastructure as code. Mais alors quels sont les problèmes soulevés, quelles solutions y apporter et avec quels outils ?Dans cet épisode, j'ai le plaisir de recevoir Maya Kaczorowski. Maya est Product Manager et Software Supply Chain Security pour Github, aussi elle est particulièrement bien placée pour répondre à mes nombreuses questions sur la chaîne d'approvisionnement, l'open source, et la sécurité. Car, au cas où j'aurais oublié de le mentionner, dans toute cette histoire, il est aussi largement question d'open source, que nous pouvons maintenant sans crainte considérer comme une des pierres angulaires de tout système d'information. Vous voilà prévenus, c'est parti !Support the show (https://www.patreon.com/electromonkeys)

Le DevOps et un mouvement et une pratique visant à l'unification du développement et de l'administration des systèmes. Sous cette définition simple en apparence se cache en réalité un monde d'inconnues, ce qui ne rend pas le mouvement facilement accessible. Qui doit y participer ? En quoi consiste cette unification ? Est-ce le rôle d'une personne, d'une équipe ou de tout une organisation. Comment mettre en place le DevOps et avec quels outils ?Pourtant, beaucoup d'entreprises ont dores et déjà adopté les concepts du DevOps, les ont mis en pratique et sont ressorties grandies de cette transformation, et plus à même de faire face aux challenges auxquels l'IT est confrontée aujourd'hui. Alors malgré le flou artistique que semble représenter le DevOps, par où commencer pour le mettre en place, et comment le structurer pour en retirer tous les bénéfices attendus ?Pour répondre à mes très nombreuses questions sur le sujet, je suis allé voir mon confrère podcaster Christophe Chaudier. Car Christophe n'est pas seulement un podcaster que j'apprécie particulièrement, il est aussi consultant DevOps et co-fondateur de Lydra, un collectif de consultants indépendants. Avec lui, je discute de la pratique du DevOps, de ses bénéfice, de sa culture et de ses enjeux.Notes de l'épisodeLes Compagnons du DevOps : https://lydra.fr/pourquoi-les-compagnons-du-devops/Radio Devops (le podcast) : https://lydra.fr/radio-devops/Le rêve du dragon : https://lydra.fr/rdo-8-comment-partager-et-diffuser-la-culture-devops/Les bénéfices du DevOps : https://lydra.fr/devops-cest-bien-beau-mais-on-y-gagne-quoi/L'egrégore : https://fr.wikipedia.org/wiki/%C3%89gr%C3%A9goreLe livre Découvrir DevOps : https://www.dunod.com/sciences-techniques/decouvrir-devops-essentiel-pour-tous-metiers-0The Phoenix Project : https://www.goodreads.com/book/show/17255186-the-phoenix-projectLa première formation DevOps de Christophe : https://www.compagnons-devops.fr/devops-mindsetSupport the show (https://www.patreon.com/electromonkeys)

Inutile de vous le rappeler, nous vivons une période trouble ; période durant laquelle nous sommes parfois obligé de revoir jusqu'à la moindre de nos habitudes quotidiennes. Est-ce un changement temporaire ou durable ? Quelque soit la réponse, cette crise a jeté un éclairage nouveau sur notre rapport avec le numérique, que son utilisation soit dans le cadre des loisirs, de l'école ou du travail.Dans ce rapport au numérique, une fois de plus nous ne sommes pas à égalité : il y a ceux qui ont la fibre et ceux qui n'ont même pas la 3G, il y a ceux qui ont un pc dernière génération avec un écran 27'', et ceux qui ont un smartphone de seconde main avec un écran 3.5''. Or dans une société où l'accès au numérique est une nécessité à tous points de vue, comme ça l'a été durant la période de confinement, la pilule est un peu dure à avaler dans un pays qui a pour devise "Liberté, Egalité et Fraternité".Pour parler de ce sujet un peu inhabituel dans ce podcast, j'ai décidé de vous surprendre en invitant de nouveau Audrey Neveu, Xavier Bourguignon et Emmanuel Feller. Après tout, il me fallait bien ce collège d'experts pour traiter de ce problème qui leur tenait particulièrement à coeur. Et si vous écoutez bien jusqu'au bout, vous découvrirez qu'ils ont une proposition très intéressante à vous faire ! C'est parti pour un tour !Support the show (https://www.patreon.com/electromonkeys)

Si d'aucun considère encore l'informatique comme un outil, beaucoup le voit aujourd'hui comme un simple objet de consommation : smartphone, console de jeu, ordinateur de bord, maison connectée, et j'en passe. A tel point qu'on en oublierait presque que ce n'est qu'une "bête" machine contrôlée par un code. Alors peut-être que, si vous n'êtes pas non plus un lecteur d'Asimov, vous vous imaginez encore les robots comme des êtres animés de noirs desseins prêts à envahir le monde...Pour que nous gardions le contrôle sur la technologie, plutôt que ce soit elle qui nous plie à sa volonté, quoi de mieux que de la faire découvrir en pratique à nos enfants ? C'est là l'objectif de Devoxx4Kids. L'initiation en s'amusant entouré d'animateurs passionnés ; peut-on rêver mieux ?Pour discuter de ce sujet passionnant, j'ai le plaisir de recevoir trois piliers emblématiques de Devoxx4Kids : Audrey Neveu, Xavier Bourguignon et Emmanuel Feller. Car, quand ils ne sont pas devant leur terminal à coder, qui chez Pivotal, qui chez SonarSource et qui chez Clever Cloud, ce sont eux qui imaginent les plus géniaux programmes pédagogiques pour nos chères têtes blondes. Alors c'est parti !Support the show (https://www.patreon.com/electromonkeys)

Spring est un framework du début des années 2000 pour faciliter le développement d'une application Java. Mais depuis le début des années 2000, bien des choses ont changé dans notre manière d'exécuter nos applications. L'apparition de Spring boot en 2014 a encore rendu plus simple la création d'une application autonome.La façon dont les applications tournaient dans les années 2000, puis 2010, a encore considérablement changé ces dernières années. Il y a d'abord eu l'avènement du cloud, avec Heroku, Cloud Foundry et Google App Engine, puis des conteneurs et de Kubernetes, sans oublier les fonctions... Chaque environnement d'exécution a ses particularités et ses spécificités qui sont autant de challenges pour le développement d'un framework.Parce que Java est un langage populaire, et que l'exécution d'applications Java est tout autant une préoccupation des devs que des ops, j'ai tenu à faire une série sur les défis de Java et du cloud natif. Pour commencer cette série, j'ai le plaisir de recevoir Stéphane Nicoll. Stéphane est software engineer pour VMware depuis le rachat de Pivotal par ce dernier, où il s'occupe activement du développement de Spring boot. Avec lui, je discute de l'évolution de Java, de Spring, des Buildpacks et de bien d'autres sujets passionnants !Support the show (https://www.patreon.com/electromonkeys)

Depuis l'arrivée des premiers smartphones, le développement d'applications mobiles a considérablement bouleversé la manière de travailler des développeurs. Les premières versions de ces applications n'ont d'ailleurs pas toutes été des réussites, les développeurs étant partagés entre créer une application cross platform, ou une application ciblant directement iOS ou Android.En quoi consiste le développement mobile ? S'agit-il de créer des clients lourds ou des applications web ? Quelle est la différence avec le monde de l'ordinateur individuel ? Quels besoins spécifiques est-ce que ça adresse ? Faut-il utiliser des frameworks comme React ou Flutter, ou bien s'orienter directement vers Swift et Kotlin ? Le développement mobile est relativement récent et fait encore face à de nombreux challenges. Pourtant de plus en plus d'entreprises développent aujourd'hui des applications spécifiquement pour ces plateformes.Pour mieux comprendre cet écosystème, je reçois dans cet épisode Yacine Rezgui. Yacine est Developer Advocate pour Google, et avec lui je discute de cet univers passionnant du mobile, depuis ses premières années jusqu'au challenges actuels auxquels il doit faire face.Notes de l'épisodeDeveloping Android Apps with Kotlin by GoogleSupport the show (https://www.patreon.com/electromonkeys)

Depuis ses débuts en 2006, le cloud n'a cessé d'évoluer pour donner aux développeurs une meilleure expérience de déploiement de leurs applications. Si Amazon, Heroku, Pivotal Cloud Foundry ont été parmi les premiers, les options sont aujourd'hui bien plus nombreuses et de plus en plus spécifiques en fonction du type d'application.Mais le cloud n'est pas le seul a avoir évolué, le web a lui aussi connu de profonds changements depuis le web 1.0 et ses sites statiques. De nouveaux langages sont apparus, et avec eux de nouveaux frameworks. Un développeur web n'a aujourd'hui que l'embarra du choix. Mais au delà du code, le "build" et la façon d'exécuter le code de l'application peuvent avoir de gros impacts sur les performances, l'expérience utilisateur, et même sur l'environnement.Azure propose aujourd'hui un nouveau concept : les Static Web Apps. Pour en parler, je reçois Wassim Chegham. Wassim est Senior Cloud Advocate pour Microsoft, et dans cet épisode, je discute avec lui des différentes évolutions du web, et des raisons pour lesquels Microsoft a choisi de lancer ce tout nouveau service.Notes de l'épisode :Slide Web 4.0Essayer Azure (12 mois gratuits)Azure Static Web Apps (preview public)Apprendre Node.js gratuitementSupport the show (https://www.patreon.com/electromonkeys)

Gordon Moore, Nolan Bushnell, Vinton Cerf, Tim Bernes-Lee, Steve Wozniak, qui n'a pas un jour entendu l'histoire d'un de ces grands bidouilleurs à l'origine des microprocesseurs, des jeux vidéo, d'Internet, du Web ou de l'ordinateur individuel ? Mais la célébrité n'était pas le but, et aucune de toutes ces belles choses n'est l'oeuvre d'une seule personne.Car le but du maker n'est pas nécessairement de créer quelque chose d'utile, mais de créer, tout simplement. Comprendre, apprendre, essayer, se tromper, recommencer, réussir parfois, partager, c'est là tout l'univers des hackers. Ai-je oublié de mentionner un sens de l'humour potache qui est souvent leur signature ?Dans cet épisode, j'ai le plaisir de recevoir Sébastien Nedjar. Sébastien est maître de conférence à l'université d'Aix-Marseille, et il est le fondateur du FabLab du pays d'Aix. Avec lui je pars à la découverte des bidouilleurs, des célèbres FabLabs, et d'un projet bien plus ambitieux pour le monde de l'éducation : Let's Steam.Notes de l'épisodeLe FabLab d'Aix en Provence : https://labaixbidouille.com/Nosbridge San Francisco : https://www.noisebridge.net/wiki/Noisebridgeles innovateurs de Walter Isaacson : https://www.livredepoche.com/livre/les-innovateurs-9782253194453L'Open Bidouille Camp : https://openbidouille.net/Maker Faire : https://makerfaire.com/Le Souk des Sciences : https://www.univ-amu.fr/en/public/science-soukCoding Goûter : https://codinggouter.org/STMicroelectronics : https://www.st.com/content/st_com/en.htmlLe projet Let's Steam : http://www.lets-steam.eu/Support the show (https://www.patreon.com/electromonkeys)

Un conteneur est un processus qui a son propre système de fichiers et qui est isolé des autres processus de son hôte par des fonctionnalités du noyau Linux. Sous cette définition à première vue anodine se cache en réalité un monde de complexité. Abstraire cette complexité et rendre l'exécution d'un conteneur simple impose de faire des compromis, et dans le cas de Docker ces choix ont souvent été au détriment de la sécurité.Aujourd'hui Redhat vient avec une alternative à Docker : Podman. Podman est un outil simple, dont le jeu de commande rappelle tout à fait celui de Docker, mais qui, contrairement à ce dernier, met la sécurité au premier plan. C'est un choix différent qui s'appuie donc sur d'autres compromis.Dans cet épisode, je reçois Benjamin Vouillaume. Benjamin est consultant pour InTech Luxembourg, et il a eu l'occasion de partager son expérience sur Podman lors de différentes conférences. Avec lui je discute des atouts et des faiblesses de Podman afin de mieux comprendre comment celui-ci s'inscrit dans le paysage technologique de Redhat.Notes de l'épisdolePodman : https://podman.io/crun : https://github.com/containers/crunbuildha : https://buildah.io/cri-o : https://cri-o.io/Support the show (https://www.patreon.com/electromonkeys)

L'objectif de l'observabilité, et donc de développer une application observable, est de s'assurer que les comportements indésirables de cette application pourront être rapidement détectés lorsqu'elle sera mise en production. Que vaudrait un service dont nous ne connaîtrions pas le taux d'indisponibilité ou d'erreurs ? Que vaudrait un système dont la cause d'un disfonctionnement ne pourrait pas être analysé ?Or la difficulté à laquelle nous nous retrouvons confrontés, c'est la diversité des outils nous permettant de collecter ces données, qu'elles soient des métriques, des logs ou des traces. Comment synthétiser cette donnée afin de l'exploiter, et comment réunir en un seul point l'ensemble des informations qui vont nous permettre de déterminer la source d'un problème.C'est un challenge que doivent relever aujourd'hui les outils d'APM. Dans cet épisode, je reçois Alex Mechain et Jean Detoeuf. Alex est Sales Engineer pour Instana où Jean est Software Engineer. Tous les deux viennent nous expliquer les enjeux de l'observabilité, et le fonctionnement d'un outil moderne d'APM.Notes de l'épisodeLe blog d'Instana : https://www.instana.com/blog/Support the show (https://www.patreon.com/electromonkeys)

Si les conteneurs sont venus révolutionner la manière d'exécuter nos applications, ils ne sont jamais que la première pierre d'un édifice beaucoup plus grand. Et dans cet édifice, Kubernetes qui permet d'orchestrer ces conteneurs, n'en est jamais que la seconde pierre.Nous avons ainsi vu tout un écosystème naître autour de Kubernetes : de nouveaux outils de CI et de CD, une nouvelle forme de monitoring, une nouvelle approche des policies, de nouveaux outils de sécurité pour répondre à de nouvelles menaces, et j'en passe. Chacun est ainsi libre de choisir les composants de cet écosystème qu'il souhaite utiliser, ou de se reposer sur un tier en mesure de faire ces choix pour lui.C'est la proposition faite par Google Anthos : une plateforme d'applications modernes. Dans cet épisode, je reçois Romain Vrignaud. Romain est DevOps Product Specialist pour Google, et ensemble nous discutons de la vision de Google au travers d'Anthos, et des différents éléments qui compose cette plateforme d'un genre tout nouveau.Notes de l'épisodegVisor https://gvisor.dev/in-toto https://github.com/in-totoGrafeas https://grafeas.io/Kritis https://github.com/grafeas/kritisIstio https://istio.io/Envoy https://www.envoyproxy.io/OPA Gatekeeper https://github.com/open-policy-agent/gatekeeperSupport the show (https://www.patreon.com/electromonkeys)

J'imagine que tout comme moi, vous êtes passionnés par la tech. C'est un monde où les choses vont vite, très vite, où le paysage change constamment, et où l'ennui n'existe pas ! Pourtant, tous les projets de transformation ne sont pas des réussites, loin s'en faut. Mais quels sont les enjeux d'un tel projet, comment se construit-il, comment faire en sorte de mettre toutes les chances de son côté pour qu'il devienne réel un succès ?Peut-être serez-vous déçu d'apprendre que d'avoir les meilleures technologies, les meilleurs ingénieurs et la meilleure volonté ne suffira pas toujours.Florent Ramière, mon invité dans l'épisode 34 sur Kafka a souhaité partager avec nous les leçons qu'il a tiré sa position de sales engineer chez Confluent, car c'est un métier que les techs connaissent peu, ou mal, et qui pourtant a un rôle crucial pour leur bien être. Merci à Florent pour ce partage, et je vous laisse apprécier cet épisode bonus.Support the show (https://www.patreon.com/electromonkeys)

Apache Kafka est une plateforme de streaming distribuée. Les données reçues en continu peuvent provenir de plusieurs sources, et sont ordonnées dans le temps. Kafka est généralement utilisé pour découpler les services qui produisent la donnée, de ceux qui la consomment et l'analysent.Mais Kafka est aussi une plateforme distribuée, en charge de partitionner et de répliquer la donnée pour des raisons de mise à l'échelle et de tolérance aux pannes. Maintenir ce type de plateforme est complexe, et doit donc s'appuyer sur des équipes disposant d'une bonne expertise opérationnelle.Certaines entreprises proposent également de gérer vos clusters Kafka à votre place, vous libérant ainsi de ces contraintes.Confluent est l'une de ces entreprises, et elle a été fondée par l'épique à l'origine d'Apache Kafka. Dans cet épisode, je reçois Florent Ramière. Florent est solutions engineer pour Confluent, et il vient nous brosser un tableau des cas d'usage et des principes de base d'Apache Kafka.Support the show (https://www.patreon.com/electromonkeys)

Avec la montée en puissance des microservices, les fonctions sont de plus en plus populaires dans nos architectures modernes. Une fonction est généralement un microservice pouvant être invoqué, par exemple, au travers d'une url, ou en réponse à un évènement.L'un des aspects qui rendent les fonctions si attractives, c'est qu'elles ne coûtent rien tant qu'elles ne sont pas utilisées. De plus, un développeur faisant appel une fonction n'a pas a gérer l'infrastructure en charge de l'exécuter. Ce type d'architecture est dite serverless.Dans un épisode précédent, nous avons exploré ce que Google proposait avec Cloud Run. Aujourd'hui, j'ai le plaisir de recevoir Guillaume Laforge. Guillaume est developer advocate pour Google Cloud Platform, et ensemble nous discutons des cas d'usage des fonctions, et des spécificités de Google Cloud Functions.Support the show (https://www.patreon.com/electromonkeys)

Redis est une base de données NoSQL de type clé-valeur qui a la particularité de stocker ses données principalement en mémoire, par opposition aux autres bases de données qui utilisent généralement des disques pour leur persistance. Utiliser la mémoire rend l'accès aux données particulièrement peu coûteux en terme de latences.Popularisée pour son utilisation en tant que système de cache, Redis s'adapte a de nombreux cas d'usage en raison des types de structures de données qu'elle supporte. Elle est par ailleurs hautement disponible et résilience, grâce à ses mécanismes de réplication et de distribution de la donnée.Dans cet épisode, j'ai le plaisir de recevoir François Cerbelle, solution architect, et Tugdual Grall, technical account manager pour RedisLabs. Avec eux nous allons explorer les différents cas d'usage de Redis, et les spécificités de cette base de données en mémoire, qui en fait actuellement l'une des plus populaires auprès des développeurs.Support the show (https://www.patreon.com/electromonkeys)

Redhat est une société qui a été fondée en 1993 et qui est la première a avoir créé un modèle économique viable en fournissant du support sur des softwares open source. En commençant par une distribution Linux, puis avec JBoss, Openstack, Ceph, Keycloak, et plus récemment Openshift, Redhat est aujourd'hui l'un des plus gros contributeur à l'open source.Cependant, contribuer ne signifie pas uniquement écrire du code, mais aussi d'être à l'écoute de ses utilisateurs, de comprendre les problèmes qu'ils cherchent à résoudre, et les difficultés auxquelles ils sont confrontés. A cette fin, Redhat a besoin de maintenir un lien étroit avec les développeurs.C'est pour cette raison que le rôle de developer advocate a fait son apparition. Un developer advocate est lui-même un ingénieur software qui trouve tout autant de plaisir à écrire du code qu'à échanger avec sa communauté, que ce soit au travers de blogs, de meetups ou de conférences.Dans cet épisode, j'ai le plaisir de recevoir Sébastien Blanc. Sébastien est directeur de l'expérience utilisateur pour Redhat, et il nous explique les tenants et les aboutissants d'une profession encore jeune et qui pourrait bien faire naître des vocations !Notes de l'épisodeLes dessous de l’organisation d’une conférence avec Pierre-Antoine Grégoire et Gildas Cuisinier : https://electro-monkeys.fr/?p=294Apprendre Kubernetes avec Jérôme Petazzoni : https://electro-monkeys.fr/?p=217Le refactoring le plus difficile de ma carrière - Jérôme Petazzoni : https://www.youtube.com/watch?v=fu7Tsv5qPGQ&t=118s&index=10&list=PLhuKb8VM9ELFxHghhttrTef-Z4Fxj4ihVSupport the show (https://www.patreon.com/electromonkeys)

Toutes les ressources de Kubernetes peuvent être considérées comme des objects accessibles au travers d'une API et dont l'état est maintenu par un contrôleur. Lorsque vous créez un déploiement par exemple, c'est au contrôleur de s'assurer que l'état que vous désirez est celui présent dans le cluster. Mais Kubernetes n'a qu'un nombre limité d'objets, comme les pods, les déploiements ou les statefulsets. Cependant, Kubernetes nous permet d'étendre cette API en créant de nouveaux objets au travers de ressources personnalisées dont l'état devra être maintenu par un contrôleur dédié. Ces nouveau objets vont par exemple vous permettre de déployer un cluster Kafka ou Elastic dans Kubernetes.Mais en plus, vous pouvez également implémenter un savoir faire opérationnel dans ces contrôleurs, et leur donner la possibilité d'agir en autonomie en réaction à un évènement, comme la création d'un nouveau cluster Kafka, la perte d'un noeud du cluster, ou une demande de backup. Un contrôleur doté d'une logique opérationnelle est appelé un opérateur. Et il existe différents frameworks pour en faciliter la création.Dans cet épisode, j'ai le plaisir de recevoir Denis Jannot. Denis est sales engineer pour D2iQ, anciennement connu en tant que Mesosphere, et il nous explique les problématiques des différents frameworks, et pourquoi D2iQ a fait le choix de créer KUDO, un framework destiné à faciliter la création d'opérateurs.Notes de l'épisodeLe site de KUDO : https://kudo.dev/L'opérateur KUDO sur Github : https://github.com/kudobuilder/kudoLes opérateurs développés pour KUDO : https://github.com/kudobuilder/operatorsSupport the show (https://www.patreon.com/electromonkeys)

La résilience applicative est un sujet complexe, car elle questionne aussi bien le code d'une application, son architecture, que l'infrastructure sur laquelle celle-ci doit tourner. Chaque composant qui entre en jeu peut avoir ses faiblesses, faiblesses qui nous sont souvent révélées lorsque ce composant est mis a rude épreuve, comme par exemple lorsqu'il est soumis à un pic de charge soudain.Choisir le lieu où le code est exécuté est donc aussi critique que d'avoir un code de qualité, et si une dépendance applicative mal gérée peut avoir un impact négatif sur une application, c'est tout aussi vrai pour une dépendance d'infrastructure, qu'il s'agisse d'un DNS, d'un Load Balancer, du cache, etc. Chacun doit être évalué et rigoureusement choisi en fonction du cas d'usage.Dans cet épisode j'ai le plaisir de recevoir Christopher Maneu. Christopher est developer advocate pour Microsoft où il est en charge d'accompagner les startups dans leur réussite technologique, et il nous brosse un tableau d'ensemble des fragilités méconnues des pièces d'infrastructure que nous utilisons quotidiennement sans nécessairement nous poser de question à leur sujet.Notes de l'épisodeLoad.io : http://findresultsonline.com/Apache JMeter : https://jmeter.apache.org/La documentation Microsoft : https://docs.microsoft.com/fr-fr/Designing Distributed Systems : https://azure.microsoft.com/en-us/resources/designing-distributed-systems/Scalabilty Rules : http://scalabilityrules.com/Support the show (https://www.patreon.com/electromonkeys)

Depuis ses origines, le cloud a pour vocation de faciliter l'expérience des développeurs en leur permettant de déployer leurs applications simplement et en gérant pour eux la complexité du run. Quand nous pensons à cette simplicité, Heroku, Cloud Foundry ou Google App Engine nous viennent directement à l'esprit. Mais le cloud a un autre visage, composé d'instances de machines virtuelles, de VPC, de firewalls et de load balancers. Ces composants sont généralement complexes et ont souvent tendance a rebuter le premier développeur venu.C'est pour cette raison que les conteneurs ont pris un tel essor ces dernières années : ils permettent aux développeurs de déployer rapidement leurs applications en s'abstrayant de la complexité de l'infrastructure. Cependant, pour gérer ces conteneurs, il faut un orchestrateur, et cet orchestrateur, c'est aujourd'hui Kubernetes. Et Kubernetes est lui aussi une pièce d'infrastructure que les développeurs ne souhaitent pas gérer. C'est pourquoi Google a lancé Cloud Run : il réuni à lui seul la simplicité d'App Engine avec la flexibilité qu'offre les conteneurs. Dans cet épisode, j'ai le plaisir de recevoir Steren Giannini. Steren est product manager pour Google Cloud Platform, et il a eu la chance de travailler aussi bien sur App Engine que sur Cloud Run. Avec lui, nous allons découvrir les défis que Cloud Run vient relever et pourquoi il constitue la plateforme idéale pour déployer vos applications.Support the show (https://www.patreon.com/electromonkeys)

Quel niveau d'isolation offre la conteneurisation ? Le marketing qui a eu lieu autour de Docker dès 2013 laissait entendre, pour simplifier les choses, qu'un conteneur était comparable à une machine virtuelle, mais en plus léger. Or du point de vue de la sécurité, il n'en est absolument rien : les conteneurs partagent tous le noyau de leur hôte, et sont principalement isolés au travers des namespaces et des cgroups, tandis que les machines virtuelles elles, sont isolées grâce à des technologies de virtualisation matérielle.Les risques liés à la faiblesse de cette isolation a pu ralentir l'adoption des conteneurs par certaines compagnies, les privant par là même des fabuleux atouts qu'apporte Kubernetes. Pourtant, dès 2015, hyper d'un côté et Intel de l'autre avaient commencé à travailler sur cette problématique pour tenter d'apporter une solution qui serait le meilleur des deux mondes. Ces projets ont par la suite fusionné pour n'en donner qu'un seul : les Kata Containers, qui sont aujourd'hui hébergés par l'Openstack foundation.Dans cet épisode, j'ai le plaisir de recevoir Samuel Ortiz. Samuel est principal engineer pour Intel, et il est l'un des contributeurs au projet Kata Containers, ainsi qu'à Rust-vmm qui est au coeur des micro VM telles que Amazon Firecracker. Avec lui nous allons découvrir ce que sont les Kata Containers ainsi que Rust-vmm, et discuter du modèle de sécurité qu'ils sont à même de nous apporter. Support the show (https://www.patreon.com/electromonkeys)

Lorsque l'école 42 a vu le jour, beaucoup n'y ont pas cru : quoi, se sont-ils dit, une école qui ne donne pas de diplôme, qui n'a même pas de profs et qui s'occupe de former des jeunes en reconversion et sans bagages techniques au métier de développeur, quelle blague ! Mais 42 a non seulement prouvé que son modèle était viable, mais qu'en plus il était formidablement efficace, plus encore que nos bonnes vieilles écoles "à l'ancienne". Forcément, ça prête à réfléchir...Or quand le fondateur de l'école 42 a publié un livre retraçant son parcours d'Epita a 42, en passant pas Epitech, et sur sa vision de l'éducation tirée de son expérience personnelle, immanquablement, je me suis jeté dessus. J'y ai découvert des opinions à contre courant assez ahurissantes que je n'aurais jamais imaginé possibles si elles n'avaient pas été vérifiées par des années de pratiques !Dans cet épisode, j'ai le plaisir de recevoir Nicolas Sadirac. Nicolas est le fondateur et l'ex directeur de l'école 42, et il travaille actuellement sur un tout nouveau projet : zone 01. Avec lui, nous revenons le parcours hors norme d'un homme qui a révolutionné le monde de l'éducation, et sur sa vision de l'apprentissage.Support the show (https://www.patreon.com/electromonkeys)

Elastic est une compagnie réputée pour des produits tels que Elastic Search, Elastic Observability ou encore Elastic Security. Mais Elastic peut également héberger et gérer pour vous cette gamme de produits ; ce qui signifie que vous pouvez les utiliser sans avoir à vous soucier de leur maintenance et tout en bénéficiant pleinement de leurs fonctionnalités.Pour cela, Elastic à développé un orchestrateur pour Amazon Web Services et Google Cloud qui se charge de maintenir l'état de vos clusters. Par exemple, en cas de perte d'un noeud du cluster, un nouveau noeud est automatiquement mis en place pour le remplacer, et toutes les opérations que cela implique sont elles aussi automatiquement gérées pour vous.Dans cet épisode, je reçois François Teychené. François est ingénieur software pour Elastic, où il est en charge de l'orchestration et de l'industrialisation des clusters Elastic. Avec lui, nous allons en apprendre un peu plus sur Elastic Cloud et sur le quotidien d'un employé d'Elastic.Support the show (https://www.patreon.com/electromonkeys)

Un concept est parfois beaucoup plus clair lorsqu'il vient accompagné d'un schéma pour l'illustrer ; un pictogramme par exemple est beaucoup plus efficace pour nous avertir de l'éventualité d'un danger que ne le ferait un long texte explicatif. Qui plus est, la représentation visuelle d'un concept nous permet de nous en souvenir durablement, car nous en gardons une image mentale simple et facile à retenir.Cependant, créer ce dessin, ce schéma, cette représentation ou ce pictogramme n'a rien d'évident. Qui ne s'est jamais retrouvé devant un tableau blanc à faire des lignes, des ronds et des carrés sans pour autant réussir à rendre plus clair l'idée qu'il était en train d'exprimer ? D'ailleurs, qui se souvient jamais d'un schéma composé de triangles et de carrés ? Marquer les esprits est un art, d'autant plus délicat que les concepts sont plus abstraits.Dans cet épisode, j'ai le plaisir de recevoir Aurélie Vache. Aurélie est développeuse pour Continental, mais elle est avant tout l'auteur de sketch notes sur Kubernetes et Istio qu'elle a publié originellement sur Twitter avant de les regrouper sous forme de pdf sur Gumroad. Avec elle, nous allons en apprendre un peu plus sur la genèse de ce projet un peu fou dans lequel elle a rendu des pods semblables à des pokeballs !Notes de l'épisodeUnderstanding Kubernetes in a visual way (120 pages), livre illustré disponible sur Gumroad a prix libre : https://gumroad.com/aurelievache#uCxcrLes Sketch Notes sur Istio : https://dev.to/aurelievache/understanding-istio-part-1-istio-components-4ik5Support the show (https://www.patreon.com/electromonkeys)

Le monitoring est un outil fondamental, et l'un des grands piliers de l'observabilité sans lequel nous serions aveugle sur l'état de santé et les performances de nos applications. Or la façon dont nous développons et exécutons ces dernières à énormément changé ces dernières années : distribuées, dynamiques, en micro services ou encore placées dans des conteneurs, les scénarios sont multiples et le plus souvent complexes.C'est dans ce contexte que Prometheus a su se différencier de ses compétiteurs : il est simple à déployer, à maintenir et à utiliser, il collecte les métriques des applications sans impacter leurs performances, et il est parfaitement adapté pour le monitoring des applications et des infrastructures cloud natives.Dans cet épisode, j'ai le plaisir de recevoir Julien Pivotto. Julien est développeur Open Source pour Inuits, et l'un des contributeurs du projet Prometheus. Avec lui nous allons découvrir comment Prometheus a su changer la donne pour devenir l'acteur open source incontournable et même le standard des outils de monitoring du marché.Notes de l'épisodeLa méthode RED de Tom Wilkie : https://thenewstack.io/monitoring-microservices-red-method/La méthode USE de Brendan Gregg : http://www.brendangregg.com/usemethod.htmlCalculateur de mémoire consommée par Prometheus : https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestionSupport the show (https://www.patreon.com/electromonkeys)

Que ce soit Google Next, la DockerCon, AWS re:invent, la KubeCon ou le VoxxedDays, qui n'a jamais eu la chance de se retrouver un jour immergé dans ce type de conférences ? Qu'on aille y chercher de la veille technologique, ou capturer un retour d'expérience, agrandir son réseau ou simplement passer du temps sur les jeux vidéo au booth, tout le monde vous le dira : c'est de la folie !Malheureusement, cette année les évènements ont fait que nous avons été privé de ces moments de fun et de partage... En guise de consolation, pourquoi ne pas visiter les coulisses d'un de ces évènements, avec comme guides deux de ses organisateurs, et pas des moindres, car comme vous aller le découvrir, ils sont totalement ingérables ! :-)Dans cet épisode, j'ai le plaisir de recevoir Pierre-Antoine Grégoire et Gildas Cuisinier. Pierre-Antoine et Gildas sont, entre autres, les organisateurs du VoxxedDays Luxembourg, et avec eux, nous allons découvrir comment à partir d'une communauté de devs, ils ont créé une conférence d'envergure internationale !Support the show (https://www.patreon.com/electromonkeys)

Fortement popularisé par Netflix au début des années 2010, le chaos engineering est un concept, voire aujourd'hui une méthodologie, qui a fortement gagné en maturité ; le principe de base étant de partir des exigences non fonctionnelles d'une application pour la rendre plus résiliante.Cependant, certaines entreprises restent peut-être encore frileuses à l'idée d'adopter une méthodologie qui, pensent-elles à tort, consiste à casser de manière chaotique leur production. Mais ce n'est pas ça, le chaos engineering est bien plus proche d'une science qui vise à faire des hypothèses et a les valider par l'expérimentation.Dans cet épisode, j'ai le plaisir de recevoir Adrian Hornsby. Adrian est évangéliste technique en architecture logicielle pour Amazon Web Services, et il vient démystifier avec nous le concept de chaos engineering.Notes de l'épisodeLe blog sur le chaos engineering de Adrian Hornsby : https://medium.com/@adhorn/the-chaos-engineering-collection-5e188d6a90e2Le livre Chaos Engineering de Casey Rosenthal : https://www.oreilly.com/library/view/chaos-engineering/9781491988459/Le livre Learning Chaos Engineering de Russ Miles : https://www.oreilly.com/library/view/learning-chaos-engineering/9781492050995/Chaos toolkit : https://chaostoolkit.org/L'ensemble de livres sur la culture du SRE chez Google : https://landing.google.com/sre/books/Support the show (https://www.patreon.com/electromonkeys)

Dans le monde actuel, les réseaux informatiques sont devenus aussi indispensables que le sont les réseaux de distribution d'eau, de gaz et d'électricité, ou les autoroutes et les voies aériennes. Sans internet, pas de world wide web, et sans réseau, pas d'applications distribuées. Il est même aujourd'hui considéré comme une simple commodité.Cependant, contrairement à l'eau et à l'électricité, les réseaux informatiques sont devenus de plus en plus complexes à comprendre dû au fait que de nos jours, eux aussi sont virtualisés. Et s'il est vrai qu'ils ont évolué en même temps que nos machines virtuelles, c'est encore plus vrai au niveau de Kubernetes, avec notamment la création des CNI pour Container Network Interface.Pour y voir plus clair dans tous ces concepts, aujourd'hui je n'ai pas un invité, mais bien trois invités : Paul Chaignon, Quentin Monnet et Robin Hahling. Paul, Quentin et Robin travailent tous les trois pour Isovalent, et contribuent au projet open source Cilium. Avec eux, nous allons découvrir pourquoi Cilium n'est pas un CNI comme les autres !Support the show (https://www.patreon.com/electromonkeys)

Avec le rachat de Docker, Mirantis a frappé fort ! Alors que certains s'interrogeaient encore sur leur passage éventuel à Docker, Mirantis a fait la démonstration avec force que Docker, non pas "était fini", mais bien "était une simple transition vers quelque chose d'autre", ce quelque chose étant, vous l'aurez compris, Kubernetes.Si comme moi vous connaissez Mirantis depuis des années pour son engagement sur le volet OpenStack, et peut-être moins sur le volet Kubernetes, alors c'est qu'il est temps de prendre le train en marche et de rassembler les wagons.Dans cet épisode, j'ai le plaisir de recevoir Daniel Virassamy. Daniel est architecte de solutions cloud pour Mirantis et vient nous en dire un peu plus sur l'état de l'art du projet OpenStack, et nous expliquer les motivations qui ont poussé Mirantis à acheter Docker.Support the show (https://www.patreon.com/electromonkeys)

Si le serverless est un concept qui a déjà plus de dix ans, la function as a service a grandement contribué à le remettre sur le devant de la scène, même si la fonction n'est jamais qu'une partie de cet écosystème. On en vient à se questionner sur la légitimité d'avoir la main ou non sur l'environnement d'exécution.Dans ce paysage, il y a deux types d'acteurs : ceux qui créent les produits comme AWS avec Lambda ou Google avec Cloud Run, et qui nous permettent de rêver à des architectures éthérées qui flotteraient dans les airs, et ceux qui utilisent ces mêmes produits. Et les retours d'expérience de ces derniers nous sont plus que jamais précieux pour répondre aux questions qu'on est en droit de se poser sur la mise en place d'une architecture serverless.Dans cet épisode, j'ai le plaisir de recevoir Alain Rouen. Alain est directeur technique pour Smile open source solutions, et il a toujours eu à coeur de tirer le meilleur parti des innovations techniques mises à notre disposition. Avec lui, nous allons en apprendre un peu plus sur les cas d'usage, et les bonnes et les mauvaises pratiques du serverless et de la function as a service.Support the show (https://www.patreon.com/electromonkeys)

Amazon Web Services est au cloud ce que la Ford T est à l'industrie automobile : il a rendu l'accès au Cloud simple et populaire ; mais contrairement à la Ford T, AWS a toujours su se ré:inventer, avec pour seul objectif l'obsession qu'il porte à la satisfaction de ses clients.Depuis près de 10 ans, AWS est considéré comme leader dans le Cloud Computing. Mais entre il y a 10 ans et aujourd'hui, bien des choses ont changé dans l'industrie. Que ce soit la petite startup de garage, la PME, ou un acteur majeur du CAC40, de plus en plus de monde à les yeux tournés vers le Cloud...Utiliser nativement le Cloud, passer dans le Cloud, gérer une infrastructure hybride, moitié on premise, moitié dans le Cloud, il y a tant de scenarios différents ! Alors revenons à la base, et posons-nous cette question : quelle est la vision du Cloud selon AWS.Dans cet épisode, j'ai le plaisir d'accueillir Sébastien Stormacq. Sébastien est Developer Advocate pour AWS, et accessoirement un confrère podcaster, et avec lui nous allons revenir sur les choses à connaître pour réussir son passage dans le Cloud !Notes de l'épisode :Le podcast AWS en français : https://aws.amazon.com/fr/blogs/france/category/podcast/AWS Amplify : https://aws.amazon.com/fr/amplify/Présentation le l'intégration à Slack à re:invent : https://www.youtube.com/watch?v=wugkTArXBYo&list=PLZ_TUMnTqfu807CK1WZis4h89umhDapCE&index=42&t=46m32sSupport the show (https://www.patreon.com/electromonkeys)

Que penser de l'état de la donnée dans Kubernetes ? Est-il assez mature, est-ce qu'on peut y aller ? Faut-il rester prudent ? Face à toutes ces interrogations, j'ai cherché quelques réponses et trouvé un cas d'usage qui en laissera plus d'un dans les étoiles !Pourriez-vous en effet vous imaginer que Kubernetes se prépare à recevoir une quantité de données issues du plus gros télescope au monde, et le tout dans un base de donnée SQL ? On me l'aurait dit que je ne l'aurais pas cru. Pourtant cette base, elle existe, et elle s'appelle Qserv.Dans cet épisode, j'ai le plaisir de recevoir Fabrice Jammes. Fabrice est ingénieur au Laboratoire de Physique de Clermont (CNRS, Université Clermont Auvergne), expert Kubernetes, en particulier en charge de packager et de tester le déploiement de LSST/Qserv. Avec lui, nous allons en apprendre un peu plus sur les challenges auxquels il fait face en utilisant Kubernetes dans le monde de la science.Support the show (https://www.patreon.com/electromonkeys)

Devops par ci, devops par là, devops par ci, devops par là, devops par ci, devops par là... Avez-vous jamais entendu un terme aussi ambigu que celui-là ? Alors si ça ne colle pas avec la théorie, dans la pratique, j'ai souvent vu un ou une devops, voire une équipe devops être le lien humain entre les devs et les ops. Parfois c'est un shift des devs, et parfois un shift des ops, mais dans tous les cas, ce sont de nouvelles compétences à acquérir, et le plus souvent ça concerne la chaîne dite d'intégration et de déploiement continu.Mais c'est quoi au juste le CI/CD ? Que s'y passe-t-il ? Quels en sont les enjeux ? Pour répondre à toutes ces questions, je me suis dit qu'il serait mieux de m'adresser directement au roi plutôt qu'à ses sujets.Dans cet épisode, j'ai donc le plaisir de recevoir Philippe Charrière. Philippe est gestionnaire de compte technique chez Gitlab, et il vient lever le voile sur les mystères qui se cachent derrière le pipeline de CI/CD !Support the show (https://www.patreon.com/electromonkeys)

Le message queue est aujourd'hui au coeur de toutes nos chères applications en micro services, permettant ainsi à chaque service de s'exécuter en toute autonomie sans être couplé à son voisin. Mais ce n'est pas son seul cas d'usage, loin s'en faut, tant le monde d'aujourd'hui tourne autour des évènements.Or quand on pense message queue, bien souvent on pense à Kafka, ou peut-être aussi à RabbitMQ ou SQS. Mais connaissez-vous NATS ? NATS est un projet open source qui a maintenant plus de 10 ans, et qui depuis longtemps prouvé sa robustesse dans des produits comme Pivotal Container Service, entre autres. Par ailleurs, NATS est aujourd'hui hébergé par la CNCF, ce qui est, de mon point de vue, un gage de qualité indéniable.Dans cet épisode, j'ai le plaisir d'accueillir Ivan Kozlovic. Ivan est ingénieur software chez Synadia, la société qui maintient et dirige le développement de NATS. Avec lui, nous allons en apprendre un peu plus sur le message queuing, et des challenges que NATS relève dans ce domaine.Notes de l'épisodeSynadia: https://synadia.com/NATS.io : https://nats.io/Le repository GitHub : https://github.com/nats-ioLa chaîne Youtube de NATS : https://www.youtube.com/c/nats_messaging/videosUne video décrivant le cas d'utilisation de NATS par une compagnie d'électricité : https://youtu.be/YB-zPHxrJ6k?t=979Practical NATS : https://www.amazon.fr/Practical-NATS-Beginner-Pro-English-ebook/dp/B07DLTN6PK/ref=sr_1_1Support the show (https://www.patreon.com/electromonkeys)

Si la matinée est un peu morne et que vous voulez un peu enflammer le chat, rien de tel que de lancer un débat sur la documentation. A quoi ça sert, à qui elle sert, faut-il ou non documenter (son code surtout), et si oui comment le faire intelligemment, etc, etc. Et le moins qu'on puisse dire, c'est que si les avis sont souvent tranchés, ils sont également très souvent contradictoires... Comme pour tout autre sujet, il y a bien évidemment la théorie et la pratique.Pour avoir un avis éclairé sur la question, j'ai la chance de recevoir dans cet épisode Rémy Léone. Rémy est cloud developer advocate chez Scaleway, et il est également le premier mainteneur de la documentation francophone de Kubernetes. Aujourd'hui, il vient nous expliquer avec passion les enjeux qui se cachent derrière une bonne documentation.Sujets évoqués pendant l’épisodeLa documentation francophone de Kubernetes : https://kubernetes.io/fr/docs/home/Le guide pour les personnes souhaitant contribuer : https://kubernetes.io/fr/docs/contribute/start/Retrouvez également les personnes contribuants à la documentation sur le Slack de Kubernetes, https://slack.k8s.io/, channel #kubernetes-docs-frElectro Monkeys PodcastSupport the show (https://www.patreon.com/electromonkeys)

Au royaume des conteneurs, la Registry est reine. Mais y prête-t-on jamais assez d'importance ? Elle pourrait être un goulot d'étranglement, un point particulièrement sensible de notre sécurité, et bien d'autres choses qui nous laisse à penser qu'elle est bien plus qu'une simple commodité.Ces dernières années, le projet Harbor, lancé par VMware puis poussé dans l'open source et finalement recueilli par la CNCF connait un véritable engouement. Pourquoi ? Parce qu'au travers de son interface accueillante, Harbor nous offre un monde de possibilités. RBAC, scan de vulnérabilités, chartmuseum et j'en passe, aucune fonctionnalité ne semble lui faire défaut. Mais de grands pouvoir implique de grandes responsabilités, et Harbor peut s'avérer un projet plus difficile à opérer qu'on ne le pense.C'est pourquoi depuis quelque temps, une équipe d'OVHCloud s'est penchée sur la création d'un opérateur en mesure de gérer aussi bien l'installation que le cycle de vie d'Harbor. Dans cette épisode, je reçois Pierre Péronnet et Maxime Hurtrel. Pierre est le principal mainteneur de l'opérateur Harbor, et Maxime product manager, et tous deux nous viennent tout droit d'OVHCloud. Avec eux, nous allons en apprendre un peu plus sur les challenges à relever pour créer un opérateur autour du projet Harbor.Sujets évoqués pendant l’épisodeL’opérateur Harbor sur Github : https://github.com/goharbor/harbor-operatorTrivy : https://github.com/aquasecurity/trivyOperator SDK : https://github.com/operator-framework/operator-sdkKubebuilder : https://github.com/kubernetes-sigs/kubebuilderLe Gitter d’OVH Registry : https://gitter.im/ovh/container-registryWebinar “L’opérateur Harbor, une nécessité pour certains qui profitera à tous” : https://www.youtube.com/watch?v=uEjOflud8V4Electro Monkeys PodcastSupport the show (https://www.patreon.com/electromonkeys)

A l'ouest de l'ouest vivait un type, un type dont je vais vous conter l'histoire, un type qui s'appelait Jérôme Petazzoni. Parce que, ne vous imaginez pas que Kubernetes s'est fait en un jour. Avant qu'on parle de Kubernetes, on a d'abord beaucoup parlé de Docker, et Docker, c'est quoi Docker ? Et avant de comprendre Kubernetes, il faut déjà comprendre les conteneurs. Et pour nous apprendre les conteneurs, et Kubernetes, de temps en temps y a un homme, et c'est de Jérôme dont je parle là, de temps en temps y a un homme, enfin, un homme qui est exactement à sa place, qui colle parfaitement dans le tableau, comme Jérôme avec Kubernetes.Dans cet épisode, je reçois Jérôme Petazzoni. Jérôme a travaillé pendant plus de huit ans pour Docker où il a acquis une solide réputation de speaker international. Il est également le cofondateur de Enix France, et s'est lancé depuis près de deux ans dans la formation et le conseil sur les conteneurs et Kubernetes au travers de sa société Tiny Shell Script LLC. Il vient aujourd'hui partager avec nous son expérience de formateur et vient nous en dire un peu plus sur le parcours pas si difficile que ça de l'apprentissage de Kubernetes.Sujets évoqués pendant l’épisodeRetrouvez Tiny Shell Script LLC sur https://tinyshellscript.com/Kubernetes the Very Hard Way de Laurent Bernaille : https://www.usenix.org/conference/lisa19/presentation/bernailleVous pouvez suivre Laurent Bernaille sur Twitter : https://twitter.com/lbernailElectro Monkeys PodcastSupport the show (https://www.patreon.com/electromonkeys)

Quand on est face à Quentin Adam pendant quelques minutes pour une interview, qu'on sait qu'il est crevé parce qu'en plus d'être CEO le gars s'est lancé dans un projet fou de construire un respirateur open source, on lui passe tout ; parce qu'on sait au fond de soi qu'il est bien gentil d'être là, plutôt que d'avoir profité de ce moment pour faire une bonne sieste bien méritée.Donc je vous l'accorde, ça manque parfois un peu de structure, on part par ici, on revient par là… Alors tant pis pour le Pulitzer, il n'empêche que j'ai au moins eu l'occasion de partager avec Quentin bon nombre de sujets passionnants !Dans cet épisode, j'ai donc le plaisir de recevoir Quentin Adam. Quentin est CEO de Clever Cloud, et il est le genre de type à s'investir à 200% dans toutes les aventures dans lesquelles il se lance. Avec lui, nous en apprendrons un plus sur Clever Cloud, et les choix qui y sont faits pour gérer notre production.Sujets évoqués pendant l’épisodeMétaphore de la forteresse : https://www.clever-cloud.com/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/Crisp : https://crisp.chat/fr/Makair : https://makair.life/Baptiste JaminValerian SaliouEmmanuel FellerPierre-Antoine GourraudErik Huneker et Marc Julien (Diabeloop)Electro Monkeys PodcastSupport the show (https://www.patreon.com/electromonkeys)

Comme l'a si justement dit Lavoisier : "Dans Kubernetes, rien ne se perd, rien ne se crée, tout se transforme". Est-ce que Kubernetes à changé les load balancers, ou les reverse proxies ? Par fondamentalement, c'est juste que nous les consommons différemment, peut-être mieux, plus efficacement, et certainement de façon plus automatisée et dynamique.S'il n'y a pas de domaine de Kubernetes où il n'y ait quotidiennement des innovations, il y en a certains qui ont sérieusement tendance à fricoter les uns avec les autres ; c'est notamment le cas pour les ingresses et le service mesh... Pourquoi, qu'on-t-il en commun ?Pour nous aider à résoudre ce mystère, je reçois dans cet épisode Michael Matur. Michael est architecte de solutions pour Containous, la société derrière Traefik et Maesh. Car si Traefik est depuis longtemps un contrôleur populaire pour nos ingresses, Maesh fait effet de nouveau venu dans le paysage du service mesh. Et si nous en découvrions un peu plus sur ces deux solutions qui ne manquent pas de fraicheur et d'ingéniosité ?Support the show (https://www.patreon.com/electromonkeys)

L'un des aspects qui rend le monde cloud natif si captivant, c'est sans doute cette capacité qu'il a d'innover en permanence. Et quand je pense à ces sociétés qui innovent, il y en a une qui me vient en tête immédiatement, c'est Rancher Labs.J'ai connu Rancher dans sa version 1, lorsqu'il était un orchestrateur d'orchestrateurs, ça ne s'invente pas. Fin 2017, lorsque toute la communauté s'est rangée derrière Kubernetes, Rancher a fait de même, et Rancher 2 est arrivé, se proposant d'être la tour de contrôle de nos clusters Kubernetes, que ceux-ci soient on prem, dans le cloud, managed ou non.Mais si Rancher est le produit far de Rancher Labs, la créativité des ses ingénieurs n'a pas de limite. Entre autres projets, je pourrais citer RancherOS, un jeos pour conteneurs, Longhorn pour le stockage, Rio pour le service mesh... ou K3s. K3s nous est présenté comme une distribution allégée de Kubernetes pour Edge, IoT, ARM et CI, et qui de surcroît ne demande pas de doctorat de clusterologie.Dans cet épisode je reçois Dmitry Shevrin. Dmitry est field engineer pour l'Europe du sud chez Rancher, et vient nous en dire un peu plus du Rancher 2.4 et cette fantastique distribution de Kubernetes qui vient manger le monde de l'IoT : K3s.Support the show (https://www.patreon.com/electromonkeys)

Si chacun à son rôle à jouer dans le paysage des nouvelles technologies, il y a les Robin, et les Batman. Parmi ceux-ci, on peut sans contester citer VMware qui a considérablement bouleversé le monde de la machine virtuelle. Enfin, je vous parle de ça, c'était hier, et c'était il y a 20 ans.Critiqué par certains pour son modèle économique, VMware n'en reste pas moi un acteur majeur de l'open source, et ses contributions y sont innombrables. Ce n'est pas non plus une société qui reste sur ses acquis : son intérêt pour les conteneurs, puis pour Kubernetes ; les achats d'Heptio, de Bitnami et de Pivotal sont autant de signes qui nous laissent présager que le vent tourne !Et c'est d'ailleurs bien le cas : au travers du projet Pacifique et de Tanzu, VMware est en train de se transformer et de se réinventer. Projet Pacifique, Tanzu, pourquoi tant de noms mystérieux qui nous invitent au voyage ? Et plus important encore : qu'est-ce qui se cache derrière ces projets aux noms si évocateurs ?Dans cet épisode je reçois Eric de Witte. Eric est solution architecte chez VMware, et vient (un peu) lever le voile sur ce que cache Tanzu. Prêt à entrer dans le terrier du lapin vert ?Support the show (https://www.patreon.com/electromonkeys)

Bienvenue sur ce tout premier épisode de ce podcast spécial d'Electro Monkeys : projet Möbius !Et mon premier sujet c'est Rook 1.3. Je dois l'avouer, Rook m'a toujours fasciné. J'avais croisé sa route à la KubeCon et CloudNativeCon de Berlin en 2017, et je ne l'ai plus jamais quitté des yeux.Depuis, il a fait bien du chemin : il a notamment fait son entrée à la CNCF dans les projets Sandbox début 2018, et, alors qu'il est aujourd'hui dans la catégorie Incubating, il s'apprête à passer prochainement au stade Graduate, qui est le plus haut niveau de maturité pour un projet de la CNCF.Qu'est-ce que Rook ? Si je dois le dépeindre en quelques mots, je dirais que c'est un opérateur Kubernetes en charge de fournir du stockage aux applications. Et comme cette petite introduction n'est peut-être pas suffisante pour ceux qui ne sont pas familiarisés avec les opérateurs, ou les problématiques de stockage dans Kubernetes, j'ai le plaisir de recevoir dans cet épisode Sébastien Han. Sébastien est ingénieur Ceph chez Redhat et aujourd'hui l'un des principaux mainteneurs du projet Rook. Avec lui, nous allons nous plonger un peu plus au coeur de Rook et de ce qu'il se propose de nous apporter.Support the show (https://www.patreon.com/electromonkeys)

Depuis 2014, les applications Serverless conçues autour des fonctions (du FaaS pour Function as a Service) sont de plus en plus populaires. Et pour cause, nos infrastructures sont de plus en plus fréquemment capable de réagir à des évènements.S'ils sont récents, les frameworks de Function as a Service n'en connaissent pas moins une rapide évolution, et si Amazon Lambda reste leader du marché, Google, Microsoft, VMware et d'autres ne sont pas en reste.Parmi eux, Knative, créé par Google et soutenu par Redhat, IBM, Pivotal, Dropbox et bien d'autres semble devenir un concurrent sérieux dans le paysage. Knative est open source, il est construit sur Kubernetes, n'a pas de lock-in, et peut donc être utilisé à même votre centre de données.Dans cet épisode je reçois Sébastien Goasguen. Sébastien a été le créateur de Kubeless, la plateforme de Function as a Service de Bitnami, et il est aujourd'hui le co-fondateur de Triggermesh, une plateforme serverless d'intégration de services cloud basée sur Knative.Support the show (https://www.patreon.com/electromonkeys)

"I'm CTO, Bitch."Combien n'ont pas un jour rêvé de prononcer ces mots magiques. Mais au delà de ça, avoir de grands pouvoirs implique de grandes responsabilités, voire un bonne dose de prise de risques.Un CTO doit constamment avoir un oeil sur le marché (et peut-être même les deux), doit comprendre et analyser les changements technologiques, et sans doute disposer d'un sixième sens relativement bien affûté.Dans cet épisode, je reçois Jonathan Basse. Jonathan est le fondateur de Data Essential, et en a été CTO pendant plus de 4 ans. Il revient avec nous sur ce rôle qui lui tient tant à coeur.Support the show (https://www.patreon.com/electromonkeys)

Depuis quelques années, Kubernetes poursuit sa folle course en avant. Alors qu'il était encore considéré il y a peu comme un orchestrateur d'applications stateless, son adoption par l'entreprise l'entraine à devoir de plus en plus être en mesure de gérer les objets stateful et la persistance.L'année dernière, lors de la KubeCon Europe, Bryan Liles nous donnait son feu vert pour utiliser le stockage dans Kubernetes ; mais quelle est la réalité de terrain ? Quel est le point de vue de ceux qui utilisent depuis des années des conteneurs et des volumes ?Cette semaine je reçois Nicolas Muller. Nicolas est le CTO de Treeptik, Docker Captain, et évangélise pour que les entreprises commencent à mettre leurs bases de données dans Kubernetes. Avec lui, nous discuterons des raisons qui lui font dire que c'est un choix judicieux, mais aussi des problèmes que ça soulève.Support the show (https://www.patreon.com/electromonkeys)

Le problème des outils informatiques, c'est que parfois ils génèrent de nouvelles façons de travailler, voire de nouvelles méthodologies. Ces nouvelles méthodologies à leur tour voient apparaître de nouveaux outils, et ces nouveaux outils... créent de nouvelles méthodologies.Parmi les outils qui ont considérablement influencé notre façon de travailler, on peut sans conteste citer Git. Git qui a tout d'abord été le fer de lance d'une nouvelle génération de développeurs, en leur apportant une autre manière de gérer le versioning de leur code ; mais il est également aujourd'hui en train de totalement bouleverser la manière dont sont gérées les opérations.Dans cet épisode, je reçois William Bartlett. William est coach DevOps chez Treeptik et il vient nous parler de cette nouvelle tendance lancée par Weaveworks à qui Google a emboité le pas, et qui se fait appeler : Gitops.Support the show (https://www.patreon.com/electromonkeys)

La gestion de logs est presque aussi vieille que l'informatique elle-même. Pourtant, elle s'est totalement transformée ces dernières années pour s'adapter aux infrastructures d'aujourd'hui. Elle est maintenant centralisée, hautement disponible, sûre et même... intelligente.Dans cet épisode je reçois Gautier Franchini. Gautier travail depuis plus de six ans dans la mise en oeuvre et l'utilisation de clusters Elastic, aussi bien pour la gestion de logs que pour l'analyse de données.Support the show (https://www.patreon.com/electromonkeys)