Electro Monkeys – Details, episodes & analysis

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)