DiscoverElectro Monkeys
Electro Monkeys

Electro Monkeys

Author: Stef

Subscribed: 29Played: 417
Share

Description

Le podcast pour découvrir et comprendre les concepts et les technologies cloud natives ! Des interviews techniques hebdomadaires sur Kubernetes, les technologies cloud natives et la communauté open source.
69 Episodes
Reverse
Dans des environnements distribués et hautement volatile, les logs, les métriques et les traces sont nos yeux et nos oreilles quand il s'agit de diagnostiquer la raison d'un incident. Et si c'est le cas pour un problème applicatif, ne pourrions-nous pas tout aussi bien en tirer avantage concernant la sécurité ?C'est la proposition que fait aujourd'hui Datadog. Pour en discuter, je reçois Marc Tremsal. Marc est Director of Product Management pour Datadog, et avec lui j'ai l'opportunité de discuter de la détection des menaces, des différent aspects du monitoring de la sécurité, mais aussi des technologies innovantes qui y sont employées, telle que eBPF.Notes de l'épisodeBlog de Justin Massey de Datadog sur le monitoring des audits logs de Kubernetes : https://www.datadoghq.com/blog/key-kubernetes-audit-logs-for-monitoring-cluster-security/Support the show (https://www.patreon.com/electromonkeys)
Il n'a fallu que trois ans à Kubernetes pour devenir fin 2017, le standard des plateformes d'orchestration du marché. Et tandis que les conteneurs enflammaient le cœur des développeurs, Kubernetes lui partait à la conquête des entreprises.Il est rare, pour ne pas dire inédit, qu'un produit jouisse d'une adoption aussi rapide, et il y a fort à parier qu'un tel succès ne doive rien au hasard. Dès lors, qu'est-ce qui justifie cet engouement pour Kubernetes et pour les conteneurs ? A quelles problématiques apportent-ils une réponse, aussi bien pour les devs que pour les ops ?Cette semaine je reçois Alexis Ducastel. Alexis est architecte infrastructure freelance, et fondateur d'infraBuilder, et avec lui j'aborde les différents points qui expliquent la popularité de Kubernetes, et pourquoi il a définitivement changé la donne.Support the show (https://www.patreon.com/electromonkeys)
Apprendre à coder est désormais enseigné à l'école. Et si nous ne pouvons voir cela que d'un bon œil, nous savons aussi pertinemment que cela introduit un biais : les enfants sont rarement passionnés par une discipline scolaire, et cela en dépit des aspects ludiques et créatifs d'un Scratch ou d'un Python.Par ailleurs, un autre problème a vu le jour ces dernières années : les ordinateurs, smartphones et tablettes font maintenant partie de notre quotidien, et de celui de nos enfants. La aussi, c'est une bonne chose, à condition que la protection de la vie privée et des données personnelles ne soit pas mise de côté, et que les réseaux sociaux ne se transforment pas en un lieu de harcèlement scolaire.Dans cet épisode, je reçois Morad et Rabah Attik. A eux deux, ils sont non seulement les auteurs de plusieurs livres de la collection "pour les kids" de chez Eyrolles, mais aussi les fondateurs d'Evolukid, une société spécialisée dans l'enseignement du numérique auprès des jeunes publics. Ensemble, nous discutons de l'apprentissage du code et de l'identité numérique.Support the show (https://www.patreon.com/electromonkeys)
L'une des forces de Kubernetes est d'être extrêmement modulaire. Et lorsque cette modularité s'étend jusqu'à laisser le choix du plugin réseau, alors la porte est grande ouverte à une multitude de possibilités.Or, malgré une grande diversité de plugins dès ses débuts, Kubernetes voit encore aujourd'hui de nouveaux plugins faire leur apparition, comme Cilium, Multus ou Antrea. Dès lors, nous pourrions nous interroger sur la nécessité de créer de nouveaux plugins, et sur les besoins spécifiques auxquels ils viennent apporter une réponse.Cette semaine, je reçois Antonin Bas. Antonin est développeur pour VMware, et travaille plus spécifiquement sur le projet open source Antrea. Avec lui, nous partons à la découverte de ce plugin réseau encore méconnu, et nous parlons en détails de ses spécificités et de ses cas d'usage.Support the show (https://www.patreon.com/electromonkeys)
Webassembly est une technologie que nous associons fortement avec un usage dans nos navigateurs. Parce qu'il est effectivement considéré comme "le langage assembleur pour le web", mais aussi parce qu'il a été créé pour surpasser certaines limitations de JavaScript.Mais, comme pour JavaScript, les cas d'usage ne se limitent pas au front, et vous seriez surpris d'apprendre tout ce que peut réaliser Webassembly au niveau du backend : filtres pour le proxy Envoy, blockchain, function as a service, et bien d'autres encore.Pour en parler plus en détails, je reçois Geoffroy Couprie, qui est ingénieur en sécurité pour Clever Cloud et qui utilise Webassembly dans des fonctions, et Ivan Enderlin qui développe une machine virtuelle pour Webassembly chez Wasmer. Leurs approches complémentaires nous permettront de brosser un tableau assez précis de l'utilisation de Webassembly pour le backend.Support the show (https://www.patreon.com/electromonkeys)
En seulement quelques années , Prometheus s'est imposé comme le standard des outils de monitoring cloud natif. Cependant, un certain nombre de fonctionnalités manquent à Prometheus, comme le stockage longue durée, le multi-tenancy ou, dans une certaine mesure, la haute disponibilité. Mais ce n'est pas un défaut pour autant, mais un choix d'architecture : Prometheus fait une seule chose, la collecte de métriques, et il la fait bien.Or ce choix pourrait être pénalisant pour une adoption en entreprise, car Prometheus ne permet pas, par exemple, de faire du capacity planning. Pour palier ce manque, de nouveaux projets ont vu le jour, comme Thanos ou Cortex. Mais ceux-ci ne sont pas là pour concurrencer Prometheus, mais bien plutôt pour l'enrichir.Dans cet épisode, je reçois Simon Pasquier. Simon est Senior Software Engineer pour Red Hat où il travaille principalement sur Prometheus. Mais à l'occasion, il lui arrive aussi de contribuer à Thanos. Avec lui, je discute de ce qu'apporte un projet comme Thanos à Prometheus, de son mode de fonctionnement et de ses fonctionnalités.Support the show (https://www.patreon.com/electromonkeys)
ETCD avec Pierre Zemb

ETCD avec Pierre Zemb

2021-01-1955:51

etcd est une base de données bien connue de toutes les équipes opérationnelles, puisqu'elle est au coeur de Kubernetes. Cependant, mis à part sa documentation en ligne, c'est une base de données sur laquelle il n'existe aucune littérature. Et c'est une chose que j'ai peine à comprendre pour un projet de cette importance qui a un tel impact sur notre quotidien.Par chance, nous ne sommes pas les seuls à devoir opérer etcd. Qui plus est, certains cloud providers l'utilisent à bien plus grande échelle que nous, ce qui est notamment le cas pour OVHcloud. Leur connaissance du modèle opérationnel d'etcd et leurs retours d'expérience nous sont d'une aide précieuse.Dans cet épisode, je reçois Pierre Zemb. Pierre est leader technique des systèmes et du stockage distribués chez OVHcloud, donc la personne idéale pour parler d'etcd. Dans cet échange, nous évoquons les bases de données de nouvelle génération et leur fonctionnement, les raisons pour lesquelles etcd a été choisie pour Kubernetes, mais aussi ses limites et ses alternatives.Notes de l'épisodeLes notes personnes de Pierre sur etcd : https://pierrezemb.fr/posts/notes-about-etcd/Les bases de données orientées colonnes : https://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_colonnesOLAP : https://fr.wikipedia.org/wiki/Traitement_analytique_en_ligneOLTP : https://fr.wikipedia.org/wiki/Traitement_transactionnel_en_ligneWhite Paper sur Google Spanner : https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46103.pdfWhite Paper de Google sur BigTable : https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdfLe site officiel de CoakcroachDB : https://www.cockroachlabs.com/Le site officiel de TiKV : https://tikv.org/Le site officiel d'etcd: https://etcd.io/Raft : https://raft.github.io/Raft un consensus distribué compréhensible : http://thesecretlivesofdata.com/raft/Raft lab : https://pdos.csail.mit.edu/6.824/labs/lab-raft.htmlPaxos vs Raft : https://www.youtube.com/watch?v=0K6kt39wyH0Documentation en ligne d'etcd : https://etcd.io/docs/v3.4.0/rfc/v3api/Interagir avec etcd : https://etcd.io/docs/v3.4.0/dev-guide/interacting_v3/etcd par rapport aux autres bases de données clés-valeurs : https://etcd.io/docs/v3.4.0/learning/why/Le site officiel de grpc : https://grpc.io/Les protobufs : https://developers.google.com/protocol-buffersGestion des clusters à grande échelle Support the show (https://www.patreon.com/electromonkeys)
Container Security est un livre écrit par Liz Rice et paru aux éditions O'Reilly en avril 2020. Je l'attendais avec impatience, et je l'ai dévoré dès sa sortie. Il est bourré d'informations utiles. Après un rappel des rudiments de Linux, tous ce qu'il y a à connaître sur la sécurité des conteneurs y est abordé, de l'isolation, au cycle de vie des images jusqu'à la gestion des secrets.En bon podcaster, je me suis tout de suite jeté sur Twitter en espérant trouver dans mon réseau quelqu'un pour parler de la sécurité des conteneurs et des différents aspects que j'avais pu découvrir au travers de ce livre. Il se trouve que c'est Liz elle-même qui m'a répondu, et a accepté sans hésiter d'être mon invitée, même si elle ne se sentait pas totalement en confiance avec son français. Et je tiens d'ailleurs à la remercier très chaleureusement d'avoir fait cet effort, car nous avons bien plus souvent l'occasion de voir des français répondre à des interviews en anglais, que l'inverse. D'ailleurs, c'est son tout premier podcast francophone.A-t-on encore besoin de présenter Liz Rice ? Liz est VP Open Source Engineering chez Aqua Security, mais elle est également Présidente du Comité de Contrôle Technique à la CNCF, et j'imagine que beaucoup d'entre vous ont déjà eu l'occasion de la croiser dans une KubeCon ou une autre. Ensemble nous discutons de la sécurité des conteneurs, en prenant comme point de départ le livre qu'elle vient de publier.Notes de l'épisodeAqua Starboard https://github.com/aquasecurity/starboardSupport the show (https://www.patreon.com/electromonkeys)
Créer une application ne consiste pas à écrire un code source immuable auquel plus personne ne prêtera attention. Au contraire, c'est un code fait pour être relu, maintenu et modifié. Or si les choses sont très claires en théorie, la pratique est comme toujours beaucoup plus complexe.Aujourd'hui, que nous soyons développeur ou SRE, nous sommes tous confrontés à l'écriture de code. Mais un code qui fait le job est-il nécessairement un bon code ? Est-ce que mon code est clair et compréhensible pour être maintenu par quelqu'un d'autre que moi ? Et en définitive, comment puis-je m'améliorer ?C'est sur ce terrain miné et riche de polémiques que Nicolas Frankel a accepté de me suivre. Nicolas est developer advocate pour Hazelcast, et ensemble nous discutons des propriétés qui font d'un code un code de qualité.Support the show (https://www.patreon.com/electromonkeys)
Kubernetes permet de résoudre bon nombre de problèmes dans la gestion des micro-services, comme par exemple leur passage à l'échelle, ou la vélocité de leur déploiement, ou encore leur fiabilité. Mais Kubernetes s'est fixé des limites, et la gestion du trafic ne fait pas partie de son périmètre.Or, que ce soit lors de son entrée dans le cluster, entre les différents services, ou même entre différents clusters, ce trafic réseau est tout ce qui nous préoccupe lorsque nous parlons de micro-services. Et c'est ici précisément que le mesh entre en scène. Mais de quel "ici" parlons-nous exactement ?Pour répondre à mes nombreuses questions, j'ai le plaisir de recevoir pour la seconde fois Denis Jannot. Denis est Director of Sales Engineering pour Solo.io, un société spécialisée dans le réseau entre applications, de l'edge jusqu'au service mesh. Avec lui nous évoquerons les API gateways, le service mesh, et même la fédération de mesh entre clusters.Notes de l'épisodeSi vous souhaitez participer aux workshops de Solo.io en janvier :https://www.eventbrite.com/e/128722074189https://www.eventbrite.com/e/128722096255Support the show (https://www.patreon.com/electromonkeys)
L'infrastructure-as-code permet d'utiliser un langage de programmation pour définir son infrastructure. L'utilisation d'outils de gestion d'infrastructure comme Puppet, Chef ou Ansible avaient amorcé cette tendance, qui s'est confirmée par la popularisation du Cloud et de langages permettant la mise en place d'infrastructures comme CloudFormation pour AWS.Puis Terraform d'Hashicorp a enrichi cet écosystème en y apportant un modèle déclaratif open source, sous la forme d'un domain-specific language. Par ailleurs, les fichiers YAML de Kubernetes ne sont pas autre chose. Mais ce modèle a ses limites, et ne correspond pas nécessairement aux attentes des développeurs.Pulumi est une société qui a une autre approche, permettant de faire de l'infrastructure-as-code avec des langages de programmation bien connus des développeurs, comme .Net, Python ou TypeScript. Kevin Kotecki est vice-président sales pour Pulumi, et avec lui nous discutons des enjeux et de sa vision des outils d'infrastructure-as-code.Support the show (https://www.patreon.com/electromonkeys)
Le chaos engineering est une pratique, un état d'esprit, une attitude bien avant d'être un ensemble d'outils. Simuler une panne, un incident, ou l'absence du meilleur élément d'une équipe est facile ; l'outillage ne vient qu'ensuite, lorsqu'il s'agit d'automatiser toutes ces tâches.Mais l'outil doit-il s'arrêter là, ou doit-il aller plus loin pour permettre de réellement capitaliser sur les conséquences d'un problème, aussi bien pour les devs que pour les ops, mais aussi pour observer l'impact qu'il entraîne au niveau des utilisateurs d'un service.Dans cet épisode, je reçois Sylvain Hellegouarch. Sylvain est cofondateur et CTO de ChaosIQ et nous discutons ensemble de cette chaîne de valeurs que constitue le chaos engineering.Notes de l'épisodeChaos Monkey https://fr.wikipedia.org/wiki/Chaos_MonkeyLitmus https://github.com/litmuschaos/litmusPowerfulSeal https://github.com/powerfulseal/powerfulsealGremlin https://www.gremlin.com/Chaos Toolkit https://chaostoolkit.org/Support the show (https://www.patreon.com/electromonkeys)
Le SRE, pour site reliability engineer, est généralement un ingénieur software mettant à profit son expérience pour gérer l'infrastructure. Mais bien que ce rôle ait déjà fait l'objet de plusieurs publications (et je vous invite d'ailleurs à retrouver les liens dans les notes de l'épisode), son quotidien reste flou et mal défini.Tout d'abord, il est responsable de la production. Mais afin que son temps soit harmonieusement partagé entre cette tâche et ses travaux d'automatisation, il doit d'abord définir un budget d'erreur avec les développeurs. Ce budget est une sorte de contrat décrivant combien de temps une application peut être en dessous de son objectif mensuellement. Et pour définir cet objectif, bien évidemment, il faut des points de mesure précis, qui sont appelés des indicateurs. Une fois ce carde mis en place, le SRE devrait pouvoir consacrer 50% de son temps à la production, et l'autre moitié à ses tâches d'automatisation. C'est la théorie.Mais qu'en est-il réellement ? Pour le savoir, j'ai le plaisir de recevoir Tony Fouchard. Tony est aujourd'hui chef de l'infrastructure chez Prevision.io, mais il a aussi occupé d'autres rôles similaires pour Blablacar et Qwant. Il a une riche expérience de SRE, et il nous invite à partager son quotidien le temps de ce podcast.Notes de l'épisodeLa collection de livres sur le SRE de Google : https://landing.google.com/sre/books/Support the show (https://www.patreon.com/electromonkeys)
Github est un dépôt de code bien connu des développeurs open source. Le code y est stocké et versionné. Par ailleurs, Github est également bien connu pour être le réseau social des devs. Mais aujourd'hui, est-ce seulement ça Github ?Au fil du temps, beaucoup de nouvelles fonctionnalités sont venues s'y ajouter : des outils de gestion de projet et de sécurité, les gists, Github actions, pour n'en citer que quelques unes. Il y a aussi eu le rachat par Microsoft, qui a sans doute changé la donne.Du 8 au 10 décembre prochain aura lieu GitHub Universe, et à cette occasion, j'ai le plaisir de recevoir Alain Hélaïli. Alain est solution engineer pour Github, et avec lui nous partons faire le tour du propriétaire pour encore mieux connaître Github.Notes de l'épisodeQu'arrive-t-il lorsque notre clé AWS est poussée par inadvertance sur Github : https://twitter.com/AlainHelaili/status/1325022828710809600Github Universe : https://githubuniverse.com/Support the show (https://www.patreon.com/electromonkeys)
Tout change constamment : les langages, les frameworks, les outils, les technologies, les coéquipiers, et inévitablement, nous aussi. Pourtant changer ne paraît jamais simple. Chaque fois que nous voulons un changement, nous avons l'impression de vouloir déplacer des montagnes.C'est d'ailleurs paradoxal quand nous y pensons, car nous sommes là à regarder un système qui ne marche pas, ou simplement mal, ou une organisation, ou un service, et bien que nous le constations, nous avons le sentiment d'être poings liés et de ne rien pouvoir y faire. D'où est-ce que cela vient, et comment y remédier ?Cette semaine j'ai le plaisir de recevoir Alexis Monville. Alexis est chef de cabinet du directeur général EMEA chez Red Hat, et le moins que nous puissions dire, c'est qu'il s'y connait en changement. Il est en effet l'auteur de Changing Your Team From The Inside, et plus récemment de I am a Software Engineer and I am in Charge. Il nous partage sa vision du changement, et nous donne le secret sur comment changer efficacement !Notes de l'épisodeRetrouvez les livres d'Alexis : https://alexis.monville.com/en/books/Support the show (https://www.patreon.com/electromonkeys)
Le bug bounty, ou chasse aux bugs ou encore prime aux bogues, est un programme de récompenses pour les personnes qui découvrent et rapportent les bugs d'un site web. En d'autres termes, une entreprise, telle que Facebook ou Google, permet aux hackers bienveillants (souvent appelés white hats ou chapeaux blancs) de lui rapporter les vulnérabilités qui l'affectent en échange d'une récompense.La méthode n'est certes pas nouvelle : elle a été bien éprouvée et a pu démontrer toute son efficacité. Alors pourquoi n'avons nous pas encore de programme sur tous nos sites web ? C'est à dire que tout le monde n'est pas Facebook ou Google, dans le sens où il n'a pas une communauté de personnes prête à répondre à leur propre campagne de bug bounty.Autre point : il faut créer un cadre légal pour entourer cette pratique, aussi bien pour se protéger d'abus, que pour protéger ceux qui donnent de leur temps à traquer les bugs. Et tout cela pour quels bénéfices au juste ? Est-ce qu'une telle chasse est vraiment nécessaire dans notre univers cloud natif ?Pour répondre à toutes ces questions, j'ai le plaisir de recevoir le chef de l'Internet : Korben. Manuel Dorne, alias Korben, est en effet le co-fondateur de YESWEHACK, une plateforme de bug bounty bien connues des spécialistes en sécurité. Il nous emmène à la découverte de ces pirates en quête des trésors du web !Support the show (https://www.patreon.com/electromonkeys)
Parmi l'arsenal des différents outils mis à notre disposition pour notre veille technologique, il y a le podcast. Bien évidemment, je ne serais pas là si je n'en étais pas persuadé, et peut-être que vous non plus. Mais qui sont ces fous qui se mettent chaque semaine derrière un micro pour créer des contenus toujours nouveaux ? Qu'est-ce qui les fait avancer ? Où vont-ils chercher leurs idées ?Chaque podcast à sa propre identité et son propre style, non seulement au travers de ses thématiques, mais aussi par la personnalité de celui qui l'anime. Bruno Soulez, que vous connaissez peut-être déjà, est le créateur de If This Then Dev, un podcast que je suis depuis ses débuts, et qui m'a décidé à me lancer à créer mon propre show.Si vous êtes curieux de partager l'espace d'une heure l'intimité d'un podcaster, vous êtes les bienvenus ! Vous y apprendrez comment IfTTD a été créé, quels sujets tiennent vraiment à coeur à Bruno, ce qu'il espère transmettre au travers de ses épisodes, et surtout la réponse à cette grande question : pourquoi ne mange-t-il que des yaourts qu'il fabrique lui-même ?Notes de l'épisodeIf This Then Dev https://ifttd.io/Cosa Vostra https://www.cosavostra.com/Big Bang Media https://www.facebook.com/BigBangMediaIncubateur/Génération Do It Yourself https://www.gdiy.fr/2h de perdues https://www.2hdp.fr/No Limit Sécu https://www.nolimitsecu.fr/Les Cast Codeurs https://lescastcodeurs.com/The Mature Dev https://www.themature.dev/Tech Rocks https://www.tech.rocks/Artisan Développeur https://artisandeveloppeur.fr/Episode #5 Comment regarder Netflix depuis l'espace ? https://ifttd.io/5-raphael-goldwaser/Episode #10 Coder pour guérir les autres https://ifttd.io/10-coder-pour-guerir-les-autres-dominique-sauquet/Episode #14 Coder peu, coder mieux https://ifttd.io/14-coder-peu-coder-mieux-dimitri-baeli/Episode #20 beta.gouv quand l'état se met en mode start-up https://ifttd.io/20-beta-gouv-quand-letat-se-met-en-mode-start-up-julien-dauphant/Episode #21 Une organisation libre où prime innovation et bonheur https://ifttd.io/21-une-organisation-libre-ou-prime-innovation-et-bonheur-quentin-adam/Episode  #46 De l'ordinateur beige au numérique vert https://ifttd.io/46-de-lordinateur-beige-au-numerique-vert-frederic-bordage/Episode #52 Le veilleur de nuit https://ifttd.io/52-le-veilleur-de-nuit/Support the show (https://www.patreon.com/electromonkeys)
Les API, pour Application Programming Interface, ont totalement bouleversé la manière d'écrire un service Web. Aujourd'hui, elles sont quasiment incontournables, d'une part parce qu'elles simplifient le développement d'applications, et d'autre part, parce qu'elles établissent un contrat documenté avec leurs consommateurs. Créées aux début des années 2000, elles se sont popularisées par la suite, jusqu'à voir leur nombre exploser avec l'arrivée des micro services.Mais à mesure que nous développons des API, nous nous rendons vite compte qu'elles ont toutes des points communs, comme l'authentification, le throttling ou le rate limiting. Réécrire ce tronc commun serait non seulement long et pénible, mais aussi il offrirait une expérience utilisateur différente pour chaque API. C'est à ce moment qu'entre en jeu les gestionnaires d'API, tel que Kong, qui est sans doute le plus populaire à ce jour.Dans cet épisode, j'ai le plaisir de recevoir Thibault Charbonnier. Thibault est principal engineer pour Kong Inc., et il n'est pas seulement le mainteneur de Kong, mais il a également participer à sa création ! Avec lui, je reviens donc sur Kong, de ses origines à aujourd'hui, sur son fonctionnement et sur ses cas d'usages.Support the show (https://www.patreon.com/electromonkeys)
Java est un langage populaire apprécié de nombreux développeurs. Certes, il est là depuis des lustres, et certains pourraient le penser obsolète face à Go ou à Rust. Pourtant, bien loin de cette hype, Java continue à faire son chemin et à se réinventer lui-même jour après jour.Pour évoquer les défis de Java face au cloud natif, j'ai déjà eu l'occasion de parler de Spring et de GraalVM native image. Cette fois, la discussion se porte sur Quarkus, que Red Hat décrit comme étant un framework Java natif pour Kubernetes, et Eclipse Vert.x une librairie Java qui facilite l'écriture de micro services.Pour évoquer ces sujets, je n'ai un, mais deux invités : Thomas Segismont et Julien Ponge. Thomas et Julien travaillent tous deux pour Red Hat, où ils sont respectivement senior software engineer et principal software engineer. Ils nous emmènent à la découverte de Quarkus et de Vert.x sur fond de GraalVM.Notes de l'épisodeVert.x in Action, Manning Publications : https://www.manning.com/books/vertx-in-action?a_aid=vertx-in-action&a_bid=22152024Le dev mode Quarkus:est supporte la plupart des protocoles, dont les outils en ligne de commande, gRPC et Kafka (update depuis l'enregistrement de l'épisode)Red Hat supporte activement Quarkus : https://quarkus.io/support/Pour ce qui concerne le mode natif, du point de vue du support Red Hat c'est Tech Preview pour l'instant (best effort). Mais la prochaine version produit devrait venir avec le support de Mandrel (https://github.com/graalvm/mandrel). Mandrel est un sous-projet de Graal qui fournit un compilateur native-image taillé pour Quarkus.Mandrel (https://github.com/graalvm/mandrel) est supporté par Red HatLa roadmap Vert.x : https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap#vertx-4La roadmap Quarkus :  https://github.com/orgs/quarkusio/projects/5Support the show (https://www.patreon.com/electromonkeys)
Les Progressive Web Apps sont des sites web qui, d'un point de vue de l'utilisateur, peuvent être perçus comme des applications natives. Elles sont avant tout destinées aux mobiles, car elles ont l'avantage, par leur nature, d'être  multi plateformes. Elles ont également un autre avantage : celui de ne pas dépendre des contraintes d'un app store.Tous ces aspects sont attractifs pour les entreprises, qui peuvent ainsi réduire leurs coûts de développement. Mais alors, comment fonctionnent ces applications ? Sont-elles facile à développer ? Quels inconvénient ont-elles vis à vis des applications natives ? Car on peut légitimement s'interroger sur la sécurité ou la stabilité d'une telle application.Dans cet épisode, je reçois Emmanuel Demey. Emmanuel est consultant Angular indépendant, et il vient récemment de publié un livre, simplement appelé Progressive Web App aux éditions ENI. Avec lui, non seulement nous allons en apprendre un peu plus sur ces applications web d'un genre nouveau, mais vous aurez aussi peut-être une chance de repartir avec un de ses livres.Support the show (https://www.patreon.com/electromonkeys)
loading
Comments 
Download from Google Play
Download from App Store