Dans le contexte actuel, Les entreprises croulent sous les données qui se multiplient à la vitesse de sortie de frameworkjs et se retrouvent éparpillées dans tout le SI. C'est ici qu'intervient l'orchestration de données. Elle permet de centraliser, de transformer et de charger des informations, offrant une vision unifiée de l'ensemble.

Au premier abord, Kestra est une startup française, mais c'est bien plus. Sa mission est de révolutionner l'orchestration de données grâce à son projet open source. Sur GitHub, la plateforme a déjà conquis des milliers d'utilisateurs, témoignant d'un intérêt marqué pour ses fonctionnalités innovantes.

Nous recevons aujourd'hui Loic Mathieu non pas comment sur faire une extension quarkus mais bien parler de Kestra et des son violon d'Ingres pour l'opensource.

Dans cet épisode, nous abordons des questions cruciales sur la sécurité dans l'environnement cloud native et Kubernetes. 

Pourquoi parle-t-on tant de cloud native security de nos jours?  Quels sont les nouveaux défis et vecteurs d'attaques que nous sous-estimons lors de l’adoption des containers ou de Kubernetes?  🔍 Explorez avec nous:  Les nouveaux challenges de la sécurité Cloud Native. Comment Kubernetes a-t-il radicalement modifié la gestion de la sécurité? Comment fournir des environnements sécurisés sans créer de frustration aux différentes équipes? 

🎤 Animé par notre architecte cloud Imad Bensisaid, ce podcast met en lumière les perspectives précieuses de nos invités de marque:  

✨ Maxime Coquerel, Microsoft MVP Azure & Security,  Lien vers son blog : https://zigmax.net  

✨ Mathieu Benoit, CNCF Ambassador & GDE Cloud   Lien vers son blog :    https://medium.com/@mabenoit 

 ✨ Vincent Ledan, Leader en Cloud Native Security (point base)  Lien vers son blog :    medium.com/@vincn.ledan  et https://pointbase.hashnode.dev/series...

Un plugin réseau est une brique cruciale au sein Kubernetes, car c'est grâce à lui qu'il est possible de créer un réseau au niveau du cluster. Depuis l'arrivée de la Container Network Interface, ou CNI pour faire court, il est très facile de brancher n'importe quel plugin qui réponde à cette interface ; et ces plugins sont légions ! Dans ce domaine, Calico est le couteau suisse des CNI.  On le retrouve dans différentes configurations que ce soit des distributions on premise ou chez les Cloud Providers. 

Pour nous parler de l’écosystème Calico, nous avons le plaisir de recevoir Stéphane Reytan. Stéphane est directeur général sécurité de Blue Trusty et  ensemble nous discuterons de Calico dans sa version Open Source qui permet de  créer une plate-forme active de protection et d'observabilité des applications , mais aussi de l’offre Enterprise proposé par Tigera.

Apache Kafka est une plateforme de streaming distribuée. Les données reçues en continu peuvent provenir de plusieurs sources, et sont ordonnées dans le temps. Kafka est généralement utilisé pour découpler les services qui produisent la donnée, de ceux qui la consomment et l'analysent.

Mais Kafka est aussi une plateforme distribuée, en charge de partitionner et de répliquer la donnée pour des raisons de mise à l'échelle et de tolérance aux pannes. Maintenir ce type de plateforme est complexe, et doit donc s'appuyer sur des équipes disposant d'une bonne expertise opérationnelle.

Certaines entreprises proposent également de gérer vos clusters Kafka à votre place, vous libérant ainsi de ces contraintes.

Confluent est l'une de ces entreprises, et elle a été fondée par l'épique à l'origine d'Apache Kafka. Dans cet épisode, je reçois Florent Ramière. Florent est solutions engineer pour Confluent, et il vient nous brosser un tableau des cas d'usage et des principes de base d'Apache Kafka.

Support the show (https://www.patreon.com/electromonkeys)

Avec la montée en puissance des microservices, les fonctions sont de plus en plus populaires dans nos architectures modernes. Une fonction est généralement un microservice pouvant être invoqué, par exemple, au travers d'une url, ou en réponse à un évènement.

L'un des aspects qui rendent les fonctions si attractives, c'est qu'elles ne coûtent rien tant qu'elles ne sont pas utilisées. De plus, un développeur faisant appel une fonction n'a pas a gérer l'infrastructure en charge de l'exécuter. Ce type d'architecture est dite serverless.

Dans un épisode précédent, nous avons exploré ce que Google proposait avec Cloud Run. Aujourd'hui, j'ai le plaisir de recevoir Guillaume Laforge. Guillaume est developer advocate pour Google Cloud Platform, et ensemble nous discutons des cas d'usage des fonctions, et des spécificités de Google Cloud Functions.

Support the show (https://www.patreon.com/electromonkeys)

Redis est une base de données NoSQL de type clé-valeur qui a la particularité de stocker ses données principalement en mémoire, par opposition aux autres bases de données qui utilisent généralement des disques pour leur persistance. Utiliser la mémoire rend l'accès aux données particulièrement peu coûteux en terme de latences.

Popularisée pour son utilisation en tant que système de cache, Redis s'adapte a de nombreux cas d'usage en raison des types de structures de données qu'elle supporte. Elle est par ailleurs hautement disponible et résilience, grâce à ses mécanismes de réplication et de distribution de la donnée.

Dans cet épisode, j'ai le plaisir de recevoir François Cerbelle, solution architect, et Tugdual Grall, technical account manager pour RedisLabs. Avec eux nous allons explorer les différents cas d'usage de Redis, et les spécificités de cette base de données en mémoire, qui en fait actuellement l'une des plus populaires auprès des développeurs.

Support the show (https://www.patreon.com/electromonkeys)

Redhat est une société qui a été fondée en 1993 et qui est la première a avoir créé un modèle économique viable en fournissant du support sur des softwares open source. En commençant par une distribution Linux, puis avec JBoss, Openstack, Ceph, Keycloak, et plus récemment Openshift, Redhat est aujourd'hui l'un des plus gros contributeur à l'open source.

Cependant, contribuer ne signifie pas uniquement écrire du code, mais aussi d'être à l'écoute de ses utilisateurs, de comprendre les problèmes qu'ils cherchent à résoudre, et les difficultés auxquelles ils sont confrontés. A cette fin, Redhat a besoin de maintenir un lien étroit avec les développeurs.

C'est pour cette raison que le rôle de developer advocate a fait son apparition. Un developer advocate est lui-même un ingénieur software qui trouve tout autant de plaisir à écrire du code qu'à échanger avec sa communauté, que ce soit au travers de blogs, de meetups ou de conférences.

Dans cet épisode, j'ai le plaisir de recevoir Sébastien Blanc. Sébastien est directeur de l'expérience utilisateur pour Redhat, et il nous explique les tenants et les aboutissants d'une profession encore jeune et qui pourrait bien faire naître des vocations !

Notes de l'épisode

• Les dessous de l’organisation d’une conférence avec Pierre-Antoine Grégoire et Gildas Cuisinier : https://electro-monkeys.fr/?p=294
• Apprendre Kubernetes avec Jérôme Petazzoni : https://electro-monkeys.fr/?p=217
• Le 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-Z4Fxj4ihV

Support the show (https://www.patreon.com/electromonkeys)

Toutes les ressources de Kubernetes peuvent être considérées comme des objects accessibles au travers d'une API et dont l'état est maintenu par un contrôleur. Lorsque vous créez un déploiement par exemple, c'est au contrôleur de s'assurer que l'état que vous désirez est celui présent dans le cluster. Mais Kubernetes n'a qu'un nombre limité d'objets, comme les pods, les déploiements ou les statefulsets. Cependant, Kubernetes nous permet d'étendre cette API en créant de nouveaux objets au travers de ressources personnalisées dont l'état devra être maintenu par un contrôleur dédié. Ces nouveau objets vont par exemple vous permettre de déployer un cluster Kafka ou Elastic dans Kubernetes.

Mais en plus, vous pouvez également implémenter un savoir faire opérationnel dans ces contrôleurs, et leur donner la possibilité d'agir en autonomie en réaction à un évènement, comme la création d'un nouveau cluster Kafka, la perte d'un noeud du cluster, ou une demande de backup. Un contrôleur doté d'une logique opérationnelle est appelé un opérateur. Et il existe différents frameworks pour en faciliter la création.

Dans cet épisode, j'ai le plaisir de recevoir Denis Jannot. Denis est sales engineer pour D2iQ, anciennement connu en tant que Mesosphere, et il nous explique les problématiques des différents frameworks, et pourquoi D2iQ a fait le choix de créer KUDO, un framework destiné à faciliter la création d'opérateurs.

Notes de l'épisode

• Le site de KUDO : https://kudo.dev/
• L'opérateur KUDO sur Github : https://github.com/kudobuilder/kudo
• Les opérateurs développés pour KUDO : https://github.com/kudobuilder/operators

Support the show (https://www.patreon.com/electromonkeys)

La résilience applicative est un sujet complexe, car elle questionne aussi bien le code d'une application, son architecture, que l'infrastructure sur laquelle celle-ci doit tourner. Chaque composant qui entre en jeu peut avoir ses faiblesses, faiblesses qui nous sont souvent révélées lorsque ce composant est mis a rude épreuve, comme par exemple lorsqu'il est soumis à un pic de charge soudain.

Choisir le lieu où le code est exécuté est donc aussi critique que d'avoir un code de qualité, et si une dépendance applicative mal gérée peut avoir un impact négatif sur une application, c'est tout aussi vrai pour une dépendance d'infrastructure, qu'il s'agisse d'un DNS, d'un Load Balancer, du cache, etc. Chacun doit être évalué et rigoureusement choisi en fonction du cas d'usage.

Dans cet épisode j'ai le plaisir de recevoir Christopher Maneu. Christopher est developer advocate pour Microsoft où il est en charge d'accompagner les startups dans leur réussite technologique, et il nous brosse un tableau d'ensemble des fragilités méconnues des pièces d'infrastructure que nous utilisons quotidiennement sans nécessairement nous poser de question à leur sujet.

Notes de l'épisode

• Load.io : http://findresultsonline.com/
• Apache JMeter : https://jmeter.apache.org/
• La documentation Microsoft : https://docs.microsoft.com/fr-fr/
• Designing Distributed Systems : https://azure.microsoft.com/en-us/resources/designing-distributed-systems/
• Scalabilty Rules : http://scalabilityrules.com/

Support the show (https://www.patreon.com/electromonkeys)

Depuis ses origines, le cloud a pour vocation de faciliter l'expérience des développeurs en leur permettant de déployer leurs applications simplement et en gérant pour eux la complexité du run. Quand nous pensons à cette simplicité, Heroku, Cloud Foundry ou Google App Engine nous viennent directement à l'esprit. Mais le cloud a un autre visage, composé d'instances de machines virtuelles, de VPC, de firewalls et de load balancers. Ces composants sont généralement complexes et ont souvent tendance a rebuter le premier développeur venu.

C'est pour cette raison que les conteneurs ont pris un tel essor ces dernières années : ils permettent aux développeurs de déployer rapidement leurs applications en s'abstrayant de la complexité de l'infrastructure. Cependant, pour gérer ces conteneurs, il faut un orchestrateur, et cet orchestrateur, c'est aujourd'hui Kubernetes. Et Kubernetes est lui aussi une pièce d'infrastructure que les développeurs ne souhaitent pas gérer. C'est pourquoi Google a lancé Cloud Run : il réuni à lui seul la simplicité d'App Engine avec la flexibilité qu'offre les conteneurs.

Dans cet épisode, j'ai le plaisir de recevoir Steren Giannini. Steren est product manager pour Google Cloud Platform, et il a eu la chance de travailler aussi bien sur App Engine que sur Cloud Run. Avec lui, nous allons découvrir les défis que Cloud Run vient relever et pourquoi il constitue la plateforme idéale pour déployer vos applications.

Support the show (https://www.patreon.com/electromonkeys)

Quel niveau d'isolation offre la conteneurisation ? Le marketing qui a eu lieu autour de Docker dès 2013 laissait entendre, pour simplifier les choses, qu'un conteneur était comparable à une machine virtuelle, mais en plus léger. Or du point de vue de la sécurité, il n'en est absolument rien : les conteneurs partagent tous le noyau de leur hôte, et sont principalement isolés au travers des namespaces et des cgroups, tandis que les machines virtuelles elles, sont isolées grâce à des technologies de virtualisation matérielle.

Les risques liés à la faiblesse de cette isolation a pu ralentir l'adoption des conteneurs par certaines compagnies, les privant par là même des fabuleux atouts qu'apporte Kubernetes. Pourtant, dès 2015, hyper d'un côté et Intel de l'autre avaient commencé à travailler sur cette problématique pour tenter d'apporter une solution qui serait le meilleur des deux mondes. Ces projets ont par la suite fusionné pour n'en donner qu'un seul : les Kata Containers, qui sont aujourd'hui hébergés par l'Openstack foundation.

Dans cet épisode, j'ai le plaisir de recevoir Samuel Ortiz. Samuel est principal engineer pour Intel, et il est l'un des contributeurs au projet Kata Containers, ainsi qu'à Rust-vmm qui est au coeur des micro VM telles que Amazon Firecracker. Avec lui nous allons découvrir ce que sont les Kata Containers ainsi que Rust-vmm, et discuter du modèle de sécurité qu'ils sont à même de nous apporter. 

Support the show (https://www.patreon.com/electromonkeys)

Lorsque l'école 42 a vu le jour, beaucoup n'y ont pas cru : quoi, se sont-ils dit, une école qui ne donne pas de diplôme, qui n'a même pas de profs et qui s'occupe de former des jeunes en reconversion et sans bagages techniques au métier de développeur, quelle blague ! Mais 42 a non seulement prouvé que son modèle était viable, mais qu'en plus il était formidablement efficace, plus encore que nos bonnes vieilles écoles "à l'ancienne". Forcément, ça prête à réfléchir...

Or quand le fondateur de l'école 42 a publié un livre retraçant son parcours d'Epita a 42, en passant pas Epitech, et sur sa vision de l'éducation tirée de son expérience personnelle, immanquablement, je me suis jeté dessus. J'y ai découvert des opinions à contre courant assez ahurissantes que je n'aurais jamais imaginé possibles si elles n'avaient pas été vérifiées par des années de pratiques !

Dans cet épisode, j'ai le plaisir de recevoir Nicolas Sadirac. Nicolas est le fondateur et l'ex directeur de l'école 42, et il travaille actuellement sur un tout nouveau projet : zone 01. Avec lui, nous revenons le parcours hors norme d'un homme qui a révolutionné le monde de l'éducation, et sur sa vision de l'apprentissage.

Support the show (https://www.patreon.com/electromonkeys)

Elastic est une compagnie réputée pour des produits tels que Elastic Search, Elastic Observability ou encore Elastic Security. Mais Elastic peut également héberger et gérer pour vous cette gamme de produits ; ce qui signifie que vous pouvez les utiliser sans avoir à vous soucier de leur maintenance et tout en bénéficiant pleinement de leurs fonctionnalités.

Pour cela, Elastic à développé un orchestrateur pour Amazon Web Services et Google Cloud qui se charge de maintenir l'état de vos clusters. Par exemple, en cas de perte d'un noeud du cluster, un nouveau noeud est automatiquement mis en place pour le remplacer, et toutes les opérations que cela implique sont elles aussi automatiquement gérées pour vous.

Dans cet épisode, je reçois François Teychené. François est ingénieur software pour Elastic, où il est en charge de l'orchestration et de l'industrialisation des clusters Elastic. Avec lui, nous allons en apprendre un peu plus sur Elastic Cloud et sur le quotidien d'un employé d'Elastic.

Support the show (https://www.patreon.com/electromonkeys)

En matière de marketing, comme dans l’immobilier, les trois choses les plus importantes sont l’emplacement, l’emplacement, l’emplacement. Un des emplacements incontournables pour mettre en valeur son site internet et son produit, c’est dans les résultats des moteurs de recherche. Les internautes privilégient les premiers résultats de leurs recherches qui bénéficieront de plus de trafic que les résultats plus bas dans la première page. Figurer sur la deuxième page, c’est quasiment synonyme de l'inexistence. Tout ce qui peut être fait pour grappiller quelques places peut améliorer considérablement le trafic qui arrive sur les pages de son site web.

Dans l’épisode d’aujourd’hui, Stéphane reçoit Jean-Marc Courtiade pour discuter de SEO, Search Engine Optimization. Jean-Marc est consultant en SEO et en analytique du numérique. Il aide différentes organisations à augmenter le trafic sur leur site, à optimiser la performance de leur offre numérique et à se mettre en conformité avec la RGPD. Il a travaillé avec des acteurs dans différents secteurs. Stéphane et Jean-Marc parleront des différents critères connus utilisés par les algorithmes d’arpentage et de classement des pages web. Ils discuteront des actions incontournables, de pourquoi ces actions sont utiles et des pistes à explorer pour améliorer son positionnement.

Un 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'épisode

• Understanding Kubernetes in a visual way (120 pages), livre illustré disponible sur Gumroad a prix libre : https://gumroad.com/aurelievache#uCxcr
• Les Sketch Notes sur Istio : https://dev.to/aurelievache/understanding-istio-part-1-istio-components-4ik5

Support the show (https://www.patreon.com/electromonkeys)

Le monitoring est un outil fondamental, et l'un des grands piliers de l'observabilité sans lequel nous serions aveugle sur l'état de santé et les performances de nos applications. Or la façon dont nous développons et exécutons ces dernières à énormément changé ces dernières années : distribuées, dynamiques, en micro services ou encore placées dans des conteneurs, les scénarios sont multiples et le plus souvent complexes.

C'est dans ce contexte que Prometheus a su se différencier de ses compétiteurs : il est simple à déployer, à maintenir et à utiliser, il collecte les métriques des applications sans impacter leurs performances, et il est parfaitement adapté pour le monitoring des applications et des infrastructures cloud natives.

Dans cet épisode, j'ai le plaisir de recevoir Julien Pivotto. Julien est développeur Open Source pour Inuits, et l'un des contributeurs du projet Prometheus. Avec lui nous allons découvrir comment Prometheus a su changer la donne pour devenir l'acteur open source incontournable et même le standard des outils de monitoring du marché.

Notes de l'épisode

• La 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.html
• Calculateur de mémoire consommée par Prometheus :  https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion

Support the show (https://www.patreon.com/electromonkeys)

Que ce soit Google Next, la DockerCon, AWS re:invent, la KubeCon ou le VoxxedDays, qui n'a jamais eu la chance de se retrouver un jour immergé dans ce type de conférences ? Qu'on aille y chercher de la veille technologique, ou capturer un retour d'expérience, agrandir son réseau ou simplement passer du temps sur les jeux vidéo au booth, tout le monde vous le dira : c'est de la folie !

Malheureusement, cette année les évènements ont fait que nous avons été privé de ces moments de fun et de partage... En guise de consolation, pourquoi ne pas visiter les coulisses d'un de ces évènements, avec comme guides deux de ses organisateurs, et pas des moindres, car comme vous aller le découvrir, ils sont totalement ingérables ! :-)

Dans cet épisode, j'ai le plaisir de recevoir Pierre-Antoine Grégoire et Gildas Cuisinier. Pierre-Antoine et Gildas sont, entre autres, les organisateurs du VoxxedDays Luxembourg, et avec eux, nous allons découvrir comment à partir d'une communauté de devs, ils ont créé une conférence d'envergure internationale !

Support the show (https://www.patreon.com/electromonkeys)

Fortement popularisé par Netflix au début des années 2010, le chaos engineering est un concept, voire aujourd'hui une méthodologie, qui a fortement gagné en maturité ; le principe de base étant de partir des exigences non fonctionnelles d'une application pour la rendre plus résiliante.

Cependant, certaines entreprises restent peut-être encore frileuses à l'idée d'adopter une méthodologie qui, pensent-elles à tort, consiste à casser de manière chaotique leur production. Mais ce n'est pas ça, le chaos engineering est bien plus proche d'une science qui vise à faire des hypothèses et a les valider par l'expérimentation.

Dans cet épisode, j'ai le plaisir de recevoir Adrian Hornsby. Adrian est évangéliste technique en architecture logicielle pour Amazon Web Services, et il vient démystifier avec nous le concept de chaos engineering.

Notes de l'épisode

• Le blog sur le chaos engineering de Adrian Hornsby : https://medium.com/@adhorn/the-chaos-engineering-collection-5e188d6a90e2
• Le livre Chaos Engineering de Casey Rosenthal : https://www.oreilly.com/library/view/chaos-engineering/9781491988459/
• Le livre Learning Chaos Engineering de Russ Miles : https://www.oreilly.com/library/view/learning-chaos-engineering/9781492050995/
• Chaos toolkit : https://chaostoolkit.org/
• L'ensemble de livres sur la culture du SRE chez Google : https://landing.google.com/sre/books/

Support the show (https://www.patreon.com/electromonkeys)

Dans le monde actuel, les réseaux informatiques sont devenus aussi indispensables que le sont les réseaux de distribution d'eau, de gaz et d'électricité, ou les autoroutes et les voies aériennes. Sans internet, pas de world wide web, et sans réseau, pas d'applications distribuées. Il est même aujourd'hui considéré comme une simple commodité.

Cependant, contrairement à l'eau et à l'électricité, les réseaux informatiques sont devenus de plus en plus complexes à comprendre dû au fait que de nos jours, eux aussi sont virtualisés. Et s'il est vrai qu'ils ont évolué en même temps que nos machines virtuelles, c'est encore plus vrai au niveau de Kubernetes, avec notamment la création des CNI pour Container Network Interface.

Pour y voir plus clair dans tous ces concepts, aujourd'hui je n'ai pas un invité, mais bien trois invités : Paul Chaignon, Quentin Monnet et Robin Hahling. Paul, Quentin et Robin travailent tous les trois pour Isovalent, et contribuent au projet open source Cilium. Avec eux, nous allons découvrir pourquoi Cilium n'est pas un CNI comme les autres !

Support the show (https://www.patreon.com/electromonkeys)

Avec le rachat de Docker, Mirantis a frappé fort ! Alors que certains s'interrogeaient encore sur leur passage éventuel à Docker, Mirantis a fait la démonstration avec force que Docker, non pas "était fini", mais bien "était une simple transition vers quelque chose d'autre", ce quelque chose étant, vous l'aurez compris, Kubernetes.

Si comme moi vous connaissez Mirantis depuis des années pour son engagement sur le volet OpenStack, et peut-être moins sur le volet Kubernetes, alors c'est qu'il est temps de prendre le train en marche et de rassembler les wagons.

Dans cet épisode, j'ai le plaisir de recevoir Daniel Virassamy. Daniel est architecte de solutions cloud pour Mirantis et vient nous en dire un peu plus sur l'état de l'art du projet OpenStack, et nous expliquer les motivations qui ont poussé Mirantis à acheter Docker.

Support the show (https://www.patreon.com/electromonkeys)

Si le serverless est un concept qui a déjà plus de dix ans, la function as a service a grandement contribué à le remettre sur le devant de la scène, même si la fonction n'est jamais qu'une partie de cet écosystème. On en vient à se questionner sur la légitimité d'avoir la main ou non sur l'environnement d'exécution.

Dans ce paysage, il y a deux types d'acteurs : ceux qui créent les produits comme AWS avec Lambda ou Google avec Cloud Run, et qui nous permettent de rêver à des architectures éthérées qui flotteraient dans les airs, et ceux qui utilisent ces mêmes produits. Et les retours d'expérience de ces derniers nous sont plus que jamais précieux pour répondre aux questions qu'on est en droit de se poser sur la mise en place d'une architecture serverless.

Dans cet épisode, j'ai le plaisir de recevoir Alain Rouen. Alain est directeur technique pour Smile open source solutions, et il a toujours eu à coeur de tirer le meilleur parti des innovations techniques mises à notre disposition. Avec lui, nous allons en apprendre un peu plus sur les cas d'usage, et les bonnes et les mauvaises pratiques du serverless et de la function as a service.

Support the show (https://www.patreon.com/electromonkeys)

Amazon Web Services est au cloud ce que la Ford T est à l'industrie automobile : il a rendu l'accès au Cloud simple et populaire ; mais contrairement à la Ford T, AWS a toujours su se ré:inventer, avec pour seul objectif l'obsession qu'il porte à la satisfaction de ses clients.

Depuis près de 10 ans, AWS est considéré comme leader dans le Cloud Computing. Mais entre il y a 10 ans et aujourd'hui, bien des choses ont changé dans l'industrie. Que ce soit la petite startup de garage, la PME, ou un acteur majeur du CAC40, de plus en plus de monde à les yeux tournés vers le Cloud...

Utiliser nativement le Cloud, passer dans le Cloud, gérer une infrastructure hybride, moitié on premise, moitié dans le Cloud, il y a tant de scenarios différents ! Alors revenons à la base, et posons-nous cette question : quelle est la vision du Cloud selon AWS.

Dans cet épisode, j'ai le plaisir d'accueillir Sébastien Stormacq. Sébastien est Developer Advocate pour AWS, et accessoirement un confrère podcaster, et avec lui nous allons revenir sur les choses à connaître pour réussir son passage dans le Cloud !

Notes de l'épisode :

• Le podcast AWS en français : https://aws.amazon.com/fr/blogs/france/category/podcast/
• AWS Amplify : https://aws.amazon.com/fr/amplify/
• Présentation le l'intégration à Slack à re:invent : https://www.youtube.com/watch?v=wugkTArXBYo&list=PLZ_TUMnTqfu807CK1WZis4h89umhDapCE&index=42&t=46m32s

Support the show (https://www.patreon.com/electromonkeys)

Que penser de l'état de la donnée dans Kubernetes ? Est-il assez mature, est-ce qu'on peut y aller ? Faut-il rester prudent ? Face à toutes ces interrogations, j'ai cherché quelques réponses et trouvé un cas d'usage qui en laissera plus d'un dans les étoiles !

Pourriez-vous en effet vous imaginer que Kubernetes se prépare à recevoir une quantité de données issues du plus gros télescope au monde, et le tout dans un base de donnée SQL ? On me l'aurait dit que je ne l'aurais pas cru. Pourtant cette base, elle existe, et elle s'appelle Qserv.

Dans cet épisode, j'ai le plaisir de recevoir Fabrice Jammes. Fabrice est ingénieur au Laboratoire de Physique de Clermont (CNRS, Université Clermont Auvergne), expert Kubernetes, en particulier en charge de packager et de tester le déploiement de LSST/Qserv. Avec lui, nous allons en apprendre un peu plus sur les challenges auxquels il fait face en utilisant Kubernetes dans le monde de la science.

Support the show (https://www.patreon.com/electromonkeys)

Devops par ci, devops par là, devops par ci, devops par là, devops par ci, devops par là... Avez-vous jamais entendu un terme aussi ambigu que celui-là ? Alors si ça ne colle pas avec la théorie, dans la pratique, j'ai souvent vu un ou une devops, voire une équipe devops être le lien humain entre les devs et les ops. Parfois c'est un shift des devs, et parfois un shift des ops, mais dans tous les cas, ce sont de nouvelles compétences à acquérir, et le plus souvent ça concerne la chaîne dite d'intégration et de déploiement continu.

Mais c'est quoi au juste le CI/CD ? Que s'y passe-t-il ? Quels en sont les enjeux ? Pour répondre à toutes ces questions, je me suis dit qu'il serait mieux de m'adresser directement au roi plutôt qu'à ses sujets.

Dans cet épisode, j'ai donc le plaisir de recevoir Philippe Charrière. Philippe est gestionnaire de compte technique chez Gitlab, et il vient lever le voile sur les mystères qui se cachent derrière le pipeline de CI/CD !

Support the show (https://www.patreon.com/electromonkeys)

Un plugin réseau est une brique cruciale au sein Kubernetes, car c'est grâce à lui qu'il est possible de créer un réseau au niveau du cluster. Depuis l'arrivée de la Container Network Interface, ou CNI pour faire court, il est très facile de brancher n'importe quel plugin qui réponde à cette interface ; et ces plugins sont légion ! Il y en a UN cependant qui se démarque du lot : Cilium. En effet, Cilium a pris le parti depuis le jour 1 d'utiliser eBPF pour gérer le réseau, la ou les autres reposent le plus souvent sur Netfilter. Or si Cilium a su tacler la concurrence en tirant le meilleur parti d'eBPF pour la mise à l'échelle, son voyage au cœur d'eBPF ne s'est pas arrêté là. L'Observabilité, les capacités de Service Mesh et de Sécurité sont autant d'aspects d'eBPF qui peuvent être intégrés à un network plugin.

Pour nous dévoiler la magie qui se cache derrière eBPF, j'ai le plaisir de recevoir Robin Hahling, mon invite de l'episode 20 sur Hubble qui est Software Engineer pour Isovalent, la société derriere Cilium, et Raphaeël Pinson, Solutions Architect également chez Isovalent. Ensemble nous discutons bien évidemment de Cilium et d'eBPF, mais aussi de toutes les nouveautés qui ont été apportées ces deux dernières années a Cilium.

Notes de l'épisode

• What’s new in Cilium 1.11?
• How Cilium Protects Against Common Network Attacks
• Isovalent announce Tetragon , an eBPF-based Security Observability & Runtime Enforcement

Quelques nouvelles de My Little Team

• Les 50 meilleures équipes B Corp pour qui travailler en 2022

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'épisode

• Synadia: https://synadia.com/
• NATS.io : https://nats.io/
• Le repository GitHub : https://github.com/nats-io
• La chaîne Youtube de NATS : https://www.youtube.com/c/nats_messaging/videos
• Une video décrivant le cas d'utilisation de NATS par une compagnie d'électricité : https://youtu.be/YB-zPHxrJ6k?t=979
• Practical NATS : https://www.amazon.fr/Practical-NATS-Beginner-Pro-English-ebook/dp/B07DLTN6PK/ref=sr_1_1

Support the show (https://www.patreon.com/electromonkeys)

Si la matinée est un peu morne et que vous voulez un peu enflammer le chat, rien de tel que de lancer un débat sur la documentation. A quoi ça sert, à qui elle sert, faut-il ou non documenter (son code surtout), et si oui comment le faire intelligemment, etc, etc. Et le moins qu'on puisse dire, c'est que si les avis sont souvent tranchés, ils sont également très souvent contradictoires... Comme pour tout autre sujet, il y a bien évidemment la théorie et la pratique.

Pour avoir un avis éclairé sur la question, j'ai la chance de recevoir dans cet épisode Rémy Léone. Rémy est cloud developer advocate chez Scaleway, et il est également le premier mainteneur de la documentation francophone de Kubernetes. Aujourd'hui, il vient nous expliquer avec passion les enjeux qui se cachent derrière une bonne documentation.

Sujets évoqués pendant l’épisode

• La 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-fr

Electro Monkeys Podcast

Support the show (https://www.patreon.com/electromonkeys)

Au royaume des conteneurs, la Registry est reine. Mais y prête-t-on jamais assez d'importance ? Elle pourrait être un goulot d'étranglement, un point particulièrement sensible de notre sécurité, et bien d'autres choses qui nous laisse à penser qu'elle est bien plus qu'une simple commodité.

Ces dernières années, le projet Harbor, lancé par VMware puis poussé dans l'open source et finalement recueilli par la CNCF connait un véritable engouement. Pourquoi ? Parce qu'au travers de son interface accueillante, Harbor nous offre un monde de possibilités. RBAC, scan de vulnérabilités, chartmuseum et j'en passe, aucune fonctionnalité ne semble lui faire défaut. Mais de grands pouvoir implique de grandes responsabilités, et Harbor peut s'avérer un projet plus difficile à opérer qu'on ne le pense.

C'est pourquoi depuis quelque temps, une équipe d'OVHCloud s'est penchée sur la création d'un opérateur en mesure de gérer aussi bien l'installation que le cycle de vie d'Harbor. Dans cette épisode, je reçois Pierre Péronnet et Maxime Hurtrel. Pierre est le principal mainteneur de l'opérateur Harbor, et Maxime product manager, et tous deux nous viennent tout droit d'OVHCloud. Avec eux, nous allons en apprendre un peu plus sur les challenges à relever pour créer un opérateur autour du projet Harbor.

Sujets évoqués pendant l’épisode

• L’opérateur Harbor sur Github : https://github.com/goharbor/harbor-operator
• Trivy : https://github.com/aquasecurity/trivy
• Operator SDK : https://github.com/operator-framework/operator-sdk
• Kubebuilder : https://github.com/kubernetes-sigs/kubebuilder
• Le Gitter d’OVH Registry : https://gitter.im/ovh/container-registry
• Webinar “L’opérateur Harbor, une nécessité pour certains qui profitera à tous” : https://www.youtube.com/watch?v=uEjOflud8V4

Electro Monkeys Podcast

Support the show (https://www.patreon.com/electromonkeys)

A l'ouest de l'ouest vivait un type, un type dont je vais vous conter l'histoire, un type qui s'appelait Jérôme Petazzoni. Parce que, ne vous imaginez pas que Kubernetes s'est fait en un jour. Avant qu'on parle de Kubernetes, on a d'abord beaucoup parlé de Docker, et Docker, c'est quoi Docker ? Et avant de comprendre Kubernetes, il faut déjà comprendre les conteneurs. Et pour nous apprendre les conteneurs, et Kubernetes, de temps en temps y a un homme, et c'est de Jérôme dont je parle là, de temps en temps y a un homme, enfin, un homme qui est exactement à sa place, qui colle parfaitement dans le tableau, comme Jérôme avec Kubernetes.

Dans cet épisode, je reçois Jérôme Petazzoni. Jérôme a travaillé pendant plus de huit ans pour Docker où il a acquis une solide réputation de speaker international. Il est également le cofondateur de Enix France, et s'est lancé depuis près de deux ans dans la formation et le conseil sur les conteneurs et Kubernetes au travers de sa société Tiny Shell Script LLC. Il vient aujourd'hui partager avec nous son expérience de formateur et vient nous en dire un peu plus sur le parcours pas si difficile que ça de l'apprentissage de Kubernetes.

Sujets évoqués pendant l’épisode

• Retrouvez Tiny Shell Script LLC sur https://tinyshellscript.com/
• Kubernetes the Very Hard Way de Laurent Bernaille : https://www.usenix.org/conference/lisa19/presentation/bernaille
• Vous pouvez suivre Laurent Bernaille sur Twitter : https://twitter.com/lbernail

Electro Monkeys Podcast

Support the show (https://www.patreon.com/electromonkeys)

Quand on est face à Quentin Adam pendant quelques minutes pour une interview, qu'on sait qu'il est crevé parce qu'en plus d'être CEO le gars s'est lancé dans un projet fou de construire un respirateur open source, on lui passe tout ; parce qu'on sait au fond de soi qu'il est bien gentil d'être là, plutôt que d'avoir profité de ce moment pour faire une bonne sieste bien méritée.

Donc je vous l'accorde, ça manque parfois un peu de structure, on part par ici, on revient par là… Alors tant pis pour le Pulitzer, il n'empêche que j'ai au moins eu l'occasion de partager avec Quentin bon nombre de sujets passionnants !

Dans cet épisode, j'ai donc le plaisir de recevoir Quentin Adam. Quentin est CEO de Clever Cloud, et il est le genre de type à s'investir à 200% dans toutes les aventures dans lesquelles il se lance. Avec lui, nous en apprendrons un plus sur Clever Cloud, et les choix qui y sont faits pour gérer notre production.

Sujets évoqués pendant l’épisode

• Mé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 Jamin
• Valerian Saliou
• Emmanuel Feller
• Pierre-Antoine Gourraud
• Erik Huneker et Marc Julien (Diabeloop)

Electro Monkeys Podcast

Support the show (https://www.patreon.com/electromonkeys)

Comme l'a si justement dit Lavoisier : "Dans Kubernetes, rien ne se perd, rien ne se crée, tout se transforme". Est-ce que Kubernetes à changé les load balancers, ou les reverse proxies ? Par fondamentalement, c'est juste que nous les consommons différemment, peut-être mieux, plus efficacement, et certainement de façon plus automatisée et dynamique.

S'il n'y a pas de domaine de Kubernetes où il n'y ait quotidiennement des innovations, il y en a certains qui ont sérieusement tendance à fricoter les uns avec les autres ; c'est notamment le cas pour les ingresses et le service mesh... Pourquoi, qu'on-t-il en commun ?

Pour nous aider à résoudre ce mystère, je reçois dans cet épisode Michael Matur. Michael est architecte de solutions pour Containous, la société derrière Traefik et Maesh. Car si Traefik est depuis longtemps un  contrôleur populaire pour nos ingresses, Maesh fait effet de nouveau venu dans le paysage du service mesh. Et si nous en découvrions un peu plus sur ces deux solutions qui ne manquent pas de fraicheur et d'ingéniosité ?

Support the show (https://www.patreon.com/electromonkeys)

L'un des aspects qui rend le monde cloud natif si captivant, c'est sans doute cette capacité qu'il a d'innover en permanence. Et quand je pense à ces sociétés qui innovent, il y en a une qui me vient en tête immédiatement, c'est Rancher Labs.

J'ai connu Rancher dans sa version 1, lorsqu'il était un orchestrateur d'orchestrateurs, ça ne s'invente pas. Fin 2017, lorsque toute la communauté s'est rangée derrière Kubernetes, Rancher a fait de même, et Rancher 2 est arrivé, se proposant d'être la tour de contrôle de nos clusters Kubernetes, que ceux-ci soient on prem, dans le cloud, managed ou non.

Mais si Rancher est le produit far de Rancher Labs, la créativité des ses ingénieurs n'a pas de limite. Entre autres projets, je pourrais citer RancherOS, un jeos pour conteneurs, Longhorn pour le stockage, Rio pour le service mesh... ou K3s. K3s nous est présenté comme une distribution allégée de Kubernetes pour Edge, IoT, ARM et CI, et qui de surcroît ne demande pas de doctorat de clusterologie.

Dans cet épisode je reçois Dmitry Shevrin. Dmitry est field engineer pour l'Europe du sud chez Rancher, et vient nous en dire un peu plus du Rancher 2.4 et cette fantastique distribution de Kubernetes qui vient manger le monde de l'IoT : K3s.

Support the show (https://www.patreon.com/electromonkeys)

Si chacun à son rôle à jouer dans le paysage des nouvelles technologies, il y a les Robin, et les Batman. Parmi ceux-ci, on peut sans contester citer VMware qui a considérablement bouleversé le monde de la machine virtuelle. Enfin, je vous parle de ça, c'était hier, et c'était il y a 20 ans.

Critiqué par certains pour son modèle économique, VMware n'en reste pas moi un acteur majeur de l'open source, et ses contributions y sont innombrables. Ce n'est pas non plus une société qui reste sur ses acquis : son intérêt pour les conteneurs, puis pour Kubernetes ; les achats d'Heptio, de Bitnami et de Pivotal sont autant de signes qui nous laissent présager que le vent tourne !

Et c'est d'ailleurs bien le cas : au travers du projet Pacifique et de Tanzu, VMware est en train de se transformer et de se réinventer. Projet Pacifique, Tanzu, pourquoi tant de noms mystérieux qui nous invitent au voyage ? Et plus important encore : qu'est-ce qui se cache derrière ces projets aux noms si évocateurs ?

Dans cet épisode je reçois Eric de Witte. Eric est solution architecte chez VMware, et vient (un peu) lever le voile sur ce que cache Tanzu. Prêt à entrer dans le terrier du lapin vert ?

Support the show (https://www.patreon.com/electromonkeys)

Bienvenue sur ce tout premier épisode de ce podcast spécial d'Electro Monkeys : projet Möbius !

Et mon premier sujet c'est Rook 1.3. Je dois l'avouer, Rook m'a toujours fasciné. J'avais croisé sa route à la KubeCon et CloudNativeCon de Berlin en 2017, et je ne l'ai plus jamais quitté des yeux.

Depuis, il a fait bien du chemin : il a notamment fait son entrée à la CNCF dans les projets Sandbox début 2018, et, alors qu'il est aujourd'hui dans la catégorie Incubating, il s'apprête à passer prochainement au stade Graduate, qui est le plus haut niveau de maturité pour un projet de la CNCF.

Qu'est-ce que Rook ? Si je dois le dépeindre en quelques mots, je dirais que c'est un opérateur Kubernetes en charge de fournir du stockage aux applications. Et comme cette petite introduction n'est peut-être pas suffisante pour ceux qui ne sont pas familiarisés avec les opérateurs, ou les problématiques de stockage dans Kubernetes, j'ai le plaisir de recevoir dans cet épisode Sébastien Han. Sébastien est ingénieur Ceph chez Redhat et aujourd'hui l'un des principaux mainteneurs du projet Rook. Avec lui, nous allons nous plonger un peu plus au coeur de Rook et de ce qu'il se propose de nous apporter.

Support the show (https://www.patreon.com/electromonkeys)

Depuis 2014, les applications Serverless conçues autour des fonctions (du FaaS pour Function as a Service) sont de plus en plus populaires. Et pour cause, nos infrastructures sont de plus en plus fréquemment capable de réagir à des évènements.

S'ils sont récents, les frameworks de Function as a Service n'en connaissent pas moins une rapide évolution, et si Amazon Lambda reste leader du marché, Google, Microsoft, VMware et d'autres ne sont pas en reste.

Parmi eux, Knative, créé par Google et soutenu par Redhat, IBM, Pivotal, Dropbox et bien d'autres semble devenir un concurrent sérieux dans le paysage. Knative est open source, il est construit sur Kubernetes, n'a pas de lock-in, et peut donc être utilisé à même votre centre de données.

Dans cet épisode je reçois Sébastien Goasguen. Sébastien a été le créateur de Kubeless, la plateforme de Function as a Service de Bitnami, et il est aujourd'hui le co-fondateur de Triggermesh, une plateforme serverless d'intégration de services cloud basée sur Knative.

Support the show (https://www.patreon.com/electromonkeys)

Ces dernières années, on fait vraiment grand cas de la donnée. Mais ne vous êtes-vous jamais demandé de quoi était faite la donnée, ou en d'autres termes : qu'est-ce qui constitue la donnée ? Une fois les data points établis, que faire de la donnée ? Est-ce qu'elle est stockée, transformée, manipulée ou analysée ? Et si oui comment, par qui et à quelle fin ?

Pour répondre à toutes ces questions, je reçois Aurélien Allienne. Aurélien est Head of Data pour SFEIR Lille, et ensemble nous allons brosser le tableau des pipelines de données, de l'ingestion à la restitution.

"I'm CTO, Bitch."

Combien n'ont pas un jour rêvé de prononcer ces mots magiques. Mais au delà de ça, avoir de grands pouvoirs implique de grandes responsabilités, voire un bonne dose de prise de risques.

Un CTO doit constamment avoir un oeil sur le marché (et peut-être même les deux), doit comprendre et analyser les changements technologiques, et sans doute disposer d'un sixième sens relativement bien affûté.

Dans cet épisode, je reçois Jonathan Basse. Jonathan est le fondateur de Data Essential, et en a été CTO pendant plus de 4 ans. Il revient avec nous sur ce rôle qui lui tient tant à coeur.

Support the show (https://www.patreon.com/electromonkeys)

Depuis quelques années, Kubernetes poursuit sa folle course en avant. Alors qu'il était encore considéré il y a peu comme un orchestrateur d'applications stateless, son adoption par l'entreprise l'entraine à devoir de plus en plus être en mesure de gérer les objets stateful et la persistance.

L'année dernière, lors de la KubeCon Europe, Bryan Liles nous donnait son feu vert pour utiliser le stockage dans Kubernetes ; mais quelle est la réalité de terrain ? Quel est le point de vue de ceux qui utilisent depuis des années des conteneurs et des volumes ?

Cette semaine je reçois Nicolas Muller. Nicolas est le CTO de Treeptik, Docker Captain, et évangélise pour que les entreprises commencent à mettre leurs bases de données dans Kubernetes. Avec lui, nous discuterons des raisons qui lui font dire que c'est un choix judicieux, mais aussi des problèmes que ça soulève.

Support the show (https://www.patreon.com/electromonkeys)

Le problème des outils informatiques, c'est que parfois ils génèrent de nouvelles façons de travailler, voire de nouvelles méthodologies. Ces nouvelles méthodologies à leur tour voient apparaître de nouveaux outils, et ces nouveaux outils... créent de nouvelles méthodologies.

Parmi les outils qui ont considérablement influencé notre façon de travailler, on peut sans conteste citer Git. Git qui a tout d'abord été le fer de lance d'une nouvelle génération de développeurs, en leur apportant une autre manière de gérer le versioning de leur code ; mais il est également aujourd'hui en train de totalement bouleverser la manière dont sont gérées les opérations.

Dans cet épisode, je reçois William Bartlett. William est coach DevOps chez Treeptik et il vient nous parler de cette nouvelle tendance lancée par Weaveworks à qui Google a emboité le pas, et qui se fait appeler : Gitops.

Support the show (https://www.patreon.com/electromonkeys)

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

Support the show (https://www.patreon.com/electromonkeys)

Nous sommes tous, à différents niveaux, des utilisateurs Linux, et nous pourrions même aller jusqu'à dire d'une ou de plusieurs distributions Linux. Le concept même de distributions, ou de familles de distributions peut paraître étrange à première vue, puisqu'elles utilisent toutes le même noyau. Si ce qui distingue principalement les familles est le système de packaging des binaires, ce qui distingue les distributions est plutôt les outils qu'elles intègrent par défaut ou qu'elles choisissent de maintenir.

Mais vous êtes-vous jamais posé la question de la complexité que pouvait représenter la création d'une distribution Linux ? Dans cet épisode, je reçois Kevin Chevreuil qui est le créateur de Kaisen Linux. C'est pour lui un side project, puisqu'il est ingénieur GNU/Linux spécialisé dans la sécurité, mais c'est pour nous l'occasion d'en découvrir un peu plus sur le monde fascinant des distributions Linux.

L'univers des startups est un univers fascinant. Partir d'une idée pour en faire un produit, quel voyage palpitant, mais qui ne s'arrête jamais en cas de succès ! Le produit ne cesse d'évoluer, la stack logicielle change et se diversifie, et les fondateurs qui ont souvent pris les postes clé dans l'entreprise doivent aller vite, s'adapter et évoluer eux aussi.

Aujourd'hui, je reçois Jean Lebrument. Jean est actuellement le CPO de Brigad, et c'est une évolution récente de son poste, puisqu'il n'y a pas longtemps encore, il en était le CPO et le CTO. Jean nous raconte les choix qu'il a dû faire, par rapport à l'évolution de Brigad, et pourquoi il a décidé de se retirer de son rôle de CTO.

Les jeux rétro sont pour beaucoup un chouette souvenir d'enfance, que vous ayez été jeux d'arcade, console ou pc. Mais étrangement, ils ont survécu, ils ont passé l'épreuve du temps et ils sont toujours là, sur les consoles rétro, sur les Raspberry Pi ou qui sait ou encore ! Il y toujours autour d'eux une communauté de bidouilleurs passionnés qui les font revivre, presque intacts après toutes ces années.

Aujourd'hui, j'ai le plaisir de recevoir David Hecq. David est le créateur de la très populaire chaîne Youtube Gunhed TV, mais aussi l'auteur des Chroniques de Gunhed, que vous pouvez retrouver sur Amazon. Une merveilleuse occasion de parler des jeux d'hier, d'aujourd'hui et de demain !

Notes de  l'épisode

• Gunhed TV : https://youtube.com/c/GunhedTV
• Chroniques de Gunhed TV - Volume 1 : https://amzn.to/34JmCjv

Au programme de ce livre damné : la terrible confrontation entre les firmes Atari, Mattel et Coleco à la fin des années 70 et qui s'est achevée avec le crash des jeux vidéo.Pourtant au départ, on y croyait en ces machines. Elles nous vendaient du rêve en pixels et nous promettaient mille et une merveilles vidéoludiques. 

On évoquera également la rocambolesque histoire duKonix Multi System, tout simplement un système d'arcade à domicile avec siège monté sur vérins. En lieu et place, on a eu droit à une explosion en plein vol, suivie d'une absorption par le trou noir de l'histoire des jeux vidéo où l'on a parfois la fâcheuse tendance de ne retenir que les succès. 

Malgré tout, derrière ces flamboyants échecs, il y a des hommes (et un peu de femmes) qui ont porté ces projets à bout de bras et qui a force de persévérance et de passion, ont réussi à les commercialiser. Vous en conviendrez, ces personnes méritent à minima qu'on raconte leur histoire... 

• Chroniques de Gunhed TV - Volume 2 : https://amzn.to/35Y9LKP

Au programme de ce second tome : la Vectrex, l'O.V.N.I. des années 80, l' Amiga CD32 et la mort (terrible) de Commodore, la Jaguar ou le dernier rugissement d'Atari et enfin, NEC PC-FX : la grande désillusion.

Les tests de charge sont une étape importante du développement d'une application et de son cycle de vie. En effet, ils permettent de tester les limites de certains composants, de valider une architecture et de s'assurer qu'elle se met à l'échelle correctement, mais aussi parfois d'éliminer des bugs de l'application elle-même.

Mais avoir un bon outil, capable de vraiment tester l'application au travers de parcours utilisateur et de remonter des données fiables n'est pas chose évidente. Et même Wikipedia a une définition erronée du test de charge.

Aujourd'hui, je reçois donc celui qui fait mentir Wikipedia, j'ai nommé Stéphane Landelle. Stephane est le CTO de Gatling, une solution de test de charge open source écrite en Scala et fournissant un DSL Java permettant de créer du test as code.

Notes de  l'épisode

• A quoi sert le test de charge: https://gatling.io/2020/03/what-are-the-objectives-of-a-load-test/
• Pourquoi la moyenne et l'écart type ne servent pas à grand chose: https://gatling.io/2018/11/metrics-analysis-load-testing-deviations/
• Pourquoi on ne doit calculer les moyennes de centiles:
  • http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-you-cant-average.html
  • https://www.circonus.com/2018/11/the-problem-with-percentiles-aggregation-brings-aggravation/
  • https://orangematter.solarwinds.com/2016/11/18/why-percentiles-dont-work-the-way-you-think/

Peut-être ne nous en rendons-nous pas compte, mais aujourd'hui la plupart des outils SaaS que nous utilisons sont américains. Il n'y a évidemment aucun mal à cela, du moins de mon point de vue, mais qu'arriverait-il si pour une quelconque raison la France ou l'Europe n'étaient plus en bons termes avec les Etats-Unis ? Pourrions-nous toujours accéder non seulement à nos outils, mais également aux données qui y sont hébergées ?

Ce sont ces réflexions qui ont amené Christophe Chaudier, mon invité du jour, à concevoir Froggit : un ensemble de services permettant d'héberger sa base de code de manière souveraine. Christophe, que j'ai déjà eu l'occasion de recevoir ici est un mentor DevOps, fondateur des compagnons du DevOps, podcasteur, youtubeur, j'en passe et dernièrement le créateur de Froggit dont il vient nous parler plus en détails.

Notes de l'épisode

• Le Linkedin de Christophe : https://www.linkedin.com/in/cchaudier/
• Le site de Froggit : http://froggit.fr/
• Le concept de SaaS Libre : https://youtu.be/qTlqL89UmsQ
• La neutralité du Net s’effrite ! (embargo des US sur l'iran) :https://www.linkedin.com/feed/update/urn:li:activity:6579664951630196736/
• L'article de Shahin Sorkh https://shahinsorkh.ir/2019/07/20/how-is-it-like-to-be-a-dev-in-iran
• Lydra : http://lydra.fr/
• La chaîne YouTube des Compagnons du DevOps : https://www.youtube.com/c/LesCompagnonsduDevOps
• La chaîne YouTube sur l'entreprenariat de Christophe : https://www.youtube.com/channel/UCvZFN6J1okCiIG4LKIXqSpg
• Docusaurus : http://docusaurus.io/
• Les Lives Docusaurus et GitLab pages : https://www.youtube.com/watch?v=OwXsEiQTdmo&list=PLR2-Y4yF_vcgK4BeImt4SUy7izAvYrMBX

Il ne vous arrive jamais de ne pas comprendre en quoi consistait un poste en lisant son intitulé ? Autant lorsqu'on parle d'un dev ou d'un ops les choses sont à peu près claires, mais ce n'est pas toujours aussi simple.

Aujourd'hui, j'ai la chance de recevoir l'un de ses oiseaux rares, puisque son job à lui c'est field engineer.

David Blaskow est en effet field engineer chez Traefik, et dans cette discussion nous allons en apprendre un peu plus sur son métier et sur son quotidien.

Lors du premier KCD France, nous avons eu la chance de pouvoir interviewer Solomon, un monsieur qui compte beaucoup pour nous tous.
Car sans lui et sa talentueuse équipe chez Docker, beaucoup ne seraient pas là à pousser du container par monts et par vaux.

Aujourd'hui nous ne parlerons pas de Docker (même si...) mais de son dernier bébé très prometteur qui révolutionnera peut-être à nouveau le monde IT et plus précisément celui de la CI/CD. C'est tout le mal que nous lui souhaitons car pour avoir travaillé avec, c'est rafraichissant et assez disruptant.

Merci à toi, Solomonstre

Au fil du temps, VMware a su se construire un écosystème entier autour de son produit phare : vSphere. J'ai déjà eu l'occasion ici de parler de Tanzu, bien évidemment, et aussi d'Antrea. Et aujourd'hui, pour nous aligner avec une des top tendances de 2022, nous allons parler de sécurité notamment au travers de deux produits : NSX-T et CarbonBlack.

Pour parler de ces sujets tout aussi complexes que passionnants, j'ai le plaisir de recevoir Tuan Nguyen, Chef de produit technique et expert sécurité réseau chez VMware, et Stéphane List, expert VMware en sécurité des endpoints, workloads et containers.

Notes de l'épisode:

NSX-T et Container Networking: 

• 2022 update- NSX: https://www.youtube.com/watch?v=6ErlfFmaoSg
• Lightboard: NSX Container Networking vision: https://youtu.be/HxwmBV3eGfE
• Deepdive Antrea container networking: https://www.youtube.com/watch?v=7Xpq-GVp2Qo

Carbon Black security:

• Introduction pour Carbon Black: https://www.youtube.com/watch?v=DkEqgdBRUDs
• Container security with CarbonBlack DevSecOps: https://www.youtube.com/watch?v=d_RhLLssYXo

Plus de détails sur le sujet (1000+ articles publiés et a jour):

• https://nsx.techzone.vmware.com/
• https://carbonblack.vmware.com

Dans certains secteurs comme notamment l'IT, le temps est au changement. Peut-être est-ce dû à la pandémie, peut-être est-ce seulement le cycle naturel des choses, mais aujourd'hui beaucoup de personnes ont fait le choix de repositionner leur carrière en fonction de leur style de vie. Travailler moins, travailler différemment, travailler pour une cause digne d'être défendue, mais ne plus travailler comme un automate, jour après jour, juste pour percevoir son salaire a la fin du mois.

Cependant, ce n'est pas un changement si simple à effectuer : comment en effet trouver l'entreprise en mesure de nous apporter ce que l'on recherche ? Comment savoir qu'une entreprise est potentiellement la bonne pour être alignée avec nos choix personnels ?

La bonne nouvelle, c'est que c'est désormais possible. My Little Team est une plateforme de recherche à dimension humaine qui vous permet d'étendre vos critères de recherche, comme les valeurs que défend une entreprise, les rythmes de travail qu'elle permet ou son style de management. Et pour en discuter plus en détail, j'ai le plaisir de recevoir Paul Gratian. Paul est co-fondateur de My Little Team et ensemble nous discutons de ce projet au cœur de ce qui sera peut-être une véritable révolution sociale dans les années à venir.

Pour ce dernier épisode de l'année, j'ai eu envie de revenir, mais également d'approfondir, le sujet d'un code soucieux de sa consommation énergétique. Y a-t-il des langages meilleurs que d'autres, des manières d'écrire et d'exécuter le code qui sont préférables à d'autres ? Et encore une fois, se pose la question de la mesure de la consommation énergétique d'une application, selon qu'elle est monolithique ou en microservices, conteneurisée ou non.

Pour parler de toutes ces épineuses questions, j'ai le plaisir de recevoir Jérémie Drouet. Jérémie est Remote Senior Software Engineer chez Datadog, et plus précisément sur Vector, car comme vous le verrez, c'est un choix qu'il a fait pour se mettre en accord avec ses propres convictions.