Electro Monkeys

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.