Architecture orientée événements, chaos des webhooks et essor des agents IA | Podcast Better Stack Ép. 17
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술
스크립트
00:00:00Bienvenue sur le podcast Better Stack, où nous discutons du développement logiciel,
00:00:04de l'IA et de toutes sortes de nouvelles technologies. Je suis l'un de vos hôtes, Andrus, et je suis rejoint aujourd'hui par
00:00:10James et Alex. Salut Alex, bienvenue dans l'émission. Merci de m'accueillir, les gars. Commençons donc
00:00:16par l'entreprise que vous dirigez. Elle s'appelle Hookdeck. Alors pour ceux qui ne connaissent pas,
00:00:22qu'est-ce que Hookdeck ? Que fait-elle ? Dites-nous en plus à ce sujet. Eh bien, j'aime la considérer comme
00:00:27l'entreprise de webhooks qui essaie de tuer les Webhooks. C'est probablement une histoire sur laquelle nous pourrons revenir.
00:00:32Mais nous construisons deux produits principaux. Le premier est l'Event Gateway. L'Event Gateway sert de
00:00:37sorte de bus d'événements spécialisé pour tous les événements provenant de l'extérieur de votre infrastructure.
00:00:41Les webhooks sont les premiers suspects, mais nous voyons beaucoup de cas d'utilisation liés à l'IoT, aux SDK, etc.
00:00:47Donc, essentiellement, nous fournissons une sorte de point de terminaison non approuvé. Vous pouvez nous envoyer n'importe quels événements.
00:00:51Et toutes les capacités pour gérer ces événements. Cela va du filtrage,
00:00:55à la transformation, au routage, à la mise en file d'attente, aux alertes, à la gestion des problèmes, la relecture est en quelque sorte tout le concept.
00:01:01Donc, vraiment, cela couvre à la fois l'interopérabilité dans le sens où j'ai besoin de recevoir
00:01:05des événements et des webhooks de tous les fournisseurs avec lesquels je travaille, n'est-ce pas ? Ça peut être Stripe, Shopify, Twilio,
00:01:10WhatsApp, TikTok, peu importe. Chacun a ses propres critères, ses bizarreries
00:01:16et ses exigences spécifiques. Et donc nous pouvons en quelque sorte standardiser tout cela et l'intégrer
00:01:20dans un contrat unique. Et ensuite, tout ce qui concerne la mise en file d'attente. Par exemple,
00:01:27pour Shopify, il y a une vente flash sur votre boutique et vous êtes absolument
00:01:31submergé par les événements. Vous normalisez cela afin de pouvoir contrôler le débit dans l'Event
00:01:38Gateway, tout ça. C'est donc une grande partie. C'est en quelque sorte le côté consommateur. Et c'est
00:01:42là que l'histoire de Hookdeck a vraiment commencé. Et plus récemment, nous avons également lancé Outpost. Outpost est entièrement
00:01:49open source, sous licence Apache 2.0. Et nous proposons désormais un service géré pour cela également. Et c'est pour envoyer
00:01:55des événements. C'est donc en quelque sorte l'autre côté de l'équation, n'est-ce pas ? Vous êtes un éditeur, une
00:01:59plateforme, un outil de développement. Nous sommes vraiment à ce stade, tout le monde envoie également des événements. Je suis surpris
00:02:05chaque jour. Outpost est donc ce service géré ou auto-hébergé que vous pouvez utiliser pour
00:02:12déclarer qui sont vos locataires, quelles sont les destinations, les points de terminaison qu'ils ont enregistrés, configurer
00:02:17des sujets et y publier des événements. Il gère tout, de la visibilité aux métriques, en passant par les garanties de livraison,
00:02:23les tentatives de rejeu, et tous les suspects habituels concernant les signatures, la rotation des signatures,
00:02:28et tout ça. La petite blague que je faisais sur le fait d'essayer de tuer les Webhooks, c'est qu'Outpost,
00:02:35oui, vous permet d'envoyer des Webhooks, mais vous permet aussi de publier des événements directement vers le bus de messages de vos utilisateurs.
00:02:39Outpost prend donc nativement en charge ce que l'on appelle désormais les destinations d'événements. Et le Webhook est
00:02:46considéré comme le routeur de transport. Vous envoyez donc essentiellement des événements via des Webhooks et
00:02:53les Webhooks sont le mécanisme de transport standard, n'est-ce pas ? Vous pouvez choisir de nouveaux protocoles de transport, comme MQ
00:02:59pour RabbitMQ ou Kafka. Et nous prenons en charge la publication directe vers les suspects habituels comme Pub/Sub,
00:03:05SQS, AWS EventBridge, et évidemment l'Event Gateway de Hookdeck, n'est-ce pas ? Je l'imagine donc comme la
00:03:12meilleure destination, mais nous verrons si les gens y croient. Vous avez dit vouloir tuer les Webhooks. J'imagine donc
00:03:18que cette idée et sa conception viennent du fait que vous en aviez tous assez des Webhooks ou que c'était
00:03:25trop difficile à gérer. Racontez-nous comment l'idée vous est venue. Oui, je racontais justement l'histoire
00:03:31à quelqu'un l'autre jour. Il y a environ cinq ans, j'ai publié cet article sur Medium.
00:03:37Cela fera bientôt six ans maintenant. Et l'article s'intitule, en écho à ce que vous dites,
00:03:42“Les Webhooks sont nuls, mais vous pouvez faire quelque chose.” C'était juste moi, dans mon
00:03:48sous-sol, vous savez, à bricoler et à construire une sorte de prototype V1 de Hookdeck.
00:03:54Mais cela venait vraiment de cette frustration. Je travaillais personnellement dans l'e-commerce et nous avons construit
00:03:59beaucoup de logiciels personnalisés pour alimenter l'e-commerce, de la gestion d'abonnement personnalisée
00:04:05à l'entreposage, à l'exécution, et tout ce genre de choses. Et tellement de vos problèmes
00:04:10se résumaient aux Webhooks. Et c'était presque une blague récurrente car, d'une part,
00:04:15j'essayais de vendre... c'était une entreprise de mode féminine, n'est-ce pas ? J'essayais de vendre de la
00:04:18lingerie et des bas, et tout ça. Et d'un autre côté, c'était : “Où est passé ce maudit
00:04:23webhook ? Qu'est-ce qui lui est arrivé ?” Il y avait un vrai décalage en termes de préoccupations.
00:04:28Cela venait vraiment de là, de ma frustration en tant que consommateur de ces Webhooks,
00:04:33parce qu'il n'existe aucun moyen “clé en main” de traiter ce
00:04:38problème. Et si vous alliez en ligne chercher une recommandation, comme... enfin,
00:04:43les webhooks ne sont pas nouveaux. Au bout du compte, ce sont des requêtes HTTP. Il y a
00:04:46évidemment des modèles établis sur la façon dont vous êtes censé gérer cela. Mais vous
00:04:50entrez très rapidement dans le vif du sujet. D'accord. Vous avez besoin de consommateurs pour l'ingestion qui peuvent
00:04:55s'auto-scaler, puis vous devez mettre en file d'attente vers une queue comme SQS. Et vous devez déployer un ensemble
00:05:00de consommateurs qui vont consommer depuis SQS. Et si quelque chose tourne mal, cela va finir
00:05:05dans la file d'attente des échecs (dead letter queue). Et vous avez besoin d'un script pour pouvoir récupérer depuis cette file et
00:05:09comprendre pourquoi les choses ont fini là-bas. Il y a toutes ces préoccupations.
00:05:14Et à mesure que la complexité augmente, vous voulez aussi être capable de relire les événements historiques que vous avez
00:05:18reçus. Vous voulez pouvoir voir ce qu'était spécifiquement la charge utile (payload) du Webhook.
00:05:22Et ensuite, vous gérez différents fournisseurs, car peut-être que Stripe va vous donner
00:05:26une interface utilisateur et qu'Intercom ne vous en donnera pas. Et vous vous retrouvez avec toutes ces
00:05:31bizarreries différentes à gérer. Cela découlait vraiment de cette frustration, et
00:05:35simplement, pourquoi n'existait-il aucune solution à cela ? Et au début, je le voyais vraiment sous un angle
00:05:41d'observabilité, et cela ne fonctionnait pas vraiment. Ce que j'ai raté, c'est que l'observabilité
00:05:47n'en est qu'une partie. En fin de compte, j'ai cette expression : le Webhook est la drogue douce
00:05:51vers l'architecture événementielle. Et la raison, et c'est aussi pourquoi j'aime insister
00:05:56sur le terme “événement” plutôt que “Webhook”, c'est que derrière chaque Webhook il y a un événement, et il y a
00:06:01maintenant des paradigmes d'architecture événementielle qui sont fournis avec ce Webhook, n'est-ce pas ? Donc chaque
00:06:07fois que vous recevez un Webhook pour une échelle importante ou des cas d'utilisation critiques, vous devez maintenant
00:06:14penser à l'idempotence, à l'ordre, aux garanties de livraison, et à tous les types de
00:06:19défis auxquels vous êtes confrontés une fois que vous commencez à gérer des paradigmes de programmation événementielle asynchrone.
00:06:25Et donc, beaucoup de ce que nous avons construit a évolué vers la construction d'une file d'attente à part entière
00:06:29au final. Il y a cette interopérabilité, nous gérons des événements,
00:06:33mais ensuite toutes ces sémantiques concernent davantage la gestion des événements, les sous-systèmes de publication, etc.
00:06:38Nous n'étions pas là pour réinventer les files d'attente. Je pense que nous avons
00:06:43découvert un tas d'idées vraiment sympas. Et une chose que nous voyons maintenant, c'est que
00:06:48les gens passent à Hookdeck pour remplacer Pub/Sub ou SQS dans leur stack, ce qui
00:06:53pour moi est assez ahurissant, car nous ne gérons pas votre VPC ni rien de tout ça. Je pense
00:06:57qu'il y a beaucoup de problèmes, peut-être, peut-être, peut-être dans la feuille de route. Mais le fait est,
00:07:05je pense qu'il y a beaucoup de sémantiques autour de l'architecture événementielle auxquelles les gens se sont
00:07:09habitués, sans vraiment les remettre en question. C'est comme : “Pourquoi faisons-nous
00:07:13des dead letter queues encore ? Qu'est-ce qui ne va pas ?” Parce que je ne connais personne qui pense que
00:07:19la dead letter queue est une sémantique pratique pour traiter les erreurs dans vos files d'attente, n'est-ce pas ? Enfin bref, je suis heureux de
00:07:25peut-être aborder certaines de ces choses, car il y a quelques opinions fortes
00:07:29là-dedans. Je ne sais pas à quel point vous êtes des nerds de Pub/Sub et de l'architecture événementielle. Je ne veux pas
00:07:35vous entraîner trop loin. Je sens que, oui, ma compréhension des dead letter queues et tout
00:07:40ça est très, très superficielle. Certaines choses que j'entends aujourd'hui, je les entends pour la première fois.
00:07:48Oui, je voulais dire que la mienne est assez superficielle aussi, mais j'ai eu affaire aux webhooks
00:07:53pas mal de fois et j'ai rencontré certains des problèmes que vous avez mentionnés. Et je pense, et c'est comme ça
00:07:57que vous défendez l'idée que les webhooks sont la drogue douce de l'architecture événementielle,
00:08:01car je suis prêt à parier que pour les développeurs ayant votre parcours, les webhooks sont
00:08:06probablement la première exposition à : “Attends, c'est asynchrone. Comment je gère ça ?”
00:08:12Et je pense qu'il y a toute cette courbe d'apprentissage, n'est-ce pas ? C'est le classique iceberg où c'est,
00:08:17oh, vous avez la requête HTTP qui arrive, et puis, vous savez, le reste de l'iceberg
00:08:21derrière dans l'eau, n'est-ce pas ? Je pense que l'une des choses que j'essaie
00:08:26de faire est d'apporter un niveau d'expérience développeur (DX) qui n'a pas vraiment été atteint dans cet espace pour que
00:08:32vous n'ayez pas à comprendre tout le reste de l'iceberg, n'est-ce pas ? Il y a des choses qui sont un
00:08:37peu inévitables, je ne veux pas le déformer. Je pense qu'une fois que vous commencez à
00:08:40travailler avec ce genre de problèmes, vous devez avoir une bonne compréhension de l'idempotence,
00:08:45par exemple, vous devez avoir une bonne compréhension des garanties d'ordre. Donc
00:08:49ce n'est pas comme si vous pouviez résoudre chaque problème. Je pense que vous traitez toujours des événements
00:08:53au bout du compte. Mais je pense qu'il y a beaucoup de sémantiques et de complexité qui viennent principalement
00:08:58d'outils qui n'ont pas été totalement pensés, plus que de la complexité
00:09:05associée à cet espace problématique. Donc je pense qu'en ce moment, nous finissons par servir deux
00:09:13sortes de clients : ceux qui connaissent vraiment le problème en profondeur et
00:09:18qui vont faire de l'ingénierie de solution autour de leur configuration Kafka actuelle et tout
00:09:23ça toute la journée. Et puis, nous leur présentons certaines de ces nouvelles sémantiques,
00:09:28et ils en sont très enthousiastes. C'est une catégorie. Mais l'autre catégorie est : “Je
00:09:31ne veux pas avoir à apprendre tout ça”, et fondamentalement, j'essaie de contourner
00:09:36tout ça. Voilà. Donc, nous voyons beaucoup de ces deux profils.
00:09:41Est-ce aussi une raison pour laquelle vous avez rendu open source cet outil, Outpost, pour faciliter la tâche aux développeurs
00:09:47pour commencer à l'utiliser ? D'une certaine manière. L'autre raison est que nous n'avons pas besoin d'Outpost
00:09:53pour gagner de l'argent. D'accord. Alors on s'est dit : autant le rendre open source. Voilà. C'est juste,
00:10:01je sais que beaucoup de notre audience YouTube aime vraiment découvrir de nouveaux outils open source. C'est
00:10:07pour ça que je voulais poser la question. Mais, premièrement, je regrette
00:10:13un peu de ne pas avoir adopté une approche plus “open source first” au début.
00:10:18Je pense que la façon dont vous construisez votre logiciel est très différente selon que vous construisez pour du propriétaire
00:10:21ou pour de l'open source. Mais concernant cette décision,
00:10:26une chose que l'on voit avec les startups financées par du capital-risque, c'est qu'on finit par avoir ce
00:10:30faux open source, n'est-ce pas ? C'est de l'open source, mais soit c'est de l'open core, soit oui, c'est open source,
00:10:34mais ils ne veulent pas vraiment que vous utilisiez l'open source, ou ils finissent par relicencier
00:10:39le logiciel sous des licences qui ne sont pas vraiment open source, etc. Voilà. Et je pense
00:10:44que cela m'a rendu vraiment enthousiaste pour Outpost et l'open source, car j'ai senti que nous avions
00:10:49l'opportunité d'avoir les bonnes incitations. Peut-être pouvons-nous entrer dans les détails de notre réflexion
00:10:54sur le business, etc. Mais dans mon esprit, les gens qui doivent recevoir des webhooks
00:10:59côté consommateur sont au moins deux à trois ordres de grandeur plus nombreux
00:11:03que les gens qui ont besoin d'envoyer un webhook, n'est-ce pas ? Parce que, réfléchissez-y : si j'envoie des webhooks,
00:11:09je les envoie à tous mes clients, et mes clients peuvent être 10, si vous démarrez,
00:11:13100, 1000, 2 millions. Voilà. Et donc, inévitablement, le côté consommateur concerne beaucoup plus de gens.
00:11:17Et donc, quand j'y pense d'un point de vue entrepreneurial,
00:11:24je suis plus enthousiaste à propos de l'activité du côté consommateur. Voilà. Mais je pense que ce
00:11:28dont nous nous sommes rendu compte, c'est qu'évidemment, vous n'avez pas de consommateurs sans bons producteurs. Et je pense
00:11:33qu'il y a de plus en plus de demande pour les webhooks en général, à travers les applications que vous développez. Donc,
00:11:37plus de gens veulent en proposer et ne veulent pas passer par la DX (expérience développeur) et les frais généraux,
00:11:42etc. Mais de mon point de vue, premièrement, envoyer des webhooks est un problème plus simple, parce que vous
00:11:46contrôlez les paramètres, alors que côté réception, vous ne contrôlez rien, le fournisseur dicte les paramètres.
00:11:51C'est donc... je ne veux pas dire que c'est simple, mais...
00:11:57et il y a certainement plein de façons de mal faire les choses. Mais en termes d'espace problématique,
00:12:02c'est définitivement plus limité du côté producteur que du côté consommateur. Et deuxièmement,
00:12:06notre travail est d'encourager la production d'événements. C'est ce qui nous importe finalement
00:12:10parce que nous voulons que plus de gens consomment ces webhooks et finissent par devenir des clients.
00:12:15Voilà. Et donc cela nous met dans une position où nous pouvons
00:12:19vraiment dire : “Regardez, si vous utilisez Outpost, que vous l'utilisiez en open source ou que vous le déployiez
00:12:23avec Hookdeck dans la version gérée, cela ne change rien pour nous.” Nous atteignons l'objectif commercial
00:12:29de toute façon. Et cet alignement des incitations m'a rendu vraiment enthousiaste.
00:12:35Il y a quelques choses que nous avons faites : d'abord, nous avons publié l'open source
00:12:40avant même d'envisager de construire une version gérée. Il n'y avait aucun plan pour construire une
00:12:44version gérée lorsque nous avons construit l'open source. Le projet a été publié il y a
00:12:48environ deux ans. Il nous a donc fallu presque deux ans avant qu'assez de gens demandent la version gérée
00:12:52pour que nous finissions par la construire. C'est donc une chose. Et l'autre partie,
00:12:57c'est que la version gérée d'Outpost exécute exactement la même build Docker que celle publiée sur
00:13:03Docker Hub à partir de l'open source. Cela signifie que nous n'avons pas de fork privé.
00:13:08Nous ne développons pas de fonctionnalités en dehors de l'open source. Nous exécutons exactement la même build.
00:13:13La question pour vous n'est donc pas : “Est-ce que telle version offre telle fonctionnalité ?”
00:13:19C'est littéralement : “Voulez-vous le déployer et prendre en charge
00:13:23le fardeau opérationnel associé, ou voulez-vous payer quelqu'un d'autre pour le faire à votre place ?”
00:13:29Je ne pense pas qu'il y ait de bonne ou de mauvaise réponse. Cela dépend de chaque entreprise, de leur niveau de
00:13:34confort, de leurs exigences de conformité, etc. Mais à cause de cela,
00:13:38je pense que nous pouvons être de bons contributeurs à la communauté open source.
00:13:44J'ai été très heureux d'y travailler parce que c'est le premier grand projet open source
00:13:51dans lequel je suis impliqué en tant que mainteneur principal.
00:13:55Oui, ça a été une bonne expérience.
00:14:01Comment trouvez-vous le monde de l'open source maintenant avec l'IA et tout le reste ?
00:14:05Avez-vous eu beaucoup de PR (pull requests) et de failles de sécurité qui n'en sont pas, ou est-ce gérable ?
00:14:09Écoutez, je ne pense pas que nous soyons à une échelle où je peux parler de ce que vivent les autres.
00:14:14Je ne veux pas déformer la situation, car ça semble difficile pour beaucoup.
00:14:20Je dirai que j'ai été surpris par la qualité des contributions.
00:14:25Mais nous avons eu des contributions où, par exemple,
00:14:30il y a une PR spécifique, toujours ouverte, pour ajouter les files d'attente Cloudflare.
00:14:34La description semble bonne, etc. Et puis, quand vous creusez le code,
00:14:40il utilise un tas d'API Cloudflare complètement inventées.
00:14:44La personne n'a clairement même pas essayé de faire tourner le code.
00:14:48Et donc maintenant, le fardeau repose sur nous.
00:14:52Je suis un peu inquiet d'être perçu comme quelqu'un qui n'encourage pas les autres.
00:14:56Je pense donc que nous devrions ajouter les files d'attente Cloudflare.
00:15:02Mais en même temps, ce n'était pas sur la feuille de route, personne d'autre ne l'a demandé.
00:15:08C'est un dilemme : si vous fermez la PR, vous avez l'air de ne pas vouloir soutenir les gens.
00:15:12Mais vous ne pouvez pas non plus y consacrer des ressources tout de suite.
00:15:15C'est un peu un cercle vicieux.
00:15:19Mais jusqu'à présent, je trouve que c'est une très bonne expérience.
00:15:24Surtout parce que nous utilisons la même build.
00:15:28Chaque fois que des clients nous contactent, nous ouvrons des issues sur GitHub.
00:15:33Nous nous assurons toujours de leur dire : “D'ailleurs, le repo est là.
00:15:37Vous pouvez contribuer.”
00:15:43Plusieurs utilisateurs ont fait des contributions et ont implémenté leurs propres fonctionnalités.
00:15:48Cela a considérablement réduit la barrière à l'entrée.
00:15:53Historiquement, le projet est en Go, et la plupart de nos utilisateurs ne sont pas développeurs Go.
00:15:58Nous voyons beaucoup de Python, TypeScript, Node.js.
00:16:03Il y a une barrière à l'entrée avec Go, et apprendre un nouveau projet est non négligeable.
00:16:07Je pense que cela a réduit cette barrière.
00:16:13Et en tant que mainteneur, c'est un signal fort que la fonctionnalité vaut la peine d'être construite.
00:16:18Quelqu'un prend de son temps pour l'implémenter.
00:16:24C'est un signal pour la hiérarchisation des tâches.
00:16:28Réduire la barrière à l'entrée est très positif.
00:16:35Si vous arrivez à gérer les inondations de spam,
00:16:39il y a beaucoup de positif.
00:16:42Sur la page d'accueil, un témoignage du PDG de Vercel m'a marqué.
00:16:48Vercel utilise Hookdeck comme produit.
00:16:53Quelqu'un fait l'effort de consacrer ses jetons pour implémenter cela.
00:16:58C'est un signal qui montre que cela compte vraiment. En termes de priorité,
00:17:02ce qui est le plus important. Donc, je pense que réduire la barrière à l'entrée est une excellente chose.
00:17:07Et si vous parvenez à éviter le déluge de spam et tout ce genre de choses,
00:17:12il y a beaucoup d'aspects positifs.
00:17:14Sur la page d'accueil, un témoignage du PDG de Vercel a particulièrement attiré mon attention.
00:17:21Vercel utilise en fait Hookdeck comme produit.
00:17:25Si vous lisez cette citation précise, il le recommande aussi.
00:17:29Ah, d'accord.
00:17:29Un peu comme pour les utilisateurs de Vercel et ce genre de choses.
00:17:32Mais il y a une anecdote assez amusante à ce sujet.
00:17:35Guillermo en a parlé sur Twitter un samedi soir.
00:17:39Je ne m'y attendais pas du tout.
00:17:40Je n'avais pas de relation préalable avec Guillermo, ni rien de ce genre.
00:17:45Cela témoigne de l'influence de certaines personnes dans la communauté.
00:17:48Le nombre d'inscriptions et la notoriété que nous avons obtenus grâce à cela
00:17:53étaient incroyables.
00:17:54Depuis, Guillermo et moi sommes restés en contact ici et là.
00:17:57Nous avons toujours eu des discussions intéressantes.
00:17:59C'est intéressant.
00:18:00En fait, si vous regardez une entreprise comme Vercel, Guillermo m'a dit
00:18:04qu'il voit beaucoup plus de gens utiliser des webhooks maintenant.
00:18:07Son analyse est que c'est principalement dû aux options des modèles de langage (LLM).
00:18:12Cela crée de nouveaux cas d'usage pour les données.
00:18:15Des choses auxquelles vous n'auriez jamais prêté attention auparavant.
00:18:18Pensez à votre système de support client.
00:18:20Par exemple, vous avez des agents et des humains qui gèrent cela.
00:18:23Il n'y a que très peu de raisons de faire quoi que ce soit avec les nouveaux tickets.
00:18:29Et ce genre de choses.
00:18:30De toute façon, c'est l'humain qui va répondre à ce message.
00:18:34Mais nous vivons désormais dans un monde où cela change complètement.
00:18:37Et quand les humains ne sont plus les seuls à déclencher les agents, ce sont les événements.
00:18:42Exact.
00:18:42Soudain, vous vous intéressez aux événements de votre système de support client,
00:18:46de votre outil marketing, etc.
00:18:48Exact.
00:18:48C'est donc certainement quelque chose que les plateformes observent.
00:18:54Et ce sont des points de discussion intéressants pour nous, évidemment.
00:18:57Mais Vercel, pour préciser, n'est pas directement un utilisateur.
00:19:01Je suis sûr qu'un tas de développeurs utilisent votre CLI locale et ce genre de choses
00:19:05chez Vercel, mais oui.
00:19:06Alors, quel est le client type pour quelqu'un qui utilise Hookdeck ?
00:19:10Par exemple, si j'avais une petite boutique de t-shirts en ligne, comment
00:19:15utiliserais-je Hookdeck ?
00:19:17Et est-ce que cela aurait du sens ?
00:19:19Probablement pas.
00:19:21D'accord.
00:19:22Vous me posez la question à un million de dollars, dans le sens où c'est un problème
00:19:26que nous avons toujours eu, car l'éventail des raisons pour utiliser des webhooks
00:19:32ou en dépendre est tout simplement immense.
00:19:35Nous recevons des webhooks des suspects habituels comme Stripe et Shopify, mais aussi
00:19:40des fournisseurs de télécoms australiens et de la chambre de compensation britannique.
00:19:47Il y en a aussi beaucoup venant du jeu EVE Online.
00:19:50Il existe apparemment une communauté de personnes qui jouent encore à ce jeu, Conan
00:19:55le barbare, vieux de 15 ans ou quelque chose comme ça.
00:19:58Et ils utilisent beaucoup de webhooks aussi.
00:20:00Ne me demandez pas pourquoi.
00:20:00Exact.
00:20:01Le fait est qu'il y a une telle diversité qu'il est très difficile de dire que telle personne est notre client.
00:20:06Exact.
00:20:08Exact.
00:20:09Donc, quand nous regardons les gens qui les utilisent, il n'y a pas de cas d'usage unique
00:20:13ou de groupe qui domine.
00:20:14Probablement pas plus de 10 %.
00:20:16Mais pour en revenir à votre exemple de e-commerce.
00:20:19Tout d'abord, une petite boutique de t-shirts n'a probablement pas construit d'applications
00:20:25personnalisées qui en dépendraient.
00:20:27Mais ils ont presque certainement installé des applications.
00:20:30Par exemple, une application pour recueillir des avis, une autre pour les notifications de stock, etc.
00:20:35Une pour la gestion des stocks et une pour leur prestataire logistique (3PL).
00:20:39Et tous ces outils reposent presque exclusivement sur les webhooks.
00:20:43Exact.
00:20:43Si je veux envoyer une notification de retour en stock, j'écoute toutes les mises à jour
00:20:48du stock dans Shopify via leurs webhooks.
00:20:50Et dès qu'un produit précédemment en rupture de stock est disponible,
00:20:53je me dis, OK, il faut envoyer l'e-mail.
00:20:54Exact.
00:20:55Donc, pratiquement chaque chose qu'ils vont installer va reposer sur des webhooks
00:20:59en arrière-plan.
00:21:00C'est donc une catégorie importante.
00:21:02Les gens construisent des applications, et ce n'est pas seulement Shopify ; Stripe par exemple
00:21:07a une grande place de marché d'applications.
00:21:09Beaucoup d'entre eux sont des clients.
00:21:11L'autre chose que nous voyons, ce sont les grandes boutiques.
00:21:14Pensez à Gymshark, Good American, Rogue, etc., où ils ont leurs propres équipes techniques
00:21:19et construisent des applications sur mesure.
00:21:22Ils créent des applications personnalisées pour l'intégration de systèmes, souvent très opérationnelles
00:21:28en termes de séquençage, comme quand une commande doit être synchronisée avec un 3PL.
00:21:34Peut-être qu'il y a des préférences client spécifiques à ajouter à ces données
00:21:39avant qu'elles n'atteignent le 3PL.
00:21:41Exact.
00:21:41Certaines vont optimiser l'expérience utilisateur, comme la gestion d'abonnements personnalisée,
00:21:46ou des e-mails spécifiques envoyés quand quelqu'un achète une carte-cadeau
00:21:51pour l'offrir à un ami, etc.
00:21:55C'est donc ce que nous observons ; la petite boutique Shopify est probablement l'exemple que vous auriez pu
00:21:59choisir et où nous ne voyons pas beaucoup de gens utiliser Hookdeck, mais partout ailleurs
00:22:04dans ce segment, vous allez tomber sur une entreprise qui utilise Hookdeck.
00:22:08C'est juste.
00:22:09C'est juste.
00:22:10C'est juste.
00:22:11Comment cela se compare-t-il à AWS EventBridge ?
00:22:14Parce que c'est l'un des autres choix dont j'ai entendu parler.
00:22:17Est-ce juste une meilleure expérience développeur ?
00:22:19Eh bien, nous connaissons tous AWS ; Amazon fait plus ou moins le même argument, non ?
00:22:24Oui.
00:22:25Oui.
00:22:26Donc, tout ce que vous dites sur votre proposition de valeur unique par rapport à,
00:22:31CloudWatch, aux services Amazon et tout le reste, s'applique.
00:22:37C'est très axé sur l'expérience développeur, n'est-ce pas ?
00:22:40Avec de bonnes API, une interface utilisateur agréable, une fiabilité à toute épreuve, etc.
00:22:46Exact.
00:22:47Exact.
00:22:47Et évidemment, le problème avec AWS est qu'on se retrouve avec
00:22:5120 services, dont on a probablement déjà oublié le nom.
00:22:56Les données et la configuration sont éparpillées partout.
00:22:59Éparpillées partout.
00:23:01Exact.
00:23:01C'est donc un point.
00:23:02Mais le point plus large est qu'AWS EventBridge ne s'intègre pas avec tout le monde.
00:23:07Tout le monde.
00:23:08Le fournisseur doit avoir intégré AWS EventBridge.
00:23:11Il y a des solutions de contournement avec l'API Gateway, etc.
00:23:16C'est vraiment conçu pour l'écosystème AWS, où la plupart des cas d'usage concernent des
00:23:23événements internes, comme le téléchargement d'un document S3, etc.
00:23:31Ce genre de choses.
00:23:31L'interopérabilité avec les tiers est limitée ; ils supportent peut-être une quarantaine de
00:23:36fournisseurs, mais pas des milliers. Ne me citez pas là-dessus.
00:23:40On finit par se retrouver dans une situation où Shopify supporte EventBridge, mais Twilio
00:23:45non.
00:23:47Exact.
00:23:47On finit par avoir besoin d'une solution agnostique qui fonctionne pour tout le monde.
00:23:51C'est ce que nous essayons de faire.
00:23:52Nous construisons notre solution de sorte que nous n'ayons pas besoin
00:23:54que le fournisseur accepte ou fasse quoi que ce soit de son côté.
00:23:59Pour rien.
00:24:02À cet égard, la manière dont nous construisons Hookdeck est assez nouvelle,
00:24:08car elle fonctionne purement via HTTP.
00:24:10L'idée est que nous vous fournissons une URL, et vous remplacez votre URL
00:24:15existante par celle que nous vous donnons.
00:24:17Ensuite, dans Hookdeck, votre destination est ce qui aurait été votre URL de webhook.
00:24:22Nous agissons comme une file d'attente basée sur le push.
00:24:25Nous recevons tous les webhooks via HTTP, puis nous les poussons
00:24:28au rythme que vous spécifiez vers votre propre point de terminaison.
00:24:31Cela signifie que vous n'avez même pas besoin de redéployer votre code.
00:24:34Vous pouvez être sur n'importe quel cloud, n'importe quelle stack, pour que cela fonctionne presque immédiatement.
00:24:39Exact.
00:24:40La seule exigence est de mettre à jour l'URL.
00:24:44C'est loin d'AWS EventBridge, qui implique un verrouillage fournisseur (vendor lock-in)
00:24:48et ne fonctionne que dans l'écosystème AWS.
00:24:53Oui.
00:24:53Je considère généralement AWS EventBridge comme l'autre grande passerelle d'événements.
00:24:58Nous voyons aussi Azure Event Grid, qui est un concurrent, gagner du terrain.
00:25:04Quand je pense à notre compétition la plus directe, ou notre inspiration
00:25:10d'une certaine manière, ce sont ces deux produits.
00:25:13Mais je pense que la portée de ce que nous essayons de faire est bien plus grande.
00:25:17Pour certains, c'est une bonne chose.
00:25:18Pour d'autres, ce n'est pas le cas, non ?
00:25:20C'est ce qu'ils veulent.
00:25:22Ils sont totalement ancrés dans l'écosystème AWS.
00:25:24Ils utilisent CloudFormation.
00:25:26Ils connaissent tous les services.
00:25:27Ils veulent pouvoir choisir les fonctionnalités.
00:25:30Et c'est très bien.
00:25:31Je ne pense pas que nous aurons jamais 100 % de parts de marché.
00:25:34Quelques points de pourcentage suffisent probablement.
00:25:38Nous essayons de montrer qu'il s'agit de la bonne solution pour les entreprises
00:25:45et les développeurs.
00:25:48Pour d'autres, AWS EventBridge sera la solution, et c'est très bien.
00:25:51J'ai remarqué que le nombre de pannes pour les grandes entreprises a augmenté au cours de l'année passée.
00:25:59Il y a des mèmes sur GitHub qui tombe en panne.
00:26:00Je me souviens, il y a deux ans, quand je travaillais,
00:26:02si le P99 chutait à 99,5 ou moins, vous aviez une conversation sérieuse
00:26:07avec votre équipe sur la façon d'améliorer cela.
00:26:13Exact.
00:26:14Comment faire en sorte que cela n'arrive plus ?
00:26:15Maintenant, c'est devenu la norme.
00:26:17Oui.
00:26:17Les gens se sont habitués au fait que GitHub tombe en panne régulièrement.
00:26:23De votre perspective chez Hookdeck, voyez-vous aussi beaucoup plus de pannes
00:26:28cette année, et comment gérez-vous ces défis ?
00:26:33C'est intéressant, car c'est une considération nécessaire si vous consommez des webhooks.
00:26:37Les webhooks de GitHub, spécifiquement, sont particulièrement problématiques.
00:26:42Il y a une chance sur deux, si vous vous connectez à Railway, Vercel ou autre,
00:26:46d'avoir une petite bannière.
00:26:47Disant que les déploiements sont interrompus car les webhooks GitHub ne fonctionnent pas.
00:26:51Le CTO de GitHub a écrit un article sur la stabilité de leur infrastructure
00:26:58au milieu de tous les mèmes, pour essayer de calmer les choses.
00:27:02Je ne pense pas que cela ait vraiment fonctionné.
00:27:03Mais il y avait un fond de vérité.
00:27:05Une des choses blâmées dans cet article était la stabilité des webhooks
00:27:09et leur dépendance à MySQL, etc.
00:27:12Exact.
00:27:13À leur crédit, le défi d'infrastructure est complètement insensé.
00:27:17Avec l'essor des agents, c'est encore plus difficile.
00:27:21Comme on parlait des mainteneurs open-source submergés.
00:27:23C'est aussi une infrastructure submergée.
00:27:26C'est un défi extrêmement difficile.
00:27:30Mais le point où j'en viens, c'est que nous le voyons aussi.
00:27:33Et nous le surveillons pour certains fournisseurs.
00:27:38Nous avons ce que nous appelons le “Hookdeck Radar”.
00:27:41Par exemple, nous avons ce que nous appelons un radar de deck.
00:27:44L'idée est de pouvoir examiner des statistiques agrégées provenant de tous les clients et de tous les
00:27:49Webhooks que nous recevons via un deck, puis de calculer des éléments comme, vous savez, la latence
00:27:53de livraison, la latence de livraison P99 pour un fournisseur, son temps de disponibilité, etc.
00:27:58Par exemple, notre radar pour Shopify est assez populaire.
00:28:01J'ai quelques centaines d'abonnés.
00:28:04L'idée est donc de vous envoyer des alertes si la latence dépasse un certain
00:28:09écart-type par rapport à la latence de base.
00:28:12C'est ça.
00:28:12Je crois que pour Shopify, la latence de base est d'environ quatre ou cinq secondes
00:28:17pour la livraison.
00:28:17Je pense qu'au-delà de 10 secondes,
00:28:19c'est ça.
00:28:20nous envoyons une alerte.
00:28:22L'idée est de pouvoir surveiller cela comme une série temporelle et d'observer
00:28:26non seulement leur temps de disponibilité brut, mais aussi leur profil de latence
00:28:31dans le temps.
00:28:32C'est certainement quelque chose que l'on observe.
00:28:33Et je pense que l'équipe Shopify en est parfaitement consciente.
00:28:36Mais on peut constater une grande variance dans ces délais de livraison.
00:28:41Il y aura, vous savez, peut-être une fois tous les deux mois ou quelque chose comme ça,
00:28:46un incident assez important concernant la latence.
00:28:49Et je pense que c'est quelque chose qu'on ne remarque généralement pas.
00:28:51C'est ça.
00:28:52Parce qu'évidemment, une panne est beaucoup plus facile à voir.
00:28:54Vous allez sur Datadog ou Better Stack.
00:28:57Vous rappelez-vous du nom du produit de métriques ?
00:29:01L'observabilité.
00:29:02L'observabilité, oui.
00:29:03Vous allez sur Better Stack, évidemment, pour construire ce genre de choses.
00:29:05Exact.
00:29:06Et vous regardez les appels HTTP vers le point de terminaison web et tout s'arrête net.
00:29:11Tout à fait.
00:29:11Le problème est assez évident, c'est simple.
00:29:14Mais si la latence grimpe à 60 secondes, c'est beaucoup plus difficile
00:29:19à détecter à partir de vos métriques réelles.
00:29:22Exact.
00:29:23C'est parce qu'il s'agit de la latence nécessaire au traitement, ce que vous devriez
00:29:27normalement tracer, etc.
00:29:28Mais c'est le délai côté fournisseur.
00:29:31Si votre code ou votre processus métier repose sur une hypothèse,
00:29:34que ces événements arrivent en temps réel, et qu'ils arrivent 60 secondes
00:29:39plus tard, cela peut introduire des tas de problèmes nuancés, des bugs et des suppositions
00:29:44erronées dans le code.
00:29:46Je pense donc que nous sommes peut-être dans une position unique pour
00:29:50fournir de bonnes données.
00:29:52Ainsi, vous pouvez savoir si le problème vient de vous ou de votre fournisseur.
00:29:55Exact.
00:29:56C'est ça qui pose problème.
00:29:57Je ne sais pas si je peux dire empiriquement si cela a augmenté ou diminué.
00:30:03Il y a les suspects habituels, etc.
00:30:06C'est facile de les pointer du doigt.
00:30:08Je ne sais pas si c'est un problème réellement distribué que nous voyons constamment.
00:30:13Je pense que c'est plutôt concentré chez certains fournisseurs.
00:30:16Et je pense que là où les gens se font avoir le plus, c'est sur les délais de livraison.
00:30:23Autre point : les gens supposent que la latence de livraison est plus faible qu'elle ne l'est en
00:30:27réalité chez la plupart des fournisseurs. On parle de quelques secondes dans la plupart des cas, ce qui,
00:30:31selon la perspective, peut être long ou non.
00:30:34Mais quand je montre ce graphique de latence, par exemple pour Shopify, à des développeurs Shopify,
00:30:40leur première réaction est : je ne m'y attendais pas.
00:30:43Exact.
00:30:43Il y a un décalage par rapport aux attentes.
00:30:46J'ai travaillé pour une grosse entreprise d'e-commerce et nous avions le même problème.
00:30:53La latence était mauvaise, mais tout le monde jouait la scène de Spider-Man, se pointant du doigt
00:30:58pour savoir qui est responsable.
00:30:59Parce qu'en général, il s'agit d'un fournisseur tiers, comme vous l'avez dit.
00:31:05Parfois, on ne peut rien y faire.
00:31:07Il faut simplement s'adapter.
00:31:08C'est cool.
00:31:09Il faut aussi faire attention à ne pas blâmer le fournisseur.
00:31:11Exact.
00:31:11C'est quelque chose qui, dans le contexte de ce que vous faites,
00:31:16est un problème courant.
00:31:18Lorsqu'il y a un incident, on se demande : quelle part de responsabilité attribuer au fournisseur ?
00:31:22Mais à un moment donné, il faut aussi savoir ce qui est raisonnable ou non.
00:31:27Et ce qui est un accident fortuit ou non.
00:31:29L'autre jour, Railway... Certains de nos déploiements de gestion de serveurs
00:31:34tournent sur Railway à cause de leur structure tarifaire.
00:31:36Comme nous devons utiliser la même version que l'open source, nous n'avons pas construit
00:31:40de système multi-tenant, ce qui ne serait pas pertinent en open source.
00:31:44Nous effectuons donc un déploiement réel pour chaque client.
00:31:48Exact.
00:31:49Pour les utilisateurs gratuits, nous déployons une instance sur Railway,
00:31:52ce qui fonctionne généralement très bien.
00:31:54Mais l'autre jour, leur compte GCP a été suspendu et ils ont été hors service pendant environ six
00:31:59heures.
00:31:59C'est ça.
00:31:59Donc, c'est comme : d'accord, pouvez-vous éviter d'en parler dans votre...
00:32:06C'est une chose que de rejeter la faute.
00:32:09Vous avez certainement une responsabilité envers vos fournisseurs.
00:32:11Mais la limite est parfois difficile à tracer.
00:32:14Je vois cette tendance naturelle des gens à vouloir pointer du doigt,
00:32:18car cela vous déresponsabilise.
00:32:20Il faut lutter contre cela.
00:32:23C'est ça.
00:32:24Mais quand on est certain que le problème vient du fournisseur,
00:32:28il est intéressant de pouvoir l'identifier et,
00:32:31vous savez, d'avoir des données réelles, ce qui est souvent le problème avec les fournisseurs.
00:32:35Exact.
00:32:35Vous ne voyez pas leurs données.
00:32:37Il est donc très difficile d'affirmer avec certitude ou preuves empiriques
00:32:42que c'est clairement eux.
00:32:43Vous devez le déduire de vos propres données, ce qui peut être juste ou faux.
00:32:46C'est ça.
00:32:47Je me demandais, en cas de panne chez Shopify ou Stripe,
00:32:51comment les événements rattrapent-ils le retard ? Cela impacte-t-il durement vos serveurs ?
00:32:57Oui, c'est essentiellement le problème de récupération.
00:33:00Et comme nous disons toujours, vous ne devriez pas assumer
00:33:05un volume spécifique de webhooks.
00:33:09Hmm.
00:33:09Nous avons cette caractéristique où chaque fournisseur impose un délai d'attente.
00:33:14Exact.
00:33:14Ils vous donnent trois secondes,
00:33:15cinq secondes, cela dépend de la plateforme.
00:33:18Cela signifie que vous ne pouvez pas effectuer de travail significatif,
00:33:21surtout si l'on prend en compte les latences réseau dans ce délai.
00:33:25C'est ça.
00:33:25C'est une des raisons pour lesquelles il faut mettre en file d'attente.
00:33:28Vous ne pouvez pas traiter ça de manière synchrone.
00:33:31J'ai perdu le fil de ma pensée.
00:33:33Pouvez-vous répéter votre question ?
00:33:39Je parlais des pannes chez Stripe et Shopify.
00:33:42Ah oui.
00:33:45Le rattrapage.
00:33:45Oui.
00:33:47Oui.
00:33:47Oui.
00:33:47Oui.
00:33:47Bref, tout ça pour dire : latence, bla bla bla... Il faut savoir auto-scaler.
00:33:52Vous devez pouvoir monter en charge.
00:33:53Il faut pouvoir scaler sur un court laps de temps.
00:33:56Ces pics peuvent avoir plusieurs raisons.
00:33:58Cela peut être naturel, suite à un import en masse effectué par votre client.
00:34:03Exact.
00:34:03C'est ça.
00:34:03Il y a d'autres raisons pour les pics.
00:34:05Mais les temps d'arrêt en font partie.
00:34:07Exact.
00:34:07Si Shopify est en panne pendant une demi-heure, dès leur rétablissement,
00:34:11ils vont traiter tout le backlog, surtout pour réduire la contre-pression sur leur file.
00:34:16C'est-à-dire traiter tout ce qui s'est accumulé.
00:34:17Ils vont scaler au-delà de leur capacité habituelle pour rattraper le retard.
00:34:22Ce qui se traduit par l'envoi massif de requêtes aux boutiques finales.
00:34:26Exact.
00:34:28Oui.
00:34:28Vous avez ces irrégularités, qui ne sont pas de votre fait.
00:34:32C'est causé à 100% par le fournisseur car il traverse ses propres défis d'infrastructure.
00:34:37Ce n'est pas vous.
00:34:38La capacité de Shopify à envoyer des webhooks est bien supérieure à la vôtre.
00:34:42C'est vrai.
00:34:44L'un de nos investisseurs était CPO chez Twilio.
00:34:49Je pense que c'est pour ça qu'il a investi.
00:34:52Oui.
00:34:52Il disait que Twilio faisait, en quelque sorte, des attaques DDoS sur ses propres clients.
00:34:56C'est inévitable dans ce genre d'événements pilotés par les fournisseurs.
00:34:59C'est un problème bien connu.
00:35:04Ils le savent, car on peut suivre la latence de réponse depuis les serveurs.
00:35:07Si vous DDoS votre client, la latence augmente.
00:35:14À un moment, les timeouts commencent.
00:35:17Le problème empire : il est plus dur d'avoir du débit avec des timeouts longs.
00:35:21Plus vous maintenez la connexion HTTP, moins vous pouvez faire de requêtes.
00:35:24Il faut scaler, et ça s'accumule.
00:35:26Tout s'empile, c'est ça ?
00:35:29C'est auto-renforçant.
00:35:31Moins vous avez de capacité, plus la latence se dégrade.
00:35:34À saturation du serveur, la latence devient catastrophique.
00:35:38Les requêtes continuent de s'empiler.
00:35:40Beaucoup de fournisseurs finissent par désactiver votre endpoint.
00:35:45Ils ne veulent pas maintenir des milliers de connexions.
00:35:46Dès qu'ils désactivent, vous perdez les données.
00:35:52Assurer un temps de réponse malgré ces variations est le vrai défi.
00:35:57Je voulais aussi demander : avec l'IA, comment cela change-t-il l'espace des webhooks ?
00:36:01Les LLM envoient plus de webhooks ?
00:36:04Comment utilisez-vous l'IA chez Hookdeck ?
00:36:07Quel est l'avenir de l'IA dans ce domaine ?
00:36:10Il se passe beaucoup de choses.
00:36:14Nous sommes un atelier de développement logiciel.
00:36:15Vous rencontrez les mêmes défis : flux de travail,
00:36:19changements fréquents, coûts des jetons...
00:36:21Oui, nous ne voulons pas de classement.
00:36:25Je crains l'idée d'un classement.
00:36:29C'est un moyen sûr de détruire vos marges.
00:36:37Quelques réflexions. Il y a une croissance des événements pilotés par les agents,
00:36:43car ils passent de déclencheurs humains à des déclencheurs événementiels.
00:36:48Tous ces produits d'agents cloud sont déclenchés par le temps ou des événements.
00:36:51Certains sont abstraits, mais il reste les PR GitHub,
00:36:54les commits, les commentaires... Tout cela est piloté par le web.
00:36:57Cela va bien au-delà : support client, Slack, données de capteurs réelles...
00:37:02Beaucoup d'agents devront déclencher des événements avec d'autres agents.
00:37:05La sortie d'un agent déclenchera potentiellement un autre agent.
00:37:10C'est un cas d'usage typique de Webhooks.
00:37:15J'ai très peur de cette idée de classement.
00:37:18Ça me semble être un moyen infaillible de détruire vos marges.
00:37:24Alors, j'ai quelques réflexions.
00:37:25Il faut repenser ces structures.
00:37:29Les agents deviennent le moteur principal.
00:37:35La fiabilité est le nouveau standard.
00:37:41Nous y travaillons.
00:37:42Chaque webhook compte désormais.
00:37:46C'est essentiel pour l'avenir.
00:37:49GitHub PR ou, vous savez, quand vous faites un commit ou un commentaire sur GitHub, tout ça est piloté par le Web.
00:37:56Mais évidemment, ça va s'étendre bien au-delà, comme le support client,
00:38:00Slack et tout le reste, et même probablement des événements en temps réel qui se produisent dans le monde réel
00:38:04à partir de données de capteurs, ce genre de choses, n'est-ce pas ?
00:38:08Je pense aussi que beaucoup d'agents devront déclencher des événements avec d'autres agents, en gros,
00:38:12le résultat d'un agent sera un événement, qui déclenchera potentiellement
00:38:17un autre agent, une autre entreprise, etc., ce qu'on pourrait, oui,
00:38:21décrire comme un cas d'usage WebHook, et c'est un peu le cas.
00:38:23Mais je pense aussi que certains concepts autour des WebHooks sont un peu bancals
00:38:28en termes de sécurité, de protocole, d'efficacité et autres.
00:38:33C'est pourquoi nous avons poussé l'utilisation de destinations d'événements comme modèle
00:38:36plus optimisé pour cela. L'autre chose aussi, c'est que si ce que vous exécutez
00:38:40en réponse à ces événements sont des workflows agentiques, qui sont non-déterministes, peuvent durer longtemps,
00:38:47cela rend beaucoup plus difficile l'ajustement de votre capacité et la mise à l'échelle
00:38:51en fonction des événements reçus. Je pense donc que la gestion du débit et de la capacité
00:38:55devient bien plus complexe. Vos taux d'échec seront plus élevés, simplement à cause
00:39:00des timeouts cloud, de vos tests qui échouent, etc.
00:39:07Donc, du point de vue de la construction d'applications, des primitives de base à utiliser,
00:39:12de leur exécution, de leur durée et de la gestion de la contre-pression,
00:39:16il y a beaucoup de nouveaux défis. En ce qui nous concerne en interne,
00:39:21je pense que nous essayons toujours de trouver la bonne méthode. Une partie de moi est juste
00:39:25complètement époustouflée par la capacité. Ce n'est pas une surprise, je ne pense pas apporter
00:39:29d'éclairage unique ici. La seule chose que je dirai, c'est que le fossé entre
00:39:34votre invite CLI ou votre codex et le fait de livrer un produit
00:39:41de haute qualité et élégant reste important. Une certaine nuance se perd dans les mèmes,
00:39:45et le reste. J'ai des doutes quant à la possibilité de consommer ce niveau de jetons
00:39:50pour produire quelque chose qui apporte une réelle valeur ajoutée au monde au final.
00:39:55D'après notre expérience, il y a évidemment beaucoup de choses autour de la sécurité,
00:40:01des facilitateurs massifs, des revues de code, etc. Mais je pense que ce sont là
00:40:06les bases, pas des éléments qui ajoutent réellement de la valeur,
00:40:11n'est-ce pas ? Quand il s'agit de construire quelque chose de vraiment
00:40:14précieux dont d'autres tirent de la valeur, je sens qu'il y a encore un fossé. Et j'ai l'impression que
00:40:19notre équipe reste responsable d'apporter ce niveau de goût, d'intuition et de compréhension
00:40:25du client, cette empathie, tout ce qu'on n'obtient pas directement d'une simple
00:40:31boîte de dialogue. Peut-être que nous sommes les imbéciles et que nous pourrions aller beaucoup plus vite
00:40:35si nous faisions tout en une seule fois. Mais pour l'instant, notre approche consiste à
00:40:42maintenir ces mêmes attentes en termes de résultat net et de ce que nous livrons à l'utilisateur final.
00:40:47Oui, évidemment, cela signifie que nous pouvons faire plus. Et je pense aussi que davantage de personnes
00:40:53ayant ce goût et cette empathie peuvent apporter de la valeur, car la barrière était le code,
00:40:57n'est-ce pas ? Par exemple, presque tout le monde dans l'entreprise, entre guillemets, code désormais,
00:41:01n'est-ce pas ? Notre designer est le codeur Vipe résident. Maintenant, il est entièrement responsable du
00:41:06site web, et il y a aussi beaucoup de travail sur les tableaux de bord,
00:41:11ou pour le marketing produit ou les relations développeurs, pas besoin de maximiser les jetons, mais s'il y avait un classement,
00:41:16ils seraient probablement en haut. C'est une très bonne chose. Ce sont des facilitateurs
00:41:20car ces personnes doivent avoir cet esprit critique, pour pouvoir livrer des choses
00:41:25élégantes pour l'utilisateur final, et la barrière est davantage le code.
00:41:30Donc, d'une certaine manière, je pense que le plus grand avantage vient de là plutôt que
00:41:36de l'ingénierie pure. Encore une fois, sans dire que l'ingénierie pure n'en tire pas
00:41:40un grand avantage, mais je pense que le goulot d'étranglement reste ce goût. De plus, je passe
00:41:45tellement de temps à examiner des PR inutiles. Il y a donc un inconvénient aussi.
00:41:51C'est sûr. Et la quantité de code que vous devez examiner.
00:41:56Oui, et cette vulnérabilité obscure qui n'a quasiment aucune chance d'exister.
00:42:01Et je ne suis même pas sûr que cela puisse être qualifié de bas niveau. Mais une fois qu'elle est apparue,
00:42:06vous vous sentez responsable. Je pense que c'est normal. Mais
00:42:09à un moment donné, nous n'avons jamais eu autant de PR ouvertes.
00:42:14Ça devient un peu fou de tout gérer. Et je pense qu'apporter
00:42:18le jugement nécessaire, comme quoi ce n'est pas parce que vous pouvez tout faire
00:42:21que vous devez tout faire, est essentiel. Cela accompagne beaucoup cette attitude
00:42:26propre aux LLM. Je pense qu'apporter du jugement sur ce qui finira par
00:42:31générer de la valeur est plus important que jamais. Parce qu'il y a
00:42:34cette satisfaction de la liste de tâches à cocher en travaillant avec des agents.
00:42:39Vous savez, de temps en temps, je suis un peu en mode pilote automatique. Je veux juste
00:42:44parcourir ma liste, faire, cocher, cocher, cocher, cocher.
00:42:48Il y a quelque chose avec les LLM où je lance cette conversation, cette conversation, cette conversation,
00:42:53peut-être cinq ou six agents en action, et ils font tous des choses,
00:42:57et ils ont tous des listes de contrôle qu'ils cochent aussi. Exactement, oui.
00:43:02Il y a donc quelque chose à propos de la satisfaction et de la récompense rapide
00:43:06qui nous gagne parfois. Ou du moins, en parlant pour moi. Quelle est la taille de l'équipe Hook ?
00:43:11On est 10 en ce moment. Oh, super. C'est très léger. Kudos. Ça a toujours été une ambition.
00:43:15Je ne me considère pas comme le meilleur manager, donc je pense que c'est mieux pour tout le monde comme ça.
00:43:23Je blague à moitié, mais je pense que nous sommes nés au milieu du COVID,
00:43:29n'est-ce pas ? Tout le monde est en télétravail. Et il y avait cette mentalité
00:43:33dès le début d'embaucher des personnes seniors expérimentées, extrêmement autonomes,
00:43:38pour donner une idée, on fait vraiment un seul appel toutes les deux semaines,
00:43:45pour discuter du produit et de l'infrastructure. Nous avons essayé d'avoir ce flux de travail asynchrone.
00:43:50Je pense que cela se prête bien aux cas d'usage de l'IA aussi. Car nous avons déjà embauché des gens
00:43:56qui privilégient cette autonomie. Je ne pense pas qu'il y ait de bonne ou de mauvaise façon,
00:44:01je ne vais pas prêcher, mais je pense que ça fonctionne pour nous.
00:44:06Rien ne fonctionne pour moi et ma santé mentale, donc voilà.
00:44:11Je voulais aborder ce que vous avez dit au début de la conversation, que
00:44:14les webhooks sont morts, la nouvelle voie est la passerelle d'événements. Avez-vous inventé ce terme ou existait-il déjà ?
00:44:21Qu'est-ce qu'une passerelle d'événements ? Je n'en ai aucune idée.
00:44:27Oui, nous l'avons inventé, et il a été difficile de construire un produit dans une catégorie
00:44:32non établie. À cause des défis de marketing, de communication, et de la façon même de
00:44:37décrire cette chose. Pendant un moment, nous l'appelions infrastructure de gestion des webhooks.
00:44:41Rien qui ne soit facile à dire. Donc, vous avez le défi de la communication,
00:44:46mais aussi le défi du produit. Quand vous construisez dans une catégorie existante,
00:44:51comme l'observabilité, vous savez ce que vous essayez d'optimiser, vos propositions de valeur,
00:44:54comme le prix ou l'expérience développeur. Mais la sémantique de base existe.
00:44:58Vous optimisez pour cette position de valeur unique. Quand vous construisez quelque chose
00:45:02qui n'existe pas vraiment, vous devez inventer la sémantique et ensuite
00:45:07construire une proposition de valeur convaincante. Donc ça devient très difficile.
00:45:10C'est un apprentissage de ces dernières années : difficile de construire un produit dans une catégorie inexistante.
00:45:14L'idée avec la passerelle d'événements était d'essayer de capturer le mieux possible,
00:45:19en deux ou trois mots, ce qu'elle fait. Notre objectif était de faire le pont entre
00:45:24le bus d'événements et les passerelles API. Capter cette notion que les passerelles sont là
00:45:28comme interface entre un fournisseur et votre propre système. Et le bus d'événements,
00:45:32dans le sens d'une gestion d'événements complète, de mise en file d'attente, etc.
00:45:37Nous essayons de trouver un terme qui marie les deux. Et quand vous pensez
00:45:43à EventBridge, ce n'est pas très loin de la passerelle d'événements. Nous voulons que les gens
00:45:49nous perçoivent comme une alternative claire. L'idée autour de la passerelle d'événements
00:45:55était aussi de dire : il existe des produits, mais pas de terminologie commune.
00:46:00Ils ne l'appellent pas ouvertement passerelle d'événements, mais nous donnerons cette étiquette.
00:46:04Il y a des produits concurrents, les nôtres, AWS, Azure, Kong est une passerelle d'événements.
00:46:10Gravity, beaucoup de fournisseurs de passerelles API entrent dans l'architecture événementielle.
00:46:14Il y a probablement une demi-douzaine de produits qui s'appelleraient ainsi.
00:46:19Je peux vous dire que quand Kong a sorti sa passerelle d'événements, j'ai dit : Oh,
00:46:24merde, deux ans après nous. Mais ce qui est gratifiant, c'est quand les clients
00:46:29ou développeurs viennent me voir et disent : je cherche une passerelle d'événements.
00:46:33C'est là qu'on se dit que le terme commence à avoir un modèle mental.
00:46:39Ils commencent à chercher explicitement pour ça, ou disent : nous essayons de remplacer notre propre passerelle.
00:46:45La première année, ça n'arrivait jamais. Maintenant, c'est un terme que je vois utilisé de plus en plus.
00:46:49C'est une bonne chose pour nous, et pour créer des attentes autour de cette primitive d'infrastructure cloud.
00:46:54J'espère qu'à un moment donné, les choses commenceront à s'aligner sur la sémantique.
00:46:58Si vous utilisez AWS EventBridge, la terminologie n'a rien à voir. Je ne veux pas
00:47:03concevoir mon produit autour d'AWS EventBridge, donc je ne vais pas réutiliser leur terminologie.
00:47:08Mais au fil du temps, avec plus de gens qui construisent, il y aura probablement une convergence.
00:47:12Si je demandais une passerelle d'événements à un LLM, est-ce qu'il vous recommanderait ?
00:47:16Oh oui. Essayez maintenant. Je pense que les chances sont bonnes.
00:47:20Je pourrais essayer en direct. C'est quelque chose qu'on suit.
00:47:23Nous sommes cités dans environ 60% de toutes les invites autour des WebHooks ou passerelles d'événements.
00:47:28C'est cool. C'est quelque chose sur lequel nous avons passé beaucoup de temps.
00:47:34Notre travail est assez bon. C'était le premier de la liste.
00:47:38Oh, sympa. Voilà. ChatGPT vient de me le donner. Très bien.
00:47:43Bien que sur la passerelle d'événements, je pense que nous ferions aussi bien sur toute requête liée aux WebHooks.
00:47:48Mais passerelle d'événements joue en notre faveur, comme nous avons inventé le terme.
00:47:52Je serais fou si nous n'étions pas les premiers. Je réalise que je ne sais pas vraiment ce que signifie
00:47:57l'architecture événementielle. En quoi diffère-t-elle d'une architecture régulière ?
00:48:01Si je mets une file d'attente Kafka dans mon système, suis-je automatiquement en architecture événementielle ?
00:48:05Oui et non. Je pense qu'une architecture événementielle est plus un ensemble de paradigmes
00:48:09et d'attentes. Une partie, ce sont les outils, Kafka, les files de messages
00:48:12ou le streaming d'événements pour découpler les systèmes.
00:48:15L'idée est d'avoir des producteurs
00:48:15et des consommateurs qui n'ont pas besoin de se connaître. Le consommateur peut consommer
00:48:20à partir d'un flux d'événements produits par n'importe qui.
00:48:24La seule attente est un contrat
00:48:25autour de l'événement lui-même : quel est le payload, quelle est la forme ?
00:48:27Souvent, il y a des schémas, Avro,
00:48:27Protobuf, etc., avec des attentes standardisées. Le contrat porte sur l'existence
00:48:31de ces événements. Et comme consommateur, ma responsabilité est de faire ce que je dois faire
00:48:35avec une création de commande ou une mise à jour de produit. Une organisation qui a vraiment adopté l'EDA
00:48:42aura un modèle systématisé avec des directives spécifiques sur la façon de faire et les formes de payload.
00:48:46C'est une approche architecturale où vous découplez intentionnellement
00:48:48Oh, sympa.
00:48:49Voilà.
00:48:49C'est ce que ChatGPT vient de me donner. Donc bien joué.
00:48:52Je ne pense pas que ce soit 100%. Au fil du temps, avec la croissance et la complexité,
00:48:56et davantage de dépendances tierces, c'est la façon naturelle dont les choses tendent à évoluer.
00:49:00Il devient très difficile de maintenir tous les systèmes couplés.
00:49:03Il faut penser à la mise à l'échelle et aux interdépendances.
00:49:05En architecture événementielle, les gens pensent, à juste titre, aux grandes entreprises.
00:49:11C'était concentré là-bas pendant la première décennie, mais ça change grâce à une meilleure aisance avec les modèles,
00:49:17aux WebHooks qui servent de produit d'appel, et à de meilleurs outils.
00:49:21Je pense à RabbitMQ, ou BullMQ basé sur Redis, des bibliothèques populaires en Python,
00:49:25Celery, Sidekiq en Ruby, ou Foundation. Il y a une amélioration progressive
00:49:31des outils qui rend cela moins intimidant, sans nécessiter une équipe d'architecture immense.
00:49:35Je pense aussi que le terme a un peu perdu de son sens. Certains ne seront pas contents,
00:49:39mais le sens s'est obscurci au fil du temps. Quand je le dis, je fais référence
00:49:43principalement au découplage des systèmes et aux préoccupations de programmation
00:49:47d'indépendance et d'ordonnancement. Une fois dans l'architecture événementielle,
00:49:53vous faites face à des préoccupations que vous n'aviez pas avant.
00:49:57Il faut apprendre à adapter la façon dont vous construisez les choses.
00:50:02Nous essayons d'apporter cela à tout le monde. Nous ne sommes pas les seuls,
00:50:06il y a des moteurs de workflow comme Temporal ou trigger.dev.
00:50:11C'est un espace où il se passe beaucoup de choses. Il n'y a peut-être plus de définition fixe.
00:50:16Pour ceux qui s'intéressent aux paradigmes, il y a David Boyan,
00:50:21ancien développeur chez AWS ayant travaillé sur EventBridge, avec ses explications sous forme de dessins.
00:50:25Il a probablement une série de contenus.
00:50:29Il a probablement de très bons exemples.
00:50:32Exactement.
00:50:36C'est une ressource fantastique.
00:50:41Je vais regarder ça.
00:50:45mais ce n'est pas le cas, n'est-ce pas ? L'objectif est-il donc d'être à 100 % piloté par les événements ?
00:50:50Ou s'agit-il simplement d'un sous-ensemble de paradigme architectural ?
00:50:54Je ne pense pas que ce soit 100 %. Je pense simplement qu'avec le temps, à mesure que l'on grandit et que la complexité augmente,
00:51:00et qu'il y a plus de dépendances tierces, etc., c'est une sorte d'évolution naturelle des choses.
00:51:04Parce qu'à un moment donné, il devient très difficile de maintenir tous ces systèmes couplés.
00:51:09Et ensuite, il faut réfléchir à la mise à l'échelle, aux interdépendances et à toutes ces choses
00:51:14d'une manière qui rend la tâche assez ardue. Mais de manière générale, quand on pense à l'architecture
00:51:19pilotée par les événements, au sens strict du terme, je pense que les gens pensent,
00:51:23et à juste titre, aux grandes entreprises. Et je pense que pendant probablement la première
00:51:28décennie de l'architecture pilotée par les événements, c'était surtout concentré dans les grandes entreprises. Mais je pense que maintenant
00:51:32cela change, en partie parce que les gens sont plus à l'aise avec ces modèles, et en partie parce que
00:51:37les webhooks sont une porte d'entrée. Mais aussi grâce à l'amélioration des outils. Je pense,
00:51:41par exemple, à RabbitMQ, ou à Bull MQ, qui est construit sur
00:51:46Redis. Il existe également tout un tas de bibliothèques populaires ; en Python, il y a
00:51:51Celery, et en Ruby, Sidekiq. Je crois qu'il y en a une autre maintenant, Foundation, qui vient aussi de
00:51:57l'équipe de Sidekiq. Bref, il y a eu une sorte de progression dans les outils autour
00:52:01de cela, ce qui rend la chose plus facile et moins intimidante, sans forcément
00:52:05avoir besoin d'une grosse équipe d'architecture et de gros déploiements Kafka qui coûtent
00:52:11très cher pour commencer à faire de l'architecture pilotée par les événements. Mais je pense aussi que le terme
00:52:15a un peu perdu de son sens. Je suis sûr que certains ne seront pas ravis que je dise cela. Mais
00:52:19je pense vraiment qu'il a perdu un peu de son sens avec le temps, ou du moins que les choses sont devenues plus floues.
00:52:25Et je pense que quand je l'utilise, je fais principalement référence à ce découplage des systèmes. Et ensuite,
00:52:31aux préoccupations de programmation que vous aurez en tant qu'ingénieur, comme le fait de devoir
00:52:37penser à l'indépendance, à l'ordre et à tous ces types de problèmes. Donc, quand
00:52:43je parle d'architecture pilotée par les événements, c'est plutôt pour dire que vous entrez dans un monde où,
00:52:48lorsque vous construisez votre application, vous devrez faire face à ces préoccupations que vous n'aviez pas avant.
00:52:52Exact. Compris. Et le fait d'être capable d'apprendre et d'adopter des méthodes de construction pour
00:52:58pouvoir répondre à ces préoccupations. Je ne sais pas si je pense initialement à la manière des
00:53:03à la manière des grandes entreprises. Et je pense qu'en un sens, ce que nous essayons de faire, c'est,
00:53:08vous savez, d'apporter cela à tout le monde d'une certaine manière. Exact. Et nous ne sommes pas
00:53:14les seuls à le faire. Il y a tout un tas d'autres personnes qui adoptent des approches différentes.
00:53:18Il y a tous ces moteurs de flux de travail et ces step functions qui, à mon avis, chevauchent
00:53:22ce que font Temporal, Ingest, Trigger.dev et ces gens-là aussi. Donc, je pense vraiment que c'est un
00:53:28espace très dynamique. Et il n'y a peut-être plus vraiment de définition fixe et bien arrêtée
00:53:34pour cela. Pour ceux qui sont vraiment intéressés par le fait d'en apprendre davantage
00:53:38sur l'architecture orientée événements et les paradigmes associés, il y a ce gars
00:53:42appelé David Boyan, qui était auparavant développeur chez AWS et qui travaillait en fait sur Event
00:53:49Bridge. Il y a ces séries de schémas explicatifs. Mais à ce stade, il en a probablement
00:53:55plusieurs centaines. Il gère aussi un projet open source maintenant appelé Event Catalog, qui pourrait être un
00:54:02bon invité de podcast pour vous. Mais tout ça pour dire que ça va dans une profondeur qui
00:54:07est presque déraisonnable. Donc, je recommande vivement cela pour ceux qui sont
00:54:14curieux. Super. On l'ajoutera aux notes de l'émission. Oui, toute votre connaissance des événements et des web
00:54:19hooks et tout ça. Est-ce que tout cela vient juste de la création de Hookdeck ?
00:54:23Ou était-ce, vous avez dit plus tôt que vous aviez eu quelques problèmes avec les webhooks, mais était-ce à ce moment-là que vous
00:54:27avez vraiment plongé dans les événements ? Tout à fait. Et je pense que cet apprentissage est venu principalement
00:54:34des problèmes, mais aussi des principes fondamentaux, dans le sens où, quand j'étais confronté à ces
00:54:38problèmes, je n'avais pas vraiment beaucoup de connaissances à ce sujet, ce qui explique en partie pourquoi j'étais aux prises
00:54:42avec ces problèmes. Oui. Donc je pense que cela est venu vraiment de la volonté de résoudre
00:54:47le problème et ses solutions, plutôt que de chercher des solutions pour les adapter au problème.
00:54:51Bien sûr. Mais au bout du compte, à ce stade,
00:54:55nous avons travaillé avec des centaines de milliers de webhooks, vous savez, de tout type.
00:54:59Et je pense que j'ai tout absorbé lors de ces conversations. Et oui, c'est fondamentalement
00:55:05très intéressant. J'ai commencé comme concepteur de produits à l'origine. Donc, tour à tour,
00:55:11vous savez, concepteur de produits, développeur full stack, puis ingénieur backend,
00:55:15puis ingénieur infrastructure. Et maintenant, je suis vraiment très, très profondément dans le
00:55:21terrier du lapin. Mais cela est venu simplement en travaillant avec les clients, en écoutant
00:55:26leurs préoccupations, en examinant l'architecture et tout ce genre de choses. Mais aussi grâce à l'équipe,
00:55:30n'est-ce pas ? Nous avons aussi des personnes dans l'équipe qui ont énormément d'expérience avec
00:55:33ces systèmes et qui ont aussi apporté cette connaissance à l'entreprise. Oui. Quand avez-vous
00:55:38réalisé que vous aviez trouvé un marché pour cela ? J'imagine que vous avez commencé à travailler dessus, puis
00:55:42l'avez publié quelque part. Et l'accueil a-t-il été bon presque immédiatement ? Ou a-t-il été très
00:55:47long de faire comprendre aux gens que c'était la meilleure option ? C'est un long, très long processus,
00:55:53dans le sens où cela a commencé avec l'article Medium dont je parlais, n'est-ce pas ? Une sorte de “web
00:55:57hooks et ce que vous pouvez y faire”. Je suis très axé sur le fait de “créer des produits
00:56:01pour les gens”. Donc la toute première version était une sorte de self-service, vous pouviez
00:56:07y aller, créer votre première connexion, comme nous l'appelions, et tout ce genre de choses.
00:56:12Et, j'ai publié cet article et tout. Il n'y avait aucune ambition d'en faire une entreprise
00:56:16ou quoi que ce soit. C'était juste un de mes 20 autres projets parallèles ratés, n'est-ce pas ? Sur lesquels je travaillais
00:56:21à l'époque. Et, je veux dire, rétrospectivement, maintenant, les
00:56:26chiffres semblent ridiculement petits, car il y a peut-être eu cinq personnes qui m'ont contacté
00:56:32suite à cet article ou quelque chose comme ça. Mais je sais que pour tous ceux qui ont travaillé sur des projets parallèles,
00:56:37et qui ont essayé de convaincre quelqu'un d'utiliser ce que vous avez construit, et ainsi de suite,
00:56:42cinq personnes, c'est putain d'incroyable. C'est mieux que tout ce que j'avais probablement jamais obtenu
00:56:48avant. Donc, j'étais super excité par ça. J'étais en fait dans mon
00:56:55camping-car, en Colombie-Britannique, en train de faire de l'escalade. Et j'étais vraiment loin d'essayer de monter
00:57:00une startup ou quoi que ce soit. Je discutais simplement avec ces personnes, en les aidant,
00:57:05à travers leurs réflexions et les problèmes qu'ils rencontraient et ce genre de
00:57:08choses. Et puis, ça a continué d'arriver, peut-être un par semaine, alors que je faisais de l'escalade.
00:57:13Et j'ouvrais Slack et je voyais les notifications. Nous avons ce canal de notification
00:57:18pour toutes les nouvelles inscriptions, n'est-ce pas ? Le même que nous avons depuis six ans ou quelque chose comme ça.
00:57:21À ce stade, c'est assez difficile de suivre, car ça défile
00:57:25très vite. Mais j'avais cette notification dans ce canal. Je me disais, oh merde, quelqu'un s'est inscrit.
00:57:31Vous êtes en train de DDOSer Slack ?
00:57:38Non, certainement pas à l'époque. Mais maintenant, vous avez dit que vous l'aviez toujours, donc c'est pour ça
00:57:44que je demande. Oui, oui. Eh bien, je veux dire, les choses vont bien, mais je ne pense pas que ce soit
00:57:48au point de DDOSer Slack. D'accord. Bref, les gars, désolé pour la digression, mais je pense qu'une hypothèse fondamentale
00:57:54au début était problématique, c'était cette idée que c'était principalement construit pour
00:57:58l'observabilité. Je pense que ce n'était pas assez poussé. Mais une fois que vous passez de “je construis un
00:58:02outil d'observabilité” à “je réinvente un bus de messages”, soudainement, la portée
00:58:08explose de façon spectaculaire. Donc, j'ai en fait rencontré mon CTO et co-fondateur au milieu de
00:58:15la construction du premier moteur de file d'attente. Et quand j'ai réalisé que
00:58:19la portée allait totalement exploser, c'est là que
00:58:23nous avons aussi cherché un petit tour de pré-amorçage auprès d'investisseurs providentiels.
00:58:28C'était assez évident que ça allait être assez coûteux à construire, et effectivement, ça l'était.
00:58:32Et si je comprends bien, vous n'avez pas suivi la voie typique de la Silicon Valley. Vous l'avez construit à Montréal, n'est-ce pas ?
00:58:36Euh, oui, c'est peut-être un peu trompeur par rapport à ce qui s'est réellement passé.
00:58:39Nous avons fait un pré-amorçage d'environ 400 000 $ avec seulement des investisseurs providentiels,
00:58:44aucun VC institutionnel. Mais quelques mois plus tard, nous sommes passés sur Hacker News,
00:58:51et c'est vraiment là que nous avons su, pour revenir à votre question, James, que
00:58:56la réponse suite à Hacker News n'était pas
00:59:00le plus gros “Show HN” de l'histoire, mais c'était bien meilleur que ce à quoi nous nous attendions.
00:59:05Petite anecdote : je me souviens de ce type qui a acheté un forfait à 300 $ après HN.
00:59:11Mon co-fondateur et moi, on s'est dit : “Mec, on a réussi”.
00:59:18C'est dans la poche. On va y arriver, c'est sûr.
00:59:22On est sortis dîner ce soir-là et on a tout dépensé.
00:59:25Oui, c'est exactement ça. La bouteille de champagne, ouais. Mais, euh, bref.
00:59:31Donc après ce Show HN, on a eu beaucoup d'intérêt
00:59:34de la part d'investisseurs nous contactant de manière proactive. Et nous avons
00:59:38fini par lever un tour auprès d'investisseurs de la Silicon Valley, une firme appelée Matrix Partners.
00:59:44Nous sommes donc toujours basés ici, une équipe centralisée, une entreprise canadienne. Nous n'avons pas
00:59:50changé pour une LLC du Delaware. Mais en même temps, nos investisseurs ont été
00:59:55formidables et je suis très heureux que nous l'ayons fait. Et je pense qu'à cause du COVID et
01:00:00ainsi de suite, il y a peut-être une acceptation croissante du fait que les entreprises ne sont pas obligées
01:00:04d'être basées là-bas pour construire des équipes à distance. Je veux dire, beaucoup de gens
01:00:08le font déjà, nous n'avons rien inventé. Il y a Zapier et
01:00:12GitLab, ils font ça depuis bien plus longtemps que n'importe qui d'autre.
01:00:17Donc je pense que cela l'a peut-être normalisé. Et c'est quelque chose que j'ai vu,
01:00:21peut-être que je suis naïf, mais c'est quelque chose que j'ai vu chez certains fondateurs.
01:00:27Vous savez, en tant que fondateurs canadiens, cette obsession sur Twitter concernant le fait
01:00:32de s'incorporer dans le Delaware. YC avait arrêté d'accepter les entreprises canadiennes, puis
01:00:38ils ont fini par revenir sur cette décision. Mais il y avait cette compréhension
01:00:42selon laquelle chaque investisseur va vous demander de devenir une LLC du Delaware. Et ils ont raison.
01:00:47Chaque investisseur va vous le demander. Ce qui manque dans cette histoire, c'est que vous pouvez juste dire non.
01:00:54Donc oui, bien sûr, ils vont demander “pourquoi pas ?” Et c'est plus facile pour eux,
01:00:58mais il s'avère que si vous dites simplement non, c'est aussi tout à fait acceptable. Au moins dans mon expérience et
01:01:03pour beaucoup de gens autour de moi. Donc je pense que c'est la partie manquante
01:01:07de cette histoire. Au bout du compte, leur travail est de déployer
01:01:11des capitaux. Ils cherchent des personnes dans lesquelles investir ou des idées originales.
01:01:15Je ne veux pas débattre des avantages et des inconvénients d'être là-bas. Je suis sûr qu'il y a
01:01:19beaucoup de positif, mais au bout du compte, c'est votre choix en tant que
01:01:24fondateur et bâtisseur, avec qui vous allez le faire et où vous allez le faire.
01:01:27Et je pense que si vous avez de bonnes idées et que vous travaillez dur derrière,
01:01:31les investisseurs respecteront cela, ou du moins, certains investisseurs le feront. Donc peut-être que votre
01:01:36travail est de les trouver. Mais il serait trompeur de dire que nous sommes complètement
01:01:41en dehors de cette bulle, mais personnellement, je suis assez content d'être toujours à Montréal.
01:01:47En tant que compatriote canadien, c'est agréable d'entendre des histoires de réussite canadiennes. Bravo pour ça.
01:01:52Mais ensuite vous avez déménagé à Toronto et vous avez juste tout foutu en l'air.
01:01:57Juste. Juste. Puis-je dire qu'en tant que compatriote du Commonwealth, c'est génial, non ? Même roi.
01:02:06C'est la même chose, vous voyez ? Oui, nous avons la reine. Enfin,
01:02:11je ne sais pas s'ils ont mis à jour vers le roi maintenant, mais nous avions la reine sur nos billets.
01:02:14Hookdeck était-il votre première startup en tant que fondateur ou y en a-t-il eu d'autres qui vous ont donné
01:02:19les outils pour savoir comment approcher les investisseurs et les trouver ? J'ai toujours été
01:02:23très entrepreneur depuis le début, dans de petites entreprises, comme
01:02:27réparer des ordinateurs à 14 ou 15 ans. Donc, dans ce sens, je parle de l'esprit d'entreprise,
01:02:34mais non, je pense que la plupart étaient des projets parallèles ratés,
01:02:38comme sortir un jeu vidéo qui n'est jamais allé nulle part.
01:02:44Ou travailler sur un réseau social, alors que je suis probablement le pire gars pour
01:02:48les rassemblements sociaux et l'organisation de choses avec des amis. Bref, j'ai traversé
01:02:53les étapes. Je dirai cependant que cette expérience dans l'entreprise de commerce électronique a été assez formative,
01:02:58dans le sens où j'ai rejoint l'entreprise en tant que premier employé et j'étais très impliqué
01:03:03avec l'équipe fondatrice. Et nous sommes passés de quatre personnes à environ 40
01:03:07en trois ans. Et tous les mouvements pour construire cette entreprise...
01:03:13C'est donc comme ça.
01:03:19Je pense à Hookdeck comme la première, mais il serait trompeur
01:03:23de le présenter uniquement comme ça. Il y a eu une exposition à ces choses avant.
01:03:27Et évidemment, j'avais cette entreprise de commerce électronique. Nous travaillions avec des investisseurs,
01:03:31le conseil d'administration, et nous avons construit des relations.
01:03:36Et le premier investisseur dans cette entreprise de commerce électronique
01:03:39a également été notre premier investisseur dans Hookdeck.
01:03:44Ce n'était donc pas un départ de zéro, mais oui,
01:03:48je ne m'attendais pas à être ici il y a quelques années. Et c'est génial.
01:03:54J'ai vu qu'il y avait une entreprise appelée Kiwi Mornings, une startup de petit-déjeuner sain. C'était quoi ?
01:04:02C'était une de mes entreprises ratées en cours de route.
01:04:09Je l'ai commencée avec ma femme. L'histoire veut que ma femme apportait
01:04:14son petit-déjeuner au travail, et tous les commerciaux étaient jaloux,
01:04:19alors ils ont commencé à lui en demander aussi. Je me suis dit : “Qu'est-ce que tu veux dire ?
01:04:24Qu'est-ce qui ne va pas chez eux ?” Mais ensuite, une chose en entraînant une autre, elle préparait cinq
01:04:30ou six petits-déjeuners chaque matin. Et on s'est dit : “Pourquoi ne pas en faire une entreprise ?”
01:04:36C'est l'une de ces idées stupides, n'est-ce pas ? Pourquoi ne pas en faire un business ?
01:04:41Nous avons donc construit ce service pour des petits-déjeuners zéro déchet au travail.
01:04:47On livrait des yaourts, des smoothies, des puddings de chia, ce genre de choses dans de petits bocaux en verre.
01:04:51On avait un petit réfrigérateur dans les bureaux. Et moi, étant moi-même,
01:04:56j'ai poussé ça trop loin. Du côté technique, toutes les commandes passaient par un
01:05:01bot Slack. Les employeurs pouvaient l'offrir comme avantage social, en payant 50% du petit-déjeuner.
01:05:06C'était tout un système.
01:05:11Donc les gens commandaient via le bot Slack, et tout ça.
01:05:16Ça s'est terminé car dans ce business, tout va mal à quatre heures du matin,
01:05:20et il n'y a pas d'argent dans la nourriture. C'est donc très difficile
01:05:25de bâtir une entreprise épanouissante. Donc à un moment donné, nous avons vendu le
01:05:29bot Slack et tout ça et avons arrêté.
01:05:34C'était en janvier 2021. Soit deux mois avant le COVID. Et pratiquement toutes les
01:05:42entreprises similaires, faisant des déjeuners de bureau,
01:05:46ont fait faillite. Donc nous avons eu un peu de chance sur le timing,
01:05:52car ça se serait terminé de toute façon.
01:05:57En tout, on a dû vendre environ 20 000 petits-déjeuners.
01:06:01Pas mal. Ouais, c'est assez cool.
01:06:06On aime toujours demander à nos invités leurs opinions tranchées sur l'industrie, l'IA, ou autre, allez-y.
01:06:12Je crois que j'en ai déjà donné quelques-unes dans cette conversation.
01:06:18Je pense que oui. Quelle est votre opinion la plus brûlante ?
01:06:22Une opinion brûlante. OK, là je vais probablement vous perdre parce que c'est très technique.
01:06:29Je suis sûr que certains de nos auditeurs comprendront ce que vous dites.
01:06:35Parfait. Alors, mon opinion brûlante est que les systèmes de file d'attente basés sur le “pull”
01:06:42sont stupides comparés aux systèmes basés sur le “push”. Et la raison pour laquelle nous n'avons pas adopté
01:06:49les systèmes “push”, c'est parce qu'aucune file d'attente n'a construit un bon système basé sur le “push”.
01:06:56Et la raison, je vais essayer d'ajouter un peu de contexte, c'est que lorsque vous construisez des files d'attente
01:07:02et des consommateurs pour chaque file, vous avez besoin d'un consommateur pour chacune.
01:07:07Ce consommateur peut être une sorte de worker longue durée qui extrait les messages.
01:07:12Mais le problème, c'est que si vous voulez avoir des files d'attente dynamiques, disons
01:07:16une file d'attente par client, car vous ne voulez pas qu'un seul client bloque toute la file
01:07:21ou consomme toute leur capacité, alors vous avez besoin d'autant de consommateurs que de files,
01:07:26ce qui devient insensé avec ce problème de multiplexage.
01:07:31Le gros avantage des systèmes “push”, c'est que toutes ces files peuvent pousser vers le même
01:07:36consommateur. Ce consommateur peut être une API avec un équilibreur de charge devant, que vous pouvez
01:07:41mettre à l'échelle horizontalement ou verticalement.
01:07:45L'essentiel est que cela est découplé du nombre de files d'attente.
01:07:49Je pense que ce que nous voyons, c'est que plus vous avez des cas d'utilisation complexes,
01:07:54plus vous voulez de manières granulaires de mettre les choses en file d'attente. Par sujet, par conditions,
01:07:58par client, etc. Cela devient insensé parce que vous avez 100 files, 100 consommateurs,
01:08:02100 files d'attente de dead-letter, tout ce bazar.
01:08:07Il est très difficile aujourd'hui de trouver des files d'attente de messages basées sur le “push”.
01:08:13C'est parce que vous déplacez le contrôle du débit. Si le débit est contrôlé
01:08:17dans le consommateur, chaque consommateur est responsable de dire, hé, je veux
01:08:2250 messages par seconde. Le nombre de messages consommés devient:
01:08:29Quelle est la capacité d'un worker ? Combien en avez-vous ? Quelle est la capacité réelle ?
01:08:33Ce n'est pas parce que vous demandez 50 par seconde que vous les atteignez,
01:08:37car cela dépend du reste du code et de sa performance.
01:08:40La raison pour laquelle nous n'avons pas adopté les files “push”, c'est que la plupart ne donnent pas
01:08:45la granularité nécessaire pour contrôler le débit. Par exemple,
01:08:50GCP Pub/Sub a un mode “push”, mais il augmente le débit
01:08:55auquel il envoie les requêtes jusqu'à ce que votre API ralentisse, ce qui dégrade le service.
01:09:00Et une fois que ça ralentit, ils réduisent le débit de livraison. Donc,
01:09:06ça grimpe, ça grimpe, le serveur crash ou a une dégradation de performance,
01:09:11ça revient à zéro, puis ça remonte, ça remonte, et ça revient
01:09:15à zéro. C'est complètement inefficace. Ça n'a aucun sens. Si vous construisez
01:09:20des files basées sur le push, avec un contrôle très précis sur le débit,
01:09:24cela simplifie énormément votre architecture. C'est mon opinion tranchée pour ceux qui savent,
01:09:29et je suis prêt à mourir pour ça.
01:09:34Je n'ai pas tout compris, mais ça semblait raisonnable, vous savez ?
01:09:40Si vous avez compris, allez voir Hookdeck. Exactement.
01:09:46Apprécié, oui. Eh bien, merci Alex. Merci d'avoir écouté cet épisode du
01:09:50Better Stack Podcast. Retrouvez-nous partout où vous obtenez vos podcasts, Spotify, Apple Music, ou ailleurs.
01:09:57Mais aujourd'hui, c'est un au revoir de ma part. Un au revoir de ma part. Et un au revoir de ma part.