Arquitetura Orientada a Eventos, Caos de Webhooks e a Ascensão dos Agentes de IA | Better Stack Podcast Ep. 17

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

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

스크립트

00:00:00Bem-vindos ao podcast Better Stack, onde conversamos sobre desenvolvimento de software,

00:00:04IA e todo tipo de tecnologia nova. Eu sou um dos seus anfitriões, Andrus, e hoje estou acompanhado por

00:00:10James e Alex. Ei, Alex, bem-vindo ao programa. Obrigado por me receberem, pessoal. Então, vamos começar

00:00:16com a empresa que você dirige. Ela se chama Hookdeck. Então, para aqueles que não estão familiarizados,

00:00:22o que é o Hookdeck? O que ele faz? Conte-nos mais sobre isso. Sim, gosto de pensar nele como a

00:00:27empresa de webhooks que está tentando acabar com os Webhooks. Essa provavelmente é uma história na qual podemos entrar.

00:00:32Mas construímos basicamente dois produtos principais. Um é o Event Gateway. O Event Gateway serve

00:00:37mais ou menos como um barramento de eventos especializado para todos os eventos que vêm de fora da sua infraestrutura.

00:00:41Webhooks são os principais suspeitos, mas vemos muitos casos de uso de IoT, baseados em SDK e assim por diante.

00:00:47Então, basicamente, fornecemos um endpoint não confiável. Você pode enviar qualquer evento para lá.

00:00:51E todas as funcionalidades para gerenciar esses eventos. Isso vai desde filtragem,

00:00:55transformação, roteamento, enfileiramento, alerta e gerenciamento de problemas; o replay é basicamente o pacote completo.

00:01:01Então, na verdade, ele cobre tanto a interoperabilidade, no sentido de que preciso receber

00:01:05eventos e webhooks de todos os fornecedores com os quais trabalho, certo? Pode ser Stripe, Shopify, Twilio,

00:01:10WhatsApp, TikTok, o que você quiser. Cada um deles tem seus próprios critérios, peculiaridades

00:01:16e requisitos específicos. E assim, podemos padronizar tudo isso e trazer

00:01:20isso para um contrato único. E então tudo a partir do ponto de vista de enfileiramento. E assim, por

00:01:27exemplo, como o Shopify, há uma venda relâmpago na sua loja e você é simplesmente

00:01:31inundado, uma debandada de eventos. Você normaliza isso para controlar a taxa de transferência e o gateway de eventos,

00:01:38e tudo mais. Então essa é uma grande parte disso. É basicamente o lado do consumidor. E é

00:01:42aí que a história do Hookdeck começou. E, mais recentemente, lançamos o Outpost. O Outpost é totalmente

00:01:49open source, um projeto Apache 2.0. E agora temos um serviço gerenciado para ele também. E é para enviar

00:01:55eventos. E, portanto, é o outro lado da equação, certo? É você como editor, como uma

00:01:59plataforma, uma ferramenta de desenvolvedor. Na verdade, agora, todo mundo também está enviando eventos. Fico surpreso

00:02:05todo dia. E assim, o Outpost é esse serviço gerenciado ou auto-hospedado que você pode usar para

00:02:12declarar quem são seus inquilinos, quais são os destinos, os endpoints que eles registraram, configurar

00:02:17tópicos e publicar eventos para eles. E lida com tudo, desde visibilidade, métricas, garantias de entrega,

00:02:23repetições e todos os suspeitos habituais em torno de assinaturas, rotação de assinaturas

00:02:28e tudo mais. A pequena piada que eu fazia sobre tentar matar os Webhooks é que o Outpost,

00:02:35sim, permite que você envie Webhooks, mas também permite que você publique eventos diretamente no barramento de mensagens

00:02:39do seu usuário. E assim, o Outpost suporta nativamente o que agora é conhecido como destinos de evento. E, portanto, o Webhook é

00:02:46pensado como o roteador de transporte. E, basicamente, você está enviando eventos via Webhooks e

00:02:53Webhooks são o mecanismo de transporte padrão, certo? E você pode escolher novos protocolos de transporte, coisas como MQ

00:02:59para RabbitMQ ou Kafka. E nós suportamos a publicação direta também para todos os suspeitos habituais como Pub/Sub,

00:03:05SQS, AWS EventBridge e, obviamente, o Hookdeck Event Gateway, certo? Então eu gosto de pensar nisso como o

00:03:12melhor destino, mas veremos se as pessoas acreditam nisso. Então você disse que quer matar os Webhooks. Então eu

00:03:18imagino que essa ideia e seu início tenham surgido do fato de que vocês estavam todos cansados de Webhooks ou que era

00:03:25muito difícil de gerenciar. Conte-nos como você teve a ideia. Sim, eu estava contando essa

00:03:31história para alguém outro dia. Há uns cinco anos, publiquei este artigo no Medium.

00:03:37Provavelmente estou chegando a seis anos agora. E o artigo é intitulado, fazendo referência ao que você está

00:03:42dizendo: “Webhooks são um lixo, mas há algo que você pode fazer a respeito”. E aquilo era apenas eu no meu

00:03:48porão, sabe, brincando e construindo uma espécie de protótipo V1 do Hookdeck.

00:03:54Mas surgiu muito dessa frustração. Eu trabalhava pessoalmente com comércio eletrônico e construímos

00:03:59muito software personalizado para impulsionar o comércio eletrônico, desde gerenciamento de assinatura personalizado até

00:04:05armazenamento, cumprimento de pedidos e tudo mais. E simplesmente tantos de seus problemas

00:04:10se resumiam a Webhooks. E era quase uma piada recorrente, porque, por um lado,

00:04:15eu estava tentando vender moda feminina, certo? Eu estava tentando vender

00:04:18lingerie e meias e coisas assim. E então, por outro lado, é como, onde diabos está o

00:04:23pedido ou o Webhook? O que aconteceu com ele? Parecia muito incompatível em termos de preocupações.

00:04:28E então, veio muito disso, apenas como, estou frustrado como consumidor desses Webhooks,

00:04:33que não existe uma maneira real, sabe, com tudo incluído de lidar com este

00:04:38problema. E se você entrasse online e procurasse por recomendação, quer dizer,

00:04:43os Webhooks não são novos. No fim das contas, são solicitações HTTP. Existem

00:04:46obviamente padrões estabelecidos sobre como você deveria lidar com isso. Mas então você

00:04:50rapidamente entra na toca do coelho. Ok. Ok. Você precisa de seus consumidores de ingestão que possam

00:04:55escalar automaticamente e então você precisa enfileirar em uma fila como o SQS. E então você precisa implantar um conjunto de

00:05:00consumidores que vão consumir do SQS. E se algo der errado, vai acabar

00:05:05na fila de dados. E então você precisa de algum script para conseguir se recuperar da fila de dados e

00:05:09entender por que as coisas acabaram lá em primeiro lugar. E existem todas essas preocupações.

00:05:14E à medida que a complexidade cresce, você também quer poder repetir eventos históricos que você

00:05:18recebeu. Você quer poder ver qual era especificamente o payload do Webhook.

00:05:22E então você começa a lidar com os diferentes fornecedores, porque, talvez o Stripe vá lhe dar

00:05:26uma interface e o Intercom não vai lhe dar uma interface. E então você tem todas essas

00:05:31peculiaridades diferentes com as quais você tem que lidar. E então, veio muito dessa frustração e

00:05:35apenas por que não havia uma solução para isso, certo? E a princípio, eu estava olhando para isso muito como

00:05:41um ponto de vista de observabilidade e não funcionou muito bem. A parte que eu de certa forma perco é que a observabilidade é

00:05:47apenas uma parte. No fim das contas, tenho esse ditado que chamo de o Webhook como a droga de entrada

00:05:51para arquitetura orientada a eventos. E a razão para isso, e é realmente também por que gosto de insistir

00:05:56no termo evento em vez de Webhook, é que atrás de cada Webhook existe um evento e existe

00:06:01agora paradigmas de arquitetura orientada a eventos que vêm empacotados com esse Webhook, certo? E assim, toda

00:06:07vez que você recebe um Webhook para qualquer escala séria ou nível de casos de uso críticos, você agora tem que

00:06:14pensar em idempotência, pedidos, garantias de entrega e todo tipo de

00:06:19desafio que você tem quando começa a lidar com um paradigma de programação assíncrona orientada a eventos.

00:06:25E, na verdade, muito do que construímos evoluiu para a construção de uma fila completa

00:06:29no fim das contas. Então, há essa interoperabilidade de que você tem certeza de que estamos lidando com eventos,

00:06:33mas todos esses tipos de semânticas são mais sobre lidar com eventos e subsistemas de publicação e assinatura

00:06:38e assim por diante em geral. E viemos de um lugar de não tentar reinventar as filas. Acho que nós tropeçamos

00:06:43em um monte de ideias realmente genuínas e legais. E uma coisa que estamos vendo agora é que

00:06:48as pessoas estão apenas mudando para o Hookdeck para trocar o Pub/Sub ou SQS da sua pilha, o que

00:06:53para mim é um pouco alucinante porque nós não executamos sua VPC e todo esse tipo de coisa. Acho

00:06:57que existem muitos problemas com isso, talvez, talvez, talvez no roteiro. Mas o ponto é, o ponto

00:07:05é que acho que existem muitas semânticas em torno da arquitetura orientada a eventos que as pessoas se acostumaram

00:07:09e ninguém questionaria realmente. E é como, por que estamos fazendo

00:07:13filas de mensagens mortas novamente? Que diabos está errado com isso? Porque não conheço ninguém que pense que

00:07:19uma fila de mensagens mortas é uma semântica conveniente para lidar com erros em suas filas, certo? Então, de qualquer forma, estou feliz em

00:07:25talvez tocar em algumas dessas coisas porque existem algumas opiniões fortes

00:07:29lá dentro. Não sei o quanto vocês são nerds de Pub/Sub e arquitetura orientada a eventos. Não quero

00:07:35arrastá-los muito para isso. Eu sinto que, sim, meu entendimento de filas de mensagens mortas e todas

00:07:40essas coisas é muito, muito superficial. Algumas das coisas que estou ouvindo hoje, ouço pela primeira vez.

00:07:48Sim, sim. Eu ia dizer que o meu também é bem superficial, mas lidei com webhooks

00:07:53bastante e lidei com alguns dos problemas que você mencionou. E acho que, é assim que

00:07:57vocês estão meio que defendendo o argumento de que webhooks são a droga de entrada para arquitetura orientada a eventos,

00:08:01porque aposto que para desenvolvedores da sua formação, webhooks é

00:08:06provavelmente a primeira exposição que vocês tiveram a, espera, isso é assíncrono. Como lido com isso?

00:08:12E acho que existe toda essa curva de aprendizado, certo? É como o clássico iceberg, onde é como,

00:08:17oh, você tem a solicitação HTTP que entra e então, sabe, o resto do iceberg

00:08:21atrás, tipo, na água, certo? E acho que uma das coisas que estou tentando

00:08:26fazer é trazer um nível de experiência do desenvolvedor (DX) que não foi realmente alcançado nesse espaço para que

00:08:32você não tenha que descobrir o resto do iceberg, certo? Existem algumas coisas que são um

00:08:37pouco inevitáveis, não quero representar mal. Acho que uma vez que você começa

00:08:40trabalhando com esse tipo de problema, você precisa ter um bom entendimento de idempotência,

00:08:45por exemplo, você precisa ter um bom entendimento de garantias de ordenação. Então,

00:08:49não é que você consegue resolver todos os problemas. Acho que você ainda lida com eventos

00:08:53no fim das contas. Mas acho que muita da semântica e complexidade vem principalmente

00:08:58de ferramentas que não foram bem pensadas, mais do que de uma complexidade genuína

00:09:05associada a esse espaço de problema. Então, acho que agora, atendemos dois

00:09:13tipos de clientes: atendemos os clientes que realmente conhecem o problema a fundo e

00:09:18que farão engenharia de solução em torno da configuração atual de Kafka deles e

00:09:23todo esse tipo de coisa, o dia todo. E então, oferecemos algumas dessas novas semânticas,

00:09:28e eles ficam muito animados com isso. Essa é uma categoria. Mas a outra categoria é,

00:09:31eu não quero ter que aprender nada disso. E, basicamente, tento

00:09:36evitar tudo isso. Então, vemos muitos desses dois perfis.

00:09:41Essa também é a razão pela qual você tornou essa ferramenta, a Outpost, open source, para facilitar para os desenvolvedores

00:09:47começarem a usá-la? De certa forma. A outra razão é porque não precisamos da Outpost

00:09:53para ganhar dinheiro. Então pensamos: acho que deveríamos torná-la open source. É só que,

00:10:01eu sei que grande parte da nossa audiência no YouTube gosta muito de conhecer novas ferramentas open source. Por isso

00:10:07que eu perguntei sobre isso também. Mas, antes de tudo, eu,

00:10:13me arrependo um pouco de, no início, não ter adotado uma abordagem mais

00:10:18focada em open source. Acho que há muitas coisas sobre como você desenvolve

00:10:21seu software que são muito diferentes quando você constrói para código fechado em vez de open source. Mas,

00:10:26sobre a decisão do open source, acho que uma coisa que vemos com startups

00:10:30financiadas por venture capital é que acabamos com esse tipo de open source fake,

00:10:34certo? É como se fosse open source, mas ou é open core, ou sim, é open source,

00:10:39mas eles realmente não querem que você use o open source, ou acabam tendo que relicenciar

00:10:44sob licenças que não são verdadeiramente open source e coisas do tipo. E acho,

00:10:49isso me deixou muito animado com a Outpost e o open source, porque senti que tínhamos a

00:10:54oportunidade de ter os incentivos certos. Talvez entremos um pouco nos detalhes de como pensamos

00:10:59sobre os negócios e tudo mais. Mas, na minha opinião, as pessoas que

00:11:03têm que receber webhooks do lado do consumidor são pelo menos duas a três ordens de magnitude mais

00:11:09numerosas do que as pessoas que precisam enviar um webhook, certo? Porque, pense bem, se eu envio webhooks,

00:11:13eu envio para todos os meus clientes, e meus clientes podem ser, sei lá, 10, se você estiver

00:11:17começando, ou 100, 1.000, 2 milhões. E, inevitavelmente, o lado do consumidor

00:11:24tem muito mais pessoas. E quando penso nisso do ponto de vista de empreendedor,

00:11:28fico mais empolgado com o negócio de focar no lado do consumidor. Mas acho que

00:11:33o que percebemos, obviamente, é que não existem consumidores sem bons produtores. E acho

00:11:37que há cada vez mais demanda por webhooks em geral, entre os aplicativos que você desenvolve. Então,

00:11:42mais pessoas querem oferecê-los e não querem passar por toda a complexidade e carga de trabalho

00:11:46e assim por diante. Mas da minha perspectiva, primeiro, enviar webhooks é um problema mais simples, porque você

00:11:51controla os parâmetros, enquanto do lado do receptor, você não controla; o fornecedor dita quais

00:11:57são os parâmetros. Então, não quero dizer que seja simples, mas é,

00:12:02e definitivamente há várias maneiras de fazer isso errado. Mas acho que, em termos de espaço

00:12:06de problema, é definitivamente mais limitado no lado do produtor do que no consumidor. E segundo,

00:12:10nosso trabalho, acho, é incentivar a produção de eventos. E é isso com que nos preocupamos no final,

00:12:15porque queremos que mais pessoas consumam esses webhooks e, eventualmente, se tornem

00:12:19clientes e coisas assim. E acho que isso nos coloca em uma posição onde podemos

00:12:23dizer com sinceridade: olha, se você vai usar a Outpost, quer você a torne open source ou a implante

00:12:29com a versão gerenciada da Hookdeck, geralmente não importa para nós. Estamos atingindo

00:12:35o objetivo de negócio de qualquer maneira. E esse incentivo alinhado me deixou muito

00:12:40animado. E acho que há algumas coisas que fizemos: primeiro, lançamos o open source

00:12:44antes mesmo de considerar construir uma versão gerenciada. Não havia nenhum plano de construir uma

00:12:48versão gerenciada quando criamos o código aberto. E o projeto de código aberto foi publicado há

00:12:52uns dois anos. Então, levou quase dois anos até que pessoas suficientes

00:12:57pedissem a versão gerenciada que acabamos construindo. Essa é uma parte. E a outra parte

00:13:03é que a versão gerenciada do Outpost executa exatamente a mesma compilação Docker publicada no

00:13:08Docker Hub a partir do código aberto, o que meio que confirma isso, no sentido de que não temos um

00:13:13fork privado. Não estamos empacotando recursos fora do código aberto. Estamos executando exatamente a mesma

00:13:19compilação Docker. Então, a questão para você não é, tipo, ah, ele oferece o recurso X ou Y,

00:13:23seja em qual versão for? É literalmente: você quer implantá-lo e cuidar

00:13:29da carga operacional associada a isso? Ou você quer pagar alguém para fazer isso por você?

00:13:34Certo. E não acho que exista uma resposta certa ou errada. Isso depende de cada negócio ou do nível de

00:13:38conforto ou da pilha tecnológica, dos requisitos de conformidade, o que você quiser. Mas por causa disso,

00:13:44sinto que podemos ser bons colaboradores para a comunidade de código aberto com esse projeto. E sim,

00:13:51fiquei muito feliz em trabalhar nisso, porque é o primeiro grande projeto de código

00:13:55aberto em que estou envolvido, além de receber contribuições

00:14:01e tudo mais, mas como um mantenedor principal. E, sim, tem sido bom.

00:14:05Como tem sido para você o mundo do código aberto agora que o Claude Code e tudo isso existem? Você

00:14:09tem recebido muitos PRs e vulnerabilidades de segurança que não são reais ou tem sido fácil de gerenciar?

00:14:14Hum, veja, não acho que estamos em uma escala em que eu possa falar sobre o que outras pessoas estão

00:14:20vivenciando. Então, definitivamente não quero deturpar a situação, porque definitivamente

00:14:25parece ruim para muita gente. Vou dizer que me surpreendi com a qualidade e

00:14:30a contribuição que tivemos, mas também tivemos contribuições em que há um

00:14:34PR específico, acho que ainda está aberto no repositório agora, que é para adicionar Cloudflare Queues como

00:14:40um destino. Como um dos destinos de eventos suportados, certo?

00:14:44A descrição parece boa no PR e tudo mais. E quando você realmente analisa

00:14:48o código, ele está usando um monte de APIs do Cloudflare completamente inventadas.

00:14:52E eles não verificaram. Quero dizer, claramente a pessoa que abriu o PR nem sequer

00:14:56tentou executá-lo. Certo. E agora o fardo está conosco, de tipo, ok,

00:15:02agora que existe este PR aberto, porque obviamente estou um pouco preocupado em ser percebido como

00:15:08alguém que não está tentando encorajar pessoas com quem poderíamos ser vistos como concorrentes.

00:15:12Então, eu realmente acho que deveríamos adicionar Cloudflare Queues e tudo mais, mas ao mesmo

00:15:15tempo, não estava no roteiro, ninguém além dessa pessoa pediu por isso e

00:15:19tudo mais. Certo. E agora está nesse estado ambíguo onde, ok, se você fechar,

00:15:24parece que você não quer apoiar pessoas que poderiam ser percebidas como concorrentes. Certo.

00:15:28Mas então você dedica recursos e altera seu roteiro e coisas do tipo,

00:15:33para ter certeza de que implementou corretamente? Certo. Então tem sido um dilema com esse

00:15:37tipo de situação. Mas, até agora, sinto que tem sido uma experiência muito boa e

00:15:43especialmente porque usamos a mesma compilação. Uma coisa que adotamos é que, sempre que

00:15:48os clientes entram em contato para dar feedback ou falam conosco sobre recursos específicos e assim por diante,

00:15:53abrimos issues no GitHub, ou indicamos PRs existentes, issues existentes e tudo mais.

00:15:58E meio que tentamos sempre garantir que as pessoas saibam, a propósito, o repositório está lá

00:16:03e você pode contribuir. E, aliás, nesse ponto, tivemos vários usuários

00:16:07da versão gerenciada que fizeram contribuições e basicamente foram lá e implementaram seus próprios recursos.

00:16:13Certo. E acho que isso reduziu imensamente a barreira de entrada para esse tipo de

00:16:18uso genuíno para contribuições. Porque, historicamente, os projetos em Go,

00:16:24a maioria dos nossos usuários provavelmente nem são desenvolvedores Go, para começar. Certo. Vemos muitos de

00:16:28Python, TypeScript, obviamente Node.js, e há uma barreira de entrada para Go. E também

00:16:35aprender um novo projeto para contribuir não é trivial. Certo. E por isso,

00:16:39acho que isso reduziu substancialmente a barreira de entrada. E isso é muito bom.

00:16:42Porque agora, se como usuário você está com essa necessidade de que algo te incomoda,

00:16:48além disso, como mantenedor, esse é um sinal muito forte de que vale a pena construir esse recurso.

00:16:53Alguém faz um esforço extra e gasta seus, sabe, tokens de palavras implementando isso.

00:16:58É um sinal de que, ok, isso realmente importa. Certo? Em termos de, tipo, classificação de ações,

00:17:02tipo, você sabe, o que é mais importante. Então acho que reduzir a barreira de entrada é muito bom.

00:17:07E então acho que se você conseguir superar as comportas de spam e todas essas coisas,

00:17:12há muitos pontos positivos nisso.

00:17:14Na página inicial, uma coisa que realmente me chamou a atenção foi um depoimento do CEO da Vercel.

00:17:21Então a Vercel está realmente usando o Hookdeck como um produto também.

00:17:25Que se você ler aquela citação específica, ele está recomendando também.

00:17:29Ah, entendi.

00:17:29Tipo, para os usuários da Vercel e esse tipo de coisa.

00:17:32Hum, mas na verdade tem uma história engraçada aí.

00:17:35Porque o Guillermo tuitou sobre isso em um sábado à noite.

00:17:39Eu não tinha ideia de que estava por vir.

00:17:40Eu realmente não tenho um relacionamento prévio com o Guillermo e esse tipo de coisa.

00:17:45E isso pode falar sobre a influência de algumas pessoas na comunidade.

00:17:48Porque a quantidade de cadastros e conscientização e assim por diante que conseguimos com isso foi,

00:17:53tipo, insana.

00:17:54Hum, desde então, eu e o Guillermo temos mantido contato aqui e ali.

00:17:57E sempre foram boas conversas e tudo mais.

00:17:59E é interessante.

00:18:00Porque, na verdade, se você olhar para uma empresa como a Vercel, uma coisa que o Guillermo me dizia

00:18:04é que ele está vendo muito mais pessoas usando Webhooks agora.

00:18:07E a leitura dele sobre isso é que é impulsionada principalmente por opções de LLM.

00:18:12E isso está criando novos casos de uso para dados.

00:18:15Com os quais você normalmente não se importaria antes.

00:18:18Tipo, pense no seu sistema de suporte ao cliente.

00:18:20Por exemplo, você tem seus agentes e humanos lá dentro.

00:18:23E há muito pouca razão para fazer qualquer coisa com, você sabe, eventos de novos tickets.

00:18:29E esse tipo de coisa.

00:18:30Porque, de qualquer forma, é o humano que vai lá responder a essa mensagem.

00:18:34Mas agora estamos obviamente em um mundo onde isso está mudando completamente.

00:18:37E quando você passa dos humanos acionando os agentes, o que aciona os agentes? São os eventos.

00:18:42Certo.

00:18:42E de repente, agora você se importa com os eventos do seu sistema de suporte ao cliente, da sua

00:18:46ferramenta de marketing e seu blá, blá, blá.

00:18:48Certo.

00:18:48E então, essa é definitivamente algo que eu acho que eles estão vendo como plataformas.

00:18:54E esse tem sido um ponto de discussão interessante para nós, obviamente.

00:18:57Mas sim, a Vercel especificamente, apenas para qualificar, não é diretamente um usuário.

00:19:01Quero dizer, tenho certeza de que um monte de desenvolvedores usam sua CLI local e esse tipo de coisa

00:19:05na Vercel, mas, uh, sim.

00:19:06Então, qual é o cliente típico de alguém usando o Hookdeck?

00:19:10Tipo, se eu tivesse, não sei, uma pequena loja de comércio eletrônico de camisetas ou algo assim, como eu

00:19:15usaria o Hookdeck para isso?

00:19:17E faria sentido usá-lo nesse caso?

00:19:19Provavelmente não.

00:19:21Certo.

00:19:22Você está me fazendo a pergunta de um milhão de dólares, no sentido de que acho que é

00:19:26algo com o qual sempre lutamos, no sentido de que a amplitude das razões pelas quais você usaria

00:19:32Webhooks ou depende de Webhooks é insanamente grande.

00:19:35Recebemos Webhooks dos suspeitos de costume, como Stripe e Shopify, mas também temos

00:19:40Webhooks vindo de todos os provedores de telecomunicações australianos e da câmara de compensação do Reino Unido.

00:19:47E na verdade tem um monte vindo do jogo EVE Online.

00:19:50Tem também uma comunidade de pessoas ainda jogando esse jogo, Conan, o Bárbaro,

00:19:55de 15 anos atrás ou algo assim.

00:19:58E eles são grandes usuários de Webhooks também.

00:20:00Não me pergunte por quê.

00:20:00Certo.

00:20:01Mas o ponto é que existe uma amplitude que é muito difícil de capturar e dizer:

00:20:06estes são nossos clientes.

00:20:08Certo.

00:20:09E quando olhamos para as pessoas que usam, não há um único caso de uso

00:20:13ou grupo ou o que quer que seja.

00:20:14Que represente mais de 10%.

00:20:16Mas chegando ao seu caso de uso de comércio eletrônico, ou seu exemplo.

00:20:19Primeiro de tudo, uma pequena loja de camisetas provavelmente não construiu aplicativos personalizados

00:20:25e esse tipo de coisa que dependeria disso.

00:20:27Mas eles quase certamente instalaram aplicativos.

00:20:30Como, por exemplo, um aplicativo para coletar avaliações, um para notificações de reposição de estoque,

00:20:35um para gerenciamento de inventário e um para seu 3PL.

00:20:39E todos esses caras confiam quase exclusivamente em Webhooks.

00:20:43Certo.

00:20:43Então, se eu quiser enviar uma notificação de reposição de estoque, o que eu faço é ouvir todas as atualizações

00:20:48de estoque na loja Shopify através dos Webhooks deles.

00:20:50E assim que um produto que estava sem estoque agora está com estoque,

00:20:53eu penso: ok, tenho que enviar o e-mail.

00:20:54Certo.

00:20:55Então, basicamente, tudo o que eles vão instalar ou adicionar e assim por diante vai

00:20:59depender de Webhooks nos bastidores.

00:21:00E essa é definitivamente uma categoria grande.

00:21:02As pessoas estão construindo aplicativos e não é apenas o Shopify, obviamente, a Stripe, por exemplo,

00:21:07tem um grande mercado de aplicativos.

00:21:09E vários deles são clientes, esse tipo de coisa.

00:21:11A outra coisa que veremos são lojas grandes.

00:21:14Como pense na Gymshark, Good American, Rogue e esse tipo de coisa,

00:21:19onde eles têm suas próprias equipes técnicas e constroem aplicativos personalizados.

00:21:22Eles estão construindo aplicativos personalizados para a integração de seus sistemas, muitas vezes muito operacionais

00:21:28em termos de, tipo, sequenciamento e quando um pedido precisa ser sincronizado com um 3PL e precisa de anotações.

00:21:34E talvez haja preferências específicas do cliente que precisam ser adicionadas a esses dados

00:21:39antes de chegar ao 3PL, esse tipo de coisa.

00:21:41Certo.

00:21:41E parte disso vai capacitar experiências de usuário, coisas como, você sabe, gerenciamento de assinatura

00:21:46personalizado ou e-mails específicos que você deseja enviar quando alguém compra um cartão-presente

00:21:51e quer enviar para um amigo e, você sabe, todo esse tipo de coisa.

00:21:55E é isso que costumamos ver, a pequena loja Shopify é provavelmente a que você poderia ter escolhido

00:21:59e que não vemos muitas pessoas usando Webhooks, mas, você sabe, quase em qualquer outro lugar

00:22:04que você mire, nesse segmento, você vai acabar em uma empresa que usa Webhooks.

00:22:08Justo.

00:22:09Justo.

00:22:10Justo.

00:22:11Como isso se compara a algo como o AWS EventBridge?

00:22:14Porque essa é uma das outras escolhas de que ouvi falar.

00:22:17É apenas uma melhor experiência do desenvolvedor ou?

00:22:19Bem, obviamente todos conhecemos a AWS, quero dizer, a Better Stack está mais ou menos fazendo o mesmo

00:22:24caso, certo?

00:22:25Sim.

00:22:26E, portanto, o que quer que vocês digam como seu ponto de venda exclusivo versus, você sabe,

00:22:31CloudWatch e os serviços de log da Amazon e todo esse tipo de coisa, acaba sendo transportado.

00:22:37Então, isso é muito o argumento da experiência do desenvolvedor, certo?

00:22:40Você sabe, APIs adequadas, MCP, uma interface legal e observabilidade sólida como uma rocha e tudo isso.

00:22:46Certo.

00:22:47Certo.

00:22:47E, obviamente, a integração disso, acho que o problema da AWS é sempre que você

00:22:51acaba com, tipo, 20 serviços, a maioria dos quais você provavelmente já esqueceu o nome.

00:22:56E os dados estão espalhados por tudo isso e a configuração também está espalhada.

00:22:59E tudo isso.

00:23:01Certo.

00:23:01Então, esse é um ponto.

00:23:02Mas acho que o ponto mais amplo é que o AWS EventBridge não se integra com todo mundo,

00:23:07todo mundo.

00:23:08Então, o fornecedor precisa ter se integrado ao AWS EventBridge.

00:23:11Existem maneiras de contornar isso com API Gateway e blá, blá, blá.

00:23:16Mas o ponto é que é muito construído para o ecossistema AWS, onde a maioria dos

00:23:23casos de uso são, na verdade, eventos internos da AWS, como coisas como um novo documento S3 sendo carregado e

00:23:31esse tipo de coisa.

00:23:31E então a interoperabilidade com terceiros, embora eles suportem cerca de 40, tipo, qualquer

00:23:36fornecedor, não me cite sobre isso, talvez tenha sido atualizado agora, mas você sabe, não milhares.

00:23:40Você sempre acaba nesse cenário onde, ok, bem, o Shopify suporta EventBridge, mas o Twilio não.

00:23:45Certo.

00:23:47Certo.

00:23:47E então você acaba com esses problemas onde você pode realmente trazer uma solução agnóstica

00:23:51e que simplesmente funciona em toda a linha.

00:23:52Então acho que essa é uma coisa que estamos tentando fazer, certo.

00:23:54É nos construir de tal forma que não precisemos que o fornecedor aceite ou concorde

00:23:59com isso, ou faça qualquer coisa do lado deles.

00:24:02E nesse ponto, a maneira como estamos construindo o Hookdeck, acho que é bastante inovadora no sentido de que

00:24:08funciona puramente via HTTP.

00:24:10E a ideia é que fornecemos a você uma URL e você pode substituir sua URL de Webhook existente

00:24:15pela URL que fornecemos.

00:24:17E então, no Hookdeck, seu destino é o que teria sido sua URL de Webhook.

00:24:22E então funcionamos como uma fila baseada em push entre isso.

00:24:25Então receberemos todos os Webhooks via HTTP e os enviaremos na taxa

00:24:28que você especificar para seu próprio endpoint.

00:24:31Mas isso significa que você nem precisa reimplantar seu código.

00:24:34Você pode estar em qualquer nuvem ou qualquer stack para que isso funcione quase imediatamente.

00:24:39Certo.

00:24:40Porque, na verdade, o único requisito é atualizar a URL no final do dia.

00:24:44E isso é muito diferente do AWS EventBridge, que é o bloqueio definitivo do fornecedor,

00:24:48precisa de compatibilidade específica e só funciona no ecossistema AWS.

00:24:53Sim.

00:24:53Eu geralmente penso no AWS EventBridge como o outro grande gateway de eventos.

00:24:58Na verdade, estamos vendo o Azure Event Grid, que é um concorrente que também ganhou algum espaço.

00:25:04E quando penso na nossa concorrência mais direta ou, na verdade, nossa inspiração

00:25:10em alguns sentidos, são esses dois produtos.

00:25:13Mas definitivamente acho que o escopo do que estamos tentando fazer é um pouco maior.

00:25:17E para algumas pessoas isso é uma coisa boa.

00:25:18Para algumas, não é uma coisa boa, certo?

00:25:20Porque para algumas, é isso que elas querem.

00:25:22Tipo, elas estão totalmente inseridas no ecossistema AWS.

00:25:24Elas estão usando CloudFormation.

00:25:26Elas estão familiarizadas com todos os serviços.

00:25:27Elas querem poder escolher as capacidades.

00:25:30E você sabe, tudo bem.

00:25:31Tipo, não acho que nunca teremos 100% de participação de mercado.

00:25:34Então, na verdade, nos EUA, acho que alguns pontos percentuais são provavelmente tudo o que você precisa.

00:25:38Então, sim, acho que estamos tentando argumentar que, para empresas de tecnologia e desenvolvedores

00:25:45e assim por diante, essa será a solução certa.

00:25:48E você sabe, para outros, o AWS EventBridge será a escolha, e tudo bem.

00:25:51Então, acho que notei no último ano que a quantidade de tempo de inatividade para grandes empresas

00:25:59tem aumentado.

00:26:00Como existem todos esses memes sobre o GitHub estar fora do ar.

00:26:02E lembro que há dois anos, quando eu estava trabalhando, se o P99 caísse

00:26:07para 99,5 ou algo menor, você teria uma conversa séria com sua equipe.

00:26:13Tipo, como isso pode acontecer?

00:26:14Certo, agora é meio que comum.

00:26:15Sim.

00:26:17Sim.

00:26:17E agora é como se as pessoas tivessem se acostumado com o GitHub estar fora do ar por tanto tempo.

00:26:23Então estou pensando, da sua perspectiva no Hookdeck, você vê que também há muito mais

00:26:28tempos de inatividade este ano do que nos anos anteriores, e como você lida com esses desafios?

00:26:33Sim, isso é interessante, porque obviamente é uma consideração que você tem que fazer se for

00:26:37consumir Webhooks, na verdade, os Webhooks do GitHub especificamente são particularmente problemáticos.

00:26:42Você sabe, há uma chance em duas de que, se você fizer login no Railway ou Vercel ou qualquer outro,

00:26:46haverá um pequeno banner.

00:26:47E é tipo, você sabe, as implantações estão fora do ar porque os Webhooks do GitHub não funcionam ou algo assim.

00:26:51E na verdade, o CTO do GitHub fez essa postagem no blog sobre a estabilidade da infraestrutura deles

00:26:58em meio a todos os memes e todo esse tipo de coisa, tentando amenizar.

00:27:02Não acho que realmente funcionou, mas era o momento.

00:27:03Mas uma das coisas que ele estava culpando explicitamente nesse artigo era a estabilidade dos Webhooks

00:27:05e como isso depende do MySQL e blá, blá, blá.

00:27:09Certo.

00:27:12Certo.

00:27:13E, com todo o mérito, só porque acho que a maneira como isso está sendo dito é um pouco descartável.

00:27:17Realmente não duvido que o desafio de infraestrutura deles seja completamente insano

00:27:21com o surgimento dos agentes.

00:27:23Da mesma forma que estamos falando sobre aqueles mantenedores de OSS sendo inundados.

00:27:26Isso também é ser inundado por infraestrutura, certo.

00:27:30E, sinto muito, tenho certeza de que é um desafio extremamente difícil.

00:27:33Mas o ponto onde estou chegando é que, sim, podemos ver isso.

00:27:38E não só isso, como também monitoramos para alguns fornecedores.

00:27:41Então, por exemplo, temos uma coisa que chamamos de Deck Radar.

00:27:44A ideia é que podemos observar estatísticas agregadas de todos os clientes e de todos os

00:27:49Webhooks que recebemos através do Deck, e então calcular coisas como, sabe, qual a latência de entrega

00:27:53é, qual a latência de entrega P99 para um fornecedor, qual o tempo de atividade deles, e coisas assim.

00:27:58Então, por exemplo, o nosso radar para o Shopify é bastante popular.

00:28:01Tenho algumas centenas de assinantes para ele.

00:28:04A ideia é que enviamos alertas, basicamente, se a latência ultrapassar um certo

00:28:09desvio padrão da latência de referência.

00:28:12Certo.

00:28:12Acho que, no caso do Shopify, a latência de referência é de cerca de quatro ou cinco segundos

00:28:17para entrega.

00:28:17Acho que se passar de 10 segundos...

00:28:19Certo.

00:28:20nós enviamos um alerta.

00:28:22A ideia é que você possa monitorar isso como uma espécie de série temporal e observar

00:28:26o tempo de atividade, não apenas em termos de tempo de atividade bruto, mas também o perfil de latência deles

00:28:31ao longo do tempo.

00:28:32E isso é definitivamente algo que você vê.

00:28:33E quero dizer, a equipe do Shopify está especificamente bem ciente disso.

00:28:36Mas você consegue ver que há muita variação nesses tempos de entrega.

00:28:41Então, vai acontecer, sabe, talvez uma vez a cada dois meses ou algo assim,

00:28:46um incidente bem significativo relacionado à latência.

00:28:49E acho que isso é algo que você geralmente não vê.

00:28:51Certo.

00:28:52Porque, obviamente, o tempo de inatividade é muito mais fácil.

00:28:54Você entra no seu DataDog ou no seu Better Stack.

00:28:57Como vocês chamam mesmo, o produto de métricas?

00:29:01Observabilidade.

00:29:02Observabilidade, sim.

00:29:03Então você entra no seu Better Stack, obviamente construindo esse tipo de coisa.

00:29:05Certo.

00:29:06E você olha para as chamadas HTTP para o ponto final de Webhook e simplesmente para de funcionar.

00:29:11Certo.

00:29:11Tipo, sabe, o problema é bem óbvio e direto.

00:29:14Mas se a latência subir para 60 segundos, isso é algo que será muito difícil

00:29:19de identificar a partir das suas métricas reais.

00:29:22Certo.

00:29:23E isso porque a latência que você leva para processar é algo que provavelmente você

00:29:27estaria rastreando e tal.

00:29:28Mas é o atraso no lado do fornecedor.

00:29:31Mas agora, se você tem uma nova suposição no seu código, na sua operação de negócios, e assim por diante,

00:29:34que pressupõe, sabe, algum tempo real para esses eventos, se eles agora chegam 60 segundos

00:29:39mais tarde, isso pode começar a introduzir um monte de problemas sutis, erros e suposições

00:29:44incorretas, e coisas do tipo no código.

00:29:46Então, acho que esse é um lugar onde talvez estejamos em uma posição um pouco mais única para

00:29:50poder fornecer bons dados.

00:29:52E assim você pode saber, oh, o problema é comigo ou com meu fornecedor?

00:29:55Certo.

00:29:56Quem está tendo problemas?

00:29:57Não sei se posso comentar empiricamente sobre, sabe, o quanto isso aumentou ou diminuiu.

00:30:03E se eles são os suspeitos de sempre que aparecem e tal.

00:30:06É fácil apontar o dedo.

00:30:08Não sei se diria que é um problema genuinamente distribuído que vemos o tempo todo.

00:30:13Acho que tende a ser mais concentrado em fornecedores específicos.

00:30:16E acho que a parte onde as pessoas tendem a ser mais afetadas é nessas latências de entrega.

00:30:23A outra coisa também é que acho que as pessoas presumem que a latência de entrega é menor do que realmente é na

00:30:27maioria dos fornecedores, porque estamos definitivamente falando de alguns segundos na maioria dos casos, o que, dependendo

00:30:31de como você olha, pode ser muito tempo ou não.

00:30:34Mas acho que quando mostro este gráfico de latência, por exemplo, do Shopify, para um grupo de desenvolvedores

00:30:40Shopify, eles ficam tipo, eu não esperava isso.

00:30:43Certo.

00:30:43Tipo, há uma quebra de expectativa que acontece.

00:30:46Eu costumava trabalhar para uma empresa de comércio eletrônico bastante grande e tínhamos o mesmo problema.

00:30:53A latência é ruim, mas todos faziam aquele meme do Homem-Aranha, apontando dedos

00:30:58para saber de qual equipe é a responsabilidade.

00:30:59Porque geralmente é basicamente um fornecedor terceirizado, como você disse.

00:31:05E às vezes não há nada que você possa fazer.

00:31:07Você só tem que contornar isso.

00:31:08Então é legal.

00:31:09Você quer ter cuidado ao culpar o fornecedor também.

00:31:11Certo.

00:31:11Acho que é algo que, obviamente, no contexto do que vocês fazem,

00:31:16sabe, é quase sempre um problema comum.

00:31:18Sempre que temos um incidente, pensamos, ok, quanta culpa você atribui ao fornecedor?

00:31:22Mas, em algum momento, sabe, também há o que é razoável versus não razoável.

00:31:27E o que é um acaso versus um acidente não casual.

00:31:29Por exemplo, no outro dia, Railway, nós... algumas das implantações de gerenciamento de outposts

00:31:34estão rodando na Railway por causa da estrutura de preços deles.

00:31:36Como temos que executar a mesma versão do código aberto, não construímos

00:31:40algo multi-inquilino, isso não seria relevante no código aberto.

00:31:44Então, basicamente, fazemos uma implantação real para cada cliente.

00:31:48Certo.

00:31:49E então, para usuários do plano gratuito, implantamos uma instância para eles na Railway,

00:31:52que, de modo geral, funciona muito bem.

00:31:54Mas no outro dia, a conta do GCP deles foi suspensa e eles ficaram fora do ar por umas seis

00:31:59horas ou algo assim.

00:31:59Certo.

00:31:59E então é tipo, ok, sabe, você não pode não falar sobre isso no seu...

00:32:06há uma coisa sobre, sabe, desviar a culpa.

00:32:09E eu definitivamente, tipo, você tem responsabilidade pelos seus fornecedores.

00:32:11Mas o ponto é, acho que o sinal é muito difícil de interpretar.

00:32:14E eu definitivamente vejo que há essa tendência natural das pessoas de quererem

00:32:18apontar o dedo porque isso meio que exime você de responsabilidade.

00:32:20E então você tem que lutar contra isso.

00:32:23Certo.

00:32:24Mas nos casos em que você pode ter certeza de que é o fornecedor,

00:32:28acho interessante poder identificar isso e,

00:32:31sabe, ter dados sobre isso, o que é frequentemente um problema com problemas de fornecedores.

00:32:35Certo.

00:32:35Você não vê o lado dos dados deles.

00:32:37E por isso é muito difícil dizer com qualquer certeza ou evidência empírica que

00:32:42são claramente eles.

00:32:43Você tem que derivar isso de seus próprios dados, o que pode estar certo ou errado.

00:32:46Certo.

00:32:47Então eu estava me perguntando, quando há uma interrupção em algo como Shopify ou Stripe,

00:32:51como os eventos recuperam o atraso e isso sobrecarrega seus servidores?

00:32:57Sim, basicamente o efeito rebote é o que acontece.

00:33:00E porque existem esses cenários onde sempre dizemos que,

00:33:05você não deve assumir um volume específico de Webhook.

00:33:09Uh-huh.

00:33:09Então, temos essa característica em que todo fornecedor vai impor um tempo limite (timeout).

00:33:14Certo.

00:33:14Eles vão lhe dar uns três segundos,

00:33:15cinco segundos, meio que depende da plataforma para responder.

00:33:18E isso significa que você realmente não pode fazer uma quantidade significativa de trabalho,

00:33:21especialmente quando você considera latências de rede e coisas desse tipo nesse atraso.

00:33:25Certo.

00:33:25E é por isso, quero dizer, não apenas por isso,

00:33:28mas é uma das razões pelas quais a coisa comum é que você precisa enfileirá-lo.

00:33:31Você não pode processar isso de forma síncrona.

00:33:33Mas perdi o fio da meada.

00:33:39Pode repetir sua pergunta?

00:33:42Eu estava falando sobre quando há uma interrupção em uma empresa como Stripe e Shopify.

00:33:45Ah, sim.

00:33:45E recuperar o atraso.

00:33:47Sim.

00:33:47Sim.

00:33:47Sim.

00:33:47De qualquer forma, tudo isso para dizer latência, blá, blá, blá, uma maneira convoluta de dizer que você precisa

00:33:52ser capaz de escalar automaticamente.

00:33:53E então você precisa ser capaz de escalar em um período de tempo bastante curto.

00:33:56E esses picos vêm de vários motivos diferentes.

00:33:58Pode ser apenas, sabe, naturalmente você fez uma importação em massa quando seu cliente fez uma importação

00:34:03em massa ou qualquer outra coisa.

00:34:03Certo.

00:34:03Há outro motivo pelo qual um pico aconteceria.

00:34:05Mas o tempo de inatividade é, na verdade, um deles.

00:34:07Certo.

00:34:07Há este momento em que, se o Shopify ficou fora do ar por meia hora, quando eles se recuperam,

00:34:11eles vão simplesmente arar o backlog, especialmente porque eles vão tentar reduzir

00:34:16a contrapressão em sua fila.

00:34:17Então, basicamente, processe tudo o que se acumulou durante o tempo de inatividade.

00:34:22E, de modo geral, o que você verá é que eles vão escalar ainda mais do que sua capacidade usual,

00:34:26porque estão tentando recuperar o atraso.

00:34:28Certo.

00:34:28E isso resulta em basicamente enviar um monte de solicitações para as lojas finais.

00:34:32E, sim, você tem essas irregularidades, mas algumas dessas irregularidades no rendimento

00:34:37não são causadas por você.

00:34:38É 100% causado pelo fornecedor porque, sabe, o fornecedor está passando por seus próprios

00:34:42desafios de infraestrutura e tudo mais.

00:34:44E, obviamente, a capacidade do Shopify de enviar Webhooks é muito maior do que sua capacidade de

00:34:49receber Webhooks, na maior parte.

00:34:52Sim.

00:34:52Curiosamente, na verdade, um dos nossos investidores era o CPO na Twilio.

00:34:56E acho que é parte do motivo pelo qual ele se interessou em investir.

00:34:59Porque uma das coisas que ele disse é que, basicamente, a Twilio estava rotineiramente

00:35:04apenas fazendo DDoS nos seus clientes, sabe, para todos os efeitos.

00:35:07E é um pouco inevitável e meio que parte do problema de fazer esses

00:35:14eventos impulsionados por fornecedores.

00:35:17E então é muito, tipo, um problema bem conhecido com fornecedores.

00:35:21E eles também sabem disso, porque é algo que você pode rastrear na latência

00:35:24de resposta dos servidores também, certo?

00:35:26Se você faz um DDoS no seu cliente, a latência de resposta do servidor aumenta.

00:35:29E em algum momento, eles começam a expirar (timeout).

00:35:31Esse problema se complica porque é mais difícil ter mais rendimento se houver tempos limite mais longos.

00:35:34Basicamente, quanto mais tempo você tiver que manter a conexão HTTP aberta, menos solicitações

00:35:38você pode fazer para qualquer trabalhador que você tenha do seu lado.

00:35:40E agora você tem que escalar, e então envia mais porque escalou, e você está certo.

00:35:45Isso apenas se acumula, certo?

00:35:46Tende a ser muito autorreforçador porque, basicamente, quanto menos capacidade você tem para

00:35:52processar esses Webhooks, mais rápido a latência degrada, certo?

00:35:57E assim, à medida que você atinge a saturação no seu servidor, a latência fica muito ruim.

00:36:01Mas essas solicitações continuam se acumulando.

00:36:04E o que muitos fornecedores fazem é que, em algum momento, eles simplesmente desativam seu endpoint

00:36:07porque, caso contrário, continuará se acumulando, certo?

00:36:10E eles não querem manter centenas de milhares de conexões HTTP abertas

00:36:14porque seu servidor é lento para responder.

00:36:15Mas, assim que eles desativam, você perde os dados.

00:36:19Então, esse também é o ponto crítico, certo?

00:36:21Portanto, realmente garantir um tempo de resposta através dessas variações, que muitas vezes estão fora do seu

00:36:25controle, é uma grande parte do desafio.

00:36:29Eu também queria perguntar: com a IA agora, como ela está mudando todo o espaço dos Webhooks?

00:36:37Eu sei que você disse que os LLMs estão enviando mais Webhooks e talvez os processando.

00:36:43Mas internamente, como você usa IA para o Hookdeck?

00:36:48E o que você vê como o futuro da IA neste espaço?

00:36:51Sim, acho que há muitas coisas acontecendo nessa frente.

00:36:54Tipo, obviamente, somos apenas uma empresa de desenvolvimento de software.

00:36:57E sinto que vocês estão passando pelos mesmos desafios em relação,

00:37:02sabe, fluxos de trabalho que mudam toda semana e custos de tokens

00:37:05e quanto é uma quantidade razoável de custo de tokens, e, sabe, tudo isso.

00:37:10Sim, não precisamos fazer um placar de líderes (leaderboard).

00:37:15Tenho muito medo da ideia do placar de líderes.

00:37:18Parece uma maneira infalível de destruir suas margens.

00:37:24Então, algumas reflexões.

00:37:25Primeiro, voltando ao que eu disse anteriormente, sabe, há um crescimento e meios para eventos

00:37:29que são impulsionados por esses casos de uso de agentes, porque os agentes estão mudando de ser acionados

00:37:35por humanos para gatilhos de eventos, e você está vendo, sabe, todos os produtos de agentes em nuvem saindo e tal,

00:37:41e muitas de nossas coisas.

00:37:42E todos eles são essencialmente acionados por agendamento ou por eventos, no final das contas.

00:37:46E alguns desses eventos são meio que abstraídos de você, mas ainda há coisas como

00:37:49GitHub PR ou, você sabe, quando você faz um commit ou comenta no GitHub, tudo isso é orientado pela web.

00:37:56Mas obviamente, vai se ramificar muito além disso, como suporte ao cliente,

00:38:00e o Slack, e o blá, blá, blá, e provavelmente até coisas em tempo real que acontecem

00:38:04no mundo real, vindas de dados de sensores e todo esse tipo de coisa, certo?

00:38:08Acho também que muitos agentes precisarão disparar eventos para outros agentes, basicamente,

00:38:12o resultado do agente será um evento, que possivelmente disparará

00:38:17outro agente, outra empresa e assim por diante, o que, sim, você poderia descrever

00:38:21como apenas um caso de uso de webhooks, e de certa forma é.

00:38:23Mas acho também que algumas das semânticas em torno de webhooks agora são um tanto falhas

00:38:28em relação à segurança, ao protocolo, à eficiência e coisas desse tipo.

00:38:33E é por isso que temos impulsionado destinos de eventos como um padrão melhor

00:38:36e um padrão mais otimizado para isso. A outra coisa também é que, se o que você executa

00:38:40em resposta a eventos são fluxos de trabalho agentic, que são indeterminísticos e podem rodar por muito tempo,

00:38:47isso torna muito mais difícil ajustar sua capacidade e escalar

00:38:51em consequência dos eventos que você recebe. Então, acho que o gerenciamento de throughput e capacidade

00:38:55torna-se muito mais difícil. Suas taxas de falha serão maiores por causa

00:39:00de timeouts na nuvem, de avaliações que não passam e de todas essas coisas.

00:39:07Então, acho que do ponto de vista da construção de aplicações e das primitivas centrais que você quer usar,

00:39:12de onde isso roda, por quanto tempo roda e como você lida com a contrapressão,

00:39:16há muitos desafios novos aí. E em termos de nós internamente,

00:39:21acho que ainda estamos tentando descobrir a maneira certa. Parte de mim está simplesmente

00:39:25impressionada com a capacidade. Não estou surpreendendo ninguém, não acho que estou trazendo

00:39:29nenhum insight único aqui. A única coisa que direi, no entanto, é que a barra entre

00:39:34ir do seu prompt de CLI ou codex, ou o que quer que seja, para realmente entregar um produto de bom gosto

00:39:41e de alta qualidade... Acho que parte dessa nuance ainda está se perdendo em meio a todos os memes e

00:39:45exposições, onde fico com dúvidas se você pode realmente gastar

00:39:50esse nível de tokens e produzir algo que realmente adicione valor ao mundo no fim

00:39:55do dia. E pelo menos em nossa experiência até agora, obviamente há muito em torno da segurança,

00:40:01que é um grande facilitador, como revisões de código e coisas do tipo. Mas acho que quando se trata de

00:40:06essas coisas, são apenas o básico. Não são coisas que genuinamente

00:40:11agregam valor no fim do dia, certo? Quando se trata de construir algo muito

00:40:14valioso que outros também valorizam, sinto que ainda há uma lacuna. E sinto que

00:40:19nossa equipe ainda é muito responsável por trazer esse nível de bom gosto, insight, compreensão do cliente

00:40:25e empatia, que você simplesmente não obtém diretamente da

00:40:31caixa de chat. E talvez nós sejamos os tolos e poderíamos estar avançando muito mais rápido

00:40:35se apenas fizéssemos tudo de uma vez. Mas, no momento, nossa abordagem ainda é

00:40:42manter o mesmo nível de expectativa em termos de produção líquida e do que entregamos ao usuário final

00:40:47no fim do dia. Sim, obviamente, isso significa que podemos fazer mais. E também, acho que mais pessoas que

00:40:53têm esse bom gosto e empatia podem trazer valor ao usuário, porque a barreira era o código,

00:40:57certo? E então, por exemplo, praticamente todos na empresa agora codam, entre aspas,

00:41:01certo? Nosso designer é o nosso codificador residente. Agora ele é totalmente responsável pelo

00:41:06site, mas também há muito trabalho de dashboard e outras coisas, ou nosso

00:41:11gerente de produto ou o pessoal de dev rel, todos, sabe, não é uma questão de token maxing, mas se houvesse

00:41:16um ranking, eles provavelmente estariam no topo. E acho que isso é algo muito bom. São facilitadores

00:41:20porque essas pessoas precisam ter aquele pensamento crítico que eu estava descrevendo

00:41:25para serem capazes de entregar coisas de bom gosto para o usuário final, e a barreira agora é mais o código.

00:41:30E, de certa forma, acho que o maior benefício vem daí, mais do que da

00:41:36engenharia pura. Novamente, não querendo dizer que a engenharia pura não esteja obtendo muito valor,

00:41:40mas acho que o gargalo ainda permanece nesse bom gosto. Além disso, passo

00:41:45tanto tempo revisando PRs inúteis. Agora, há um lado negativo nisso também.

00:41:51Com certeza. E a quantidade de código que você tem que revisar.

00:41:56Sim. E tipo, criar essa vulnerabilidade obscura que basicamente não tem chance nenhuma.

00:42:01E não tenho nem certeza se isso se qualifica como baixa, certo. Mas obviamente, uma vez que aparece,

00:42:06você sente uma responsabilidade. E isso, acho que é normal. Mas,

00:42:09a certo ponto, foi como, você sabe, nunca tivemos tantos PRs abertos em nenhum momento.

00:42:14E está ficando um pouco insano realmente entender tudo isso. E,

00:42:18acho que trazer o julgamento de que não é porque você pode fazer tudo,

00:42:21que você deve fazer tudo. E acho que isso vem muito com aquela atitude

00:42:26de LLM. E acho que trazer julgamento para o que eventualmente gerará

00:42:31valor, ou tem o potencial de gerar valor, é mais importante do que nunca.

00:42:34Porque há uma certa satisfação em marcar uma lista de tarefas ao

00:42:39trabalhar com agentes, você sabe, de vez em quando, fico com o cérebro desligado. É tipo,

00:42:44só quero passar pela minha lista e tudo o que você é e apenas marcar, marcar, marcar, marcar.

00:42:48Certo. E há algo que vem com isso com LLMs, onde tipo, começo esta

00:42:53conversa, começo esta conversa, começo esta conversa e talvez cinco ou seis agentes

00:42:57em andamento e todos eles fazendo coisas, e todos eles têm checklists que estão marcando

00:43:02também. Certo. Certo. Certo. Yeah. Yeah. Então, há algo sobre a

00:43:06satisfação e a recompensa rápida associada a isso. E acho que às vezes

00:43:11isso pode nos pegar. Certo. Ou pelo menos, falando por mim. Qual é o tamanho da equipe de engenharia?

00:43:15Somos 10 agora. Uau. Isso é muito enxuto. Yeah. Kudos. Sempre foi uma ambição minha.

00:43:23Não me considero o melhor gerente. Então acho que é melhor para todos dessa forma.

00:43:29Não, eu estava meio que brincando, acho que desde o início, nascemos no meio da COVID,

00:43:33certo? Todos remotos. E havia muito essa mentalidade desde o início de

00:43:38contratar pessoas seniores, experientes, extremamente autônomas,

00:43:45para dar uma ideia, fazemos apenas uma única chamada a cada duas semanas para discutir

00:43:50produto e infraestrutura. E tentamos muito ter esse tipo de fluxo de trabalho

00:43:56assíncrono. E acho que isso se presta bem aos casos de uso de IA também, porque

00:44:01já contratamos e otimizamos para pessoas que têm essa autonomia. Certo. Não acho que haja

00:44:06certo ou errado. Não vou pregar sobre a maneira como fazemos as coisas, mas acho que funciona para nós.

00:44:11Nada funciona para mim e minha sanidade. Então, tem isso.

00:44:14Eu queria tocar no ponto que você disse no início da conversa, de que,

00:44:21webhooks estão mortos. O novo caminho é o gateway de eventos. Você cunhou esse termo ou já estava

00:44:27no éter? O que é um gateway de eventos? Não tenho entendimento disso.

00:44:32Sim, nós cunhamos e tem sido muito difícil construir um produto e uma categoria de

00:44:37produto que não é estabelecida. Porque você tem os desafios de marketing e

00:44:41comunicação, e como descrever essa coisa. Certo. Por um tempo estávamos

00:44:46chamando de infraestrutura de gerenciamento de webhooks e coisas do tipo.

00:44:51Nada que seja fácil de falar. Então, você tem o desafio da comunicação,

00:44:54mas também tem o desafio do produto. Porque quando você está construindo um produto em uma categoria existente,

00:44:58digamos melhor stack, observabilidade, você sabe o que está tentando otimizar,

00:45:02seus USPs específicos, que no seu caso, acho que muito é sobre preço

00:45:07e experiência do desenvolvedor e coisas assim. Certo. Mas a questão é que a semântica central existe. Então o que

00:45:10você está otimizando é essa proposta de valor única. Quando você está construindo algo que não

00:45:14existe realmente, você tem que inventar a semântica e também construir uma proposta de

00:45:19valor convincente sobre essa semântica. Certo. Então isso se torna muito difícil.

00:45:24E esse é um aprendizado dos últimos dois anos, é muito difícil construir um produto em uma

00:45:28categoria existente. Então a ideia com o gateway de eventos e de onde veio é

00:45:32tentar capturar da melhor forma possível, em duas ou três palavras que espero que

00:45:37soem bem, o que ele faz. Nosso objetivo era criar uma ponte entre barramento de eventos

00:45:43e basicamente gateways de API. Certo. E capturar essa noção de que gateways estão lá

00:45:49como uma interface entre um fornecedor e seu próprio sistema, etc. Certo. E

00:45:55barramento de eventos no sentido de que isso é um gerenciamento completo de eventos, filas, etc.

00:46:00Certo. Então estamos tentando encontrar um termo que combine esses dois. E realmente quando

00:46:04você pensa em EventBridge, não é muito longe de gateway de eventos. E realmente, queremos

00:46:10que as pessoas nos percebam como competindo com o EventBridge, por exemplo, como uma

00:46:14alternativa clara. Certo. E acho que a ideia em torno de gateway de eventos também era

00:46:19dar uma ideia de que, olha, existem produtos existentes agora. Não há terminologia comum

00:46:24em torno dessas coisas. Certo. Eles não chamam explicitamente de gateway de eventos, mas daremos esse

00:46:29rótulo. E então, há alguns produtos competindo, um dos nossos, mas depois tem a AWS,

00:46:33Azure, tem outros, como o Kong, que é um gateway de eventos. Agora há o Gravitee. Há

00:46:39vários provedores de API gateway entrando na arquitetura orientada a eventos também.

00:46:45Então, a esta altura, provavelmente existem meia dúzia de produtos,

00:46:49pelo menos, que se chamariam gateway de eventos, e não sei se tivemos

00:46:54alguma coisa a ver com isso, mas posso dizer que quando a Kong lançou o seu, eu pensei: Oh,

00:46:58merda, foram dois anos depois de começarmos a chamar assim. Mas a parte que é

00:47:03realmente gratificante é quando os clientes vêm até você, desenvolvedores vêm até mim e dizem: Estou

00:47:08procurando um gateway de eventos. E é como, oh, você sabe, agora você pensa: ok,

00:47:12acho que o termo está chegando a algum lugar, no sentido de que as pessoas têm um modelo mental

00:47:16com isso, estão começando a procurar explicitamente, ou dizem:

00:47:20estamos tentando substituir nosso próprio gateway de eventos. São coisas que surgiram

00:47:23na conversa. Posso dizer que, durante o primeiro ano, isso não surgia. E agora,

00:47:28com o tempo, é um termo que vejo outros usarem cada vez mais. Acho que é algo bom.

00:47:34Acho que é bom para nós como empresa, mas também no sentido de tentar

00:47:38criar expectativas de que esta é uma primitiva de infraestrutura em nuvem que existe.

00:47:43E este é o conjunto básico de expectativas que você pode ter em torno disso. E

00:47:48espero que em algum momento, as coisas comecem a se alinhar e a semântica também.

00:47:52Se você está usando o AWS EventBridge, a terminologia tem muito pouco em comum.

00:47:57Não quero projetar meu produto em torno do AWS EventBridge por causa de todos os produtos que ele tem.

00:48:01Então, definitivamente não vou reutilizar a terminologia deles se não achar que faz

00:48:05um sentido sólido. Mas acho que com o tempo, sabe,

00:48:09com mais pessoas construindo em torno do produto, haverá alguma convergência.

00:48:12Yeah.

00:48:15Sim.

00:48:15Você acha que se eu pedisse por um gateway de eventos em uma LLM, ela recomendaria vocês?

00:48:20Ah, sim. Tente agora. Acho que as chances são muito boas.

00:48:24Eu poderia tentar ao vivo.

00:48:25É algo que rastreamos, certo?

00:48:27Sim.

00:48:27É algo que rastreamos. Somos citados em cerca de 60% de cada prompt

00:48:31que é sobre webhooks ou gateway de eventos e coisas do tipo.

00:48:35Isso é legal. Algo em que obviamente dedicamos muito tempo. E em relação aos nossos dados,

00:48:42que podem não ser de altíssima qualidade, estamos fazendo um bom trabalho.

00:48:46Foi o primeiro da lista.

00:48:48Ah, legal.

00:48:49Aí está.

00:48:49Que o ChatGPT acabou de me dar. Então, muito bem.

00:48:52Sim. Embora eu ache que, sobre gateway de eventos, provavelmente nos sairíamos tão bem

00:48:56em qualquer consulta relacionada a webhooks. Mas gateway de eventos definitivamente

00:49:00joga a nosso favor, no sentido de que nós cunhamos o termo, então eu ficaria

00:49:03bravo se não fôssemos os primeiros.

00:49:05Na verdade, percebi agora que não sei o que significa arquitetura orientada a eventos. Como ela difere

00:49:11de uma arquitetura comum? Tipo, se eu colocar uma fila Kafka no meu sistema,

00:49:17automaticamente tenho uma arquitetura orientada a eventos?

00:49:21Sim e não. No sentido de que acho que quando você fala sobre arquitetura orientada a eventos, é

00:49:25mais um conjunto de paradigmas e expectativas. Então, parte disso vai ser,

00:49:31sim, as ferramentas, certo? Você está usando Kafka, filas de mensagens ou

00:49:35streaming de eventos destinados a desacoplar sistemas. Então, quando se resume a isso,

00:49:39a ideia é que você tem produtores e consumidores, esses sistemas não precisam

00:49:43saber sobre os outros, certo? Então o consumidor pode consumir de um fluxo de

00:49:47eventos produzido por qualquer pessoa. E a única expectativa real que você tem

00:49:53é um contrato sobre o que é o evento em si. Qual é o payload, qual é a forma?

00:49:57Sim. E muitas vezes haverá esquemas, esquemas específicos que as pessoas usarão,

00:50:02como esquemas baseados em Avro, Protobuf, etc., onde haverá expectativas

00:50:06padronizadas sobre o que são esses payloads. E realmente, o contrato se torna

00:50:11sobre, ok, esses eventos existem. E em algum momento eu posso ter um evento e, como consumidor,

00:50:16minha responsabilidade é fazer o que quer que eu deva fazer com um pedido criado ou uma atualização de produto, etc.

00:50:21Certo. Mas agora, uma organização que realmente abraçou EDA terá um

00:50:25padrão sistematizado em torno disso, onde haverá diretrizes específicas

00:50:29sobre como isso deve ser feito e quais devem ser as formas dos payloads.

00:50:32E será uma abordagem arquitetural onde você desacoplará intencionalmente

00:50:36seus serviços e criará a comunicação entre eles orientada a eventos, certo?

00:50:41Sinto que muitas empresas adotam uma abordagem híbrida, certo? Alguma coisa é orientada a eventos,

00:50:45outras não. Então, o objetivo é ser 100% orientado a eventos?

00:50:50Ou é apenas um subconjunto de um paradigma arquitetural?

00:50:54Não acho que seja 100%. Apenas penso que com o tempo, à medida que você cresce e a complexidade aumenta,

00:51:00e há mais dependências de terceiros e assim por diante, é meio que o caminho natural que as coisas tendem

00:51:04a seguir. Porque em algum momento, é muito difícil manter todos esses sistemas acoplados.

00:51:09E então você tem que pensar sobre escalabilidade, interdependências e todo esse tipo de coisa

00:51:14de uma maneira que torna tudo muito difícil. Mas falando de forma geral, quando pensamos em

00:51:19arquitetura orientada a eventos, no sentido do termo, acho que as pessoas pensam,

00:51:23e com razão, em grandes empresas, certo? E acho que provavelmente durante a primeira

00:51:28década da arquitetura orientada a eventos, ela estava concentrada principalmente em grandes empresas. Mas acho que agora

00:51:32isso está mudando, em parte porque as pessoas estão mais confortáveis com os padrões, em parte porque

00:51:37webhooks são uma porta de entrada para isso. E também porque algumas das ferramentas estão melhorando. Por exemplo,

00:51:41estou pensando, por exemplo, no RabbitMQ ou no BullMQ, que é construído sobre

00:51:46Redis, tipo bibliotecas; há também várias bibliotecas populares em Python, tem

00:51:51o Celery, e em Ruby, tem o Sidekiq. Acho que existe outra agora, como o Foundation, que também é do

00:51:57pessoal do Sidekiq. Enfim, tem havido uma evolução progressiva das ferramentas em torno

00:52:01disso, o que também torna mais fácil de trabalhar e menos intimidante, onde você não

00:52:05precisa apenas de uma grande equipe de arquitetura e grandes implementações de Kafka, que custam muito

00:52:11dinheiro e tudo mais para começar a fazer arquitetura orientada a eventos. Mas também acho que o termo

00:52:15perdeu um pouco do seu significado. Tenho certeza de que algumas pessoas não ficariam felizes em ouvir isso. Mas

00:52:19realmente acho que ele perdeu um pouco do seu significado com o tempo, ou pelo menos as águas ficaram turvas quanto ao que queremos dizer.

00:52:25E acho que, quando eu digo isso, o que quero dizer principalmente é esse desacoplamento de sistemas. E então

00:52:31também as preocupações de programação que você terá como engenheiro, no sentido de,

00:52:37sabe, ter que pensar sobre dependência, ordenação e todos esses tipos de preocupações. Então, quando

00:52:43eu digo arquitetura orientada a eventos, é mais como se você estivesse entrando em um mundo onde

00:52:48ao construir seu aplicativo, você terá esses conjuntos de preocupações que não tinha antes.

00:52:52Certo. Entendi. E ser capaz de aprender e adaptar como você constrói as coisas para poder

00:52:58acomodar essas preocupações. Não sei se inicialmente me refiro ao tipo de

00:53:03forma de grande empresa. E acho que, de certa forma, o que estamos fazendo é tentar,

00:53:08sabe, trazer isso de alguma maneira para todo mundo. Certo. E nós não somos o único

00:53:14player fazendo isso. Tem várias outras pessoas adotando abordagens diferentes.

00:53:18Existem todos os mecanismos de fluxo de trabalho e "step functions" que acho que se sobrepõem,

00:53:22como Temporal, Ingest, Trigger.dev e esse pessoal também. Então, realmente acho que é um

00:53:28espaço onde muitas coisas estão acontecendo. E talvez não exista uma definição fixa

00:53:34muito boa para isso hoje em dia. Para quem tem muito interesse em aprender mais

00:53:38sobre arquitetura orientada a eventos e os paradigmas associados a isso, existe esse cara

00:53:42chamado David Boyan, que era "developer advocate" na AWS e trabalhava no Event

00:53:49Bridge. Aquelas séries de explicações com desenhos. Mas a esta altura, ele provavelmente tem

00:53:55centenas delas, e ele também gerencia um projeto open source chamado Event Catalog, que pode ser outro

00:54:02bom convidado para o podcast de vocês. Mas tudo isso para dizer que o nível de profundidade

00:54:07é quase irracional. Então, recomendo bastante para aqueles que estão curiosos.

00:54:14Legal. Vamos adicionar às notas do programa. E todo esse seu conhecimento sobre eventos e web

00:54:19hooks e tudo mais, você tem bastante disso, veio tudo de construir o Hookdeck?

00:54:23Ou foi, claro, você disse antes que teve alguns problemas com webhooks, mas foi aí que você

00:54:27realmente mergulhou fundo em eventos? Com certeza. E acho que esse aprendizado veio muito

00:54:34dos problemas, mas também dos princípios básicos, no sentido de que, quando eu estava lidando com esses

00:54:38problemas, eu não tinha muito conhecimento sobre isso, o que era parte do motivo de eu estar lidando

00:54:42com eles. Então, acho que veio muito de um lugar de tentar resolver o problema

00:54:47e as soluções para esse problema, em vez de trabalhar em soluções e

00:54:51tentar adaptá-las ao problema. Certo. Mas no final das contas, a esta altura,

00:54:55já trabalhamos com centenas de milhares de webhooks de toda parte

00:54:59do espectro. E acho que apenas absorvi tudo dessas conversas. E sim, tem sido

00:55:05bem interessante. Na verdade, comecei como designer de produto. Então, tipo,

00:55:11designer de produto, desenvolvedor full stack, depois engenheiro de back-end,

00:55:15depois engenheiro de infraestrutura. E agora, muito, muito fundo na

00:55:21toca do coelho. Mas isso veio apenas trabalhando com clientes, ouvindo

00:55:26suas preocupações, revisando a arquitetura e tudo mais. Mas também da equipe,

00:55:30certo? Temos pessoas na equipe que também têm muita experiência trabalhando com

00:55:33esses sistemas e trouxeram esse conhecimento para a empresa. Quando você percebeu,

00:55:38que tinha encontrado um mercado para isso? Imagino que você começou a trabalhar nisso e depois

00:55:42postou em algum lugar. Foi bem recebido imediatamente? Ou tem sido um processo lento

00:55:47para convencer as pessoas de que esta é a melhor opção? Processo lento é pouco,

00:55:53no sentido de que começou com aquele artigo no Medium, como eu referi, certo? "Web

00:55:57hooks e algo que você pode fazer sobre eles". Eu tenho a mentalidade de criar produtos

00:56:01para as pessoas. E a primeira versão era autoatendimento, você podia

00:56:07entrar e criar a sua primeira conexão, como chamamos, e tudo mais.

00:56:12E postei esse artigo. Não havia ambição de criar um negócio com isso ou

00:56:16qualquer coisa. Era apenas mais um dos 20 projetos paralelos fracassados

00:56:21que eu estava trabalhando na época. E, olhando em retrospecto, agora os

00:56:26números parecem ridiculamente pequenos, talvez cinco pessoas entraram em contato

00:56:32por causa daquele artigo ou algo assim. Mas sei que para quem já trabalhou em projetos paralelos,

00:56:37e já passou por tentar fazer alguém usar algo que você criou,

00:56:42cinco é incrível. Cinco é melhor do que eu provavelmente já consegui antes.

00:56:48E então, fiquei super animado com isso. Eu estava na verdade no meu

00:56:55trailer, na Colúmbia Britânica, escalando rochas. E eu estava muito longe de

00:57:00tentar criar uma startup. Apenas conversando com aquelas pessoas, guiando-as

00:57:05pelo processo, o que eu estava pensando e o problema que elas tinham e esse tipo de

00:57:08coisa. E então, foi chegando um por semana, enquanto eu estava escalando,

00:57:13e eu abria o Slack e tinha aquela notificação. Temos esse canal de notificação

00:57:18para cada inscrição, certo? O mesmo que temos há uns seis anos.

00:57:21A esta altura, é difícil até acompanhar porque rola

00:57:25muito rápido. Mas eu tinha aquela notificação no canal. Eu ficava

00:57:31tipo, "ah, droga", sabe, alguém se inscreveu. Você está atacando o Slack com DDOS?

00:57:38Não, definitivamente não naqueles dias. Mas você disse que ainda tem isso agora, por isso

00:57:44perguntei. Certo, certo. Bem, as coisas estão indo bem, mas não acho que chegue ao

00:57:48ponto de derrubar o Slack. Enfim, pessoal, desculpe por isso, mas acho que a principal

00:57:54suposição no início que era problemática era essa ideia de que era construído

00:57:58principalmente para observabilidade. Acho que simplesmente não era o suficiente. Mas quando você passa de dizer

00:58:02que está criando uma ferramenta de observabilidade para dizer que está reinventando um barramento de mensagens,

00:58:08o escopo explode dramaticamente. Então, acabei conhecendo o CTO e cofundador no meio

00:58:15da construção do primeiro mecanismo de filas. E, quando

00:58:19percebi que o escopo ia explodir, foi aí que

00:58:23fomos atrás de um pequeno aporte, investidores anjo e coisas assim.

00:58:28Era evidente que seria bem caro de construir, e acabou sendo mesmo.

00:58:32E, pelo que entendi, você não seguiu o caminho típico de SF. Você construiu em Montreal, certo?

00:58:36Sim, talvez seja um pouco desonesto dizer isso. Nós fizemos

00:58:39um pré-seed de cerca de 400.000 dólares apenas com investidores anjo, sem VCs institucionais.

00:58:44Mas alguns meses depois fizemos nosso Hacker News e foi aí que realmente soubemos,

00:58:51voltando à sua pergunta, James, que a resposta do Hacker News, bem, não foi

00:58:56o maior "Show HN" de todos os tempos, mas foi muito melhor do que

00:59:00esperávamos. Uma anedota engraçada: lembro-me daquele cara que comprou um plano de 300 dólares

00:59:05depois do Hacker News. Lembro-me do meu cofundador e eu dizendo, "cara, conseguimos".

00:59:11Foi um negócio fechado. Tínhamos certeza de que iríamos dar certo.

00:59:18Fomos jantar naquela noite e gastamos tudo. É algo a mais.

00:59:22Sim, é exatamente isso. A garrafa de champanhe. Mas, de qualquer forma,

00:59:25daquele "Show HN", tivemos muito interesse de investidores entrando em contato

00:59:31proativamente. Então, acabamos levantando uma rodada de investidores do Vale do Silício,

00:59:34uma empresa chamada Matrix Partners. Então, ainda somos uma equipe centralizada,

00:59:38uma empresa canadense. Não mudamos para uma LLC em Delaware, mas, ao mesmo tempo,

00:59:44acho que nossos investidores foram tremendos e fico muito feliz que fizemos isso.

00:59:50Acho que por causa da COVID, houve uma aceitação crescente de que empresas

00:59:55não precisam estar baseadas em tal lugar e podem construir equipes remotas.

01:00:00Quero dizer, várias pessoas já faziam isso, não inventamos nada. Ainda existem

01:00:04Zapier, GitLab e todos esses caras que fazem isso há muito mais tempo.

01:00:08Então acho que isso apenas normalizou a prática.

01:00:12E, talvez eu seja ingênuo, mas é algo que vi de alguns fundadores.

01:00:17Como fundadores canadenses, existe esse debate no Twitter sobre incorporar em Delaware,

01:00:21já que a YC parou de aceitar empresas canadenses. Depois voltaram atrás na decisão.

01:00:27Mas havia esse entendimento de que todo investidor vai pedir para você se tornar uma LLC em Delaware.

01:00:32E eles têm razão. Todo investidor vai pedir, mas a parte que falta na história é que você pode simplesmente dizer não.

01:00:38Sim, com certeza. Eles vão perguntar "por que não?". É mais fácil para eles,

01:00:42mas se você disser não, também é totalmente aceitável. Pelo menos na minha experiência,

01:00:47e de muitas pessoas ao meu redor. Então acho que essa é a parte que falta.

01:00:54Hum, então sim, com certeza. Eles vão perguntar, sabe, tipo por que não? E é mais fácil para eles,

01:00:58Não quero discutir prós e contras. Tenho certeza de que há pontos positivos,

01:01:03mas é sua escolha como fundador e construtor com quem e onde vai fazer isso.

01:01:07Se você tem boas ideias e trabalha duro, os investidores respeitarão isso.

01:01:11Pelo menos alguns respeitarão. Pode ser que seu trabalho seja encontrá-los.

01:01:15Então, seria desonesto dizer que estamos completamente fora dessa bolha,

01:01:19mas, pessoalmente, construí minha vida aqui e estou feliz por estar em Montreal.

01:01:24fundador e construtor, com quem você vai fazer isso e onde vai fazê-lo.

01:01:27E acho que se você tiver boas ideias e trabalhar duro nelas, os investidores ainda vão

01:01:31respeitar isso, ou pelo menos alguns investidores ainda vão respeitar. Certo. E talvez o seu

01:01:36trabalho seja encontrá-los, mas sim. Então, acho que seria desonesto dizer que estamos completamente

01:01:41fora dessa bolha, mas, eu sei pessoalmente, sabe, construí minha vida aqui e

01:01:47estou muito feliz por ainda estar em Montreal. Bem, como um colega canadense, é bom

01:01:52ouvir histórias de sucesso canadenses. Então, parabéns por isso, mas aí você se mudou para Toronto e

01:01:57simplesmente estragou tudo. Justo, justo. Posso dizer que, como um colega da Commonwealth, é ótimo, certo? O mesmo

01:02:06rei. É a mesma coisa, sabe? Sim. Nós temos o rei. Quer dizer,

01:02:11não sei se já atualizaram para o rei agora, mas tínhamos a rainha em nossa nota.

01:02:14Sim. A Hookdeck foi sua primeira startup como fundador ou houve outras na jornada que lhe deram

01:02:19meios de saber como contatar investidores e encontrá-los? Sempre fui

01:02:23muito empreendedor desde o início com pequenas empresas, tipo ir para

01:02:27zonas de aposentados, consertar computadores aos 14 ou 15 anos e coisas assim. Certo. Então, acho que nesse

01:02:34sentido, falando mais do espírito empreendedor, mas não, acho que

01:02:38a maior parte foram projetos paralelos fracassados, como lançar um videogame que basicamente nunca

01:02:44chegou a lugar nenhum. Sabe, várias outras coisas, em certo ponto eu estava trabalhando em uma rede social,

01:02:48apesar de eu ser provavelmente o pior cara para encontros sociais e para organizar

01:02:53coisas com amigos. Enfim, passei por várias situações. Devo dizer, porém,

01:02:58essa experiência na empresa de e-commerce foi realmente muito formativa no sentido de que

01:03:03eu fui o primeiro funcionário lá e me envolvi muito com a equipe fundadora.

01:03:07E fomos de, você sabe, basicamente quatro pessoas para umas 40 ou algo assim

01:03:13em três anos. E todo o processo de construir aquele negócio e tudo mais,

01:03:19tudo aquilo. Então, eu penso na Hookdeck como a primeira,

01:03:23mas seria desonesto posicioná-la totalmente como tal. Acho que houve uma exposição a essas coisas

01:03:27antes disso. E obviamente tive essa empresa de e-commerce. Trabalhamos com investidores também,

01:03:31com o conselho e esse tipo de coisa, e construímos relacionamentos lá também.

01:03:36E o primeiro investidor daquele negócio de e-commerce foi também nosso primeiro investidor inicial na Hookdeck.

01:03:39Então, não foi começando totalmente do zero, como algumas pessoas podem se encontrar, mas sim,

01:03:44acho que ainda não esperava estar aqui há alguns anos. E isso é ótimo.

01:03:48Eu vi que existe uma empresa chamada Kiwi Mornings, uma startup de café da manhã saudável. O que era tudo aquilo?

01:03:54E quanto à sua lição de casa. Então, esse foi um dos negócios fracassados ao longo do caminho.

01:04:02Na verdade, comecei com minha esposa. A história é que minha esposa trazia

01:04:09o café da manhã dela para o trabalho, e todos os vendedores lá tinham inveja

01:04:14do café da manhã dela e começaram a pedir um para ela. E eu fiquei tipo, como assim o café da manhã dela era para os vendedores?

01:04:19O que há de errado? Mas aí uma coisa levou a outra e ela começou a fazer cinco

01:04:24ou seis cafés da manhã todas as manhãs para a equipe de vendas. E eles pensaram, por que não,

01:04:30sabe, uma daquelas ideias estúpidas, por que não transformar isso em um negócio? E então,

01:04:36construímos esse serviço para café da manhã com desperdício zero no trabalho. E entregávamos

01:04:41iogurtes, smoothies, pudins de chia e coisas assim em potes de vidro.

01:04:47Tínhamos geladeiras pequenas nos escritórios e tudo mais. E, sendo quem sou, levei isso

01:04:51longe demais. No lado de produto e engenharia, todos os pedidos eram feitos através de um

01:04:56bot do Slack, e os empregadores podiam oferecer como benefício onde, essencialmente,

01:05:01eles pagariam 50% do café da manhã. E sabe, tinha toda essa coisa.

01:05:06Então, sim, as pessoas pediam o café da manhã pelo bot do Slack e tudo mais, não necessariamente.

01:05:11Chegou ao fim. É só que nesse negócio, tudo dá errado às quatro da manhã,

01:05:16e não há dinheiro em comida. Quando você combina essas duas coisas, é muito difícil

01:05:20construir um negócio satisfatório. Então, em certo ponto, acabamos vendendo o

01:05:25bot do Slack e tudo mais, e paramos de fazer. Mas, felizmente,

01:05:29isso foi em janeiro de 2021. Então, dois meses antes da COVID. E, basicamente, todas as

01:05:34empresas equivalentes, e havia muitas fazendo almoço para escritórios e coisas assim,

01:05:42basicamente todas faliram. Então, tivemos um pouco de sorte com o tempo, porque

01:05:46teria terminado de qualquer maneira. Certo. Mas, no geral, acho que vendemos uns 20 mil cafés da manhã.

01:05:52Oh, muito legal. É bem legal.

01:05:57Então, sempre gostamos de perguntar aos nossos convidados, quais são suas opiniões fortes

01:06:01sobre o setor, IA, o que for, mande ver. Sinto que já dei algumas nesta conversa.

01:06:06Acho que sim. Qual é a sua opinião mais polêmica? Algo bem quente.

01:06:12Uma opinião bem polêmica. Ok. É aqui que provavelmente vou te perder, porque é algo muito específico

01:06:18sobre arquitetura e sistemas. Tenho certeza que parte do nosso público vai entender o que você está

01:06:22dizendo. Perfeito. Então, minha opinião polêmica é que sistemas de consumo baseados em 'pull' (coleta)

01:06:29são muito limitados comparados aos sistemas baseados em 'push' (envio). E a razão pela qual não adotamos

01:06:35sistemas de push é porque ninguém construiu um bom sistema de push. E a razão pela qual digo isso,

01:06:42e tentarei dar um pouco de contexto, é que quando você constrói filas e consumidores para cada

01:06:49fila em que coloca eventos, você precisa de um consumidor para ela. E esse consumidor

01:06:56pode ser um worker de longa duração puxando dados daquela fila. Mas o problema é que, se você quer ter filas dinâmicas,

01:07:02digamos, uma fila por cliente, porque você não quer que um cliente atrase toda a fila ou

01:07:07ocupe toda a capacidade, você precisa de tantos consumidores quanto filas,

01:07:12o que se torna insano devido ao problema de multiplexação.

01:07:16A grande vantagem do sistema de push é que todas essas filas podem enviar para o mesmo

01:07:21consumidor. E esse único consumidor pode ser uma API com um balanceador de carga na frente, que você pode

01:07:26escalar horizontal ou verticalmente. O ponto é que você pode fazer isso totalmente desacoplado

01:07:31de quantas filas você realmente tem. E acho que uma coisa que estamos vendo é que,

01:07:36quando você entra em casos de uso cada vez mais complexos, você acaba com formas

01:07:41mais granulares de querer colocar coisas em fila. Então, você quer filas por tópico, por condições específicas,

01:07:45por cliente e assim por diante. E fica completamente insano porque aí você tem 100 filas,

01:07:49100 consumidores e toda a bagunça que vem com isso. Mas é muito difícil hoje

01:07:54encontrar filas de mensagens baseadas em push.

01:07:58E a razão para isso é que você está mudando onde o throughput é controlado. Se o throughput

01:08:02é controlado no consumidor, cada consumidor é responsável por dizer: 'Quero 50 mensagens por segundo'.

01:08:07E quantas mensagens você consome depende da capacidade de um worker, quantos workers você tem,

01:08:13e qual a capacidade efetiva. Não é porque você diz que quer 50 por segundo que

01:08:17realmente vai a 50, pois depende de todo o resto do código e se ele é rápido o suficiente.

01:08:22Então, acho que a razão pela qual não mudamos para filas de push é que a maioria não dá

01:08:29a granularidade necessária. Por exemplo, o Google Pub/Sub tem um modo push,

01:08:33mas no modo push, eles basicamente aumentam a taxa na qual enviam requisições até

01:08:37sua API começar a ficar lenta, o que significa que eles degradaram o serviço.

01:08:40E então eles diminuem a taxa. E o resultado final é que ele sobe, sobe, o servidor trava

01:08:45ou tem degradação de performance, volta para zero, e depois recomeça.

01:08:50É totalmente inútil. E acho que se você construir filas de push

01:08:55com controle refinado sobre o throughput e comportamento exato da taxa de consumo,

01:09:00isso simplifica muito sua arquitetura. Então, essa é a opinião que defendo.

01:09:06Quer dizer, não entendi tudo, mas pareceu razoável, sabe?

01:09:11Acho que se você entendeu, vá conferir a Hookdeck. Sim, exatamente.

01:09:15Agradeço isso. Bem, obrigado, Alex. Obrigado por ouvir este episódio do

01:09:20Better Stack Podcast. Encontre-nos onde você ouve seus podcasts, Spotify, Apple Music ou qualquer outro lugar.

01:09:24Mas hoje é um adeus da minha parte. Adeus da minha parte. E um adeus da minha parte.

01:09:29arquitetura. Então, isso é tudo que eu defendo para quem entende e, mas, mas, mas, mas, eu estou disposto

01:09:34a morrer por isso. Quer dizer, eu não entendi tudo, mas pareceu razoável, sabe?

01:09:40Acho que se você entendeu, dê uma olhada no Hookdeck. Sim, exatamente.

01:09:46Agradeço, sim. Bem, obrigado, Alex. Obrigado por ouvir este episódio do

01:09:50Better Stack Podcast. Encontre-nos onde você ouve seus podcasts, Spotify, Apple Music ou em qualquer outro lugar.

01:09:57Mas hoje é um adeus da minha parte. Adeus da minha parte. E um adeus da minha parte.

핵심 요약

A arquitetura de eventos e o gerenciamento de webhooks substituem filas tradicionais e resolvem a complexidade de integração por meio de gateways focados na experiência do desenvolvedor.

하이라이트

O Hookdeck opera com dois produtos principais: o EventGateway para consumo de webhooks e o Outpost, uma ferramenta de código aberto voltada para o envio de eventos.
A infraestrutura do Outpost processa mais de 10 produtos e utiliza exatamente a mesma compilação Docker publicada no Docker Hub a partir do código aberto.
A adoção de webhooks e eventos em plataformas como a Vercel cresceu expressivamente devido à expansão dos fluxos de trabalho e agentes de inteligência artificial.
O tempo de entrega de webhooks em grandes plataformas como o Shopify apresenta latências de referência entre quatro e cinco segundos, com alertas disparados acima de dez segundos.
O Hookdeck conta com uma equipe enxuta de 10 colaboradores e opera com um modelo totalmente remoto baseado em profissionais seniores e autônomos.

타임라인

Apresentação do Hookdeck e Ecossistema de Eventos

O Hookdeck desenvolve o Event Gateway para normalizar e gerenciar eventos e webhooks de fontes externas como Stripe, Shopify e Twilio.
O projeto Outpost funciona como uma solução de código aberto sob licença Apache 2.0 para publicação de eventos e destinos de mensagens.
A arquitetura orientada a eventos introduz desafios operacionais como idempotência, ordenação e garantias de entrega que superam o transporte HTTP básico.

O barramento de eventos padroniza a interoperabilidade entre múltiplos fornecedores que possuem critérios e requisitos específicos. A transição de webhooks simples para arquiteturas orientadas a eventos exige o tratamento de filas, retransmissões e alertas de falhas. O Outpost permite que desenvolvedores enviem webhooks e publiquem eventos diretamente em barramentos de mensagens dos usuários finais.

Código Aberto e o Papel da Inteligência Artificial

A versão gerenciada do Outpost executa exatamente a mesma compilação Docker disponível no repositório de código aberto.
O uso de ferramentas de IA generativa no desenvolvimento reduz barreiras de entrada, mas atrai pull requests superficiais ou com APIs inexistentes.
A ascensão de agentes de inteligência artificial eleva o volume de eventos gerados em plataformas de infraestrutura e suporte ao cliente.

A estratégia de código aberto alinha os incentivos comerciais com a comunidade de desenvolvedores ao eliminar forks privados na versão gerenciada. As ferramentas de IA auxiliam equipes enxutas no desenvolvimento e na operação, embora gerem um volume elevado de revisões de código automatizado. O aumento de agentes inteligentes substitui acionamentos humanos por gatilhos baseados em eventos.

Latência, Interrupções e Confiabilidade de Fornecedores

O Deck Radar monitora estatísticas agregadas de entrega e calcula desvios de latência para fornecedores como o Shopify.
O tempo de inatividade em plataformas de terceiros gera picos de tráfego conhecidos como efeito rebote durante a recuperação dos backlogs.
A saturação de servidores causada por disparos em massa resulta em tempos limite e perda potencial de dados se os endpoints falharem.

As variações de latência em serviços externos dificultam a identificação de gargalos operacionais a partir de métricas internas isoladas. Quando plataformas importantes sofrem interrupções prolongadas, a retomada do envio de eventos sobrecarrega os servidores de destino. O gerenciamento adequado do tráfego evita o comportamento de negação de serviço involuntária sobre os clientes.

Operações, Empreendedorismo e Gateways de Eventos

A equipe de engenharia do Hookdeck opera com 10 pessoas sob um formato estritamente assíncrono e ciclos de alinhamento quinzenais.
O termo gateway de eventos foi cunhado para preencher a lacuna entre gateways de API e barramentos de mensagens tradicionais.
Sistemas de consumo baseados em envio superam os modelos de coleta ao centralizar o controle de capacidade e reduzir a complexidade de multiplexação.

A empresa mantém uma estrutura descentralizada com foco em autonomia e contratação de perfis seniores. O conceito de gateway de eventos estabelece um padrão de infraestrutura em nuvem agnóstico em relação ao ecossistema da AWS. A defesa por sistemas de envio reflete a busca por arquiteturas mais escaláveis no processamento de cargas assíncronas.

커뮤니티 글

모든 글 보기

이 영상에 대해 글쓰기