Electro Monkeys

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 Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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.Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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-9909780110a3Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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/ Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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 Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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/ Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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/ Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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 Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.

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)Hébergé par Audiomeans. Visitez audiomeans.fr/politique-de-confidentialite pour plus d'informations.