Событийно-ориентированная архитектура, хаос вебхуков и развитие AI-агентов | Better Stack Podcast, эп. 17
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술
스크립트
00:00:00Добро пожаловать на подкаст Better Stack, где мы обсуждаем разработку программного обеспечения,
00:00:04ИИ и всевозможные новые технологии. Я один из ваших ведущих, Андрус, и сегодня со мной
00:00:10Джеймс и Алекс. Привет, Алекс, добро пожаловать на шоу. Спасибо, что пригласили, ребята. Итак, давайте начнем
00:00:16с компании, которой ты руководишь. Она называется Hookdeck. Для тех, кто не знаком,
00:00:22что такое Hookdeck? Что она делает? Расскажи нам подробнее. Да, мне нравится думать о ней как о
00:00:27компании, которая пытается убить вебхуки. Это, наверное, история, в которую мы можем углубиться.
00:00:32Мы создаем два основных продукта. Один из них — Event Gateway. Event Gateway служит
00:00:37чем-то вроде специализированной шины событий для всех событий, поступающих извне вашей инфраструктуры.
00:00:41Вебхуки — главный подозреваемый, но мы видим много сценариев использования IoT, SDK и так далее.
00:00:47По сути, мы предоставляем своего рода ненадежную конечную точку. Вы можете отправлять любые события.
00:00:51А затем все возможности для управления этими событиями. Это фильтрация,
00:00:55трансформация, маршрутизация, очереди, оповещения, управление инцидентами и повторная отправка — в общем, всё.
00:01:01Так что на самом деле это охватывает как интероперабельность, в том смысле, что мне нужно получать
00:01:05события и вебхуки от всех вендоров, с которыми я работаю, верно? Это может быть Stripe, Shopify, Twilio,
00:01:10WhatsApp, TikTok, что угодно, вы называете. У каждого из них свои критерии, причуды
00:01:16и специфические требования. И мы можем стандартизировать всё это и свести
00:01:20к единому контракту. А затем всё с точки зрения очередей. Например, если в
00:01:27Shopify проходит флеш-распродажа в вашем магазине, и вас просто заваливает
00:01:31потоком событий. Вы нормализуете это, чтобы контролировать пропускную способность, и шлюз событий
00:01:38делает всё это. Так что это большая часть дела. Это сторона потребителя. И с этого
00:01:42собственно и началась история Hookdeck. Совсем недавно мы выпустили Outpost. Outpost — это полностью
00:01:49open-source проект с лицензией Apache 2.0. И у нас теперь есть управляемый сервис для него. Он предназначен для отправки
00:01:55событий. Это как бы другая сторона уравнения, верно? Вы как издатель, как
00:01:59платформа или разработчик инструмента. Мы сейчас в той точке, где все отправляют события. Я удивляюсь
00:02:05каждый день. И Outpost — это управляемый или самостоятельно хостируемый сервис, который вы можете использовать, чтобы
00:02:12объявлять, кто ваши арендаторы, какие у них зарегистрированы пункты назначения и конечные точки, настраивать
00:02:17темы и публиковать в них события. Он обрабатывает всё: от видимости, метрик, гарантий доставки,
00:02:23повторных попыток до всех обычных вещей, таких как подписи, ротация подписей
00:02:28и всё такое. Шутка про то, что я пытаюсь убить вебхуки, заключается в том, что Outpost,
00:02:35да, позволяет отправлять вебхуки, но также позволяет публиковать события напрямую в шину сообщений
00:02:39вашего пользователя. Outpost изначально поддерживает то, что теперь известно как пункты назначения событий. Вебхук же
00:02:46считается транспортным маршрутизатором. По сути, вы отправляете события через вебхуки, и
00:02:53вебхуки — это стандартный транспортный механизм, верно? А вы можете выбирать новые протоколы, такие как MQ
00:02:59для RabbitMQ или Kafka. И мы поддерживаем публикацию напрямую во все привычные места, такие как Pub/Sub,
00:03:05SQS, AWS EventBridge, и, очевидно, Hookdeck Event Gateway, верно? Мне нравится думать об этом как о
00:03:12лучшем пункте назначения, но посмотрим, поверят ли в это люди. Ты сказал, что хочешь убить вебхуки. Я
00:03:18представляю, что идея возникла из того, что вы все устали от вебхуков или ими
00:03:25было слишком сложно управлять. Расскажи, как к тебе пришла эта идея. Да, я как раз рассказывал
00:03:31эту историю кому-то на днях. Лет пять или около того назад я опубликовал статью на Medium.
00:03:37Наверное, уже приближаюсь к шести годам. Статья называлась — отсылая к тому, о чем ты
00:03:42говорил — “Вебхуки — отстой, но вы можете с этим что-то сделать”. Это был просто я в своем
00:03:48подвале, возился и строил прототип V1 для Hookdeck.
00:03:54Но это действительно выросло из того разочарования. Я лично работал в eCommerce, и мы создали
00:03:59много собственного ПО для поддержки eCommerce: от управления подписками до
00:04:05складского учета и фулфилмента. И так много проблем
00:04:10сводилось к вебхукам. Это было почти как шутка, потому что с одной стороны,
00:04:15я пытался продавать женскую моду, верно? Пытался продавать
00:04:18белье, нейлон и всё такое. А с другой стороны, возникал вопрос: где, черт возьми, этот
00:04:23чертов вебхук? Что с ним случилось? Это казалось совершенно несоответствующим задачам.
00:04:28И всё пришло из того разочарования: я как потребитель этих вебхуков
00:04:33видел, что нет никакого готового решения для этой
00:04:38проблемы. А если зайти в интернет и поискать рекомендации... Ну, в смысле,
00:04:43вебхуки — не новинка. В конце концов, это HTTP-запросы. Существуют
00:04:46устоявшиеся паттерны того, как с этим работать. Но вы очень быстро погружаетесь в кроличью нору.
00:04:50Окей. Вам нужны потребители для приема данных, которые могут автоматически масштабироваться, а затем нужно поставить их в очередь, например SQS.
00:04:55А потом нужно развернуть набор потребителей, которые будут обрабатывать эту очередь.
00:05:00И если что-то пойдет не так, оно попадет в очередь недоставленных сообщений (dead-letter queue).
00:05:05А потом вам нужен какой-то скрипт, чтобы восстановить данные из этой очереди и
00:05:09понять, почему они вообще туда попали. И возникает множество таких забот.
00:05:14По мере роста сложности вы также хотите иметь возможность воспроизводить исторические события,
00:05:18которые вы получили. Хотите видеть, каким был конкретный полезный контент (payload) вебхука.
00:05:22И вы начинаете иметь дело с разными вендорами, потому что, может быть, Stripe даст
00:05:26вам UI, а Intercom — нет. И вам приходится иметь дело со всеми этими
00:05:31разными причудами. Всё это выросло из того разочарования: почему не было решения этой проблемы?
00:05:35Сначала я смотрел на это с точки зрения наблюдаемости (observability), и это не очень сработало.
00:05:41Я упустил то, что наблюдаемость — это только одна часть. В конечном итоге, я называю вебхуки “наркотиком”
00:05:47для событийно-ориентированной архитектуры.
00:05:51Именно поэтому я настаиваю на термине “событие”, а не “вебхук”, что за каждым вебхуком
00:05:56стоит событие, и теперь существуют парадигмы событийно-ориентированной архитектуры,
00:06:01которые идут в комплекте с этим вебхуком, верно? И каждый раз, когда вы получаете вебхук
00:06:07для какого-то серьезного масштаба или критически важных случаев, вы должны теперь
00:06:14думать об идемпотентности, порядке, гарантиях доставки и всех видах
00:06:19вызовов, которые возникают, когда вы начинаете иметь дело с асинхронными событийно-ориентированными парадигмами программирования.
00:06:25Так что многое из того, что мы построили, в конце концов эволюционировало в создание полноценной очереди.
00:06:29Есть эта интероперабельность — мы имеем дело с событиями,
00:06:33но вся эта семантика касается работы с событиями, pub/sub-системами
00:06:38и так далее. Мы не пытались изобрести очереди заново. Думаю, мы наткнулись на кучу
00:06:43довольно крутых идей. И сейчас мы видим, что люди просто переходят на Hookdeck,
00:06:48чтобы заменить Pub/Sub или SQS в своем стеке, что
00:06:53для меня ошеломляюще, потому что мы не запускаем ваш VPC и все эти вещи. Думаю,
00:06:57с этим связано много проблем... может быть, в будущем. Но суть в том,
00:07:05что существует много семантики событийно-ориентированной архитектуры, к которой люди привыкли,
00:07:09и никто особо не задается вопросом. Почему мы снова делаем
00:07:13очереди недоставленных сообщений? Что, черт возьми, с этим не так? Я не знаю никого, кто считает, что
00:07:19очередь недоставленных сообщений — это удобная семантика для работы с ошибками в очередях, верно? Так что...
00:07:25я с радостью коснусь некоторых из этих вещей, потому что есть пара сильных мнений
00:07:29на этот счет. Не знаю, насколько вы, ребята, фанаты Pub/Sub и событийно-ориентированной архитектуры. Не хочу
00:07:35затягивать вас слишком глубоко. Я чувствую, да, моё понимание очередей недоставленных сообщений и
00:07:40всего такого очень поверхностное. Некоторые вещи, о которых я сегодня слышу, слышу впервые.
00:07:48Да, я тоже хотел сказать, что мое понимание на поверхностном уровне, но я имел дело с вебхуками
00:07:53немало и сталкивался с некоторыми упомянутыми вами проблемами. И я думаю, именно поэтому
00:07:57вы ребята и говорите, что вебхуки — это наркотик для событийно-ориентированной архитектуры,
00:08:01потому что я готов поспорить, что для разработчиков с вашим бэкграундом вебхуки — это
00:08:06вероятно, первое столкновение с мыслью: “Подождите, это асинхронно. Как мне с этим работать?”
00:08:12И есть вся эта кривая обучения, верно? Это как классический айсберг: есть
00:08:17HTTP-запрос, который приходит, а остальная часть айсберга
00:08:21скрыта под водой. И я думаю, одна из вещей, которую я пытаюсь
00:08:26сделать — это привнести уровень UX, который еще не был достигнут в этой сфере, чтобы
00:08:32вам не приходилось разбираться с остальной частью айсберга. Есть вещи, которые
00:08:37неизбежны, я не хочу вводить в заблуждение. Я думаю, когда начинаешь работать
00:08:40работая с подобными проблемами, нужно хорошо понимать идемпотентность,
00:08:45например, нужно хорошо понимать гарантии порядка. Так что
00:08:49нельзя сказать, что можно решить любую проблему. Думаю, в конечном счёте вы всё равно имеете дело с событиями.
00:08:53Но мне кажется, что семантика и сложность во многом возникают
00:08:58из-за непродуманных инструментов, а не из-за подлинной сложности,
00:09:05связанной с этой предметной областью. Поэтому сейчас мы, по сути, обслуживаем два
00:09:13типа клиентов: тех, кто глубоко разбирается в проблеме и
00:09:18готов заниматься инженерными решениями вокруг своей текущей настройки Kafka и всего
00:09:23такого прочего целыми днями. И мы предлагаем им некоторые новые семантики,
00:09:28и они действительно воодушевлены этим. Это одна категория. Но другая категория — это
00:09:31те, кто не хочет во всё это вникать и по сути пытается просто
00:09:36обойти всё это стороной. Да. Поэтому мы видим много представителей этих двух профилей.
00:09:41Это также причина, по которой вы сделали Outpost инструментом с открытым исходным кодом, чтобы разработчикам
00:09:47было проще начать пользоваться им? В некотором смысле. Другая причина в том, что нам не нужен Outpost,
00:09:53чтобы зарабатывать деньги. Ладно. Поэтому мы решили, что просто сделаем его открытым. Да. Это просто,
00:10:01я знаю, что нашей аудитории на YouTube очень нравится узнавать о новых open-source инструментах. Поэтому
00:10:07я и решил спросить об этом. Но, во-первых, я немного жалею,
00:10:13что в самом начале мы не использовали более открытый подход.
00:10:18Я думаю, что процесс создания программного обеспечения сильно отличается,
00:10:21когда вы строите его как закрытое или как открытое. Но
00:10:26возвращаясь к решению об open-source, я думаю, что одна из вещей, которую вы видите в венчурных
00:10:30стартапах, — это появление «фейкового» открытого ПО,
00:10:34то есть оно как бы open-source, но либо это open-core, либо да, оно открыто,
00:10:39но они на самом деле не хотят, чтобы вы им пользовались, или они в конечном итоге меняют лицензии
00:10:44на те, что уже не являются по-настоящему открытыми. Да. И я думаю,
00:10:49это очень вдохновило меня на развитие Outpost и open-source, потому что я почувствовал, что у нас есть
00:10:54возможность создать правильные стимулы. Может быть, мы немного углубимся в то, как мы
00:10:59думаем о бизнесе и всё такое. Но по моим представлениям, людей, которым
00:11:03нужно получать вебхуки на стороне потребителя, как минимум в два-три порядка больше,
00:11:09чем тех, кому нужно их отправлять, верно? Ведь подумайте, если я отправляю вебхуки,
00:11:13я отправляю их всем своим клиентам, а их может быть 10, если вы только
00:11:17начинаете, или 100, 1000, 2 миллиона. Да. И неизбежно, что сторона потребителей просто гораздо
00:11:24масштабнее. И когда я думаю об этом с точки зрения предпринимателя,
00:11:28я больше воодушевлён бизнесом, ориентированным на потребительскую сторону. Но мне кажется,
00:11:33мы поняли, что, очевидно, у вас не будет потребителей без хороших производителей. И думаю,
00:11:37спрос на вебхуки в целом растёт для всех приложений, которые вы разрабатываете. Поэтому,
00:11:42всё больше людей хотят их предлагать, но не хотят проходить через сложности настройки и всё остальное.
00:11:46Но с моей точки зрения, отправка вебхуков — это более простая задача, потому что вы
00:11:51контролируете параметры, в то время как на стороне получателя вы их не контролируете — продавец диктует,
00:11:57какими будут параметры. Так что это не то чтобы совсем просто, но
00:12:02безусловно, есть много способов сделать это неправильно. Но в плане сложности
00:12:06проблемы, для производителей она определённо более ограничена, чем для потребителей. И второе,
00:12:10наша работа — поощрять генерацию событий. Это то, о чём мы в конечном счёте
00:12:15заботимся, потому что мы хотим, чтобы больше людей потребляло эти вебхуки и в итоге потенциально
00:12:19становились нашими клиентами и всё такое. Поэтому я думаю, это ставит нас в положение, когда мы можем
00:12:23искренне сказать: смотрите, если вы собираетесь использовать Outpost, будь то в open-source версии или
00:12:29развёрнутой через управляемую версию Hookdeck, для нас это, как правило, не имеет значения. Мы достигаем
00:12:35бизнес-цели в любом случае. Это выравнивание стимулов очень меня
00:12:40вдохновило. И есть пара вещей, которые мы сделали: во-первых, мы выпустили open-source
00:12:44ещё до того, как задумались о создании управляемой версии. Планов строить
00:12:48управляемую версию, когда мы создавали открытую, не было. Проект с открытым кодом был опубликован
00:12:52около двух лет назад. Так что прошло почти два года, прежде чем достаточное количество людей
00:12:57запросили управляемую версию, и мы занялись её созданием. Это одна часть. И другая
00:13:03часть в том, что управляемая версия Outpost запускает в точности ту же сборку Docker, которая опубликована
00:13:08на Docker Hub из открытого исходного кода. Это встроено в саму суть, в том смысле, что у нас нет закрытого
00:13:13форка. Мы не упаковываем функции отдельно от открытого кода. Мы действительно используем одну и ту же
00:13:19сборку Docker. Поэтому вопрос для вас не в том, «предлагает ли она функцию X или Y»,
00:13:23а в том, хотите ли вы развернуть её сами и взять на себя
00:13:29операционную нагрузку, или хотите заплатить кому-то другому, чтобы он сделал это за вас?
00:13:34Нет правильного или неправильного ответа. Это зависит от каждого бизнеса, уровня
00:13:38комфорта, стека технологий, требований соответствия нормам и так далее. Но благодаря этому,
00:13:44я чувствую, что мы можем быть полезными участниками open-source сообщества с этим проектом. И да,
00:13:51я был очень рад работать над ним, потому что это первый крупный open-
00:13:55source проект, в котором я участвую не просто как человек, делающий вклад,
00:14:01а как основной мейнтейнер. Так что да, это был хороший опыт.
00:14:05Как вам мир open-source теперь, когда существуют Claude Code и всё такое? Было ли у вас
00:14:09много PR и ложных сообщений об уязвимостях или с этим легко справляться?
00:14:14Хм, послушайте, не думаю, что мы находимся в таком масштабе, чтобы я мог говорить о том, с чем сталкиваются
00:14:20другие люди. Поэтому я не хочу искажать ситуацию, потому что для многих
00:14:25всё звучит довольно плохо. Скажу лишь, что я был удивлён качеством
00:14:30вкладов, которые мы получали, но у нас определённо были и такие случаи, как один
00:14:34конкретный PR, который, кажется, до сих пор висит в репозитории, с добавлением очередей Cloudflare в качестве
00:14:40пункта назначения, так как это одно из поддерживаемых мест назначения событий.
00:14:44Описание в PR звучит хорошо и всё такое. Но когда начинаешь копаться
00:14:48в коде, оказывается, что там используются какие-то выдуманные API Cloudflare.
00:14:52И они даже не перепроверили это. Ясно, что человек, открывший PR, даже
00:14:56не пытался запустить его. Да. И теперь бремя ложится на нас: окей,
00:15:02теперь, когда висит этот открытый PR, я немного беспокоюсь, что нас могут воспринять как тех,
00:15:08кто не хочет поощрять людей, с которыми нас могут посчитать конкурентами.
00:15:12Поэтому я считаю, что нам стоит добавить очереди Cloudflare и всё такое, но в то же
00:15:15время это было в закрытом дорожной карте, никто, кроме этого человека, не просил об этом,
00:15:19и всё такое. И теперь это в подвешенном состоянии: если закрыть PR,
00:15:24выглядит так, будто вы не хотите поддерживать людей, которые могут быть конкурентами.
00:15:28Но стоит ли выделять ресурсы, менять дорожную карту и
00:15:33убеждаться, что всё реализовано правильно? Так что это дилемма.
00:15:37Но пока я чувствую, что это очень хороший опыт,
00:15:43особенно потому, что мы используем одну и ту же сборку. Ещё одна вещь, к которой мы пришли: когда
00:15:48клиенты обращаются за обратной связью или говорят нам о конкретных функциях и так далее,
00:15:53мы открываем issues на GitHub или ссылаемся на существующие PR и так далее.
00:15:58И мы стараемся всегда дать людям понять: «Кстати, репозиторий здесь,
00:16:03вы можете зайти и внести вклад». И, кстати, несколько наших
00:16:07управляемых пользователей внесли вклад, самостоятельно реализовав свои функции.
00:16:13И я думаю, это значительно снизило барьер входа для такого рода
00:16:18реальных случаев использования. Ведь исторически проекты на Go... большинство наших пользователей
00:16:24вероятно, вообще не являются Go-разработчиками. Мы видим много
00:16:28Python, TypeScript, очевидно, Node.js, и для Go есть барьер входа. А также
00:16:35изучение нового проекта для внесения вклада — это непросто. Поэтому
00:16:39я думаю, это значительно снизило барьер входа. И это действительно хорошо.
00:16:42Потому что теперь, если вы как пользователь столкнулись с тем, что вас что-то очень сильно беспокоит,
00:16:48то для меня как мейнтейнера это сильный сигнал, что функцию стоит реализовать.
00:16:53Кто-то тратит свое время и “токены” на внедрение этой функции.
00:16:58Это сигнал, что это действительно важно. Что касается ранжирования,
00:17:02что наиболее важно. Так что снижение порога входа — это очень хорошо.
00:17:07Думаю, если удастся справиться с потоком спама и всем этим,
00:17:12в этом много положительного.
00:17:14На целевой странице мне очень запомнился отзыв от генерального директора Vercel.
00:17:21Так что Vercel тоже использует Hookdeck как продукт.
00:17:25Если прочитать эту конкретную цитату, она тоже его рекомендует.
00:17:29О, понятно.
00:17:29Что-то вроде пользователей Vercel и тому подобное.
00:17:32Хм, но с этим связана забавная история.
00:17:35Гильермо написал об этом в Твиттере в субботу вечером.
00:17:39Я понятия не имел, что это произойдет.
00:17:40У меня не было никаких отношений с Гильермо до этого.
00:17:45Это говорит о влиянии некоторых людей в сообществе.
00:17:48Потому что количество регистраций и узнаваемости, которое мы получили от этого, было
00:17:53просто безумным.
00:17:54С тех пор мы с Гильермо время от времени общаемся.
00:17:57Это всегда были хорошие беседы и все такое.
00:17:59Интересно.
00:18:00Потому что, если посмотреть на такую компанию, как Vercel, Гильермо рассказывал мне,
00:18:04что видит гораздо больше людей, использующих вебхуки сейчас.
00:18:07И его мнение таково, что это в основном связано с использованием LLM.
00:18:12Это создает новые сценарии использования данных.
00:18:15О которых вы обычно не заботились раньше.
00:18:18Например, система поддержки клиентов.
00:18:20У вас есть агенты и люди, которые там работают.
00:18:23Нет особого смысла что-то делать с событиями о новых тикетах.
00:18:29И все в таком духе.
00:18:30Потому что, в любом случае, именно человек будет отвечать на это сообщение.
00:18:34Но теперь мы в мире, где все полностью меняется.
00:18:37И когда вы переходите от людей, запускающих агентов, к тому, что запускает агентов — это события.
00:18:42Верно.
00:18:42И внезапно вас начинают интересовать события из системы поддержки,
00:18:46маркетинговых инструментов и так далее.
00:18:48Верно.
00:18:48Это определенно то, что, я думаю, платформы сейчас замечают.
00:18:54Это были интересные дискуссионные темы для нас.
00:18:57Но да, Vercel не является нашим прямым пользователем.
00:19:01Уверен, многие разработчики используют ваш локальный CLI и все такое
00:19:05в Vercel, но да.
00:19:06Так кто же типичный клиент Hookdeck?
00:19:10Например, если у меня небольшой магазин футболок, как бы я использовал Hookdeck?
00:19:15И имело бы это смысл?
00:19:17Скорее всего, нет.
00:19:19Понятно.
00:19:21Хорошо.
00:19:22Вы задаете мне вопрос на миллион долларов в том смысле, что с этим мы всегда боролись,
00:19:26потому что спектр причин, по которым вам нужны вебхуки или вы зависите от них, просто огромен.
00:19:32Мы получаем вебхуки от обычных компаний, вроде Stripe и Shopify.
00:19:35Но также мы получаем их от австралийских телеком-провайдеров и клиринговых палат Великобритании.
00:19:40И, кстати, много вебхуков приходит от игры EVE Online.
00:19:47Есть также сообщество людей, до сих пор играющих в Conan the Barbarian,
00:19:50игру пятнадцатилетней давности.
00:19:55И они тоже активно используют вебхуки.
00:19:58Не спрашивайте меня зачем.
00:20:00Верно.
00:20:00Да.
00:20:01Суть в том, что очень сложно определить, кто наш типичный клиент.
00:20:06Именно так.
00:20:08Верно.
00:20:09Поэтому, когда мы смотрим на людей, которые этим пользуются, нет единого сценария,
00:20:13группы или чего-то еще.
00:20:14Что составляло бы более 10%.
00:20:16Но возвращаясь к вашему примеру с e-commerce.
00:20:19Прежде всего, небольшой магазин футболок вряд ли создал собственные приложения,
00:20:25которые бы зависели от этого.
00:20:27Но они почти наверняка установили готовые приложения.
00:20:30Например, приложение для сбора отзывов, для уведомлений о поступлении товара,
00:20:35управления запасами или приложение для работы с 3PL-провайдером.
00:20:39И все они почти исключительно полагаются на вебхуки.
00:20:43Верно.
00:20:43Поэтому, если я хочу отправить уведомление о наличии, я отслеживаю все
00:20:48обновления запасов в Shopify через их вебхуки.
00:20:50И как только товар, которого не было, снова в наличии,
00:20:53я думаю: “Окей, надо отправить письмо”.
00:20:54Верно.
00:20:55В сущности, все, что они установят или добавят, будет
00:20:59работать через вебхуки.
00:21:00Это одна большая категория.
00:21:02Люди создают приложения, и это не только Shopify, конечно. У Stripe, например,
00:21:07есть большой маркетплейс приложений.
00:21:09И многие из них наши клиенты.
00:21:11Другой тип клиентов — большие магазины.
00:21:14Думаю, наподобие Gymshark или Rogue, у которых есть технические команды,
00:21:19создающие собственные кастомные приложения.
00:21:22Они строят их для интеграции систем, часто очень операционной, с точки зрения
00:21:28последовательности действий: когда заказ должен быть синхронизирован с 3PL и дополнен примечаниями.
00:21:34Может быть, есть специфические предпочтения клиентов, которые нужно добавить в эти данные,
00:21:39прежде чем они попадут к 3PL.
00:21:41Верно.
00:21:41Некоторые вещи помогают улучшить пользовательский опыт, например, управление
00:21:46подписками или отправка определенных писем, когда кто-то покупает подарочную карту
00:21:51и хочет отправить её другу, ну и всё в таком духе.
00:21:55Так что это то, что мы обычно видим. Небольшой магазин Shopify — это, вероятно,
00:21:59тот пример, который вы привели, и где люди не очень часто используют Hookdeck, но
00:22:04почти везде в этом сегменте вы столкнетесь с компанией,
00:22:08которая использует Hookdeck.
00:22:09Справедливо.
00:22:10Вполне.
00:22:11Как это сравнимо с чем-то вроде AWS EventBridge?
00:22:14Потому что это один из вариантов, о которых я слышал.
00:22:17Это просто лучший опыт для разработчиков?
00:22:19Ну, очевидно, все мы знаем AWS. Я имею в виду, что Better Stack делает примерно
00:22:24то же самое, верно?
00:22:25Да.
00:22:26И все, что вы говорите о своем уникальном торговом предложении в сравнении с CloudWatch,
00:22:31сервисами Amazon и всем остальным, переносится и сюда.
00:22:37Это в значительной степени аргумент в пользу опыта разработчика, верно?
00:22:40Нормальные API, MCP, приятный UI, солидная наблюдаемость и тому подобное.
00:22:46Верно.
00:22:47Верно.
00:22:47И, очевидно, с интеграцией. Я думаю, проблема AWS всегда в том, что
00:22:51в итоге у вас 20 сервисов, названия большинства из которых вы уже забыли.
00:22:56Данные разбросаны, конфигурация разбросана, и все такое.
00:22:59Разбросана, все разбросано.
00:23:01Верно.
00:23:01Это один из моментов.
00:23:02Но более важный момент в том, что AWS EventBridge не интегрируется со всеми.
00:23:07Со всеми.
00:23:08Вендор должен сам интегрироваться с AWS EventBridge.
00:23:11Есть способы обойти это с помощью API Gateway и тому подобного.
00:23:16Но суть в том, что это решение создано для экосистемы AWS, где большая часть
00:23:23сценариев — это внутренние события AWS, например, когда загружен новый документ S3,
00:23:31и все такое.
00:23:31Взаимодействие со сторонними сервисами ограничено — они поддерживают сорок с лишним,
00:23:36не цитируйте меня, может, уже больше, но точно не тысячи.
00:23:40Вы всегда попадаете в ситуацию: окей, Shopify поддерживает EventBridge, а Twilio — нет.
00:23:45Twilio нет.
00:23:47Верно.
00:23:47Поэтому вы можете предложить агностическое решение,
00:23:51которое просто работает везде.
00:23:52Думаю, это то, что мы пытаемся сделать.
00:23:54Мы строим систему так, чтобы вендорам не нужно было соглашаться или
00:23:59делать что-либо со своей стороны.
00:24:02В этом плане, то, как мы строим Hookdeck, довольно инновационно: он
00:24:08полностью работает по HTTP.
00:24:10Идея в том, что мы даем вам URL, и вы можете заменить существующий URL вебхука
00:24:15на предоставленный нами.
00:24:17А в Hookdeck вашим пунктом назначения будет ваш старый URL.
00:24:22Мы работаем как очередь с методом push между ними.
00:24:25Мы получаем все вебхуки по HTTP, а затем отправляем их с той скоростью,
00:24:28которую вы укажете, на ваш эндпоинт.
00:24:31Это означает, что вам даже не нужно переразвертывать код.
00:24:34Вы можете быть на любом облаке, на любом стеке, и всё заработает практически сразу.
00:24:39Верно.
00:24:40Ведь единственное требование — обновить URL.
00:24:44Это далеко от AWS EventBridge, который требует привязки к вендору,
00:24:48специфической совместимости и работает только в экосистеме AWS.
00:24:53Да.
00:24:53Я обычно думаю об EventBridge как о другом большом шлюзе событий.
00:24:58Мы также видим, что Azure Event Grid, как конкурент, набирает обороты.
00:25:04Так что, когда я думаю о наших прямых конкурентах или источниках вдохновения,
00:25:10это эти два продукта.
00:25:13Но я определенно думаю, что масштаб того, что мы делаем, гораздо больше.
00:25:17Для одних это хорошо.
00:25:18Для других — нет, верно?
00:25:20Некоторым нужно именно это.
00:25:22Они полностью погружены в экосистему AWS.
00:25:24Используют CloudFormation.
00:25:26Знакомы со всеми сервисами.
00:25:27Хотят иметь возможность выбирать инструменты.
00:25:30И знаете, это нормально.
00:25:31Я не думаю, что мы когда-либо займем 100% рынка.
00:25:34На самом деле, пара процентных пунктов — это, вероятно, все, что нужно.
00:25:38Мы пытаемся доказать, что для компаний и разработчиков, которые этого хотят,
00:25:45наше решение будет правильным.
00:25:48А для других AWS EventBridge будет в самый раз, и это нормально.
00:25:51Я заметил, что за последний год количество простоев у крупных компаний увеличилось.
00:25:59Везде мемы про падения GitHub.
00:26:00Помню, два года назад, когда я работал,
00:26:02если P99 падал до 99.5 или ниже, это был повод для серьезного
00:26:07разговора с командой: “Как это могло произойти?”
00:26:13Верно.
00:26:14Теперь это в порядке вещей.
00:26:15Верно.
00:26:17Да.
00:26:17Люди привыкли, что GitHub может лежать долгое время.
00:26:23С вашей точки зрения, видите ли вы, что в этом году простоев больше,
00:26:28чем в предыдущие годы, и как вы справляетесь с этими вызовами?
00:26:33Да, это интересно, потому что это нужно учитывать, если вы собираетесь
00:26:37использовать вебхуки. Вебхуки GitHub, в частности, очень проблемные.
00:26:42Шанс один к двум, что если вы зайдете на Railway или Vercel,
00:26:46там будет баннер.
00:26:47Типа “деплой недоступен из-за проблем с вебхуками GitHub”.
00:26:51CTO GitHub написал пост о стабильности инфраструктуры,
00:26:58в разгар всех мемов, пытаясь как-то утихомирить ситуацию.
00:27:02Не думаю, что это сработало.
00:27:03Но одна вещь была там указана.
00:27:05Одной из причин была стабильность вебхуков,
00:27:09и их зависимость от MySQL и всего остального.
00:27:12Верно.
00:27:13Надо отдать им должное, мой тон может быть немного пренебрежительным.
00:27:17Я не сомневаюсь, что инфраструктурные вызовы у них совершенно безумные,
00:27:21с появлением агентов.
00:27:23Так же, как и те мейнтейнеры open-source проектов, которых завалили работой.
00:27:26Это инфраструктурный перегруз.
00:27:30Извините, уверен, это сложнейшая задача.
00:27:33Но к чему я веду: да, мы видим это.
00:27:38И более того, мы мониторим это для некоторых вендоров.
00:27:41Например, у нас есть штука, которую мы называем радаром для вебхуков.
00:27:44Идея в том, что мы можем просматривать агрегированную статистику от всех клиентов и по всем
00:27:49вебхукам, которые мы получаем через Hookdeck, а затем вычислять такие показатели, как, например, задержка
00:27:53доставки, какова задержка доставки P99 для поставщика, каково время их безотказной работы и всё такое.
00:27:58Например, наш радар для Shopify довольно популярен.
00:28:01На него подписана пара сотен пользователей.
00:28:04Идея заключается в том, что мы отправляем вам оповещения, если задержка выходит за пределы определённого
00:28:09стандартного отклонения от базового уровня задержки.
00:28:12Да.
00:28:12Мне кажется, в случае с Shopify базовая задержка составляет около четырёх или пяти секунд
00:28:17для доставки.
00:28:17Думаю, если она превышает 10 секунд,
00:28:19да.
00:28:20Мы отправляем оповещение.
00:28:22Идея в том, что вы можете отслеживать это как временные ряды и смотреть
00:28:26на их время работы, не только в плане общего аптайма, но и на профиль задержек
00:28:31с течением времени.
00:28:32Это определённо то, что можно наблюдать.
00:28:33И я имею в виду, что команда Shopify прекрасно об этом знает.
00:28:36Но видно, что в этом времени доставки есть большая вариативность.
00:28:41Так что, знаете, возможно, раз в два месяца или около того,
00:28:46происходит довольно значительный инцидент с задержкой.
00:28:49И я думаю, что это то, чего обычно не замечают.
00:28:51Верно.
00:28:52Потому что простои, очевидно, заметить гораздо проще.
00:28:54Вы заходите в Datadog или Better Stack.
00:28:57Вы, ребята, снова называете это продуктом для метрик?
00:29:01Наблюдаемость.
00:29:02Да, наблюдаемость.
00:29:03Так что вы заходите в Better Stack, очевидно, строя всё это.
00:29:05Да.
00:29:06И вы смотрите на HTTP-запросы к вебхуку, а они просто перестают приходить.
00:29:11Верно.
00:29:11Проблема довольно очевидна, и это просто.
00:29:14Но если задержка возрастает до 60 секунд, это уже очень трудно
00:29:19определить по вашим актуальным метрикам.
00:29:22Верно.
00:29:23И это происходит потому, что задержка возникает на этапе обработки, что вы, возможно, и
00:29:27отслеживаете, и так далее.
00:29:28Но это задержка на стороне поставщика.
00:29:31Но теперь, если в вашем коде или бизнес-операциях есть предположение,
00:29:34что события приходят в реальном времени, а они приходят с задержкой в 60 секунд,
00:29:39это может начать вызывать кучу нюансов, багов и неверных предположений
00:29:44в коде и тому подобное.
00:29:46Поэтому я думаю, что мы занимаем более уникальную позицию,
00:29:50чтобы предоставлять полезные данные.
00:29:52Так что вы можете знать: “О, проблема у меня или у моего поставщика?”
00:29:55Верно.
00:29:56У кого возникают проблемы?
00:29:57Не знаю, могу ли я эмпирически прокомментировать, насколько это выросло или уменьшилось.
00:30:03Есть ли обычные подозреваемые, которые выходят из строя и так далее.
00:30:06На них легко указывать пальцем.
00:30:08Я не уверен, назвал бы я это глобально распределённой проблемой, которую мы видим постоянно.
00:30:13Мне кажется, она более сконцентрирована у конкретных поставщиков.
00:30:16И я думаю, что люди чаще всего страдают именно от задержек доставки.
00:30:23Ещё одно, люди полагают, что задержка доставки у большинства поставщиков меньше, чем есть на самом деле,
00:30:27потому что в большинстве случаев речь идёт о нескольких секундах, что,
00:30:31в зависимости от того, как на это смотреть, может быть долго или не очень.
00:30:34Но я думаю, когда я показываю этот график задержки, например, Shopify, группе разработчиков Shopify,
00:30:40у них первая реакция: “Я этого не ожидал”.
00:30:43Верно.
00:30:43Возникает своего рода разрушение ожиданий.
00:30:46Я работал в довольно крупной компании электронной коммерции, и у нас была та же проблема.
00:30:53Задержка ужасна, но все были как в том меме с Человеком-пауком, указывающим друг на друга,
00:30:58выясняя, чья команда за это отвечает.
00:30:59Потому что обычно это сторонний поставщик, как вы и сказали.
00:31:05И иногда с этим просто ничего нельзя поделать.
00:31:07Нужно просто искать обходные пути.
00:31:08Так что всё в порядке.
00:31:09Нужно быть осторожным, обвиняя поставщика.
00:31:11Верно.
00:31:11Это то, что, очевидно, в контексте того, что делаете вы,
00:31:16всегда является общей проблемой.
00:31:18Всякий раз, когда у нас возникает инцидент, мы думаем: “Окей, сколько вины лежит на поставщике?”
00:31:22Но в какой-то момент возникает вопрос разумности происходящего.
00:31:27Что является случайностью, а что нет.
00:31:29Например, на днях Railway... некоторые наши развёртывания управления аванпостами
00:31:34работают на Railway из-за их структуры ценообразования.
00:31:36Поскольку мы должны использовать ту же версию, что и open source, мы не строили
00:31:40мультитенантную архитектуру, это было бы неуместно для open source.
00:31:44Так что мы по сути делаем развёртывание для каждого отдельного клиента.
00:31:48Верно.
00:31:49И для пользователей бесплатного плана мы разворачиваем экземпляр на Railway,
00:31:52что, в общем-то, работает довольно неплохо.
00:31:54Но на днях их учётную запись GCP отключили, и они не работали около шести
00:31:59часов или типа того.
00:31:59Да.
00:31:59И тогда возникает вопрос: можно ли не говорить об этом в вашем...
00:32:06Есть одна вещь насчёт перекладывания вины.
00:32:09Вы определённо несёте ответственность за своих поставщиков.
00:32:11Но суть в том, что эту грань довольно трудно соблюдать.
00:32:14Я определённо вижу, что есть естественная склонность людей хотеть
00:32:18указывать пальцем, потому что это снимает с вас ответственность.
00:32:20Так что приходится бороться с этим.
00:32:23Верно.
00:32:24Но в тех случаях, когда вы уверены, что проблема в поставщике,
00:32:28интересно иметь возможность определить это,
00:32:31и иметь данные, что часто является проблемой при работе с поставщиками.
00:32:35Верно.
00:32:35Вы не видите их сторону данных.
00:32:37Поэтому очень трудно с какой-либо уверенностью или эмпирическими доказательствами сказать,
00:32:42что это явно они.
00:32:43Вам приходится выводить это из собственных данных, что может быть правильно или нет.
00:32:46Верно.
00:32:47Мне было интересно, когда происходит сбой у компаний вроде Shopify или Stripe,
00:32:51как события догоняют текущую очередь и не бьёт ли это сильно по вашим серверам?
00:32:57Да, по сути, вот что происходит.
00:33:00И я... потому что в тех сценариях, когда мы всегда говорим,
00:33:05что не стоит предполагать объём вебхуков.
00:33:09Мгм.
00:33:09У нас есть характеристика: каждый поставщик будет применять тайм-аут.
00:33:14Верно.
00:33:14Они дадут вам, скажем, три секунды,
00:33:15пять секунд — зависит от платформы — на ответ.
00:33:18Это значит, что вы не можете сделать много полезного,
00:33:21особенно если учесть задержки сети и всё такое в этой задержке.
00:33:25Верно.
00:33:25И поэтому, ну, это не единственная причина,
00:33:28но это одна из причин, почему обычно нужно ставить события в очередь.
00:33:31Нельзя обрабатывать их синхронно.
00:33:33Но я потерял мысль.
00:33:39Можете повторить ваш вопрос?
00:33:42Я говорил о сбоях в таких компаниях, как Stripe и Shopify.
00:33:45О, да.
00:33:45И о том, как они догоняют очередь.
00:33:47Да.
00:33:47Да.
00:33:47Да.
00:33:47В общем, всё это к тому, что задержки... это запутанный способ сказать, что вам нужно
00:33:52автомасштабироваться.
00:33:53Вам нужно уметь масштабироваться в довольно короткие сроки.
00:33:56И эти всплески возникают по разным причинам.
00:33:58Это может быть просто естественный массовый импорт, когда ваш клиент сделал его,
00:34:03или что-то в этом роде.
00:34:03Верно.
00:34:03Есть и другие причины для всплесков.
00:34:05Но простои — одна из них.
00:34:07Верно.
00:34:07Наступает момент, когда, если Shopify не работал полчаса, к моменту восстановления
00:34:11они просто будут пробиваться через бэклог, особенно стараясь снизить
00:34:16противодавление в своей очереди.
00:34:17То есть, по сути, они прорабатывают всё, что накопилось во время простоя.
00:34:22И, как правило, вы увидите, что они масштабируются даже больше своей обычной
00:34:26ёмкости, потому что пытаются догнать очередь.
00:34:28Верно.
00:34:28И это приводит к тому, что они просто отправляют кучу запросов конечным магазинам.
00:34:32И да, возникают такие нерегулярности, но некоторые из них
00:34:37вызваны не вами.
00:34:38Они на 100% вызваны поставщиком, потому что он сам проходит через собственные
00:34:42инфраструктурные проблемы и всё такое.
00:34:44И, очевидно, ёмкость Shopify по отправке вебхуков намного выше, чем ваша ёмкость
00:34:49по их приёму, по большей части.
00:34:52Да.
00:34:52Забавно, но один из наших инвесторов был CPO в Twilio.
00:34:56И я думаю, это одна из причин, почему он хотел инвестировать.
00:34:59Потому что одно из вещей, что он сказал, было то, что Twilio регулярно
00:35:04фактически DDoS-ит своих клиентов, если говорить прямо.
00:35:07Это отчасти неизбежно и является частью проблемы выполнения подобных
00:35:14событий, управляемых поставщиком.
00:35:17Так что это вполне известная проблема поставщиков.
00:35:21И они знают это, потому что это можно отследить по задержке ответа
00:35:24серверов, верно?
00:35:26Если вы DDoS-ите своего клиента, задержка ответа сервера возрастает.
00:35:29И в какой-то момент начинаются тайм-ауты.
00:35:31Эта проблема усугубляется, потому что сложнее поддерживать пропускную способность при долгих тайм-аутах.
00:35:34Чем дольше вы удерживаете HTTP-соединение, тем меньше запросов
00:35:38может обработать конкретный воркер на вашей стороне.
00:35:40Теперь вам нужно масштабироваться, и вы отправляете больше, потому что отмасштабировались, верно?
00:35:45Всё это просто накапливается, верно?
00:35:46Это имеет свойство самоподкрепляться, потому что, по сути, чем меньше ёмкости у вас для
00:35:52обработки этих вебхуков, тем быстрее деградирует задержка, верно?
00:35:57И по мере того, как вы достигаете насыщения сервера, задержка становится совсем плохой.
00:36:01А запросы всё копятся и копятся.
00:36:04И многие поставщики в какой-то момент просто отключают вашу конечную точку,
00:36:07потому что иначе она будет продолжать переполняться, верно?
00:36:10И они не хотят удерживать сотни тысяч HTTP-соединений,
00:36:14потому что ваш сервер медленно отвечает.
00:36:15Но как только они отключают её, вы теряете данные.
00:36:19В этом тоже подвох, верно?
00:36:21Так что обеспечение времени отклика при подобных вариациях, которые часто вне вашего
00:36:25контроля, — это большая часть проблемы.
00:36:29Я также хотел спросить: как ИИ меняет всё пространство вебхуков?
00:36:37Я знаю, что вы говорили, что LLM теперь отправляют больше вебхуков и, возможно, обрабатывают их.
00:36:43Но внутри, как вы используете ИИ для Hookdeck?
00:36:48И каким вы видите будущее ИИ в этой сфере?
00:36:51Да, на этом фронте много чего происходит.
00:36:54Как компания по разработке ПО, мы очевидно проходим через это.
00:36:57Мне кажется, вы, ребята, сталкиваетесь с теми же проблемами:
00:37:02рабочие процессы, меняющиеся каждую неделю, затраты на токены,
00:37:05насколько это разумная сумма расходов на токены, и всё такое.
00:37:10Да, нам не обязательно делать таблицу лидеров.
00:37:15Меня очень пугает идея с таблицей лидеров.
00:37:18Это верный способ уничтожить свою маржу.
00:37:24Так что, несколько мыслей.
00:37:25Во-первых, возвращаясь к сказанному ранее: есть рост и средства для событий,
00:37:29вызванные агентными сценариями использования, потому что агенты переходят от запуска
00:37:35людьми к событийно-ориентированным триггерам, и вы видите, как появляются все облачные агентные продукты.
00:37:41И многое из нашего тоже.
00:37:42В конечном итоге всё это запускается либо по расписанию, либо событиями.
00:37:46Некоторые из этих событий абстрагированы от вас, но всё же есть вещи вроде
00:37:49GitHub PR, или, скажем, коммиты или комментарии в GitHub — всё это управляется через веб.
00:37:56Но, очевидно, это выйдет далеко за рамки этого: поддержка клиентов,
00:38:00Slack, всякое такое, и, вероятно, даже работа в реальном времени, происходящая в физическом
00:38:04мире, например, на основе данных с датчиков, понимаете?
00:38:08Думаю, многим агентам также нужно будет вызывать события у других агентов, по сути,
00:38:12результатом работы агента будет событие, которое, возможно, запустит
00:38:17другого агента, в другой компании и так далее, что, да, можно описать
00:38:21как вариант использования вебхуков, в каком-то смысле это так и есть.
00:38:23Но мне кажется, что некоторые семантические аспекты вебхуков сейчас несовершенны,
00:38:28например, в плане безопасности, протоколов, эффективности и подобных вещей.
00:38:33И именно поэтому мы продвигаем целевые точки событий (event destinations) как более подходящий
00:38:36и оптимизированный паттерн для этого. Ещё один момент: если то, что вы запускаете
00:38:40в ответ на события — это агентские рабочие процессы, которые недетерминированы и могут выполняться долго,
00:38:47то становится намного сложнее управлять мощностями и масштабированием
00:38:51в ответ на поступающие события. Думаю, управление пропускной способностью и мощностями
00:38:55становится намного сложнее. Уровень ошибок будет выше из-за того, что,
00:39:00ну, облака превышают время ожидания, ваши тесты не проходят и всё в таком духе.
00:39:07Поэтому, с точки зрения создания приложений, основных примитивов, которые вы хотите использовать,
00:39:12того, где и как долго это работает, как вы справляетесь с обратным давлением и всем таким,
00:39:16здесь возникает много новых проблем. А что касается нас, внутри компании,
00:39:21мы всё ещё пытаемся найти правильный путь. Часть меня просто
00:39:25поражена производительностью. Я никого не удивлю, не думаю, что делюсь каким-то
00:39:29уникальным инсайтом. Но скажу одно: грань между тем, чтобы
00:39:34перейти от промпта в CLI или кодекса к выпуску высококачественного,
00:39:41эстетичного продукта — эта грань всё ещё теряется за всеми мемами и хайпом,
00:39:45где мне сомнительно, что можно потратить такой объём токенов и произвести что-то,
00:39:50что действительно добавит ценности миру. И, по крайней мере, в нашем опыте,
00:39:55очевидно, что вокруг безопасности есть огромные возможности, вроде проверки кода.
00:40:01Но я думаю, что когда дело доходит до...
00:40:06это лишь базовые вещи. Они не те, что по-настоящему
00:40:11добавляют ценности, понимаете? Когда дело доходит до создания чего-то по-настоящему
00:40:14ценного, из чего другие извлекают пользу, я чувствую, что здесь всё ещё есть разрыв. И я чувствую, что
00:40:19наша команда по-прежнему несёт ответственность за привнесение этого уровня вкуса, инсайтов, понимания клиентов,
00:40:25эмпатии и всего того, чего просто нельзя получить напрямую из чат-бота.
00:40:31Так что, возможно, мы сами глупим и могли бы двигаться намного быстрее,
00:40:35если бы мы просто всё делали с первой попытки. Но сейчас наш подход заключается в том, чтобы
00:40:42сохранять тот же уровень ожиданий в отношении чистого результата и того, что мы поставляем конечному пользователю.
00:40:47Да, очевидно, это значит, что мы можем делать больше. И также я думаю, что больше людей,
00:40:53обладающих вкусом и эмпатией, могут приносить пользу пользователю, потому что барьером был код,
00:40:57верно? И, например, почти все в компании теперь, условно говоря, пишут код,
00:41:01верно? Наш дизайнер — наш штатный разработчик. Теперь он полностью отвечает за
00:41:06веб-сайт, и есть куча работы с дашбордами, или продуктовый маркетолог,
00:41:11или кто-то из devrel — все они, знаете, не то чтобы максимизируют токены, но если бы была таблица лидеров,
00:41:16они, вероятно, были бы где-то в топе. И я думаю, это очень хорошо. Это расширяет возможности,
00:41:20потому что эти люди должны обладать критическим мышлением, о котором я говорил,
00:41:25чтобы выпускать эстетичные вещи для конечного пользователя, а барьер — это скорее сам код.
00:41:30И в каком-то смысле я думаю, что наибольшая выгода идёт отсюда, больше,
00:41:36чем от чистого инжиниринга. Опять же, не говорю, что чистый инжиниринг не получает огромную
00:41:40пользу, но думаю, что бутылочное горлышко всё ещё в этом вкусе. Плюс, я трачу
00:41:45так много времени на просмотр бессмысленных PR, так что в этом есть и обратная сторона.
00:41:51Точно. И количество кода, которое приходится проверять.
00:41:56Да, и вот эта неясная уязвимость, вероятность которой практически нулевая.
00:42:01Я даже не уверен, можно ли это назвать низким приоритетом. Но, очевидно, раз уж это всплыло,
00:42:06чувствуешь ответственность. И думаю, это нормально. Но,
00:42:09в какой-то момент это стало похоже на то, что у нас никогда не было столько открытых PR.
00:42:14И становится просто безумием пытаться охватить всё это. И я думаю,
00:42:18привнесение суждения о том, что раз ты можешь сделать всё,
00:42:21это не значит, что ты должен делать всё — это очень созвучно с этим отношением к LLM.
00:42:26И я думаю, что привнесение суждения о том, что в конечном итоге принесёт
00:42:31ценность или имеет потенциал её принести — сейчас важнее, чем когда-либо.
00:42:34Потому что есть своего рода удовлетворение от работы с агентами,
00:42:39как в списке дел. Знаете, иногда я просто отключаюсь. Типа,
00:42:44я просто хочу пройтись по списку и всё сделать, галочка, галочка, галочка.
00:42:48Верно. И в LLM есть что-то такое, типа, я начинаю этот
00:42:53диалог, этот диалог, этот диалог, и, может быть, пять-шесть агентов работают,
00:42:57делают вещи, и у них тоже есть списки задач, которые они отмечают.
00:43:02Да, да, да. Так что есть что-то в этом роде,
00:43:06удовлетворении и быстром вознаграждении, связанном с этим. И думаю, иногда
00:43:11это берет верх над нами. Точно. Или, по крайней мере, говорю за себя. Насколько большая ваша команда?
00:43:15Нас сейчас 10 человек. Ого, очень мало. Да, уважение. Это всегда было моей амбицией.
00:43:23Не считаю себя лучшим менеджером, так что, думаю, так будет лучше для всех.
00:43:29Нет, я отчасти шучу, но думаю, мы родились в разгар COVID,
00:43:33верно? Все на удалёнке. И с самого начала был такой настрой на
00:43:38найм опытных, чрезвычайно автономных людей.
00:43:45Чтобы вы понимали, мы проводим один созвон раз в две недели для обсуждения
00:43:50продукта и инфраструктуры. И мы старались придерживаться асинхронного
00:43:56рабочего процесса. Думаю, это хорошо подходит и для сценариев с ИИ. Мы
00:44:01уже нанимали людей, оптимизированных под эту автономию. Не думаю, что здесь есть
00:44:06правильный или неправильный путь, не буду проповедовать наш способ, но он работает для нас.
00:44:11Ничто так не работает для меня и моего здравомыслия. Так что вот.
00:44:14Я хотел коснуться того, что вы сказали в самом начале разговора: эээ,
00:44:21вебхуки мертвы, новый путь — это event gateway. Вы сами придумали этот термин или он уже был где-то
00:44:27в эфире? Что такое event gateway? Я этого совсем не понимаю.
00:44:32Да, мы его придумали, и было очень трудно построить продукт и категорию,
00:44:37которая ещё не установлена. Из-за проблем с маркетингом и
00:44:41коммуникацией, того, как вообще описать эту штуку. Долгое время мы говорили,
00:44:46называя это инфраструктурой управления вебхуками и всякое такое.
00:44:51Ничего, что легко произносится. Так что у вас есть вызов в коммуникации,
00:44:54но также вызов в самом продукте. Потому что когда вы строите продукт в существующей
00:44:58категории, скажем, мониторинга стека, вы знаете, что оптимизируете,
00:45:02свои специфические USP, которые, в вашем случае, я думаю, во многом связаны с ценой
00:45:07и DX. Но дело в том, что базовая семантика уже существует. И то, что вы
00:45:10оптимизируете — это ваше уникальное ценностное предложение. Когда вы строите что-то, чего
00:45:14на самом деле ещё не существует, вам нужно изобрести семантику, а затем построить
00:45:19убедительное ценностное предложение поверх этой семантики. Это становится очень сложно.
00:45:24И это один из уроков за последние пару лет — очень трудно строить продукт в
00:45:28несуществующей категории. Так что идея event gateway пришла оттуда,
00:45:32пытаясь поймать как можно лучше, парой слов, которые, надеюсь, легко
00:45:37произносятся, то, что это делает. Наша цель была — создать мост между шиной событий
00:45:43и API-шлюзами. И захватить это понятие, что шлюзы существуют для того,
00:45:49как интерфейс между поставщиком и вашей собственной системой. А шина событий
00:45:55в смысле полномасштабного управления событиями и очередями и так далее.
00:46:00Так что мы пытались найти термин, который бы сочетал эти две вещи. И на самом деле, когда
00:46:04вы думаете об event bridge, это недалеко от event gateway. И мы хотим,
00:46:10чтобы люди воспринимали нас как конкурентов event bridge, например, мы видим
00:46:14себя как чёткую альтернативу. Думаю, идея event gateway также была в том,
00:46:19чтобы сказать: смотрите, существующие продукты есть, общепринятой терминологии
00:46:24вокруг них нет. Они не называют это в открытую event gateway, а мы дадим
00:46:29эту метку. И уже есть пара конкурирующих продуктов в этой категории,
00:46:33один наш, но есть ещё AWS, Azure, Kong теперь тоже event
00:46:39gateway. Есть Gravity, куча API-шлюзов начинают переходить в
00:46:45event-driven архитектуру. Сейчас, вероятно, есть с полдюжины продуктов,
00:46:49которые называют себя event gateway, и я не знаю, причастны ли мы к этому,
00:46:54но когда Kong выпустили свой event gateway, я подумал: о, чёрт,
00:46:58спустя два года после нас. Но что по-настоящему приятно,
00:47:03это когда клиенты приходят к тебе, разработчики приходят и говорят: я
00:47:08ищу event gateway. И это значит, что у людей появляется ментальная
00:47:12модель этого или они начинают это осознанно искать, или говорят:
00:47:16мы пытаемся заменить свой собственный event gateway. Такое всплывало в
00:47:20разговорах. Но скажу, что в первый год этого точно не было.
00:47:23А теперь, со временем, этот термин используют всё больше. И я думаю, это хорошо.
00:47:28Хорошо для нашего бизнеса, но и в плане создания ожиданий: вот этот облачный
00:47:34инфраструктурный примитив, который существует.
00:47:38И базовый набор ожиданий, который у вас может быть вокруг него.
00:47:43И надеюсь, когда-нибудь вещи начнут выравниваться в семантике.
00:47:48Если вы используете AWS EventBridge, терминологии у нас мало общего.
00:47:52Я не хочу проектировать продукт вокруг AWS EventBridge из-за всех продуктов, что у них есть.
00:47:57Поэтому я не буду использовать их терминологию, если не считаю, что это имеет твёрдый смысл.
00:48:01Но думаю, со временем, когда люди будут строить вокруг этого...
00:48:05произойдёт некая конвергенция.
00:48:09Да.
00:48:12Если я спрошу LLM про event gateway, порекомендует ли она вас?
00:48:15О да, попробуйте сейчас. Думаю, шансы велики.
00:48:15Могу попробовать вживую.
00:48:20Мы это отслеживаем.
00:48:24Да.
00:48:25Мы цитируемся примерно в 60% каждого запроса,
00:48:27связанного с вебхуками или event gateway.
00:48:27Круто. Мы потратили на это много времени.
00:48:31И судя по нашим данным, мы справляемся неплохо.
00:48:35Это был первый вариант в списке.
00:48:42О, здорово.
00:48:46Вот и всё.
00:48:48ChatGPT только что выдал. Молодцы.
00:48:49Да.
00:48:49Хотя думаю, по event gateway мы работаем так же хорошо,
00:48:52как и по запросам, связанным с вебхуками.
00:48:56Но event gateway однозначно играет нам на руку,
00:49:00мы же придумали термин.
00:49:03Я бы разозлился, если бы мы не были первыми.
00:49:05Я осознал, что не знаю, что значит event-driven архитектура. Как она отличается
00:49:11от обычной? Если я воткну Kafka-очередь в свою систему,
00:49:17я автоматически стану event-driven архитектурой?
00:49:21И да, и нет. Думаю, event-driven архитектура — это скорее
00:49:25парадигма и набор ожиданий. Часть этого — инструменты, верно? Вы используете
00:49:31Kafka или очереди сообщений, чтобы развязать системы. В итоге,
00:49:35идея в том, что есть производители и потребители, которые не знают
00:49:39друг о друге. Потребитель может брать события из потока,
00:49:43которые может генерировать кто угодно. Единственное реальное ожидание — это
00:49:47контракт самого события. Каков его формат?
00:49:53Часто используются схемы, вроде Avro или Protobuf,
00:49:57где есть стандартизированные ожидания насчёт полезной нагрузки.
00:50:02Контракт заключается в том, что событие существует.
00:50:06Как потребитель, я должен обработать создание заказа или обновление продукта.
00:50:11Организация, которая приняла EDA, будет иметь систематизированные паттерны,
00:50:16конкретные рекомендации по форматам данных.
00:50:21Это архитектурный подход: преднамеренное разделение сервисов
00:50:25и превращение коммуникации в event-driven.
00:50:29Многие компании используют гибридный подход.
00:50:32Цель — 100% event-driven?
00:50:36Или это просто часть архитектурной парадигмы?
00:50:41Не думаю, что 100%. Но со временем, по мере роста сложности и
00:50:45увеличения зависимостей, это естественный путь развития.
00:50:50Потому что в какой-то момент крайне сложно поддерживать связь всех систем.
00:50:54Тогда приходится думать о масштабировании и взаимозависимостях.
00:51:00В целом, говоря об event-driven архитектуре, люди представляют что-то огромное,
00:51:04корпоративное. Первое десятилетие это так и было.
00:51:09Теперь всё меняется, люди осваиваются с паттернами.
00:51:14Инструменты становятся лучше. Есть RabbitMQ, BullMQ,
00:51:19Celery в Python, Sidekick в Ruby.
00:51:23Прогрессивные инструменты делают это менее устрашающим.
00:51:28Вам не нужно больше огромной команды и Kafka-деплоев.
00:51:32Но термин немного потерял смысл, размылся.
00:51:37Когда я использую этот термин, я имею в виду разделение систем.
00:51:41Программные заботы об очередности и зависимостях.
00:51:46Вы входите в мир, где у вас появляются новые проблемы.
00:51:51Надо адаптировать то, как вы строите приложение.
00:51:57Мы пытаемся сделать это доступным для всех.
00:52:01Есть и другие игроки, workflow-движки.
00:52:05Temporal, Ingest, Trigger.dev.
00:52:11Пространство очень живое, чётких определений нет.
00:52:15Кому интересно, есть Дэвид Бойан.
00:52:19Бывший адвокат разработчиков из AWS, работал над EventBridge.
00:52:25У него отличные серии объясняющих рисунков.
00:52:31Это база для тех, кто хочет глубже разобраться.
00:52:37Он проделал большую работу в этой области.
00:52:43Настоятельно рекомендую посмотреть его материалы.
00:52:48Для старта в event-driven архитектуре это лучший ресурс.
00:52:52Там всё разложено по полочкам с простых примеров.
00:52:58Идеально для входа в тему без лишнего шума.
00:53:03в каком-то крупном корпоративном ключе. И мне кажется, в некотором смысле мы просто пытаемся, ну,
00:53:08донести это до каждого. Верно. И мы не единственные, кто этим занимается.
00:53:14Есть и другие игроки, использующие иные подходы.
00:53:18Существуют различные движки рабочих процессов и функции шагов, которые, как мне кажется, пересекаются,
00:53:22как Temporal, Ingest, trigger.dev и им подобные. Так что я действительно думаю, что это
00:53:28сфера, где многое происходит. И, возможно, не существует какого-то единого четкого определения
00:53:34для этого. Для тех, кому действительно интересно узнать побольше
00:53:38об архитектуре, управляемой событиями, о парадигмах, связанных с этим, и так далее. Есть такой парень,
00:53:42Дэвид Боян, который раньше был евангелистом разработчиков в AWS и занимался EventBridge.
00:53:49Это те серии графических объяснений. Но на данный момент у него, наверное, уже
00:53:55несколько сотен таких работ, он также ведет проект с открытым исходным кодом под названием Event Catalog — возможно, это был бы хороший гость для подкаста.
00:54:02Но всё это к тому, что глубина проработки здесь просто невероятная.
00:54:07Верно. Так что я определенно рекомендую их тем, кому любопытно.
00:54:14Круто. Добавим это в описание выпуска. Да, все ваши знания о событиях, веб-хуках
00:54:19и всем остальном. Похоже, их у вас очень много, все они пришли из создания Hookdeck?
00:54:23Или же, ну, вы говорили раньше, что у вас были проблемы с веб-хуками, но именно тогда вы
00:54:27действительно глубоко погрузились в события? О да, и я думаю, что это обучение шло в основном
00:54:34от самих проблем, но также и от первооснов, в том смысле, что когда я сталкивался с теми
00:54:38проблемами, у меня на самом деле не было глубоких знаний, что отчасти и было причиной, по которой я с ними столкнулся.
00:54:42Да. Поэтому я думаю, что это пришло из попыток разобраться в самой проблеме
00:54:47и найти пути их решения, а не искать готовые решения и
00:54:51притягивать их за уши к проблеме. Верно. Но в конечном итоге, к настоящему моменту,
00:54:55мы поработали с сотнями тысяч пользователей, с самыми разными людьми.
00:54:59И думаю, я просто впитал всё это из этих бесед. И да, это было
00:55:05довольно интересно. Изначально я начинал как продуктовый дизайнер. Так что,
00:55:11продуктовый дизайнер, фулстек-разработчик, затем бэкенд-инженер,
00:55:15затем инфраструктурный инженер. И теперь я очень, очень глубоко погружен в эту
00:55:21кроличью нору. Но это произошло благодаря работе с клиентами, прислушиванию к их
00:55:26проблемам, анализу архитектуры и всему такому. Но также и благодаря команде,
00:55:30верно? У нас в команде есть люди, у которых огромный опыт работы с
00:55:33такими системами, и они также привнесли эти знания в компанию. Да. Когда вы
00:55:38поняли, что нашли рынок для этого? Я полагаю, вы начали работать над этим, а потом
00:55:42где-то это выложили. Была ли реакция хорошей почти сразу? Или это был довольно долгий
00:55:47путь к тому, чтобы люди поняли, что это лучший вариант? Медленный путь — это еще мягко сказано,
00:55:53в том смысле, что все началось с той статьи на Medium, о которой я упоминал, верно? Типа, вот веб-хуки,
00:55:57и вот что с ними можно сделать. Я придерживаюсь мышления: делайте продукт для людей.
00:56:01Первая версия была чем-то вроде самообслуживания, вы могли зайти и создать, например, свое первое
00:56:07соединение, как мы это называли, и всё такое.
00:56:12И я опубликовал эту статью. У меня не было амбиций построить из этого бизнес или что-то
00:56:16такое. Это был просто один из 20 других моих провальных побочных проектов, над которыми я тогда работал.
00:56:21И, если оглянуться назад, сейчас цифры кажутся просто смехотворно маленькими,
00:56:26потому что из той статьи пришли, может быть, человек пять.
00:56:32Но я знаю, что для всех, кто занимался побочными проектами
00:56:37и прошел через все этапы попыток заставить кого-то использовать то, что вы создали,
00:56:42пять — это чертовски круто. Это больше, чем когда-либо у меня было раньше.
00:56:48Так что я был этому очень рад. Я тогда был в своем фургоне в Британской Колумбии, занимался скалолазанием.
00:56:55Я был очень далек от попыток построить стартап или что-то подобное. Просто общался с теми людьми,
00:57:00разбирал их проблемы, то, что они думали, и все такое.
00:57:05А потом клиенты начали потихоньку появляться, может, по одному в неделю, и я, будучи на скалах,
00:57:08открывал Slack, и там было уведомление. У нас есть этот канал для уведомлений
00:57:13о новых регистрациях, верно? Такой же, какой у нас был последние шесть лет.
00:57:18канал уведомлений о каждой регистрации, да? Тот же самый, что у нас был лет шесть или около того.
00:57:21К этому моменту за ними уже довольно сложно следить, потому что они просто...
00:57:25быстро прокручиваются. Но у меня было это уведомление в канале. Я думал:
00:57:31«О черт, кто-то зарегистрировался». Вы что, устраиваете DDOS-атаку на Slack?
00:57:38Нет, тогда точно нет. Но вы сказали, что он у вас есть и сейчас. Вот почему я спрашиваю.
00:57:44Да, да, да. Ну, в смысле, дела идут хорошо, но не думаю, что до уровня DDOS-атаки на Slack.
00:57:48Ладно. В общем, извините за отступление, но я думаю, что одна ключевая ошибка в начале была в том,
00:57:54что мы считали, будто это инструмент для наблюдаемости. Я думаю, этого было недостаточно.
00:57:58Но как только вы переходите от идеи «я создаю инструмент для наблюдаемости» к «я переизобретаю шину сообщений»...
00:58:02внезапно масштаб проекта драматически расширяется. Так что я фактически встретил своего технического директора и сооснователя
00:58:08как раз в процессе создания первого движка очередей. И когда я осознал,
00:58:15что масштаб проекта станет колоссальным, тогда-то мы и решили...
00:58:19привлечь небольшие ангельские инвестиции на стадии pre-seed.
00:58:23Было довольно очевидно, что разработка будет стоить дорого, так оно и вышло.
00:58:28И, как я понимаю, вы не пошли по типичному пути Сан-Франциско. Вы создали компанию в Монреале, верно?
00:58:32Э-э, да, это немного не совсем то, как всё было на самом деле.
00:58:36Мы привлекли около 400 000 долларов только от бизнес-ангелов,
00:58:39никаких институциональных венчурных фондов. Но через несколько месяцев мы опубликовали пост на Hacker News,
00:58:44и тогда, возвращаясь к вашему вопросу, Джеймс... Думаю, реакция на Hacker News,
00:58:51не была самым большим успехом на HN, но она была гораздо лучше, чем мы ожидали.
00:58:56Забавный случай: помню, был один парень, который купил план за 300 долларов,
00:59:00сразу после публикации. И я помню, как мы с сооснователем сказали: «Чувак, мы прорвались».
00:59:05Типа, это дело в шляпе. Мы точно добьемся успеха.
00:59:11Пошли вечером на ужин и потратили всё. Типа того.
00:59:18Да, именно так. Бутылка шампанского и всё такое.
00:59:22Но в любом случае, после той публикации на HN
00:59:25у нас появилось много интереса со стороны инвесторов, которые выходили на связь проактивно.
00:59:31И в итоге мы закрыли раунд с инвесторами из Кремниевой долины, фирмой под названием Matrix Partners.
00:59:34Так что мы всё ещё базируемся в Канаде. Мы не переоформлялись в Delaware LLC,
00:59:38но наши инвесторы были просто потрясающими, и я очень рад, что мы всё сделали именно так.
00:59:44Думаю, из-за пандемии появилось больше принятия того, что компании не обязательно
00:59:50быть из Долины, можно строить удаленные команды. Куча людей этим занималась.
00:59:55Мы ничего не изобрели, есть Zapier, GitLab и все остальные ребята, которые делают это дольше всех.
01:00:00Так что это просто стало нормой. И это то, что я видел у других основателей.
01:00:04Может, я просто наивен, но среди канадских основателей в Твиттере была эта тема
01:00:08насчет регистрации компании в Делавэре, а YC перестали принимать канадские компании,
01:00:12GitLab и все остальные ребята, которые занимаются этим гораздо дольше, чем кто-либо другой.
01:00:17стать Delaware LLC. И они правы: каждый инвестор будет об этом просить.
01:00:21Но в этой истории упускается то, что вы можете просто сказать «нет».
01:00:27Конечно, они спросят: «Почему нет?». Им так проще, но оказывается,
01:00:32если просто отказаться, это тоже абсолютно нормально. По крайней мере, в моем опыте
01:00:38и опыте людей, которые меня окружают. Думаю, это недостающая часть истории.
01:00:42В конце концов, их работа — вкладывать капитал. Они ищут людей для инвестиций и оригинальные идеи.
01:00:47Я не хочу спорить о плюсах и минусах жизни в Долине. Уверен, в этом есть много позитива,
01:00:54Да, безусловно. Они спросят: «Почему нет?», ведь так им проще,
01:00:58Думаю, если у вас есть хорошие идеи и вы вкладываете в них труд, инвесторы будут это уважать.
01:01:03По крайней мере, некоторые инвесторы. Возможно, ваша работа — найти их.
01:01:07Так что, наверное, было бы нечестно говорить, что мы полностью вне этого «пузыря»,
01:01:11но я лично очень рад, что остался в Монреале.
01:01:15Как соотечественнику-канадцу, приятно слышать истории канадского успеха.
01:01:19Так что хвала вам за это, но потом вы переехали в Торонто и...
01:01:24как основателю и разработчику, с кем и где это делать.
01:01:27И я думаю, если у вас есть хорошие идеи и вы вкладываете в них труд, инвесторы будут
01:01:31уважать это, или, по крайней мере, некоторые инвесторы это оценят. Верно. И, возможно, ваша
01:01:36задача — найти их, но да. Думаю, было бы нечестно говорить, что мы полностью
01:01:41вне этого пузыря, но, лично я, знаете, устроил свою жизнь здесь, и
01:01:47я лично очень рад, что до сих пор в Монреале. Что ж, как коллеге-канадцу, приятно
01:01:52слышать об историях успеха канадцев. Так что честь вам и хвала, но потом вы переехали в Торонто и
01:01:57просто всё испортили. Справедливо, справедливо. Могу ли я сказать как представитель Содружества, что это здорово, верно? Один
01:02:06король. Это же одно и то же, верно? Да. Да. У нас есть королева. В смысле,
01:02:11не знаю, обновили ли они всё до короля сейчас, но у нас на купюрах была королева.
01:02:14Да. Был ли Hookdeck вашим первым стартапом в качестве основателя, или были другие на этом пути, которые дали вам
01:02:19некие инструменты, чтобы понять, как связываться с инвесторами и находить их? Я всегда
01:02:23был очень предприимчивым с самого начала, в маленьких компаниях, вроде
01:02:27ремонта компьютеров в 14 или 15 лет и всё такое. Верно. Так что, думаю, в этом
01:02:34смысле, если говорить о предпринимательском духе, то да, но нет, я думаю,
01:02:38большинство из них были провальными сторонними проектами, вроде выпуска видеоигры, которая по сути никуда
01:02:44не продвинулась. Знаете, куча других, в какой-то момент я работал над некоей социальной
01:02:48сетью, несмотря на то, что я, наверное, хуже всех справляюсь с посиделками и
01:02:53организацией встреч с друзьями. В любом случае, прошёл через все круги ада. Скажу, однако,
01:02:58этот опыт в компании C-commerce был весьма полезным в том смысле, что
01:03:03я пришёл туда первым сотрудником, и был очень вовлечён в работу с командой основателей.
01:03:07И мы выросли, по сути, с четырёх человек до сорока или около того
01:03:13за три года. И, знаете, все процессы создания бизнеса и всё такое,
01:03:19всё это было там. Так что, думаю, я считаю Hookdeck первым, но
01:03:23было бы нечестно полностью позиционировать его так. Думаю, у меня был некий опыт
01:03:27до этого. И, конечно, у меня была эта компания электронной коммерции. Мы работали
01:03:31с инвесторами, с советом директоров и так далее, выстраивали там отношения.
01:03:36И наш первый инвестор в той компании электронной коммерции был также нашим первым инвестором в Hookdeck.
01:03:39Так что это не было начинанием с нуля, как у многих людей, но да,
01:03:44я всё же не ожидал оказаться здесь пару лет назад. И это здорово.
01:03:48Я видел компанию под названием Kiwi Mornings, стартап по продаже здоровых завтраков. Что это было?
01:03:54А, домашнее задание. Что ж, это был один из тех провальных бизнесов на моём пути.
01:04:02Я основал его вместе с женой. История в том, что моя жена приносила
01:04:09свой завтрак на работу, и все ребята из отдела продаж завидовали ей
01:04:14и начали просить её сделать завтрак и для них. Я такой: “Что значит твой завтрак для ребят из продаж”?
01:04:19Что не так? Но одно привело к другому, и она делала завтраки для пяти
01:04:24или шести человек каждое утро для отдела продаж. И они такие: “А почему бы нам не...
01:04:30знаете, одна из тех глупых идей, почему бы нам не сделать из этого бизнес?” И мы
01:04:36создали этот сервис по доставке завтраков без отходов прямо на рабочие места. Мы доставляли,
01:04:41йогурты, смузи, пудинги из семян чиа и всё такое в маленьких стеклянных баночках.
01:04:47У нас были маленькие холодильники в офисах. И я, будучи собой, зашёл слишком далеко.
01:04:51Со стороны продукта и инженерии всё было автоматизировано — все заказы шли через
01:04:56Slack-бота, и работодатели могли сделать это корпоративной льготой, оплачивая, по сути,
01:05:0150% стоимости завтрака. И была вся эта история.
01:05:06И люди заказывали завтраки через Slack-бота. Но в конце концов,
01:05:11всё закончилось. Просто в этом бизнесе всё идёт не так в четыре часа утра,
01:05:16плюс в продуктовом бизнесе почти нет прибыли. Когда совмещаешь эти вещи, очень трудно
01:05:20построить устойчивый бизнес. В какой-то момент мы продали Slack-бота
01:05:25и прекратили этим заниматься. Но, к счастью,
01:05:29это было в январе 2021 года, за два месяца до COVID. А потом практически
01:05:34все аналогичные компании, занимавшиеся обедами в офисах, просто закрылись.
01:05:42Так что нам немного повезло с таймингом, потому что это всё равно бы закрылось. Верно. Но
01:05:46в целом, думаю, мы продали около 20 000 завтраков.
01:05:52О, довольно круто. Да, довольно круто.
01:05:57Да. Мы всегда спрашиваем наших гостей: каковы ваши смелые прогнозы
01:06:01насчёт индустрии, ИИ, чего угодно. Давай.
01:06:06Думаю, я уже озвучил несколько в этом разговоре.
01:06:12Думаю, да. Какой самый смелый? Прямо горячий?
01:06:18Горячее некуда. Хорошо. Наверное, здесь я вас потеряю, потому что это очень глубокая тема
01:06:22архитектуры и систем очередей. Уверен, наши слушатели поймут, о чём я.
01:06:29Отлично. Так вот, мой смелый прогноз в том, что системы очередей с опросом (pull-based)
01:06:35просто глупы по сравнению с push-системами. А причина, почему мы их не приняли,
01:06:42в том, что никто не построил хорошую push-систему. И сейчас я попытаюсь дать немного контекста.
01:06:49Когда вы строите очереди и потребителей для каждой очереди, вам нужно иметь для неё свой обработчик.
01:06:56Этот обработчик может быть неким долгоживущим воркером. Но проблема в том, что
01:07:02если вы хотите динамически создавать очереди — скажем, вы хотите очередь на каждого
01:07:07клиента, потому что не хотите, чтобы один клиент забил всю очередь или занял всю ёмкость,
01:07:12то теперь вам нужно иметь столько же потребителей, сколько очередей.
01:07:16Это безумие, потому что возникает проблема мультиплексирования. Большое преимущество push-систем в том,
01:07:21что все эти очереди могут отправлять данные одному и тому же потребителю.
01:07:26И этот потребитель может быть API с балансировщиком нагрузки, который можно масштабировать
01:07:31горизонтально или вертикально. Суть в том, что это полностью развязано с количеством очередей.
01:07:36И я думаю, что мы наблюдаем, как по мере усложнения кейсов вы приходите к всё более
01:07:41гранулярным способам постановки задач в очередь. Вы хотите очереди по топикам, по условиям,
01:07:45по клиентам и так далее. И это превращается в полный хаос: 100 очередей, 100 потребителей,
01:07:49100 очередей для неудачных попыток и всё сопутствующее безумие.
01:07:54Сегодня очень трудно найти push-очереди сообщений.
01:07:58Причина в том, что смещается контроль пропускной способности. Если она контролируется в потребителе,
01:08:02то каждый потребитель сам отвечает за то, сколько запросов он хочет обрабатывать.
01:08:07И количество потребляемых сообщений зависит от мощности воркера и количества воркеров.
01:08:13Это не значит, что если вы хотите 50 сообщений в секунду, вы их получите, потому что всё зависит
01:08:17от остального кода и его быстродействия. Верно. Думаю, причина, почему мы не перешли на push-очереди,
01:08:22в том, что большинство из них не дают нужной гранулярности контроля.
01:08:29Например, GCP Pub/Sub имеет push-режим, но в нём они просто наращивают скорость,
01:08:33с которой присылают запросы, пока ваше API не начнёт тормозить.
01:08:37А когда оно начинает тормозить, они снижают скорость доставки.
01:08:40В итоге получается график: рост, сервер падает, скорость падает до нуля, потом снова рост.
01:08:45Это просто бессмысленно. Верно. И я думаю, если вы строите push-систему,
01:08:50где есть точный контроль пропускной способности, это упрощает архитектуру.
01:08:55Это мой смелый прогноз, за который я готов стоять до конца.
01:09:00Я не всё понял, но звучит разумно, понимаете?
01:09:06Думаю, если вы это поняли, зацените Hookdeck. Да, точно.
01:09:11Спасибо за это. Что ж, спасибо тебе, Алекс. Спасибо, что слушали этот эпизод
01:09:15подкаста Better Stack. Ищите нас там, где слушаете подкасты: Spotify, Apple Music или где угодно ещё.
01:09:20Но сегодня время прощаться от меня. До свидания от меня. И до свидания от меня.
01:09:24контроль над пропускной способностью и точным поведением скорости потребления, это значительно упрощает вашу
01:09:29архитектуру. В общем, это всё, что я могу сказать тем, кто в теме, но я готов
01:09:34стоять на своём. То есть, я не всё понял, но это прозвучало разумно, понимаешь?
01:09:40Думаю, если вам интересно разобраться, загляните на Hookdeck. Да, именно так.
01:09:46Ценим это, да. Что ж, спасибо, Алекс. Спасибо, что слушали этот эпизод
01:09:50подкаста Better Stack. Ищите нас там, где слушаете подкасты: в Spotify, Apple Music или где угодно ещё.
01:09:57А на сегодня всё. Прощаюсь с вами я. И я. И я тоже прощаюсь.