Event-Driven Architektur, Webhook-Chaos und der Aufstieg von KI-Agenten | Better Stack Podcast Ep. 17

Deutschالعربية English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

컴퓨터/소프트웨어창업/스타트업AI/미래기술

스크립트

00:00:00Willkommen zum Better Stack Podcast, wo wir Gespräche über Softwareentwicklung,

00:00:04KI und alle Arten neuer Technologien führen. Ich bin einer eurer Gastgeber, Andrus, und heute werde ich begleitet von

00:00:10James und Alex. Hey, Alex, willkommen in der Show. Danke, dass ihr mich eingeladen habt, Leute. Fangen wir also mit

00:00:16dem Unternehmen an, das du leitest. Es heißt Hookdeck. Für diejenigen, die nicht damit vertraut sind:

00:00:22Was ist Hookdeck? Was macht es? Erzähl uns mehr darüber. Ja, ich betrachte es gerne als

00:00:27das Webhook-Unternehmen, das versucht, Webhooks zu töten. Das ist wahrscheinlich eine Geschichte, auf die wir eingehen können.

00:00:32Aber wir bauen zwei Hauptprodukte. Eines ist das Event Gateway. Das Event Gateway dient also

00:00:37als eine Art spezialisierter Event-Bus für alle Ereignisse, die von außerhalb deiner Infrastruktur kommen.

00:00:41Webhooks sind ein Hauptverdächtiger, aber wir sehen viele IoT- und SDK-basierte Anwendungsfälle und so weiter.

00:00:47Im Grunde stellen wir also eine Art nicht vertrauenswürdigen Endpunkt bereit. Du kannst beliebige Ereignisse dorthin senden.

00:00:51Und dann alle Funktionen, um diese Ereignisse zu verwalten. Das geht von Filtern,

00:00:55Transformation, Routing, Warteschlangen, Alarm- und Problemmanagement, Wiederholung ist sozusagen das Ganze.

00:01:01Es deckt also wirklich sowohl die Interoperabilität ab, in dem Sinne, dass ich

00:01:05Ereignisse und Webhooks von allen Anbietern erhalten muss, mit denen ich zusammenarbeite, richtig? Das könnten Stripe, Shopify, Twilio,

00:01:10WhatsApp, TikTok, was auch immer, nenn es beim Namen. Jeder von ihnen hat seine eigenen Kriterien und Macken

00:01:16und spezifischen Anforderungen. Und so können wir das alles standardisieren und

00:01:20in einen einzigen Vertrag bringen. Und dann alles vom Standpunkt der Warteschlange aus. Zum Beispiel,

00:01:27bei Shopify, gibt es einen Flash-Sale in deinem Shop und du wirst absolut

00:01:31überflutet, wie von einer Stampede mit Ereignissen. Du normalisierst das, sodass du den Durchsatz und das Event

00:01:38Gateway und all das steuern kannst. Das ist also ein großer Teil davon. Es ist sozusagen die Konsumentenseite. Und das ist

00:01:42wo die Geschichte von Hookdeck irgendwie begann. Und kürzlich haben wir auch Outpost veröffentlicht. Outpost ist vollständig

00:01:49Open Source, ein Apache 2.0 Projekt. Und wir haben jetzt auch einen verwalteten Service dafür. Und es dient dazu, Ereignisse

00:01:55zu senden. Und das ist sozusagen die andere Seite der Gleichung, richtig? Du als Publisher, als

00:01:59Plattform, ein Dev-Tool. Wir sind an diesem Punkt wirklich so, dass jeder auch Ereignisse sendet. Ich bin jeden Tag

00:02:05überrascht. Und Outpost ist also dieser verwaltete Service oder selbst gehostete Service, den du nutzen kannst, um

00:02:12deklarieren, wer deine Mandanten sind, was die Ziele, die Endpunkte sind, die sie registriert haben, Themen konfigurieren

00:02:17und Ereignisse an sie veröffentlichen. Und es handhabt alles von Sichtbarkeit, Metriken, Zustellungsgarantien,

00:02:23Wiederholungsversuche und all die üblichen Verdächtigen wie Signaturen, Signaturrotation,

00:02:28und all das. Der kleine Scherz, den ich darüber gemacht habe, Webhooks töten zu wollen, ist, dass Outpost

00:02:35zwar erlaubt, Webhooks zu senden, aber auch, Ereignisse direkt an den Message-Bus deiner Benutzer

00:02:39zu veröffentlichen. Outpost unterstützt also nativ das, was heute als Event-Destinationen bekannt ist. Webhook wird also

00:02:46als Transport-Router betrachtet. Du sendest also im Grunde Ereignisse über Webhooks und

00:02:53Webhooks ist der Standard-Transportmechanismus, richtig? Und du kannst neue Transportprotokolle wählen, wie MQ

00:02:59für RabbitMQ oder Kafka. Und wir unterstützen auch die Veröffentlichung direkt an alle üblichen Verdächtigen wie Pub/Sub,

00:03:05SQS, AWS EventBridge und natürlich das Hookdeck Event Gateway, richtig? Ich betrachte es also als

00:03:12das bessere Ziel, aber wir werden sehen, ob die Leute glauben, dass es so ist. Du sagtest also, du willst Webhooks töten. Ich

00:03:18stelle mir vor, dass diese Idee und ihre Entstehung daher kamen, dass ihr alle Webhooks leid wart oder es

00:03:25zu schwer zu verwalten war. Erzähl uns, wie du auf die Idee gekommen bist. Ja, ich habe das gerade

00:03:31neulich jemandem erzählt. Vor etwa fünf Jahren habe ich diesen Artikel auf Medium veröffentlicht.

00:03:37Ich komme wahrscheinlich bald auf sechs Jahre. Und der Artikel trägt den Titel, passend zu dem, was du

00:03:42sagst: “Webhooks sind scheiße, aber man kann etwas dagegen tun.” Und das war einfach ich in meinem

00:03:48Keller, weißt du, wie ich herumexperimentiert und eine Art V1-Prototyp von Hookdeck gebaut habe.

00:03:54Aber es kam sehr stark von dieser Frustration. Ich habe persönlich im E-Commerce gearbeitet und wir haben

00:03:59viel maßgeschneiderte Software entwickelt, um den E-Commerce anzutreiben, von benutzerdefiniertem Abonnementmanagement bis hin zu

00:04:05Lagerhaltung und Abwicklung und all diesem Zeug. Und einfach so viele der Probleme

00:04:10liefen auf Webhooks hinaus. Und es war fast eine Art wiederkehrender Witz, denn auf der einen Seite

00:04:15versuchte ich, ein Modegeschäft für Damen zu führen, richtig? Ich versuchte, Dessous und

00:04:18Nylons und so etwas zu verkaufen. Und am anderen Ende hieß es: Wo zum Teufel ist der

00:04:23Webhook? Was ist damit passiert? Es fühlte sich einfach sehr unpassend an in Bezug auf die Anliegen.

00:04:28Und es kam also sehr stark daher, dass ich einfach als Konsument dieser Webhooks frustriert war,

00:04:33dass es keine wirkliche “Batteries included”-Art und Weise gab, dieses

00:04:38Problem anzugehen. Und wenn man online ging und nach Empfehlungen suchte, gibt es,

00:04:43ich meine, Webhooks sind nicht neu. Letztendlich sind es HTTP-Anfragen. Es gibt

00:04:46offensichtlich etablierte Muster, wie man damit umgehen soll. Aber dann gerät man

00:04:50sehr schnell in ein Kaninchenloch. Okay, du brauchst deine Ingestions-Konsumenten, die automatisch skalieren können,

00:04:55und dann musst du in eine Warteschlange wie SQS einreihen. Und dann musst du eine Reihe von

00:05:00Konsumenten bereitstellen, die von SQS konsumieren. Und wenn etwas schiefgeht, landet es

00:05:05in der Dead-Letter-Queue. Und dann brauchst du ein Skript, um dich von der Dead-Letter-Queue zu erholen und

00:05:09zu verstehen, warum die Dinge dort überhaupt gelandet sind. Und da gibt es einfach all diese Anliegen.

00:05:14Und wenn die Komplexität zunimmt, möchtest du auch in der Lage sein, historische Ereignisse, die du

00:05:18empfangen hast, erneut abzuspielen. Du möchtest sehen können, was genau die Nutzlast des Webhooks war.

00:05:22Und dann hast du es mit verschiedenen Anbietern zu tun, denn vielleicht gibt dir Stripe

00:05:26ein UI und Intercom nicht. Und dann hast du all diese

00:05:31unterschiedlichen Macken, mit denen du klarkommen musst. Es entstand also sehr stark aus dieser Frustration heraus und

00:05:35einfach aus der Frage, warum es keine Lösung dafür gab, richtig? Zuerst habe ich es sehr aus einer

00:05:41Observability-Perspektive betrachtet und das hat nicht wirklich funktioniert. Der Teil, den ich vermisse, ist, dass Observability

00:05:47nur ein Teil davon ist. Letztendlich habe ich diesen Spruch, ich nenne Webhooks eine Einstiegsdroge

00:05:51zur eventgesteuerten Architektur. Und der Grund dafür ist – und deshalb bestehe ich auch so sehr

00:05:56auf dem Begriff Ereignis statt Webhook – dass hinter jedem Webhook ein Ereignis steht und es

00:06:01jetzt Paradigmen der eventgesteuerten Architektur gibt, die mit diesem Webhook einhergehen, richtig? Und jedes Mal,

00:06:07wenn du einen Webhook für einen ernsthaften Umfang oder ein kritisches Szenario empfängst, musst du jetzt

00:06:14über Idempotenz, Reihenfolge, Zustellungsgarantien und all die Arten von

00:06:19Herausforderungen nachdenken, die du hast, sobald du dich mit asynchronen, eventgesteuerten Programmierparadigmen befasst.

00:06:25Vieles von dem, was wir gebaut haben, entwickelte sich also letztendlich dazu, eine vollwertige Warteschlange

00:06:29zu bauen. Es gibt also diese Interoperabilität, bei der sichergestellt ist, dass wir mit Ereignissen zu tun haben,

00:06:33aber dann drehen sich all diese Arten von Semantik mehr um den Umgang mit Ereignissen und Pub/Sub-Systemen

00:06:38und so weiter. Und wir kamen aus einer Ecke, in der wir nicht versuchen wollten, Warteschlangen neu zu erfinden. Ich glaube, wir sind

00:06:43über eine Reihe von ziemlich coolen Ideen gestolpert. Und eine Sache, die wir jetzt sehen, ist, dass

00:06:48Leute tatsächlich zu Hookdeck wechseln, um Pub/Sub oder SQS aus ihrem Stack zu ersetzen, was

00:06:53für mich irgendwie verblüffend ist, weil wir nicht deine VPC und all das Zeug betreiben. Ich denke,

00:06:57es gibt viele Probleme damit, vielleicht auf der Roadmap. Aber der Punkt ist, ich denke, es gibt viele Semantiken

00:07:05rund um die eventgesteuerte Architektur, an die sich die Leute gewöhnt haben, ohne sie wirklich zu hinterfragen.

00:07:09Und es ist wie: Warum machen wir wieder Dead-Letter-Queues? Was zum Teufel stimmt damit nicht?

00:07:13Denn ich kenne niemanden, der denkt, dass eine Dead-Letter-Queue eine bequeme Semantik

00:07:19für den Umgang mit Fehlern in Warteschlangen ist, richtig? Also, und ich bin froh, vielleicht

00:07:25einige dieser Dinge anzusprechen, denn da gibt es einige starke Meinungen.

00:07:29Ich weiß nicht, wie sehr ihr Nerds in Sachen Pub/Sub und eventgesteuerter Architektur seid. Ich möchte

00:07:35euch nicht zu tief hineinziehen. Ich habe das Gefühl, ja, mein Verständnis von Dead-Letter-Queues und all

00:07:40dem Zeug ist sehr, sehr oberflächlich. Einige der Dinge, die ich heute höre, höre ich zum ersten Mal.

00:07:48Ja, ja. Ich wollte sagen, meins ist auch ziemlich oberflächlich, aber ich habe mich schon einiges mit Webhooks

00:07:53beschäftigt und einige der von dir erwähnten Probleme behandelt. Und ich denke, genau das

00:07:57Argument, dass Webhooks die Einstiegsdroge zur eventgesteuerten Architektur sind,

00:08:01denn ich wette, dass Webhooks für Entwickler mit eurem Hintergrund

00:08:06wahrscheinlich die erste Berührung damit waren: Moment, das ist asynchron. Wie gehe ich damit um?

00:08:12Und ich denke, es gibt diese ganze Lernkurve, richtig? Es ist wie der klassische Eisberg,

00:08:17wo es heißt: Oh, da kommt die HTTP-Anfrage und dann, weißt du, der Rest des Eisbergs

00:08:21hinter dem, im Wasser, richtig? Und ich denke, eine der Sachen, die ich versuche

00:08:26zu tun, ist eine Ebene der DX zu bringen, die in diesem Bereich noch nicht wirklich erreicht wurde, sodass

00:08:32du den Rest des Eisbergs nicht wirklich herausfinden musst, richtig? Es gibt einige Dinge, die

00:08:37ein wenig unvermeidlich sind, ich möchte es nicht falsch darstellen. Ich denke, sobald man anfängt,

00:08:40mit solchen Problemen zu arbeiten, muss man ein gutes Verständnis von Idempotenz haben,

00:08:45zum Beispiel muss man ein gutes Verständnis von Reihenfolgegarantien haben. Also

00:08:49ist es nicht so, dass man jedes Problem lösen kann. Ich denke, man hat es immer noch mit Ereignissen zu tun,

00:08:53letztendlich. Aber ich glaube, es gibt viele Semantiken und Komplexitäten, die hauptsächlich davon kommen,

00:08:58dass die Werkzeuge nicht vollständig durchdacht sind, mehr als von der echten Komplexität,

00:09:05die mit diesem Problemraum verbunden ist. Also ich glaube, im Moment bedienen wir zwei

00:09:13Arten von Kunden: Wir bedienen Kunden, die das Problem wirklich in der Tiefe kennen und

00:09:18Lösungsdesign rund um ihr aktuelles Kafka-Setup und all das Zeug betreiben.

00:09:23Und dann pitchen wir ihnen einige dieser neuen Semantiken, und sie sind wirklich begeistert davon. Das ist eine Kategorie.

00:09:28Aber die andere Kategorie ist: Ich möchte das eigentlich gar nicht lernen müssen

00:09:31und im Grunde versuchen, diese ganze Sache zu umgehen, richtig. Wir sehen also viele dieser zwei Profile.

00:09:36Ist das auch ein Grund, warum ihr dieses Werkzeug Outpost Open Source gemacht habt, um es Entwicklern leichter zu machen,

00:09:41damit anzufangen, wenn sie es benutzen? In mancher Hinsicht. Der andere Grund ist, dass wir Outpost

00:09:47nicht brauchen, um Geld zu verdienen. Okay, und deshalb dachten wir uns, wir sollten es einfach Open Source machen. Ja, es ist einfach,

00:09:53ich weiß, dass unser YouTube-Publikum es wirklich mag, von neuen Open-Source-Tools zu erfahren. Deshalb habe ich

00:10:01einfach nachgefragt. Aber zunächst einmal bereue ich es ein wenig,

00:10:07in den frühen Tagen nicht einen etwas mehr Open-Source-First-Ansatz gewählt zu haben. Es gibt viele Dinge,

00:10:13wie man Software baut, die sehr anders sind, wenn man für Closed Source gegenüber Open Source baut. Aber

00:10:18um zur Open-Source-Entscheidung zu kommen, ich denke, was man jetzt bei venture-backed

00:10:21Startups sieht, ist, dass man bei diesem Pseudo-Open-Source landet, richtig? Es ist Open Source, aber

00:10:26entweder Open Core oder ja, es ist Open Source, aber sie wollen nicht wirklich, dass du das Open Source

00:10:30nutzt, oder sie müssen um die Lizenzierung herum

00:10:34herumspielen, die keine echten Open-Source-Lizenzen sind und all das Zeug, richtig. Und ich denke,

00:10:39das hat mich wirklich für Outposts und Open Source begeistert, dass ich das Gefühl hatte, wir hätten eine

00:10:44Gelegenheit, die richtigen Anreize zu haben. Vielleicht kommen wir ein wenig in die Details,

00:10:49wie wir über das Geschäft nachdenken. Aber in meinem Kopf sind die Leute, die auf der Konsumentenseite Webhooks

00:10:54empfangen müssen, mindestens zwei bis drei Größenordnungen mehr

00:10:59als Leute, die einen Webhook senden müssen, richtig? Denn denk mal darüber nach, wenn ich Webhooks sende,

00:11:03sende ich sie an alle meine Kunden, und meine Kunden könnten 10 sein, wenn du gerade erst

00:11:09anfängst, 100, 1000, 2 Millionen. Richtig. Und daher ist die Konsumentenseite zwangsläufig

00:11:13einfach viel größer. Und wenn ich aus unternehmerischer Sicht darüber nachdenke,

00:11:17bin ich mehr an dem Geschäft interessiert, auf der Konsumentenseite zu pushen, richtig. Aber ich denke,

00:11:24was wir realisiert haben, ist offensichtlich, dass man keine Konsumenten ohne gute Produzenten hat. Und ich denke,

00:11:28es gibt immer mehr Nachfrage nach Webhooks im Allgemeinen für Anwendungen, die du entwickelst. Und so,

00:11:33wollen auch mehr Leute sie anbieten und nicht durch die DX und den Overhead gehen,

00:11:37und so weiter. Aber aus meiner Perspektive ist das Senden von Webhooks einfach ein einfacheres Problem, weil du

00:11:42die Parameter kontrollierst, während auf der Empfängerseite der Anbieter diktiert, was die

00:11:46Parameter sind. Es neigt dazu, ich möchte nicht sagen, es ist einfach, aber

00:11:51es gibt definitiv eine Reihe von Möglichkeiten, dies falsch zu machen. Aber ich denke, in Bezug auf den Problemraum

00:11:57ist es auf der Produzentenseite definitiv begrenzter als auf der Konsumentenseite. Und zweitens:

00:12:02Unsere Arbeit besteht darin, die Produktion von Ereignissen zu fördern. Und das ist die Sache, um die wir uns letztendlich

00:12:06kümmern, weil wir wollen, dass mehr Leute diese Webhooks konsumieren und möglicherweise Kunden werden,

00:12:10richtig. Und ich denke, das bringt uns in eine Position, in der wir truly sagen können: Schau, wenn du Outpost benutzen willst,

00:12:15ob du es Open Source machst oder ob du es mit Hookdeck in der verwalteten Version einsetzt,

00:12:19ist es für uns im Allgemeinen egal. Wir erreichen auf die eine oder andere Weise das Geschäftsziel, richtig.

00:12:23Und diese Ausrichtung der Anreize hat mich wirklich begeistert. Und ich denke, es gibt ein paar Dinge, die wir getan haben.

00:12:29Zuerst haben wir das Open Source veröffentlicht, bevor wir überhaupt darüber nachgedacht haben, eine verwaltete Version zu bauen.

00:12:35Es gab generell keinen Plan, eine verwaltete Version zu bauen, als wir das Open Source gebaut haben. Und das Open-Source-Projekt wurde

00:12:40vor etwa zwei Jahren veröffentlicht. Es hat also fast zwei Jahre gedauert, bis genug Leute

00:12:44nach der verwalteten Version gefragt haben, dass wir sie schließlich gebaut haben. Das ist also der eine Teil. Und der andere Teil

00:12:48ist auch, dass die verwaltete Version von Outpost genau den gleichen Docker-Build ausführt, der auf

00:12:52Docker Hub aus dem Open Source veröffentlicht wird. Wir haben keinen privaten Fork.

00:12:57Wir paketieren keine Funktionen und so weiter außerhalb des Open Source. Wir führen wirklich genau den gleichen

00:13:03Docker-Build aus. Die Frage für dich ist also nicht: Oh, bietet es Funktion X oder Y,

00:13:08was auch immer in beiden Versionen? Es ist buchstäblich nur: Willst du es bereitstellen und musst dich um

00:13:13den damit verbundenen operativen Aufwand kümmern? Oder willst du jemand anderen dafür bezahlen, es für dich zu tun?

00:13:19Richtig. Und ich glaube nicht, dass es eine richtige oder falsche Antwort gibt. Das hängt von jedem Unternehmen ab oder dem Niveau an

00:13:23Komfort oder Stack, ihren Compliance-Anforderungen und so weiter. Richtig. Aber deswegen

00:13:29habe ich das Gefühl, dass wir gute Mitwirkende zur Open-Source-Community mit diesem Projekt sein können. Und ja,

00:13:34ich war sehr froh, daran zu arbeiten, weil es das erste große Open-Source-Projekt ist,

00:13:38an dem ich beteiligt bin, außerhalb des Anhörens von Beiträgen und so weiter, sondern als Core-Maintainer.

00:13:44Also ja, nein, es war gut. Wie hast du die Open-Source-Welt empfunden, jetzt wo Claude Code und dergleichen existieren?

00:13:51Hattest du viele PRs und Sicherheitslücken, die nicht echt sind, oder war es okay zu verwalten?

00:13:55Schau, ich glaube nicht, dass wir in einem Maßstab sind, in dem ich für andere sprechen kann,

00:14:01was sie erleben. Ich möchte die Situation also definitiv nicht falsch darstellen, denn

00:14:05es klingt für viele Leute definitiv schlimm da draußen. Ich werde sagen, dass ich von der Qualität

00:14:09und den Beiträgen überrascht war, die wir hatten, aber wir hatten definitiv auch Beiträge, wo es diesen einen

00:14:14spezifischen PR gab, ich glaube, er ist immer noch offen im Repo, Cloudflare Queues als eine

00:14:20Destination hinzuzufügen, weil das eine der unterstützten Ereignis-Destinationen ist.

00:14:25Die Beschreibung klingt gut im PR. Und wenn man dann wirklich den Code durchsieht,

00:14:30benutzt er eine Reihe von komplett erfundenen Cloudflare-APIs.

00:14:34Und sie haben es nicht doppelt geprüft. Die Person, die den PR geöffnet hat, hat ihn nicht einmal

00:14:40wirklich versucht auszuführen. Richtig. Und jetzt liegt die Last bei uns, okay,

00:14:44jetzt ist dieser PR offen, weil ich ein wenig besorgt bin, wahrgenommen zu werden als,

00:14:48dass wir Leute nicht ermutigen, mit denen wir konkurrieren könnten.

00:14:52Also denke ich, wir sollten Cloudflare Queues hinzufügen, aber gleichzeitig war

00:14:56es nicht auf der Roadmap, niemand sonst hat außer dieser Person danach gefragt. Und jetzt ist es in diesem Zustand,

00:15:02dass man, wenn man es schließt, so aussieht, als wolle man keine Leute unterstützen, die als Wettbewerber wahrgenommen werden könnten.

00:15:08Aber widmet man dann tatsächlich Ressourcen und schiebt es auf der Roadmap nach oben,

00:15:12stellt sicher, dass man es korrekt implementiert? Es war also eine Zwickmühle in solchen Situationen.

00:15:15Aber bisher habe ich das Gefühl, dass es eine wirklich gute Erfahrung war,

00:15:19besonders weil wir den gleichen Build verwenden. Eine Sache, die wir übernommen haben, ist, dass wir, wenn

00:15:24Kunden Feedback erreichen oder sie mit uns über spezifische Funktionen sprechen,

00:15:28eröffnen wir Issues auf GitHub oder wir verweisen auf bestehende PRs, bestehende Issues.

00:15:33Und wir stellen sicher, dass die Leute wissen: Übrigens, das Repo ist da,

00:15:37und ihr könnt einen Beitrag leisten. Tatsächlich haben wir mehrere verwaltete Benutzer dazu gebracht, einen Beitrag zu leisten

00:15:43und im Grunde ihre eigenen Funktionen zu implementieren. Richtig. Und ich denke, es hat die Eintrittsbarriere für diese Art von Beiträgen

00:15:48enorm gesenkt. Da die Projekte historisch in Go sind, sind die meisten unserer Benutzer wahrscheinlich keine Go-Entwickler,

00:15:53richtig. Wir sehen viel Python, TypeScript, offensichtlich Node.js, also gibt es eine Eintrittsbarriere für Go. Und auch

00:15:58einfach ein neues Projekt zu lernen, zu dem man beitragen will, ist nicht trivial. Richtig. Und so

00:16:03denke ich, hat es diese Eintrittsbarriere substanziell gesenkt. Und das ist wirklich gut.

00:16:07Denn jetzt, wenn du als Benutzer denkst: Oh, diese Sache stört mich wirklich.

00:16:13Und plus, als Maintainer ist das ein so starkes Signal, dass diese Funktion es wert ist, gebaut zu werden.

00:16:18Jemand geht aus dem Weg und verbringt seine wertvolle Zeit damit, dies zu implementieren.

00:16:24Wie ein Signal, dass dies wirklich zählt. Richtig. In Bezug auf das Stock-Ranking,

00:16:28was am wichtigsten ist. Ich denke also, die Eintrittsbarriere zu senken ist wirklich gut.

00:16:35Und ich denke, wenn man es schafft, aus den Fluten von Spam und all diesem Zeug herauszukommen,

00:16:39gibt es viel Positives daran.

00:16:42Auf der Landingpage ist mir ein Testimonial vom CEO von Vercel besonders aufgefallen.

00:16:48Vercel benutzt also Hookdeck als ein Produkt.

00:16:53Jemand macht sich die Mühe und investiert seine Wort-Token in die Implementierung.

00:16:58Es ist ein Signal, dass es wirklich wichtig ist. In Bezug auf das Ranking,

00:17:02was am wichtigsten ist. Ich denke also, die Eintrittsbarriere zu senken, ist sehr gut.

00:17:07Wenn man es schafft, die Flut an Spam und all dem Zeug zu bewältigen,

00:17:12hat es viele positive Aspekte.

00:17:14Auf der Landingpage ist mir ein Zitat vom CEO von Vercel besonders aufgefallen.

00:17:21Vercel nutzt Hookdeck tatsächlich auch als Produkt.

00:17:25Wenn man dieses spezielle Zitat liest, wird es dort auch empfohlen.

00:17:29Oh, verstehe.

00:17:29So etwas wie Vercel-Nutzer und ähnliches.

00:17:32Dazu gibt es eigentlich eine lustige Geschichte.

00:17:35Denn Guillermo hat an einem Samstagabend darüber getweetet.

00:17:39Ich hatte keine Ahnung, dass es kommen würde.

00:17:40Ich hatte zuvor keine direkte Beziehung zu Guillermo oder dergleichen.

00:17:45Das spricht für den Einfluss mancher Leute in der Community.

00:17:48Denn die Menge an Anmeldungen und Aufmerksamkeit, die wir dadurch bekamen, war

00:17:53wahnsinnig.

00:17:54Seitdem stehen Guillermo und ich hin und wieder in Kontakt.

00:17:57Und es waren immer gute Gespräche.

00:17:59Es ist interessant.

00:18:00Denn wenn man sich ein Unternehmen wie Vercel ansieht, sagte mir Guillermo,

00:18:04ist, dass er tatsächlich sieht, wie viel mehr Leute jetzt WebEx nutzen.

00:18:07Seine Einschätzung war, dass dies hauptsächlich durch LLM-Optionen getrieben wird.

00:18:12Das schafft neue Anwendungsfälle für Daten,

00:18:15um die man sich vorher nicht gekümmert hätte.

00:18:18Denken Sie zum Beispiel an Ihr Kundensupport-System.

00:18:20Dort haben Sie Agenten und Menschen, die damit arbeiten.

00:18:23Es gibt nur wenig Grund, irgendetwas mit neuen Ticket-Ereignissen zu tun.

00:18:29Und dergleichen.

00:18:30Denn am Ende ist es der Mensch, der die Nachricht beantwortet.

00:18:34Aber wir leben offensichtlich in einer Welt, in der sich das komplett ändert.

00:18:37Und wenn man von Menschen, die Agenten auslösen, dazu übergeht, dass Ereignisse sie auslösen, stimmt's?

00:18:42Richtig.

00:18:42Plötzlich interessieren Sie sich für Ereignisse aus Ihrem Kundensupport-System,

00:18:46Ihrem Marketing-Tool und so weiter.

00:18:48Richtig.

00:18:48Und das ist definitiv etwas, das Plattformen meiner Meinung nach sehen.

00:18:54Und das waren für uns natürlich interessante Diskussionspunkte.

00:18:57Aber Vercel ist nicht direkt ein Nutzer.

00:19:01Ich bin sicher, viele Entwickler nutzen Ihr lokales CLI und dergleichen bei Vercel, aber...

00:19:05ja.

00:19:06Was ist der typische Kunde für jemanden, der Hookdeck nutzt?

00:19:10Wenn ich, keine Ahnung, einen kleinen T-Shirt-Onlineshop hätte, wie würde ich Hookdeck dafür nutzen?

00:19:15Und ergäbe das in diesem Fall Sinn?

00:19:17Wahrscheinlich nicht.

00:19:19Okay.

00:19:21Okay.

00:19:22Du stellst mir die Millionen-Dollar-Frage. Wir hatten immer Schwierigkeiten damit,

00:19:26weil die Bandbreite der Gründe, warum man Webhooks nutzt oder auf sie angewiesen ist, unglaublich groß ist.

00:19:32WebEx oder die Abhängigkeit von WebEx ist einfach wahnsinnig groß.

00:19:35Wir bekommen WebEx von den üblichen Verdächtigen wie Stripe und Shopify, aber wir haben auch

00:19:40WebEx von allen australischen Telekommunikationsanbietern und dem britischen Clearinghaus.

00:19:47Und es gibt tatsächlich eine ganze Menge, die vom Spiel EVE Online kommen.

00:19:50Es gibt auch anscheinend eine Community von Leuten, die immer noch dieses Conan-Spiel nutzen,

00:19:55das Barbaren-Spiel von vor etwa 15 Jahren oder so.

00:19:58Und die setzen auch voll auf WebEx.

00:20:00Richtig.

00:20:00Richtig.

00:20:01Der Punkt ist, diese Vielfalt macht es sehr schwer, zu sagen: “Das ist unser Kunde.”

00:20:06Richtig.

00:20:08Richtig.

00:20:09Es gibt keinen einzelnen Anwendungsfall oder keine Gruppe, die mehr als 10 Prozent ausmacht.

00:20:13Aber zu Ihrem Beispiel mit dem E-Commerce:

00:20:14Ein kleiner T-Shirt-Laden hat wahrscheinlich keine benutzerdefinierten Apps,

00:20:16die darauf angewiesen wären.

00:20:19Aber sie haben fast sicher Apps installiert. Zum Beispiel eine App, um Bewertungen zu sammeln,

00:20:25eine für Benachrichtigungen bei wieder verfügbaren Artikeln,

00:20:27eine für die Bestandsverwaltung und eine für den 3PL-Dienstleister.

00:20:30All diese Anbieter verlassen sich fast ausschließlich auf Webhooks.

00:20:35Wenn ich eine “Wieder auf Lager”-Benachrichtigung senden will, höre ich auf alle Bestandsaktualisierungen

00:20:39Und diese Anbieter verlassen sich fast ausschließlich auf Webhooks.

00:20:43Richtig.

00:20:43Wenn ich also eine Benachrichtigung bei “wieder vorrätig” senden will, dann reagiere ich auf alle Lager-

00:20:48bestandsaktualisierungen im Shopify-Shop über deren Webhooks.

00:20:50Und sobald ein Produkt, das vorher nicht vorrätig war, wieder auf Lager ist,

00:20:53sage ich: Okay, muss die E-Mail rausschicken.

00:20:54Richtig.

00:20:55Im Grunde wird sich also jede einzelne Sache, die sie installieren oder hinzufügen,

00:20:59im Hintergrund auf Webhooks stützen.

00:21:00Viele davon sind Kunden.

00:21:02Außerdem sehen wir große Shops, wie Gymshark, Rogue und andere,

00:21:07die eigene Technik-Teams haben und benutzerdefinierte Apps bauen.

00:21:09Sie bauen Apps für ihre Systemintegration,

00:21:11oft sehr operativ, etwa für die Synchronisierung

00:21:14einer Bestellung mit dem 3PL-Dienstleister.

00:21:19Vielleicht müssen kundenspezifische Vorlieben zu den Daten hinzugefügt werden,

00:21:22bevor sie den 3PL-Dienst erreichen.

00:21:28Und manche davon verbessern das Nutzererlebnis,

00:21:34wie Abo-Verwaltung oder spezifische E-Mails, wenn jemand eine Geschenkkarte kauft.

00:21:39All das sehen wir.

00:21:41Richtig.

00:21:41Der kleine Shopify-Store, den du als Beispiel gewählt hast, nutzt Hookdeck zwar wenig,

00:21:46aber fast überall sonst landest du bei einem Unternehmen, das Webhooks nutzt.

00:21:51Alles klar.

00:21:55Wie lässt sich das mit AWS EventBridge vergleichen?

00:21:59rausgegriffen haben, wo wir nicht sehen, dass viele Leute WebEx nutzen, aber wissen Sie, fast überall sonst

00:22:04in diesem Segment, da werden Sie zwangsläufig auf ein Unternehmen stoßen,

00:22:08das WebEx einsetzt.

00:22:09Sie machen mehr oder weniger dasselbe Argument, oder?

00:22:10Ja.

00:22:11Wie lässt es sich mit so etwas wie AWS EventBridge vergleichen?

00:22:14anführt, das überträgt sich darauf.

00:22:17Es geht sehr um das Argument der Entwicklererfahrung.

00:22:19Richtige APIs, eine schöne Benutzeroberfläche, solide Funktionalität und dergleichen.

00:22:24Richtig.

00:22:25Das AWS-Problem ist oft,

00:22:26dass man am Ende 20 Dienste hat, deren Namen man wahrscheinlich schon wieder vergessen hat.

00:22:31Die Daten und Konfigurationen sind über alles verstreut.

00:22:37Aber der breitere Punkt ist: AWS EventBridge integriert sich nicht mit jedem.

00:22:40Der Anbieter muss sich selbst mit AWS EventBridge integriert haben.

00:22:46Es gibt Umwege über das API-Gateway,

00:22:47aber es ist sehr für das AWS-Ökosystem gebaut,

00:22:47wo die Anwendungsfälle meist interne AWS-Ereignisse sind,

00:22:51wie das Hochladen eines neuen S3-Dokuments.

00:22:56Die Interoperabilität mit Drittanbietern ist begrenzt.

00:22:59Es sind nicht Tausende.

00:23:01Man endet in Szenarien,

00:23:01wo Shopify EventBridge unterstützt, Twilio aber nicht.

00:23:02Man braucht eine agnostische Lösung, die überall funktioniert.

00:23:07Wir wollen es so bauen,

00:23:08dass wir den Anbieter nicht brauchen, damit er zustimmt.

00:23:11Hookdeck funktioniert rein über HTTP.

00:23:16Wir geben dir eine URL, mit der du deine bestehende Webhook-URL ersetzen kannst.

00:23:23Dein Ziel ist dann das, was früher deine URL war.

00:23:31Wir arbeiten als Push-basierte Warteschlange dazwischen.

00:23:31Wir empfangen alle Webhooks per HTTP und leiten sie mit der von dir

00:23:36gewünschten Rate an deinen Endpunkt weiter.

00:23:40Das bedeutet, du musst deinen Code nicht einmal neu bereitstellen.

00:23:45Es funktioniert in jeder Cloud und mit jedem Stack.

00:23:47Die einzige Voraussetzung ist, die URL zu aktualisieren.

00:23:47Das ist weit entfernt von AWS EventBridge,

00:23:51dem ultimativen Vendor-Lock-in.

00:23:52Ich sehe EventBridge als das andere große Event-Gateway.

00:23:54Azure Event Grid gewinnt auch an Boden.

00:23:59Sie sind unsere Inspiration und Konkurrenz.

00:24:02Die Tragweite dessen, was wir tun, ist jedoch etwas größer.

00:24:08Für manche ist das gut, für andere nicht.

00:24:10Manche sind tief im AWS-Ökosystem verwurzelt und nutzen CloudFormation.

00:24:15Das ist in Ordnung.

00:24:17Wir werden nie 100 Prozent Marktanteil haben,

00:24:22ein paar Prozentpunkte reichen völlig aus.

00:24:25Wir versuchen zu zeigen, dass wir die richtige Lösung für Entwickler sind.

00:24:28Für andere ist AWS EventBridge besser, und das ist okay.

00:24:31Mir ist aufgefallen, dass die Ausfallzeiten bei großen Unternehmen im letzten Jahr zugenommen haben.

00:24:34Es gibt Memes darüber, dass GitHub ständig down ist.

00:24:39Früher war ein Abfall des P99-Werts auf 99,5 Prozent,

00:24:40eine ernste Angelegenheit.

00:24:44Und das ist ein ziemlicher Unterschied zu AWS EventBridge, das quasi der ultimative Anbieter-

00:24:48Siehst du bei Hookdeck, dass es mehr Ausfälle gibt?

00:24:53Wie gehst du damit um?

00:24:53GitHub-Webhooks sind besonders problematisch.

00:24:58Da gibt es ständig Banner, dass Deployments nicht funktionieren.

00:25:04Der GitHub-CTO hat einen Blogpost dazu geschrieben,

00:25:10um die Wogen zu glätten – ohne großen Erfolg.

00:25:13Er machte Webhook-Stabilität für die Probleme verantwortlich.

00:25:17Die Infrastruktur-Herausforderung durch KI-Agenten ist riesig.

00:25:18So wie OSS-Maintainer überflutet werden, wird die Infrastruktur überflutet.

00:25:20Das ist extrem schwierig.

00:25:22Wir sehen das, und wir überwachen es für einige Anbieter.

00:25:24Wir haben “Hookdeck Radar”.

00:25:26Damit analysieren wir aggregierte Statistiken,

00:25:27um Lieferlatenzen und Uptime zu berechnen.

00:25:30Unser Shopify-Radar ist sehr beliebt.

00:25:31Ich glaube nicht, dass wir jemals einen Marktanteil von 100 % erreichen werden.

00:25:34Ehrlich gesagt reichen in den USA wahrscheinlich schon ein paar Prozentpunkte völlig aus.

00:25:38Wir versuchen also zu verdeutlichen, dass das für bestimmte Unternehmen und

00:25:45Entwickler usw. die richtige Lösung sein wird.

00:25:48Und für andere ist AWS EventBridge eben die Wahl, was auch völlig in Ordnung ist.

00:25:51Mir ist im letzten Jahr aufgefallen, dass die Ausfallzeiten bei großen

00:25:59Unternehmen zugenommen haben.

00:26:00Es gibt ja diese ganzen Memes darüber, dass GitHub offline ist.

00:26:02Ich erinnere mich, dass wir vor zwei Jahren, als ich noch gearbeitet habe, beim P99-Wert,

00:26:07wenn der auf 99,5 oder darunter fiel, ein ernstes Gespräch mit dem Team geführt hätten.

00:26:13Wie konnte das passieren?

00:26:14Heute gehört das irgendwie zum Alltag.

00:26:15Genau, heute ist das quasi Tagesgeschäft.

00:26:17Ja.

00:26:17Und jetzt haben sich die Leute irgendwie daran gewöhnt, dass GitHub so lange ausfällt.

00:26:23Mich würde aus deiner Sicht bei Hook interessieren: Siehst du dieses Jahr auch

00:26:28deutlich mehr Ausfälle als in den Vorjahren, und wie gehst du mit diesen Herausforderungen um?

00:26:33Ja, das ist interessant, denn natürlich muss man das berücksichtigen, wenn man

00:26:37Wenn man Webhooks von GitHub nutzen will, sind die Webhooks von GitHub tatsächlich besonders problematisch.

00:26:42Weißt du, die Chancen stehen fast fünfzig zu fünfzig, dass man beim Einloggen auf Railway, Vercel oder wo auch immer,

00:26:46einen kleinen Banner sieht.

00:26:47Und da steht dann so etwas wie: Deployments sind ausgefallen, weil die GitHub-Webhooks nicht funktionieren.

00:26:51Der CTO von GitHub hat dazu tatsächlich einen Blogbeitrag über die Stabilität ihrer Infrastruktur geschrieben,

00:26:58mitten in all den Memes und dem ganzen Trubel, um die Situation etwas zu beruhigen.

00:27:02Bis bald.

00:27:03Ich glaube nicht, dass es viel gebracht hat, aber es gab keinen Zeitpunkt.

00:27:05Aber eines der Dinge, die in dem Artikel ausdrücklich kritisiert wurden, war die Stabilität von WebEx

00:27:09und wie es von MySQL und so weiter abhängt.

00:27:12Sehr gerne.

00:27:13Das Gespräch war wirklich aufschlussreich.

00:27:17Wir haben viel abgedeckt.

00:27:21Über Events und Webhooks.

00:27:23Und ihre Rolle in der modernen Entwicklung.

00:27:26Das Thema bleibt spannend.

00:27:30Wir sehen uns sicher wieder.

00:27:33Viel Erfolg weiterhin.

00:27:38Bis zum nächsten Mal.

00:27:41Wir haben zum Beispiel eine Funktion, die wir “Deck Radar” nennen.

00:27:44Die Idee dahinter ist, dass wir aggregierte Statistiken von allen Kunden und allen Webhooks

00:27:49Webhooks, die wir über Deck erhalten, und dann Dinge wie die Zustelllatenz berechnen

00:27:53Wir messen die P99-Zustelllatenz eines Anbieters, dessen Verfügbarkeit und ähnliche Dinge.

00:27:58Unser Radar für Shopify ist zum Beispiel ziemlich beliebt.

00:28:01Ich habe ein paar hundert Abonnenten dafür.

00:28:04Die Idee ist, dass wir Benachrichtigungen senden, wenn die Latenz eine bestimmte Standardabweichung

00:28:09der Basislatenz überschreitet.

00:28:12Richtig.

00:28:12Ich glaube, im Fall von Shopify liegt die Basislatenz für die Zustellung bei etwa vier bis fünf Sekunden.

00:28:17Genau.

00:28:17Wenn es über 10 Sekunden geht, dann...

00:28:19Richtig.

00:28:20Dann senden wir eine Benachrichtigung.

00:28:22Man kann das wie eine Art Zeitreihen-Daten überwachen und sich das Latenzprofil

00:28:26und die Verfügbarkeit nicht nur als reinen Uptime-Wert, sondern über die Zeit hinweg ansehen.

00:28:31Über die Zeit.

00:28:32Das ist definitiv etwas, das man sieht.

00:28:33Ich meine, das Shopify-Team ist sich dessen durchaus bewusst.

00:28:36Man kann aber sehen, dass es bei den Zustellzeiten eine große Varianz gibt.

00:28:41Es gibt also vielleicht alle zwei Monate einen ziemlich signifikanten Latenzvorfall.

00:28:46Das ist etwas, das man normalerweise nicht bemerkt.

00:28:49Und das ist, glaube ich, etwas, das man normalerweise nicht sieht.

00:28:51Richtig.

00:28:52Ausfallzeiten sind natürlich viel einfacher zu erkennen.

00:28:54Man schaut in DataDog oder Better Stack.

00:28:57Wie nennt ihr das nochmal? Das Metrik-Produkt?

00:29:01Observability.

00:29:02Genau, Observability.

00:29:03Man schaut in Better Stack, um so etwas zu bauen.

00:29:05Richtig.

00:29:06Wenn die HTTP-Aufrufe an den Webhook-Endpunkt plötzlich aufhören, ist das Problem ziemlich offensichtlich.

00:29:11Genau.

00:29:11Das ist unkompliziert.

00:29:14Aber wenn die Latenz auf 60 Sekunden ansteigt, ist das anhand der Metriken sehr schwer zu erkennen.

00:29:19Das ist aus deinen eigentlichen Metriken kaum ersichtlich.

00:29:22Richtig.

00:29:23Das liegt an der Latenz, die man für die Verarbeitung braucht, was man wahrscheinlich trace-n würde.

00:29:27Aber es ist die Verzögerung auf der Anbieterseite.

00:29:28Das ist eine Verzögerung aufseiten des Anbieters.

00:29:31Wenn dein Code oder Geschäftsbetrieb jedoch auf Echtzeit-Events ausgelegt ist...

00:29:34und diese jetzt mit 60 Sekunden Verzögerung ankommen, führt das zu vielen nuancierten Fehlern.

00:29:39Es entstehen falsche Annahmen und Probleme im Code.

00:29:44Solche Dinge eben.

00:29:46Ich denke, das ist ein Bereich, in dem wir vielleicht einzigartig positioniert sind,

00:29:50um gute Daten zu liefern.

00:29:52So weißt du genau: Liegt es an mir oder an meinem Anbieter?

00:29:55Richtig.

00:29:56Wer hat die Probleme?

00:29:57Ich weiß nicht, ob ich empirisch beurteilen kann, wie viel es zu- oder abgenommen hat.

00:30:03Es gibt die üblichen Verdächtigen, auf die man mit dem Finger zeigen kann.

00:30:06Auf die man leicht zeigen kann.

00:30:08Ich weiß nicht, ob ich sagen würde, dass es ein durchgängig verteiltes Problem ist, das wir ständig sehen.

00:30:13Ich glaube, es konzentriert sich eher auf bestimmte Anbieter.

00:30:16Das Problem, bei dem Leute eher hängenbleiben, sind die Zustelllatenzen.

00:30:23Außerdem denken viele, dass die Zustelllatenz niedriger ist, als sie bei den meisten Anbietern tatsächlich ist.

00:30:27Meistens sprechen wir von ein paar Sekunden, was je nachdem, wie man es betrachtet,

00:30:31eine lange oder kurze Zeit sein kann.

00:30:34Wenn ich aber zum Beispiel dieses Latenzdiagramm von Shopify einer Gruppe von Shopify-Entwicklern zeige,

00:30:40ist deren erste Reaktion: “Das habe ich nicht erwartet.”

00:30:43Richtig.

00:30:43Es bricht mit ihren Erwartungen.

00:30:46Ich habe früher bei einem recht großen E-Commerce-Unternehmen gearbeitet und wir hatten dasselbe Problem.

00:30:53Die Latenz war schlecht, aber alle waren wie im Spider-Man-Meme und zeigten aufeinander,

00:30:58wer dafür verantwortlich ist.

00:30:59Denn normalerweise ist es, wie du sagst, ein Drittanbieter.

00:31:05Manchmal kann man einfach nichts tun.

00:31:07Man muss damit arbeiten.

00:31:08Das ist cool.

00:31:09Man sollte vorsichtig sein, dem Anbieter die Schuld zu geben.

00:31:11Richtig.

00:31:11Ich denke, in dem Kontext, in dem ihr arbeitet, ist das immer ein häufiges Problem.

00:31:16Jedes Mal, wenn wir einen Vorfall haben, fragt man sich:

00:31:18Wie viel Schuld liegt beim Anbieter?

00:31:22Irgendwann muss man unterscheiden, was vernünftig ist und was nicht.

00:31:27Was ist ein Ausreißer und was nicht?

00:31:29Neulich bei Railway zum Beispiel: Einige unserer Outpost-Management-Deployments

00:31:34laufen wegen ihrer Preisstruktur auf Railway.

00:31:36Da wir dieselbe Version wie Open Source ausführen müssen, haben wir keine

00:31:40Multi-Tenancy-Lösung gebaut, das wäre bei Open Source nicht relevant.

00:31:44Also führen wir für jeden Kunden ein eigenes Deployment durch.

00:31:48Richtig.

00:31:49Für kostenlose Nutzer deployen wir eine Instanz auf Railway,

00:31:52was im Allgemeinen ziemlich gut funktioniert.

00:31:54Neulich wurde deren GCP-Konto abgeschaltet und sie waren für etwa sechs Stunden down.

00:31:59Oder so etwas.

00:31:59Richtig.

00:31:59Da fragt man sich: Soll man das überhaupt ansprechen?

00:32:06Es ist eine Sache, die Schuld von sich zu weisen.

00:32:09Natürlich trägt man Verantwortung für seine Anbieter.

00:32:11Aber der Punkt ist, es ist schwierig, diesen Weg zu gehen.

00:32:14Ich sehe bei Leuten eine natürliche Tendenz, mit dem Finger auf andere zu zeigen,

00:32:18weil man sich so von der eigenen Verantwortung entbindet.

00:32:20Man muss also ein wenig dagegen ankämpfen.

00:32:23Richtig.

00:32:24Aber in Fällen, in denen man sicher sein kann, dass es am Anbieter liegt,

00:32:28ist es interessant, das zu identifizieren

00:32:31und die entsprechenden Daten dazu zu haben, was bei Anbieterproblemen oft schwierig ist.

00:32:35Richtig.

00:32:35Man sieht die Daten ihrer Seite nicht.

00:32:37Es ist daher sehr schwierig, mit Sicherheit oder empirischen Beweisen zu sagen,

00:32:42dass sie es eindeutig sind.

00:32:43Man muss es aus den eigenen Daten ableiten, was richtig oder falsch sein kann.

00:32:46Richtig.

00:32:47Ich habe mich gefragt: Wenn es einen Ausfall bei Shopify oder Stripe gibt,

00:32:51wie holen die Events auf und trifft das eure Server sehr hart?

00:32:57Ja, im Grunde ist das ein “Rex-Massacre”.

00:33:00Wir sagen immer, dass man kein bestimmtes Webhook-Volumen voraussetzen sollte.

00:33:05Man sollte kein spezifisches Volumen annehmen.

00:33:09Mhm.

00:33:09Jeder Anbieter erzwingt ein Zeitlimit.

00:33:14Richtig.

00:33:14Sie geben dir drei oder...

00:33:15fünf Sekunden Zeit, um zu antworten.

00:33:18Das bedeutet, man kann kaum sinnvolle Arbeit leisten,

00:33:21insbesondere wenn man Netzwerklatenz und Verzögerungen einrechnet.

00:33:25Richtig.

00:33:25Das ist ein Grund, warum man...

00:33:28Das ist der Grund, warum man es in eine Queue stellen muss.

00:33:31Man kann das nicht synchron verarbeiten.

00:33:33Ich habe den Faden verloren.

00:33:39Kannst du die Frage wiederholen?

00:33:42Ich sprach darüber, wenn Stripe oder Shopify einen Ausfall haben.

00:33:45Ach ja.

00:33:45Und das Aufholen.

00:33:47Genau.

00:33:47Ja.

00:33:47Ja.

00:33:47Wie gesagt: Latenz, bla, bla, komplizierte Art zu sagen, man muss in der Lage sein,

00:33:52automatisch zu skalieren.

00:33:53Man muss in der Lage sein, in einem sehr kurzen Zeitrahmen zu skalieren.

00:33:56Die Spikes haben verschiedene Gründe.

00:33:58Es könnte ein Massenimport des Kunden sein oder was auch immer.

00:34:03Richtig.

00:34:03Genau.

00:34:03Es gibt auch andere Gründe für Spikes.

00:34:05Aber Ausfallzeiten sind einer davon.

00:34:07Richtig.

00:34:07Wenn Shopify eine halbe Stunde down ist, werden sie nach der Wiederherstellung

00:34:11den Rückstand aufarbeiten und versuchen, den Rückstau abzubauen.

00:34:16Sie arbeiten alles ab, was sich...

00:34:17während der Ausfallzeit angesammelt hat.

00:34:22Normalerweise skalieren sie sogar höher als ihre übliche Kapazität,

00:34:26weil sie versuchen, den Rückstand aufzuholen.

00:34:28Richtig.

00:34:28Das führt dazu, dass eine Menge Anfragen an die End-Stores gesendet werden.

00:34:32Diese Unregelmäßigkeiten sind zu 100% durch den Anbieter verursacht,

00:34:37nicht durch dich.

00:34:38Weil der Anbieter seine eigenen Infrastrukturprobleme hat.

00:34:42Und so weiter.

00:34:44Die Kapazität von Shopify, Webhooks zu senden, ist viel höher als deine Kapazität,

00:34:49Webhooks zu empfangen.

00:34:52Ja.

00:34:52Interessanterweise war einer unserer Investoren CPO bei Twilio.

00:34:56Ich glaube, das ist einer der Gründe, warum er investiert hat.

00:34:59Er sagte, dass Twilio seine Kunden im Grunde routinemäßig

00:35:04einer DDoS-Attacke aussetzte.

00:35:07Das ist ein wenig unvermeidlich und Teil des Problems bei diesen anbietergesteuerten Events.

00:35:14Es ist ein bekanntes Problem.

00:35:17Das ist ein bekanntes Problem bei Anbietern.

00:35:21Sie wissen das auch, denn das kann man an der Antwortlatenz

00:35:24der Server ablesen, oder?

00:35:26Wenn man seine Kunden DDoS-t, steigt die Antwortlatenz des Servers.

00:35:29Irgendwann kommt es zu Timeouts.

00:35:31Das Problem verschärft sich, weil längere Timeouts den Durchsatz senken.

00:35:34Je länger man die HTTP-Verbindung offen halten muss, desto weniger Anfragen

00:35:38kann jeder deiner Worker verarbeiten.

00:35:40Man muss skalieren und sendet dann noch mehr.

00:35:45Es staut sich einfach alles auf.

00:35:46Es verstärkt sich selbst: Je weniger Kapazität man zur Verarbeitung der Webhooks hat,

00:35:52desto schneller degradiert die Latenz.

00:35:57Wenn der Server an seine Sättigungsgrenze stößt, wird die Latenz sehr schlecht.

00:36:01Die Anfragen stapeln sich weiter.

00:36:04Viele Anbieter deaktivieren irgendwann den Endpunkt,

00:36:07da es sich sonst immer weiter aufbaut.

00:36:10Sie wollen nicht Hunderttausende HTTP-Verbindungen halten,

00:36:14nur weil der Server langsam antwortet.

00:36:15Sobald sie ihn deaktivieren, gehen Daten verloren.

00:36:19Das ist auch ein kritischer Punkt.

00:36:21Die Antwortzeit bei solchen Varianzen sicherzustellen, ist oft außerhalb deiner Kontrolle

00:36:25und eine große Herausforderung.

00:36:29Ich wollte auch fragen: Wie verändert KI den Bereich der Webhooks?

00:36:37Du sagtest, LLMs senden jetzt mehr Webhooks und verarbeiten sie vielleicht.

00:36:43Aber intern: Wie nutzt ihr KI für Hookdeck?

00:36:48Und was siehst du als Zukunft der KI in diesem Bereich?

00:36:51Da passiert eine Menge.

00:36:54Wir als Softwareentwickler-Shop...

00:36:57Ihr macht wahrscheinlich ähnliche Erfahrungen mit Workflows,

00:37:02die sich jede Woche ändern, sowie mit Token-Kosten

00:37:05und der Frage, was angemessene Kosten sind.

00:37:10Wir müssen kein Leaderboard machen.

00:37:15Ich habe Angst vor der Leaderboard-Idee.

00:37:18Das ist ein sicherer Weg, die Margen zu zerstören.

00:37:24Ein paar Gedanken dazu.

00:37:25Erstens, um darauf zurückzukommen: Es gibt Wachstum bei Events,

00:37:29die durch agentische Use Cases getrieben sind, da Agenten nicht mehr nur von Menschen,

00:37:35sondern von Events ausgelöst werden. Cloud-Agenten-Produkte kommen auf den Markt.

00:37:41Viele Dinge davon.

00:37:42All diese werden letztendlich durch Zeitpläne oder Events ausgelöst.

00:37:46Einige Events sind abstrahiert, aber es sind Dinge wie GitHub PRs,

00:37:49GitHub-PRs oder wenn man einen Kommentar auf GitHub schreibt, all das ist webbasiert.

00:37:56Aber natürlich wird sich das weit darüber hinaus ausbreiten, wie zum Beispiel bei Kundensupport,

00:38:00Slack und allem anderen, sogar bei Echtzeitereignissen in der realen Welt, etwa durch Sensordaten,

00:38:04und ähnliche Dinge, oder?

00:38:08Ich glaube auch, dass viele Agenten Ereignisse für andere Agenten auslösen müssen.

00:38:12Der Output eines Agenten wird ein Ereignis sein, das wiederum einen anderen Agenten,

00:38:17ein anderes Unternehmen und so weiter triggern könnte, was man zwar

00:38:21als reinen Webhook-Anwendungsfall bezeichnen, was es irgendwie auch ist.

00:38:23Ich finde aber auch, dass manche der Semantiken rund um Webhooks momentan etwas fehlerhaft sind,

00:38:28insbesondere bei Themen wie Sicherheit, Protokollen und Effizienz.

00:38:33Deshalb setzen wir uns für Event-Destinationen als besseres Muster ein,

00:38:36da sie in diesem Bereich optimierter sind. Ein weiterer Punkt: Wenn das, was man als

00:38:40Reaktion auf Ereignisse ausführt, agentische Workflows sind, die nicht deterministisch sind und lange laufen können,

00:38:47macht es das deutlich schwieriger, Kapazitäten anzupassen und je nach Ereignisaufkommen zu skalieren.

00:38:51Durchsatz- und Kapazitätsmanagement werden also deutlich komplexer.

00:38:55Die Fehlerraten werden steigen, einfach durch Timeouts in der Cloud,

00:39:00oder weil Evals nicht bestehen und ähnliche Dinge.

00:39:07Aus Sicht der Anwendungsentwicklung gibt es also viele neue Herausforderungen hinsichtlich der Kernprimitive,

00:39:12wo sie laufen, wie lange sie laufen und wie man mit Backpressure und ähnlichem umgeht.

00:39:16Was uns intern betrifft, versuchen wir immer noch, den richtigen Weg zu finden.

00:39:21Ein Teil von mir ist einfach nur überwältigt von der Kapazität.

00:39:25Ich überrasche damit niemanden, das ist sicher keine einzigartige Erkenntnis.

00:39:29Aber eines muss ich sagen: Die Schwelle, um vom CLI-Prompt oder Codex zu einem wirklich

00:39:34hochwertigen, geschmackvollen Produkt zu kommen – ein Teil dieser Nuancen geht in all den Memes und dem Hype verloren.

00:39:41Ich habe Zweifel, ob man tatsächlich eine solche Menge an Token ausgeben und am Ende

00:39:45etwas erschaffen kann, das einen echten Mehrwert für die Welt bietet.

00:39:50Unsere bisherige Erfahrung zeigt natürlich, dass es viel Potenzial bei Sicherheitsaspekten gibt,

00:39:55etwa bei Code-Reviews, was massiv hilft.

00:40:01Aber das ist eher der Standard. Das sind Dinge, die nicht wirklich den entscheidenden Mehrwert liefern.

00:40:06Wenn es darum geht, etwas wirklich Wertvolles zu bauen, aus dem andere Nutzen ziehen,

00:40:11gibt es meiner Meinung nach noch eine große Lücke.

00:40:14Unser Team ist nach wie vor dafür verantwortlich, Geschmack, Einblicke und Kundenverständnis einzubringen,

00:40:19sowie die Empathie, die man einfach nicht direkt aus einer Chatbox bekommt.

00:40:25Vielleicht sind wir auch die Narren und könnten viel schneller sein, wenn wir einfach alles im “One-Shot”-Verfahren erledigen würden.

00:40:31Aber unser Ansatz ist nach wie vor, hohe Erwartungen an das Endergebnis zu stellen.

00:40:35Ja, natürlich können wir dadurch mehr erreichen. Und ich glaube, dass auch mehr Leute,

00:40:42die diesen Geschmack und diese Empathie besitzen, einen Mehrwert für den Nutzer schaffen können, weil die Hürde nun einmal der Code war.

00:40:47So gesehen programmiert heute fast jeder im Unternehmen – unser Designer ist mittlerweile ein “Vibe-Coder”.

00:40:53Er ist voll verantwortlich für die Website, aber es gibt auch viel Dashboard-Arbeit oder Produktmarketing,

00:40:57wo Leute – zwar nicht “Token-Maxing” betreiben – aber wenn es eine Bestenliste gäbe, wären sie wahrscheinlich ganz vorne dabei.

00:41:01Und das ist eine gute Sache. Es sind Enabler, weil diese Menschen über kritisches Denken verfügen,

00:41:06um geschmackvolle Produkte für Endnutzer zu liefern – die Barriere ist jetzt viel mehr der Code selbst.

00:41:11In gewisser Weise sehe ich darin einen der größten Vorteile, mehr noch als bei der reinen Programmierung.

00:41:16Nicht, dass die reine Programmierung davon nicht profitiert, aber der Flaschenhals bleibt dieser “Geschmack”.

00:41:20Und ich verbringe so viel Zeit damit, zahllose PRs zu prüfen – das ist die Kehrseite.

00:41:25Stimmt. Und die Menge an Code, die man reviewen muss...

00:41:30Ja, und dann gibt es diese obskuren Schwachstellen, für die es praktisch null Chancen gibt.

00:41:36Ich bin mir nicht einmal sicher, ob das als “Low” durchgeht, aber sobald es auftaucht, fühlt man sich verantwortlich.

00:41:40Das ist wohl normal. Aber manchmal hat man so viele offene PRs,

00:41:45dass es verrückt wird. Man muss das Urteilsvermögen bewahren: Nur weil man alles tun kann, heißt das nicht, dass man es tun sollte.

00:41:51Es gehört zu dieser LLM-Mentalität dazu.

00:41:56Urteilsvermögen darüber, was wirklich Wert stiftet, ist wichtiger denn je.

00:42:01Es gibt eine gewisse Befriedigung bei der Arbeit mit Agenten, ähnlich wie beim Abhaken einer To-Do-Liste.

00:42:06Manchmal schalte ich ab und will einfach nur meine Liste durchgehen: Häkchen setzen, fertig.

00:42:09Bei LLMs ist das ähnlich: Ich starte fünf, sechs Unterhaltungen gleichzeitig,

00:42:14die alle an etwas arbeiten und ihre eigenen Checklisten abarbeiten.

00:42:18Genau. Es gibt diese sofortige Belohnung, die einen manchmal überwältigt.

00:42:21Zumindest spreche ich da für mich selbst. Wie groß ist dein Team eigentlich?

00:42:26Wir sind zehn Personen. Das ist super schlank, Respekt!

00:42:31Es war schon immer mein Ziel. Ich sehe mich selbst nicht als den besten Manager,

00:42:34daher ist das für alle Beteiligten besser.

00:42:39Wir sind mitten in der Pandemie entstanden, also war Remote von Anfang an gesetzt.

00:42:44Wir haben von Beginn an auf erfahrene, extrem autonome Leute gesetzt.

00:42:48Wir haben im Grunde nur ein Meeting alle zwei Wochen, um Produkt und Infrastruktur zu besprechen.

00:42:53Wir versuchen, asynchron zu arbeiten, was sich gut auf KI-Anwendungsfälle überträgt,

00:42:57da wir ohnehin Leute eingestellt haben, die diese Autonomie mitbringen.

00:43:02Ich will nicht predigen, aber für uns funktioniert das.

00:43:06Es funktioniert für meine geistige Gesundheit, das ist die Hauptsache.

00:43:11Ich wollte noch auf deine Eingangsbehauptung zurückkommen: “Webhooks sind tot, die Zukunft ist das Event Gateway.”

00:43:15Hast du den Begriff geprägt oder gab es den schon? Was ist überhaupt ein Event Gateway?

00:43:23Ja, wir haben ihn geprägt, und es war sehr schwer, eine Produktkategorie aufzubauen, die noch nicht existierte.

00:43:29Ich meine, von Anfang an, wir sind quasi mitten in der Pandemie entstanden,

00:43:33Eine Zeit lang nannten wir es “Webhook-Management-Infrastruktur”.

00:43:38Das klingt alles nicht besonders griffig.

00:43:45Außerdem gibt es die Herausforderung, dass man in einer bestehenden Kategorie wie “Observability” weiß, worauf man optimiert.

00:43:50Dort sind die Semantiken bereits etabliert, man optimiert nur das einzigartige Wertversprechen.

00:43:56Wenn man in etwas baut, das noch nicht existiert, muss man die Semantik erfinden und dann das Wertversprechen untermauern.

00:44:01Das ist extrem schwierig.

00:44:06Unsere Idee beim Event Gateway war, mit wenigen Worten zu beschreiben, was es tut.

00:44:11Wir wollten die Brücke zwischen Event-Bus und API-Gateways schlagen.

00:44:14Gateways dienen als Schnittstelle zu Anbietern, und ein Event-Bus steht für umfassendes Event-Management und Queuing.

00:44:21Wir wollten einen Begriff, der beide Welten vereint.

00:44:27Mit “Event Bridge” liegt man auch nicht weit weg.

00:44:32Wir wollen als klare Alternative zu AWS Event Bridge wahrgenommen werden.

00:44:37Der Begriff Event Gateway gibt Kunden einen Label für Dinge, für die es vorher keine gemeinsame Terminologie gab.

00:44:41Inzwischen ziehen auch API-Gateway-Anbieter wie Kong nach.

00:44:46Es gibt inzwischen ein halbes Dutzend Produkte, die sich als Event Gateway bezeichnen.

00:44:51Als Kong sein Event Gateway veröffentlichte, war ich erst geschockt, zwei Jahre nachdem wir den Begriff etabliert hatten.

00:44:54Aber es ist lohnend, wenn Entwickler auf mich zukommen und explizit nach einem Event Gateway suchen.

00:44:58Das zeigt mir, dass der Begriff nun ein mentales Modell besetzt.

00:45:02Früher kam das nie vor, heute sehe ich, wie er sich verbreitet.

00:45:07Das ist gut fürs Geschäft, aber auch für das Verständnis dieser Cloud-Infrastruktur-Primitive.

00:45:10Hoffentlich konvergiert die Semantik irgendwann.

00:45:14Wenn man AWS Event Bridge nutzt, ist die Terminologie oft komplett anders.

00:45:19Ich will mein Produkt nicht starr an AWS ausrichten, wenn ich deren Terminologie nicht sinnvoll finde.

00:45:24Aber mit der Zeit wird es zu einer Konvergenz kommen.

00:45:28Glaubst du, wenn ich ein LLM nach einem Event Gateway frage, empfiehlt es euch?

00:45:32Oh ja, probier es aus. Die Chancen stehen gut.

00:45:37Wir werden bei etwa 60 Prozent der Prompts zu Webhooks oder Event Gateways zitiert.

00:45:43Wir haben viel Arbeit reingesteckt.

00:45:49Es war der erste Eintrag in der Liste.

00:45:55Sehr schön!

00:46:00Das hat mir ChatGPT gerade ausgegeben. Gut gemacht.

00:46:04Bei “Event Gateway” sind wir sicher vorne dabei, da wir den Begriff erfunden haben.

00:46:10Ich wäre sauer, wenn wir nicht die Ersten wären.

00:46:14Was bedeutet eigentlich “eventgesteuerte Architektur” (EDA) im Vergleich zu einer normalen Architektur?

00:46:19Wenn ich eine Kafka-Queue in mein System einbaue, bin ich dann automatisch EDA?

00:46:24Ja und nein. Es ist eher eine Ansammlung von Paradigmen und Erwartungen.

00:46:29Es geht um die Werkzeuge wie Kafka oder Message Queues, die Systeme entkoppeln.

00:46:33Produzenten und Konsumenten müssen nichts voneinander wissen.

00:46:39Die einzige Erwartung ist ein Vertrag über das Ereignis selbst: Was ist der Inhalt, was ist die Form?

00:46:45Oft gibt es Schemata, wie Avro oder Protobuf.

00:46:49Die Verantwortung des Konsumenten ist es, bei einem Ereignis wie “Bestellung erstellt” das Richtige zu tun.

00:46:54Organisationen, die EDA wirklich leben, haben systematisierte Muster.

00:46:58Es ist ein architektonischer Ansatz, um Dienste bewusst zu entkoppeln.

00:47:03Viele Firmen wählen einen hybriden Ansatz. Muss man zu 100% eventgesteuert sein?

00:47:08Nein. Aber mit zunehmender Komplexität und Abhängigkeiten ist das die natürliche Richtung.

00:47:12Es wird irgendwann unmöglich, alle Systeme eng zu koppeln.

00:47:16Früher war EDA auf große Unternehmen konzentriert.

00:47:20Das ändert sich jetzt, weil die Leute vertrauter mit den Mustern werden.

00:47:23Webhooks sind wie eine Einstiegsdroge, und die Tools werden besser.

00:47:28Denk an RabbitMQ, BullMQ auf Redis-Basis oder Python-Bibliotheken wie Celery.

00:47:34Es braucht nicht mehr zwingend große Architektur-Teams und teure Kafka-Deployments.

00:47:38Der Begriff hat jedoch etwas an Bedeutung verloren, auch wenn das manchen nicht gefällt.

00:47:43Für mich geht es vor allem um die Entkopplung von Systemen.

00:47:48Man muss über Aspekte wie Unabhängigkeit und Reihenfolge nachdenken.

00:47:52Wenn man Apps baut, kommen diese Sorgen hinzu.

00:47:57Wir versuchen, das für jeden zugänglich zu machen.

00:48:01Auch Workflow-Engines wie Temporal oder Ingest und trigger.dev überschneiden sich hier.

00:48:05Es gibt keine feste Definition mehr.

00:48:09Wer mehr darüber lernen will, sollte David Boyan folgen.

00:48:12Er war früher bei AWS und hat an Event Bridge gearbeitet.

00:48:15Die “Drawing-Explainers”.

00:48:15Er hat eine ganze Serie dazu.

00:48:20Sehr empfehlenswert.

00:48:24Danke für die Tipps.

00:48:25Sehr gerne.

00:48:27Hat Spaß gemacht.

00:48:27Das ist etwas, das wir nachverfolgen. Wir werden in etwa 60% aller,

00:48:31aller Prompts zu Themen wie WebEx oder Event-Gateways und Ähnlichem genannt.

00:48:35Das ist cool. Und es ist etwas, in das wir offensichtlich viel Zeit investiert haben. Und was unsere Daten

00:48:42betrifft, die vielleicht nicht von höchster Qualität sind, machen wir einen ziemlich guten Job. Also

00:48:46Bis dann.

00:48:48Tschüss.

00:48:49Tschüss.

00:48:49Die ChatGPT mir gerade gegeben hat. Also gut gemacht.

00:48:52Ja. Obwohl ich denke, dass wir beim Event Gateway wahrscheinlich genauso gut sind

00:48:56bei allen Arten von WebEx-bezogenen Anfragen und solchen Dingen. Aber Event Gateway ist definitiv

00:49:00ein Vorteil für uns, in dem Sinne, dass wir den Begriff geprägt haben, ich meine, ich,

00:49:03Mach's gut.

00:49:05Ich realisiere gerade, dass ich eigentlich gar nicht weiß, was ereignisgesteuerte Architektur bedeutet. Was ist der Unterschied

00:49:11zu einer normalen Architektur? Wenn ich zum Beispiel eine Kafka-Queue in mein System einbaue,

00:49:17habe ich dann automatisch eine ereignisgesteuerte Architektur?

00:49:21Ja und nein. Ich denke, wenn man von ereignisgesteuerter Architektur spricht, ist das

00:49:25eher eine Reihe von Paradigmen und Erwartungen, die man damit verbindet. Ein Teil davon sind

00:49:31sicherlich die Werkzeuge, oder? Du nutzt Kafka, Message Queues oder Event-Streaming,

00:49:35die dazu dienen, Systeme zu entkoppeln. Im Grunde geht es also darum,

00:49:39dass man Producer und Consumer hat. Diese Systeme müssen nichts voneinander wissen,

00:49:43sie müssen nichts über den anderen wissen, richtig? Ein Consumer kann einen Event-Stream konsumieren,

00:49:47der von irgendwem produziert wurde. Die einzige wirkliche Erwartungshaltung, die man hat,

00:49:53ist ein Vertrag darüber, was das Ereignis selbst ist. Wie sieht die Nutzlast aus, wie ist die Struktur?

00:49:57Ja. Und oft gibt es Schemas, wie zum Beispiel Avro-basierte Schemas, Protobuf und ähnliches,

00:50:02bei denen es standardisierte Erwartungen an die Nutzlasten gibt und so weiter.

00:50:06Der Vertrag dreht sich also darum, dass diese Ereignisse existieren. Und als Consumer

00:50:11habe ich die Verantwortung, das zu tun, was bei einer Bestellung oder einem Produkt-Update erforderlich ist.

00:50:16Richtig. Aber eine Organisation, die wirklich auf EDA setzt, systematisiert dieses Muster,

00:50:21mit spezifischen Richtlinien dafür, wie man das macht und wie die Nutzlasten aussehen sollen.

00:50:25Es ist ein architektonischer Ansatz, bei dem man Dienste absichtlich entkoppelt

00:50:29und die Kommunikation zwischen ihnen ereignisgesteuert gestaltet.

00:50:32Ich habe das Gefühl, dass viele Unternehmen einen hybriden Ansatz verfolgen, oder?

00:50:36Einiges ist ereignisgesteuert, anderes nicht. Ist das Ziel also, 100% ereignisgesteuert zu sein?

00:50:41Oder ist es nur ein Teil eines architektonischen Paradigmas?

00:50:45Ich glaube nicht, dass 100% das Ziel ist. Ich denke, mit zunehmendem Wachstum und Komplexität

00:50:50und immer mehr Abhängigkeiten von Drittanbietern ist es einfach der natürliche Weg.

00:50:54Denn irgendwann ist es sehr schwierig, all diese Systeme fest miteinander zu koppeln.

00:51:00Man muss dann über Skalierung und gegenseitige Abhängigkeiten nachdenken,

00:51:04was sehr schwierig wird. Allgemein gesprochen denken Menschen beim Begriff ereignisgesteuerte Architektur

00:51:09zurecht an große Unternehmen. Im ersten Jahrzehnt war das vor allem dort konzentriert.

00:51:14Aber das ändert sich jetzt, weil die Leute vertrauter mit den Mustern werden und die Werkzeuge besser werden.

00:51:19Ich denke da zum Beispiel an RabbitMQ oder BullMQ, das auf Redis basiert.

00:51:23Es gibt auch viele beliebte Bibliotheken wie Celery für Python oder Sidekiq für Ruby.

00:51:28Es gibt jetzt auch Foundation von den Machern von Sidekiq. Es gibt also immer bessere Werkzeuge,

00:51:32die es einfacher und weniger einschüchternd machen, damit anzufangen.

00:51:37Webhooks eine Art Einstiegsdroge dafür sind. Und auch, weil die Werkzeuge immer besser werden. Ich denke da zum Beispiel an,

00:51:41Aber ich glaube auch, dass der Begriff ein wenig an Bedeutung verloren hat. Manche mögen das nicht hören,

00:51:46aber die Definition ist mit der Zeit etwas verwässert worden.

00:51:51Wenn ich den Begriff verwende, meine ich vor allem die Entkopplung von Systemen.

00:51:57Und auch die Programmieraspekte, über die man sich als Ingenieur Gedanken machen muss,

00:52:01wie zum Beispiel Abhängigkeiten und die Reihenfolge von Ereignissen.

00:52:05Wenn man also mit ereignisgesteuerter Architektur beginnt, betritt man eine Welt,

00:52:11in der man mit genau diesen neuen Herausforderungen konfrontiert wird.

00:52:15Verstanden. Man muss lernen, wie man seine Software aufbaut, um diesen Anforderungen gerecht zu werden.

00:52:19Ich weiß nicht, ob ich das sofort im Sinne eines großen Unternehmens meine.

00:52:25Wir versuchen im Grunde, das für alle zugänglich zu machen.

00:52:31Es gibt auch viele andere, die verschiedene Ansätze verfolgen.

00:52:37Workflow-Engines und Step-Functions wie Temporal oder Trigger.dev überschneiden sich da auch.

00:52:43Ich denke, es ist also eine sehr spannende Entwicklung.

00:52:48Richtig. Ich verstehe, worauf du hinauswillst.

00:52:52Das klingt nach einem interessanten Ansatz.

00:52:58Definitiv, danke für die Erläuterung.

00:53:03im großen Unternehmensmaßstab. Und ich glaube, in gewisser Weise versuchen wir, das irgendwie,

00:53:08ja, irgendwie für alle zugänglich zu machen. Richtig. Und wir sind nicht der einzige Akteur,

00:53:14der das tut. Es gibt eine Reihe anderer Leute, die unterschiedliche Ansätze verfolgen.

00:53:18Es gibt all diese Workflow-Engines und Step-Functions, die sich meiner Meinung nach überschneiden,

00:53:22wie Temporal, Ingest, Trigger.dev und so weiter. Ich glaube also tatsächlich, dass es ein

00:53:28Bereich ist, in dem sich viel tut. Und es gibt vielleicht keine wirklich gute, feste Definition

00:53:34mehr dafür. Für diejenigen, die wirklich daran interessiert sind, mehr

00:53:38über ereignisgesteuerte Architektur und die damit verbundenen Paradigmen zu erfahren,

00:53:42gibt es diesen Typen namens David Boyan, der früher Developer Advocate bei AWS war und tatsächlich an EventBridge arbeitete.

00:53:49Das sind diese Serien von zeichnungsbasierten Erklärungen. Aber mittlerweile hat er wahrscheinlich

00:53:55mehrere hundert davon, und er betreibt jetzt auch ein Open-Source-Projekt namens Event Catalog, das vielleicht ein weiterer

00:54:02guter Podcast-Gast für euch wäre. Aber alles in allem geht es so tief in die Materie,

00:54:07dass es fast schon unangemessen ist. Richtig. Also empfehle ich das definitiv für diejenigen, die

00:54:14neugierig sind. Cool. Wir packen es in die Shownotes. Ja, all dein Wissen über Events und Webhooks

00:54:19und alles andere. Du hast also eine Menge davon durch den Aufbau von Hookdeck gelernt.

00:54:23Oder war es, du sagtest ja vorhin, dass du einige Probleme mit Webhooks hattest, aber war das der Moment,

00:54:27in dem du wirklich tief in Events eingetaucht bist? Auf jeden Fall. Und ich glaube, das Wissen kam sehr stark von

00:54:34den Problemen, aber auch von den ersten Prinzipien in dem Sinne, dass ich, als ich mit diesen

00:54:38Problemen zu tun hatte, eigentlich nicht viel Wissen darüber hatte, was ein Teil davon war, warum ich überhaupt

00:54:42mit diesen Problemen zu kämpfen hatte. Ja. Ich glaube also, es kam sehr stark daher, dass ich

00:54:47versucht habe, das Problem und dessen Lösungen zu verstehen, anstatt mich auf Lösungen zu konzentrieren und

00:54:51diese dann nachträglich auf das Problem anzuwenden. Richtig. Aber am Ende des Tages,

00:54:55haben wir bis jetzt mit hunderttausenden von Webhooks gearbeitet, aus allen Bereichen.

00:54:59Ich habe also einfach viel aus diesen Gesprächen aufgesogen. Und ja, es war im Grunde genommen

00:55:05ziemlich interessant. Ich habe eigentlich ursprünglich als Produktdesigner angefangen. Also,

00:55:11Produktdesigner, dann Full-Stack-Entwickler, dann Back-End,

00:55:15dann Infrastruktur-Ingenieur. Und jetzt bin ich sehr, sehr tief im

00:55:21Kaninchenbau gelandet. Aber das kam einfach dadurch, dass ich mit Kunden gearbeitet habe und auf ihre

00:55:26Anliegen gehört und die Architektur überprüft habe, und so weiter. Aber auch durch das Team,

00:55:30richtig? Wir haben Leute im Team, die eine Menge Erfahrung mit diesen Systemen haben

00:55:33und dieses Wissen ins Unternehmen eingebracht haben. Ja. Wann hast du

00:55:38realisiert, dass du einen Markt dafür gefunden hattest? Ich nehme an, du hast angefangen daran zu arbeiten und es dann

00:55:42irgendwo gepostet. War die Resonanz fast sofort gut? Oder war es ein eher langsamer

00:55:47Prozess, bis die Leute wussten, dass dies die bessere Option ist? Langsam ist kaum der richtige Begriff,

00:55:53denn es fing mit diesem Medium-Artikel an, auf den ich mich beziehe, richtig? Über Webhooks

00:55:57und dass man etwas dagegen tun kann. Ich bin sehr in der Denkweise verhaftet, Produkte für Leute zu bauen.

00:56:01Die erste Version war also eine Art Self-Service-Tool, man konnte reingehen und seine erste Verbindung erstellen,

00:56:07wie wir es nannten, und all diese Dinge.

00:56:12Und ich habe diesen Artikel gepostet. Es gab keine Ambitionen, ein Geschäft daraus zu machen

00:56:16oder was auch immer. Es war nur eines von 20 anderen gescheiterten Nebenprojekten, an denen ich damals

00:56:21gearbeitet habe. Und im Nachhinein erscheinen die Zahlen jetzt unglaublich klein,

00:56:26denn vielleicht haben sich fünf Leute auf diesen Artikel hin gemeldet oder so.

00:56:32Aber jeder, der an Nebenprojekten gearbeitet hat und versucht hat, jemanden dazu zu bringen,

00:56:37etwas zu benutzen, das er gebaut hat, weiß, dass fünf Leute verdammt verrückt sind.

00:56:42Das ist besser als alles, was ich jemals zuvor hatte. Also war ich super aufgeregt deswegen.

00:56:48Ich war tatsächlich in meinem Campervan in British Columbia beim Klettern. Ich war sehr weit davon entfernt,

00:56:55ein Startup zu gründen oder was auch immer. Ich hatte einfach Gespräche mit diesen Leuten,

00:57:00bin mit ihnen durchgegangen, was ich dachte und welche Probleme sie hatten.

00:57:05Und dann trudelten nach und nach vielleicht einer pro Woche ein. Und ich war beim Klettern,

00:57:08holte Slack raus und sah die Benachrichtigung. Wir haben diesen Benachrichtigungskanal

00:57:13für alle Anmeldungen, denselben, den wir seit sechs Jahren haben.

00:57:18Mittlerweile ist es ziemlich schwierig, den Überblick zu behalten, weil es so schnell scrollt.

00:57:21Aber ich sah diese Benachrichtigung im Kanal und dachte: Oh Scheiße,

00:57:25jemand hat sich angemeldet. DDoSst du Slack?

00:57:31Nein, definitiv nicht in jenen Tagen. Aber du hast gesagt, du hast ihn immer noch.

00:57:38Ja, Dinge laufen gut, aber nicht so, dass ich Slack DDoSse.

00:57:44Also, eine Kernannahme am Anfang, die problematisch war, war die Idee, dass es nur für Observability gebaut ist.

00:57:48Ich glaube, das war nicht weit genug gedacht. Aber sobald man davon ausgeht,

00:57:54ich baue ein Observability-Tool, hin zum Neuerfinden eines Message-Busses, öffnet sich der Bereich dramatisch.

00:57:58Ich traf meinen CTO und Mitgründer mitten in der Entwicklung der ersten Queueing-Engine.

00:58:02Als ich merkte, dass sich der Rahmen komplett öffnet, haben wir uns um eine kleine Pre-Seed-Finanzierung

00:58:08durch Angel-Investoren bemüht. Es war offensichtlich, dass die Entwicklung ziemlich teuer werden würde.

00:58:15Und wie ich verstehe, bist du nicht den typischen SF-Weg gegangen. Du hast es in Montreal aufgebaut, oder?

00:58:19Ja, das ist vielleicht ein wenig unaufrichtig. Wir haben eine Pre-Seed-Runde

00:58:23von etwa 400.000 Dollar von Angel-Investoren bekommen, keine institutionellen VCs.

00:58:28Aber ein paar Monate später waren wir auf Hacker News.

00:58:32Die Resonanz auf Hacker News war nicht der größte 'Show HN'-Moment aller Zeiten,

00:58:36aber viel besser, als wir erwartet hatten.

00:58:39Eine lustige Anekdote: Ein Typ kaufte einen 300-Dollar-Plan nach HN.

00:58:44eine Pre-Seed-Runde von etwa 400.000 Dollar nur von Angel-Investoren, also keine institutionellen VCs. Aber dann

00:58:51nach ein paar Monaten hatten wir unsere „Accurate News“ und da wussten wir irgendwie, um auf

00:58:56deine Frage zurückzukommen, James, die Resonanz auf die „Accurate News“, ich meine, es war nicht

00:59:00die größte „Show HN“-Veröffentlichung aller Zeiten, aber sie war viel besser, als wir es jemals

00:59:05erwartet hätten, und eine lustige Anekdote: Ich erinnere mich, dass ein Typ einen 300-Dollar-Plan kaufte,

00:59:11Wir haben dann eine Runde bei einer Silicon-Valley-Firma namens Matrix Partners aufgenommen.

00:59:18Das war's. Wir wussten, wir schaffen es auf jeden Fall.

00:59:22Sind an dem Abend essen gegangen und haben alles ausgegeben. Und noch mehr.

00:59:25Ich bin sehr froh darüber. Wegen COVID gibt es eine wachsende Akzeptanz,

00:59:31dass Firmen nicht mehr an einem Ort sein müssen.

00:59:34Wir haben das nicht erfunden, Zapier und GitLab haben das schon viel länger gemacht.

00:59:38Es ist normal geworden.

00:59:44Ich bin vielleicht naiv, aber als kanadische Gründer gibt es das Thema,

00:59:50dass man in Delaware gründen muss und YC keine kanadischen Firmen mehr akzeptierte.

00:59:55Sie haben die Entscheidung revidiert, aber es hieß, jeder Investor werde das verlangen.

01:00:00Und sie haben recht, jeder Investor wird fragen.

01:00:04Der Punkt, der in der Geschichte fehlt, ist, dass man einfach 'Nein' sagen kann.

01:00:08Sicher, sie werden fragen, warum nicht, und es ist einfacher für sie.

01:00:12die GitLab und all diese anderen Leute, die das schon viel länger machen als alle anderen.

01:00:17Letztendlich ist es ihr Job, Kapital einzusetzen.

01:00:21Sie suchen nach Leuten, in die sie investieren können.

01:00:27Ich will nicht über das Für und Wider debattieren.

01:00:32Es ist deine Wahl als Gründer, mit wem und wo du es machst.

01:00:38Wenn du gute Ideen hast und die Arbeit hineinsteckst, werden Investoren das respektieren.

01:00:42Vielleicht ist es deine Aufgabe, sie zu finden.

01:00:47Ich bin sehr froh, in Montreal zu sein.

01:00:54Als Mit-Kanadier ist es schön, kanadische Erfolgsgeschichten zu hören.

01:00:58Fair genug. Als Commonwealth-Mitglied, gleicher König, alles das Gleiche, oder?

01:01:03Ja, wir haben die Königin. Ich weiß nicht, ob es jetzt der König ist.

01:01:07War Hookdeck dein erstes Startup, oder gab es andere?

01:01:11Ich war schon immer sehr unternehmerisch, habe mit 14 oder 15 Computern repariert.

01:01:15Es gab viele gescheiterte Nebenprojekte.

01:01:19Ich habe ein Videospiel veröffentlicht, das nirgendwohin führte.

01:01:24Ich habe mal an einem sozialen Netzwerk gearbeitet, obwohl ich der Schlechteste bei gesellschaftlichen Dingen bin.

01:01:27Diese E-Commerce-Firma war sehr prägend.

01:01:31Ich war der erste Mitarbeiter und war sehr in das Gründungsteam eingebunden.

01:01:36Wir wuchsen in drei Jahren von vier auf 40 Leute.

01:01:41Ich betrachte Hookdeck als das Erste, aber es gab vorher schon ein wenig Kontakt zu Investoren.

01:01:47Unser erster Investor in dem E-Commerce-Geschäft war auch unser erster bei Hookdeck.

01:01:52Es war nicht ganz bei Null angefangen.

01:01:57Ich habe nicht erwartet, vor ein paar Jahren hier zu sein.

01:02:06Ich habe von einer Firma namens Kiwi Mornings gehört, ein Startup für gesundes Frühstück. Was war das?

01:02:11Das war eines der gescheiterten Unternehmen.

01:02:14Meine Frau brachte Frühstück zur Arbeit mit, und die Sales-Leute wurden eifersüchtig.

01:02:19Schließlich machte sie jeden Morgen fünf bis sechs Frühstücksportionen.

01:02:23Wir dachten: Warum machen wir nicht ein Geschäft daraus?

01:02:27Wir lieferten Zero-Waste-Frühstück in Gläsern in Büros.

01:02:34Ich habe es technisch übertrieben mit einem Slack-Bot für die Bestellungen.

01:02:38Es endete, weil im Lebensmittelgeschäft um vier Uhr morgens alles schiefgeht und man kaum Geld verdient.

01:02:44Wir haben den Bot verkauft und aufgehört.

01:02:48Das war im Januar 2021, zwei Monate vor COVID.

01:02:53Danach gingen fast alle Firmen in dem Bereich pleite.

01:02:58Wir hatten Glück mit dem Timing. Wir haben wohl 20.000 Frühstücksportionen verkauft.

01:03:03Ziemlich cool.

01:03:07Wir fragen Gäste immer nach ihren 'Hot Takes' über die Branche, KI oder was auch immer.

01:03:13Ich habe schon ein paar gegeben.

01:03:19Was ist dein 'brennend heißer' Take?

01:03:23Okay, das ist sehr technisch.

01:03:27Mein heißester Take: Poll-basierte Warteschlangensysteme sind sehr dumm im Vergleich zu Push-basierten Systemen.

01:03:31Wir haben keine Push-basierten Systeme, weil niemand ein gutes gebaut hat.

01:03:36Wenn man Warteschlangen und Konsumenten hat, braucht man für jede Queue einen Konsumenten.

01:03:39Das wird wahnsinnig, wenn man dynamische Queues will, z. B. pro Kunde.

01:03:44Ein Push-basiertes System erlaubt es, dass alle Queues an denselben Konsumenten pushen.

01:03:48Dieser Konsument kann ein API mit Load Balancer sein, das man horizontal skalieren kann.

01:03:54Ich habe gesehen, da gibt es eine Firma namens Kiwi Mornings, ein Startup für gesundes Frühstück. Was hatte es damit auf sich?

01:04:02Es ist schwer, Push-basierte Message Queues zu finden.

01:04:09Wenn die Durchsatzkontrolle beim Konsumenten liegt, ist es schwer.

01:04:14Das hängt von der restlichen Code-Performance ab.

01:04:19GCP Pub/Sub hat einen Push-Modus, aber die rammen die Rate hoch, bis die API langsamer wird.

01:04:24Dann drosseln sie wieder. Es ist ein ständiges Auf und Ab.

01:04:30Das ergibt keinen Sinn.

01:04:36Wenn man Push-basierte Queues baut, die feingranulare Kontrolle bieten, vereinfacht das die Architektur enorm.

01:04:41Das ist mein Take, für den ich sterben würde.

01:04:47Ich habe nicht alles verstanden, aber es klang vernünftig.

01:04:51Wer es verstanden hat, schaut euch Hookdeck an.

01:04:56Danke, Alex. Danke fürs Zuhören bei dieser Folge des Better Stack Podcasts.

01:05:01Findet uns überall, wo es Podcasts gibt: Spotify, Apple Music.

01:05:06Heute ist es ein Abschied von mir.

01:05:11Und ja, die Leute bestellten ihr Frühstück über den Slack-Bot und so weiter, nicht unbedingt

01:05:16es kam zu einem Ende. Es ist nur so, dass in diesem Geschäft alles um vier Uhr morgens schiefgeht

01:05:20und außerdem gibt es mit Lebensmitteln kaum Geld zu verdienen. Und wenn man diese beiden Dinge kombiniert,

01:05:25ist es sehr schwierig, ein erfüllendes Geschäft aufzubauen. Also haben wir irgendwann den

01:05:29Slack-Bot und alles andere verkauft und einfach aufgehört, es weiterzumachen. Aber zum Glück,

01:05:34war das im Januar 2021. Also etwa zwei Monate vor COVID. Und dann hat im Grunde jedes

01:05:42vergleichbare Unternehmen – es gab schon viele, die sich mit Mittagessen und ähnlichem beschäftigten

01:05:46wie etwa Büro-Mittagessen – im Grunde allesamt das Geschäft aufgegeben. Also hatten wir

01:05:52mit dem Timing etwas Glück, denn es wäre sowieso zu Ende gegangen. Richtig. Also,

01:05:57ja. Aber alles in allem haben wir wahrscheinlich 20.000 Frühstücke oder so verkauft, schätze ich.

01:06:01Oh, ziemlich cool. Ja, das ist ziemlich cool.

01:06:06Oh ja. Wir fragen unsere Gäste ja immer, was sind deine „Hot Takes“ über die Branche,

01:06:12KI oder was auch immer, schieß los. Ich habe das Gefühl, ich habe in diesem Gespräch schon ein paar abgegeben.

01:06:18Ich glaube, das hast du. Ja. Was ist dein heißester Take? So richtig brennend heiß.

01:06:22Ein brennend heißes Steak. Okay. Hier werde ich dich wahrscheinlich verlieren, weil es sehr tief in die

01:06:29Details der Event-gesteuerten Architektur geht. Ich bin mir sicher, einige unserer Zuhörer werden verstehen,

01:06:35was du sagst. Perfekt. Also mein heißester Take ist, dass Pull-basierte Consumer oder Pull-basierte

01:06:42Warteschlangensysteme im Vergleich zu Push-basierten Systemen einfach sehr dumm sind. Und der Grund, warum wir diese

01:06:49Push-basierten Systeme nicht übernommen haben, ist, dass niemand ein gutes Push-basiertes System baut. Und der Grund, warum ich das

01:06:56sage – und jetzt versuche ich, ein wenig Kontext dazu zu geben – ist, dass man beim Aufbau von Warteschlangen

01:07:02und Consumern für jede Warteschlange, in die man Ereignisse einfügt, auch einen Consumer braucht. Und dieser

01:07:07Consumer könnte irgendein lang laufender Worker sein, der die Warteschlange abfragt. Aber das

01:07:12Problem ist, wenn man dynamisch Warteschlangen haben will, sagen wir, man will eine Warteschlange pro

01:07:16Kunde, richtig? Weil man nicht möchte, dass ein Kunde die ganze Warteschlange blockiert oder

01:07:21die Kapazität des jeweils anderen beansprucht, das ist die Art von Problemen. Jetzt braucht man so viele Consumer wie

01:07:26Warteschlangen, was verrückt wird, weil man dieses Multiplexing-Problem hat, bei dem jede Warteschlange ihren

01:07:31Consumer braucht. Der große Vorteil bei Push-basierten Systemen ist, dass alle diese Warteschlangen an denselben

01:07:36Consumer senden können. Und dieser eine Consumer kann eine API mit einem Load Balancer davor sein, die man

01:07:41horizontal oder vertikal skalieren kann, ganz egal. Aber der Punkt ist, man kann das

01:07:45völlig entkoppelt von der Anzahl der tatsächlich vorhandenen Warteschlangen tun. Und ich denke, eines der Dinge, die wir

01:07:49sehen, ist, dass man bei immer komplexeren Anwendungsfällen mit immer

01:07:54granulareren Methoden endet, nach denen man Dinge in Warteschlangen einreihen möchte. Man möchte pro Thema, pro spezifischer

01:07:58Bedingung und pro Kunde in eine Warteschlange einreihen und so weiter. Und es wird völlig irre, weil man dann

01:08:02100 Warteschlangen, 100 Consumer, 100 Dead-Letter-Queues und das ganze Chaos hat, das

01:08:07damit einhergeht. Aber es ist heutzutage sehr schwierig, Push-basierte Nachrichten-Warteschlangen zu finden.

01:08:13Der Grund dafür ist, dass man verlagert, wo der Durchsatz kontrolliert wird. Wenn der

01:08:17Durchsatz im Consumer kontrolliert wird, ist jeder Consumer selbst dafür verantwortlich zu sagen: „Hey, ich möchte

01:08:2250 Nachrichten pro Sekunde oder gleichzeitig oder was auch immer.“ Und dann wird die Anzahl der Nachrichten, die man verarbeitet,

01:08:29zu einer Frage der Kapazität eines Workers: Wie viele Worker hast du? Und was ist die effektive

01:08:33Kapazität? Nur weil du sagst, du willst 50 pro Sekunde, heißt das nicht, dass es auch tatsächlich mit 50 pro Sekunde läuft,

01:08:37denn es hängt vom restlichen Code ab, ob dieser schnell genug ist und so weiter.

01:08:40Richtig. Ich denke, der Grund, warum wir nicht zu Push-basierten Warteschlangen übergegangen sind, ist, dass die meisten

01:08:45tatsächlich nicht die notwendige Granularität und Kontrolle über den Durchsatz bieten. Zum Beispiel

01:08:50hat GCP Pub/Sub zwar einen Push-Modus, aber im Push-Modus fahren sie im Grunde die Rate hoch,

01:08:55mit der sie Anfragen senden, bis deine API anfängt langsamer zu werden, an welchem Punkt sie es im Grunde

01:09:00verschlechtert haben. Und sobald es langsamer wird, drosseln sie die Übertragungsrate wieder. Was man also am Ende

01:09:06hat, ist, dass es sich hochschaukelt, hochschaukelt, der Server stürzt ab oder hat ernsthafte Leistungseinbußen,

01:09:11geht wieder ganz zurück auf null, und dann schaukelt es sich wieder hoch, hoch, hoch, hoch, geht wieder ganz

01:09:15zurück auf null. Und es ist einfach völlig durch. Es ergibt keinen Sinn. Richtig. Und ich denke, wenn man

01:09:20Push-basierte Nachrichten-Warteschlangen baut – und das ist eines der Themen, an denen ich arbeite –, wo man eine sehr feine

01:09:24Kontrolle über den Durchsatz und das exakte Verhalten der Verarbeitungsrate hat, vereinfacht das so vieles in deiner

01:09:29Architektur. Das ist also mein Take für die Leute, die sich auskennen, und einer, für den ich bereit bin,

01:09:34zu sterben. Ich meine, ich habe nicht alles verstanden, aber es klang vernünftig, weißt du?

01:09:40Ich denke, wenn du das verstanden hast, schau dir Hookdeck an. Ja, genau.

01:09:46Das weiß ich zu schätzen, ja. Nun, danke Alex. Danke, dass ihr diese Folge des

01:09:50Better Stack Podcasts gehört habt. Findet uns überall dort, wo es Podcasts gibt, bei Spotify, Apple Music oder irgendwo anders.

01:09:57Aber für heute heißt es Tschüss von mir. Tschüss von mir. Und tschüss von mir.

핵심 요약

Hookdeck ersetzt fehleranfällige Webhook-Strukturen und Pull-Warteschlangen durch ein standardisiertes Event Gateway, das Ereignisse gepuffert und kontrolliert an Endpunkte weiterleitet.

하이라이트

Hookdeck entwickelt zwei Hauptprodukte: das Event Gateway als spezialisierten Event-Bus für externe Ereignisse wie Webhooks und Outpost als Open-Source-Service zum Senden von Ereignissen.
Das Open-Source-Projekt Outpost läuft auf demselben Docker-Build wie die verwaltete Version, ohne private Forks oder ausgegliederte Funktionen.
Das Team hinter Hookdeck besteht aus zehn Personen und arbeitet komplett remote mit Fokus auf asynchrone Prozesse.
Pull-basierte Warteschlangensysteme benötigen pro Warteschlange einen eigenen Consumer, während Push-basierte Systeme alle Queues an denselben skalierbaren Endpunkt bündeln.
Hookdeck Radar analysiert aggregierte Statistiken von Anbietern wie Shopify, um Zustelllatenzen und Uptime netzwerkschonend zu überwachen.

타임라인

Produktportfolio und Entstehungsgeschichte von Hookdeck

Hookdeck baut das Event Gateway zur Standardisierung und Verwaltung externer Ereignisse wie Webhooks.
Das Open-Source-Projekt Outpost ermöglicht das deklarative Senden von Ereignissen direkt an Message-Bus-Destinationen.
Frustrationen beim Betrieb individueller E-Commerce-Software und unzuverlässige Webhooks motivierten die Entwicklung einer zentralen Lösung.

Die Produkte standardisieren die Interoperabilität verschiedener Drittanbieter wie Stripe, Shopify oder WhatsApp in einen einzigen Vertrag. Dabei übernimmt das Event Gateway die Konsumentenseite mit Filtern, Transformationen und Warteschlangen, während Outpost als Apache 2.0 Open-Source-Projekt die Publisher-Seite abdeckt. Die Idee entstand aus persönlichen Problemen bei der Verwaltung von E-Commerce-Infrastrukturen ohne integrierte Fehlerbehandlung oder Dead-Letter-Queue-Wiederherstellung.

Open-Source-Strategie und Community-Beiträge

Die verwaltete Version von Outpost nutzt exakt denselben Open-Source-Docker-Build ohne künstliche Funktionsbeschränkungen.
GitHub-Beiträge von Entwicklern dienen als starkes Signal für die Priorisierung neuer Roadmap-Funktionen.
Erwähnungen durch prominente Branchenpersönlichkeiten wie Vercel-CEO Guillermo Rauch steigerten die Aufmerksamkeit und Anmeldezahlen massiv.

Die Entscheidung für Open Source basiert auf einer klaren Ausrichtung der Anreize, da die Konsumentenseite deutlich größer ist als die Produzentenseite. Trotz Herausforderungen durch KI-generierte Pull Requests mit fiktiven APIs senkt die Offenheit die Eintrittsbarriere für Nutzer erheblich. Kunden tragen aktiv zur Weiterentwicklung bei, indem sie eigene Funktionen direkt im Repository implementieren.

Vergleich mit AWS EventBridge und Infrastruktur-Herausforderungen

Hookdeck arbeitet agnostisch über HTTP, während AWS EventBridge stark an das AWS-Ökosystem und integrierte Anbieter gebunden ist.
Hookdeck Radar misst aggregierte Latenzprofile und Verfügbarkeiten von Drittanbietern wie Shopify über die Zeit.
Anbieter-Ausfälle erzeugen nach der Wiederherstellung extreme Lastspitzen, die unvorbereitete Server durch Timeouts überlasten.

Im Gegensatz zu AWS EventBridge erfordert Hookdeck keine Code-Änderungen oder Zustimmung des Drittanbieters, sondern ersetzt lediglich die Webhook-URL durch eine Push-basierte Warteschlange. Überwachungstools wie Radar helfen dabei, schleichende Latenzverschlechterungen bei externen Anbietern von echten Systemausfällen zu unterscheiden. Nach längeren Ausfällen von Plattformen wie Shopify versuchen diese, den Rückstau geballt abzubauen, was bei unzureichender Skalierung zu kaskadierenden Fehlern führt.

Einfluss von KI, Teamstruktur und Begriffsschöpfung

Agentische Workflows und Cloud-Agenten erhöhen das Volumen an ereignisbasierten Anfragen und erfordern robuste Durchsatzkontrollen.
Das Hookdeck-Team arbeitet mit zehn Personen rein remote und setzt auf hochautonome Mitarbeiter mit minimalem Meeting-Aufwand.
Der Begriff Event Gateway wurde von Grund auf als Brücke zwischen Event-Bus und API-Gateway etabliert.

Künstliche Intelligenz verändert die Softwareentwicklung, verschiebt jedoch den Engpass von der reinen Codierung hin zu Produktgeschmack und Empathie. Die Erschaffung der neuen Produktkategorie Event Gateway erforderte das Definieren neuer Semantiken, die inzwischen auch von anderen Anbietern übernommen werden. Der Begriff der eventgesteuerten Architektur bedeutet dabei vor allem die gezielte Entkopplung von Systemen durch standardisierte Verträge.

Unternehmensanfänge und architektonische Hot Takes

Hookdeck startete nach einem Medium-Artikel als kleines Nebenprojekt in einem Campervan.
Eine Pre-Seed-Finanzierung von Angel-Investoren und der Start in Montreal legten den Grundstein für das Wachstum.
Push-basierte Warteschlangensysteme mit feingranularer Durchsatzkontrolle sind architektonisch deutlich überlegen gegenüber starren Pull-Modellen.

Nach ersten positiven Rückmeldungen aus einem Medium-Artikel und einem erfolgreichen Hacker-News-Launch folgten institutionelle Investoren wie Matrix Partners. Das Unternehmen bewies, dass weltweite B2B-Infrastruktur auch außerhalb von Silicon Valley aufgebaut werden kann. Zum Abschluss formuliert der Gründer einen radikalen technischen Standpunkt: Push-basierte Message Queues lösen das komplexe Multiplexing-Problem pro-Kunde-basierter Architekturen wesentlich effektiver als herkömmliche Pull-Warteschlangen.

커뮤니티 글

모든 글 보기

이 영상에 대해 글쓰기