Electro Monkeys

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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