Arsitektur Berbasis Peristiwa, Kekacauan Webhook, dan Kebangkitan Agen AI | Better Stack Podcast Ep. 17

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

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

스크립트

00:00:00Selamat datang di podcast Better Stack, tempat kami berbincang tentang pengembangan perangkat lunak,

00:00:04AI, dan segala jenis teknologi baru. Saya salah satu pemandu acara Anda, Andrus, dan hari ini saya ditemani oleh

00:00:10James dan Alex. Hei, Alex, selamat datang di acara ini. Terima kasih telah mengundang saya, teman-teman. Jadi, mari kita mulai

00:00:16dengan perusahaan yang Anda jalankan. Namanya Hookdeck. Jadi, bagi mereka yang belum tahu,

00:00:22apa itu Hookdeck? Apa fungsinya? Beritahu kami lebih banyak tentang itu. Ya, saya suka menganggapnya sebagai

00:00:27perusahaan webhook yang mencoba untuk mematikan Webhook. Itu mungkin cerita yang bisa kita bahas.

00:00:32Tapi kami membangun dua produk utama. Salah satunya adalah Event Gateway. Jadi, Event Gateway berfungsi sebagai

00:00:37semacam bus acara khusus untuk semua acara yang datang dari luar infrastruktur Anda.

00:00:41Webhook adalah tersangka utamanya, tetapi kami melihat banyak kasus penggunaan IoT dan berbasis SDK dan sebagainya.

00:00:47Jadi pada dasarnya, kami menyediakan semacam titik akhir yang tidak tepercaya. Anda bisa mengirim acara apa pun ke sana.

00:00:51Dan kemudian semua kemampuan untuk mengelola acara tersebut. Jadi itu mulai dari penyaringan,

00:00:55transformasi, perutean, antrean, peringatan, dan manajemen masalah, pemutaran ulang adalah bagian dari semuanya.

00:01:01Jadi sungguh, ini mencakup interoperabilitas dalam arti bahwa saya perlu menerima

00:01:05acara dan webhook dari semua vendor yang bekerja sama dengan saya, bukan? Itu bisa jadi Stripe, Shopify, Twilio,

00:01:10WhatsApp, TikTok, apa pun, sebut saja. Mereka masing-masing memiliki kriteria dan keanehan mereka sendiri

00:01:16serta persyaratan khusus yang mereka miliki. Dan jadi kami bisa menstandarisasi semua itu dan membawanya

00:01:20ke dalam satu kontrak. Dan kemudian semuanya dari sudut pandang pengantrean. Dan jadi misalnya,

00:01:27seperti Shopify, ada obral kilat di toko Anda dan Anda mendapatkan lonjakan acara yang luar biasa.

00:01:31Anda menormalkannya sehingga Anda bisa mengontrol throughput dan gateway acara

00:01:38dan semua itu. Jadi itu bagian besarnya. Ini semacam sisi konsumen. Dan di situlah

00:01:42cerita Hookdeck dimulai. Dan baru-baru ini, kami juga merilis Outpost. Outpost sepenuhnya

00:01:49bersumber terbuka, proyek Apache 2.0. Dan kami sekarang memiliki layanan terkelola untuknya juga. Dan itu untuk mengirim

00:01:55acara. Dan jadi ini seperti sisi lain dari persamaannya, bukan? Ini adalah Anda sebagai penerbit, sebagai

00:01:59platform, alat pengembang. Kami benar-benar di titik ini, di mana semua orang juga mengirim acara. Saya terkejut

00:02:05setiap hari. Dan jadi Outpost adalah layanan terkelola atau layanan yang di-host sendiri yang bisa Anda gunakan untuk

00:02:12menyatakan siapa penyewa Anda, apa tujuan, titik akhir yang telah mereka daftarkan, mengonfigurasi

00:02:17topik, dan menerbitkan acara kepada mereka. Dan menangani segalanya mulai dari visibilitas, metrik, jaminan pengiriman,

00:02:23coba lagi, dan semua hal yang biasa dilakukan seputar tanda tangan, rotasi tanda tangan,

00:02:28dan semua itu. Lelucon kecil yang saya buat tentang mencoba mematikan Webhook adalah bahwa Outpost,

00:02:35ya, memungkinkan Anda mengirim Webhook, tetapi juga memungkinkan Anda menerbitkan acara langsung ke bus pesan pengguna Anda.

00:02:39Dan jadi Outpost secara asli mendukung apa yang sekarang dikenal sebagai tujuan acara. Dan jadi Webhook

00:02:46dianggap sebagai perute transportasi. Dan jadi Anda pada dasarnya mengirim acara melalui Webhook dan

00:02:53Webhook adalah mekanisme transportasi standar, bukan? Dan Anda dapat memilih protokol transportasi baru, seperti MQ

00:02:59untuk RabbitMQ atau Kafka. Dan kami mendukung penerbitan langsung juga ke semua yang biasa seperti Pub/Sub,

00:03:05SQS, AWS EventBridge, dan tentu saja Event Gateway Hookdeck, bukan? Jadi saya suka menganggapnya sebagai

00:03:12tujuan yang lebih baik, tapi kita lihat apakah orang percaya itu. Jadi Anda bilang Anda ingin mematikan Webhook. Jadi saya

00:03:18bayangkan ide ini dan permulaannya muncul dari fakta bahwa Anda semua lelah dengan Webhook atau itu

00:03:25terlalu sulit untuk dikelola. Ceritakan tentang bagaimana Anda mendapatkan ide tersebut. Ya, saya baru saja menceritakan

00:03:31ceritanya kepada seseorang tempo hari. Sekitar lima tahun yang lalu, saya menerbitkan artikel ini di Medium.

00:03:37Saya mungkin mendekati enam tahun sekarang. Dan artikel tersebut diberi judul, yang sangat berkaitan dengan apa yang Anda

00:03:42katakan, “Webhook menyebalkan, tapi ada sesuatu yang bisa Anda lakukan tentang itu.” Dan itu hanyalah saya di

00:03:48ruang bawah tanah saya, Anda tahu, bermain-main dan membangun semacam prototipe V1 dari Hookdeck.

00:03:54Tetapi itu sangat berasal dari rasa frustrasi itu. Saya pribadi bekerja di eCommerce dan kami membangun

00:03:59banyak perangkat lunak khusus untuk menjalankan eCommerce mulai dari manajemen langganan khusus hingga

00:04:05pergudangan dan pemenuhan dan semua hal semacam itu. Dan hanya banyak masalah Anda

00:04:10bermuara pada Webhook. Dan itu hampir seperti lelucon yang berulang karena di satu sisi,

00:04:15saya mencoba menjual bisnis mode wanita, bukan? Saya mencoba menjual

00:04:18pakaian dalam dan nilon dan sebagainya. Dan kemudian di sisi lain, seperti, di mana Webhook sialan itu?

00:04:23Apa yang terjadi padanya? Itu hanya terasa sangat tidak cocok dalam hal kekhawatiran.

00:04:28Dan jadi itu sangat berasal dari situ, hanya seperti saya frustrasi sebagai konsumen Webhook tersebut

00:04:33bahwa tidak ada cara yang benar-benar lengkap untuk menangani masalah ini.

00:04:38Dan jika Anda mencari rekomendasi secara online, seperti ada,

00:04:43maksud saya, Webhook bukanlah hal baru. Pada akhirnya, itu adalah permintaan HTTP. Ada

00:04:46pola yang jelas ditetapkan seputar bagaimana Anda seharusnya menangani ini. Tapi kemudian Anda

00:04:50dengan sangat cepat masuk ke lubang kelinci. Oke. Oke. Anda memerlukan konsumen konsumsi yang dapat

00:04:55menskala otomatis dan kemudian Anda perlu mengantre ke dalam antrean seperti SQS. Dan kemudian Anda perlu menyebarkan serangkaian

00:05:00konsumen yang akan mengonsumsi dari SQS. Dan kemudian jika terjadi kesalahan, itu akan berakhir

00:05:05di antrean data. Dan kemudian Anda memerlukan skrip untuk dapat pulih dari antrean data dan

00:05:09memahami mengapa hal-hal berakhir di sana sejak awal. Dan hanya ada semua kekhawatiran itu.

00:05:14Dan seiring bertambahnya kompleksitas, Anda juga ingin dapat memutar ulang acara historis yang telah Anda

00:05:18terima. Anda ingin dapat melihat secara khusus apa muatan Webhook tersebut.

00:05:22Dan kemudian Anda mulai berurusan dengan vendor yang berbeda karena mungkin Stripe akan memberi

00:05:26Anda UI dan kemudian Intercom tidak akan memberi Anda UI. Dan kemudian Anda memiliki semua

00:05:31keanehan yang berbeda yang harus Anda tangani. Dan jadi itu sangat berasal dari frustrasi itu dan

00:05:35hanya seperti mengapa tidak ada solusi untuk ini, bukan? Dan pada awalnya saya melihatnya sangat dari sudut pandang

00:05:41observabilitas dan itu tidak benar-benar berhasil. Bagian yang saya lewatkan adalah bahwa observabilitas

00:05:47hanya satu bagian darinya. Pada akhirnya, saya memiliki pepatah yang saya sebut sebagai obat pembuka

00:05:51menuju arsitektur berbasis acara. Dan alasannya, dan juga mengapa saya suka bersikeras

00:05:56pada istilah acara daripada Webhook, adalah bahwa di balik setiap Webhook ada acara dan ada

00:06:01sekarang paradigma arsitektur berbasis acara yang datang terpaket dengan Webhook itu, bukan? Dan jadi setiap

00:06:07kali Anda menerima Webhook untuk skala serius atau tingkat kasus penggunaan kritis apa pun, Anda sekarang harus

00:06:14berpikir tentang potensi pemesanan, jaminan pengiriman, dan semua jenis

00:06:19tantangan yang Anda miliki setelah Anda mulai berurusan dengan paradigma pemrograman berbasis acara asinkron.

00:06:25Dan jadi benar-benar banyak dari apa yang kami bangun berkembang menjadi membangun antrean lengkap

00:06:29pada akhirnya. Jadi ada interoperabilitas yang Anda yakini bahwa kami berurusan dengan acara,

00:06:33tetapi kemudian semua jenis semantik tersebut lebih seputar berurusan dengan acara dan subsistem pub

00:06:38dan sebagainya secara umum. Dan kami datang dari tempat yang tidak mencoba menciptakan kembali antrean. Saya pikir kami seperti

00:06:43tersandung pada beberapa ide keren yang cukup tulus. Dan satu hal yang kami lihat sekarang adalah ada

00:06:48orang-orang yang benar-benar pindah ke Hookdeck untuk menukar pub/sub atau SQS dari tumpukan mereka, yang

00:06:53bagi saya cukup membingungkan karena kami tidak menjalankan VPC Anda dan semua hal semacam itu. Saya pikir

00:06:57ada banyak masalah dengan itu mungkin, mungkin, mungkin di peta jalan. Tapi intinya adalah, intinya

00:07:05adalah, saya pikir ada banyak semantik seputar arsitektur berbasis acara yang orang-orang sudah

00:07:09terbiasa dan tidak ada yang benar-benar mempertanyakan. Dan itu seperti, mengapa kita melakukan

00:07:13antrean surat mati lagi? Apa yang salah dengan itu? Karena saya tidak tahu siapa pun yang berpikir seperti

00:07:19antrean surat mati adalah semantik yang nyaman untuk menangani kesalahan dalam antrean Anda, bukan? Jadi bagaimanapun, dan saya senang

00:07:25mungkin menyentuh beberapa hal itu karena ada beberapa pendapat yang sangat kuat di

00:07:29sana. Saya tidak tahu seberapa besar Anda kutu buku tentang pub/sub dan arsitektur berbasis acara. Saya tidak

00:07:35ingin menyeret Anda terlalu jauh ke dalamnya. Saya merasa, ya, pemahaman saya tentang antrean surat mati dan semua

00:07:40hal itu sangat, sangat minim. Seperti beberapa hal yang saya dengar hari ini, saya dengar untuk pertama kalinya.

00:07:48Ya, ya. Saya akan mengatakan milik saya juga cukup dangkal, tetapi saya telah berurusan dengan webhook

00:07:53cukup banyak dan berurusan dengan beberapa masalah yang Anda sebutkan. Dan saya pikir seperti, dan begitulah

00:07:57kalian semacam membuat poin untuk ini, webhook adalah obat pembuka menuju arsitektur berbasis acara,

00:08:01karena saya berani bertaruh bahwa untuk pengembang dengan latar belakang Anda, webhook adalah

00:08:06mungkin paparan pertama yang Anda miliki terhadap, tunggu, ini asinkron. Bagaimana saya menangani ini?

00:08:12Dan saya pikir ada kurva pembelajaran ini, bukan? Ini seperti gunung es klasik di mana seperti,

00:08:17oh, Anda memiliki permintaan HTTP yang masuk dan kemudian seperti, Anda tahu, sisa gunung es

00:08:21di balik semacam di dalam air, bukan? Dan saya pikir salah satu hal yang saya coba

00:08:26lakukan adalah membawa tingkat DX yang belum benar-benar dicapai di ruang itu sehingga

00:08:32Anda tidak benar-benar harus mencari tahu sisa gunung esnya, bukan? Ada beberapa hal yang sedikit

00:08:37tak terelakkan, seperti saya tidak ingin salah menyajikannya. Seperti saya pikir begitu Anda mulai

00:08:40bekerja dengan masalah semacam itu, Anda perlu memiliki pemahaman yang baik tentang potensi,

00:08:45misalnya, Anda perlu memiliki pemahaman yang baik tentang jaminan pemesanan. Jadi

00:08:49seperti itu tidak, tidak seperti Anda bisa menyelesaikan setiap masalah. Saya pikir Anda masih berurusan dengan acara

00:08:53pada akhirnya. Tapi saya pikir ada banyak semantik dan kompleksitas yang terutama datang

00:08:58dari peralatan yang tidak dipikirkan sepenuhnya daripada kompleksitas asli yang terkait dengan

00:09:05ruang masalah itu. Jadi saya pikir saat ini kami akhirnya melayani dua jenis pelanggan,

00:09:13kami akhirnya melayani pelanggan yang benar-benar tahu masalahnya secara mendalam dan

00:09:18akan melakukan rekayasa solusi seputar pengaturan Kafka mereka saat ini dan semua

00:09:23hal semacam itu sepanjang hari. Dan kemudian, Anda tahu, kami menawarkan mereka beberapa semantik baru,

00:09:28dan mereka sangat bersemangat tentang itu. Itu satu kategori. Tapi kategori lainnya adalah,

00:09:31saya tidak, saya tidak benar-benar ingin mempelajari semua ini. Dan pada dasarnya saya mencoba

00:09:36untuk menghindari semua ini. Benar. Jadi kami melihat banyak dua profil itu.

00:09:41Apakah itu juga alasan mengapa Anda membuka sumber alat ini, Outpost, untuk memudahkan pengembang

00:09:47untuk memulai, saat menggunakannya? Dalam beberapa hal. Cara lainnya adalah karena kami tidak butuh Outpost

00:09:53untuk menghasilkan uang. Oke. Dan jadi kami seperti, saya rasa kita harus membukanya saja. Ya. Itu hanya,

00:10:01saya tahu bahwa banyak audiens YouTube kami benar-benar suka mengetahui tentang alat sumber terbuka baru. Itulah

00:10:07mengapa saya hanya, Anda tahu, pergi untuk menanyakan tentang itu juga. Tapi, tapi saya, jadi pertama-tama, saya seperti,

00:10:13saya agak menyesal sedikit, seperti di masa-masa awal tidak mengambil pendekatan yang lebih

00:10:18sumber terbuka terlebih dahulu. Dan saya pikir ada banyak hal yang, bagaimana Anda akhirnya membangun

00:10:21perangkat lunak Anda yang sangat berbeda ketika Anda membangun untuk sumber tertutup versus sumber terbuka. Tapi

00:10:26datang ke keputusan sumber terbuka, saya pikir satu hal yang Anda lihat seperti dengan usaha

00:10:30didukung, seperti startup dan hal semacam itu adalah Anda akhirnya berakhir dengan sumber terbuka

00:10:34palsu, bukan? Ini seperti sumber terbuka, tapi baik itu seperti inti terbuka atau seperti, ya, ini sumber terbuka,

00:10:39tapi mereka benar-benar tidak ingin Anda menggunakan sumber terbuka atau mereka akhirnya harus melisensikan ulang

00:10:44di sekitar lisensi yang bukan sumber terbuka sejati dan hal semacam itu. Benar. Dan saya pikir,

00:10:49saya pikir itu membuat saya sangat bersemangat untuk Outpost dan sumber terbuka adalah bahwa saya merasa kami memiliki

00:10:54kesempatan untuk memiliki insentif yang tepat. Sekarang, mungkin kita masuk sedikit ke gulma tentang bagaimana kami

00:10:59berpikir tentang bisnis dan hal semacam itu. Tapi menurut saya, orang yang harus

00:11:03menerima webhook di sisi konsumen setidaknya dua hingga tiga kali lipat lebih banyak

00:11:09daripada orang yang perlu mengirim webhook, bukan? Karena seperti, pikirkanlah, jika saya mengirim webhook,

00:11:13saya mengirimnya ke semua pelanggan saya, dan pelanggan saya mungkin, Anda tahu, 10, jika Anda baru

00:11:17memulai 100, seperti 1000, 2 juta. Benar. Dan jadi, dan jadi mau tidak mau, sisi konsumen hanyalah

00:11:24banyak orang. Dan jadi ketika saya memikirkannya lebih dari sudut pandang pengusaha,

00:11:28saya seperti, saya lebih bersemangat tentang bisnis mendorong sisi konsumen. Benar. Tapi saya pikir

00:11:33apa yang kami sadari, meskipun, adalah jelas, Anda tidak memiliki konsumen tanpa produsen yang baik. Dan saya pikir

00:11:37ada lebih banyak permintaan untuk webhook secara umum, di seluruh aplikasi yang Anda kembangkan. Dan jadi,

00:11:42seperti juga lebih banyak orang ingin menawarkannya dan tidak ingin melalui edX dan overhead dan

00:11:46sebagainya. Tapi dari perspektif saya, pertama, mengirim webhook hanyalah masalah yang lebih sederhana, karena Anda

00:11:51mengontrol parameter sementara di sisi penerima, Anda tidak vendor menentukan apa

00:11:57parameternya. Jadi cenderung, saya tidak ingin mengatakan itu sederhana, tapi seperti itu,

00:12:02dan jelas ada banyak cara Anda bisa melakukan ini salah. Tapi saya pikir dalam hal masalah

00:12:06ruang, itu jelas lebih terbatas di sisi produsen dan di sisi konsumen. Dan kemudian kedua,

00:12:10tugas kami, saya pikir adalah untuk mendorong produksi acara. Dan itulah hal yang pada akhirnya

00:12:15kami pedulikan karena kami ingin lebih banyak orang mengonsumsi webhook tersebut dan akhirnya berpotensi menjadi

00:12:19pelanggan dan hal semacam itu. Benar. Dan jadi saya pikir itu menempatkan kita pada posisi di mana kita bisa

00:12:23benar-benar mengatakan, lihat, jika Anda akan menggunakan Outpost, apakah Anda membukanya atau Anda menyebarkannya

00:12:29dengan Hookdeck pada versi terkelola, itu umumnya tidak masalah bagi kami. Kami mencapai

00:12:35tujuan bisnis dengan cara apa pun. Benar. Dan jadi insentif keselarasan itu membuat saya benar-benar

00:12:40bersemangat. Dan saya pikir ada beberapa hal yang kami lakukan pertama, kami merilis sumber terbuka

00:12:44sebelum bahkan mempertimbangkan membangun versi terkelola. Tidak ada rencana untuk membangun

00:12:48versi terkelola ketika kami membangun sumber terbuka. Dan proyek sumber terbuka telah diterbitkan sekitar

00:12:52dua tahun lalu pada titik ini. Jadi butuh waktu hampir dua tahun sebelum cukup banyak orang

00:12:57meminta versi terkelola sehingga kami akhirnya menagihnya. Jadi itu satu bagian. Dan bagian lain

00:13:03juga versi terkelola Outpost menjalankan build Docker yang sama persis yang diterbitkan di

00:13:08Docker dari sumber terbuka, itu membangunnya tepat dalam arti bahwa kami tidak memiliki garpu pribadi.

00:13:13Kami tidak mengemas fitur dan sebagainya di luar sumber terbuka. Kami benar-benar menjalankan build Docker yang sama persis.

00:13:19Dan jadi pertanyaan untuk Anda bukan seperti, oh, apakah itu menawarkan fitur X atau Y,

00:13:23apa pun dalam versi mana pun? Ini benar-benar hanya apakah Anda ingin menyebarkannya dan harus mengurus

00:13:29beban operasional yang terkait dengan itu? Atau Anda ingin membayar orang lain untuk melakukannya untuk Anda?

00:13:34Benar. Dan saya tidak berpikir ada jawaban yang benar atau salah. Itu tergantung pada setiap bisnis atau tingkat

00:13:38kenyamanan atau stok, persyaratan kepatuhan mereka, sebut saja. Benar. Tapi karena itu,

00:13:44saya merasa kami bisa menjadi kontributor yang baik bagi komunitas sumber terbuka dengan proyek itu. Dan ya,

00:13:51Saya sangat senang mengerjakannya karena ini adalah proyek sumber terbuka besar pertama

00:13:55yang saya terlibat, di luar mendengar kontribusi mereka

00:14:01dan hal semacam itu, tetapi sebagai pengelola inti. Jadi, ya, tidak, itu bagus.

00:14:05Bagaimana Anda menemukan dunia sumber terbuka sekarang setelah Claude Code dan banyak hal itu ada? Apakah

00:14:09Anda memiliki banyak PR dan kerentanan keamanan yang tidak nyata atau apakah tidak apa-apa untuk dikelola?

00:14:14Um, lihat, saya tidak berpikir kita berada pada skala di mana saya dapat berbicara tentang apa yang dialami orang lain.

00:14:20Jadi saya jelas tidak ingin salah menyajikan situasi ini karena itu jelas

00:14:25terdengar buruk bagi banyak orang. Saya akan mengatakan bahwa saya terkejut dengan kualitas dan

00:14:30kontribusi yang kami miliki, tetapi kami jelas juga memiliki kontribusi di mana ada satu

00:14:34PR khusus, saya pikir masih terbuka di repo saat ini, yaitu untuk menambahkan antrean Cloudflare sebagai

00:14:40tujuan. Karena seperti salah satu tujuan acara yang didukung, benar? Deskripsi terdengar bagus di PR

00:14:44dan hal semacam itu. Dan kemudian ketika Anda benar-benar menggali

00:14:48kodenya, itu seperti menggunakan sekumpulan API Cloudflare yang benar-benar dibuat-buat.

00:14:52Dan mereka tidak memeriksanya dua kali. Hanya, maksud saya, jelas orang yang membuka PR bahkan tidak

00:14:56benar-benar mencoba menjalankannya. Benar. Dan jadi, dan jadi sekarang bebannya ada pada kita seperti, oke,

00:15:02sekarang ada PR terbuka ini, karena jelas saya agak khawatir dianggap sebagai

00:15:08kita seperti tidak mencoba untuk mendorong orang yang bisa kita anggap bersaing.

00:15:12Jadi, jadi saya pikir kita harus menambahkan antrean Cloudflare dan hal semacam itu, tetapi pada saat

00:15:15yang sama, itu ada di peta jalan tertutup, tidak ada orang lain selain orang ini yang memintanya dan

00:15:19hal semacam itu. Benar. Dan sekarang ini dalam keadaan yang canggung di mana seperti, oke, jika Anda menutupnya,

00:15:24Anda terlihat seperti Anda tidak ingin mendukung orang yang bisa dianggap sebagai pesaing. Benar.

00:15:28Tetapi kemudian apakah Anda benar-benar mendedikasikan sumber daya dan memindahkan peta jalan Anda dan hal semacam itu,

00:15:33pastikan Anda menerapkannya dengan benar. Benar. Jadi ini agak sulit dengan

00:15:37situasi semacam itu. Um, tapi sejauh ini saya merasa, ini adalah pengalaman yang sangat baik dan

00:15:43terutama karena kami menggunakan build yang sama. Satu hal yang kami lakukan adalah setiap kali

00:15:48pelanggan menjangkau untuk umpan balik atau mereka berbicara dengan kami tentang fitur tertentu dan sebagainya,

00:15:53kami membuka masalah di GitHub, atau kami menunjuk ke PR yang ada, masalah yang ada dan hal semacam itu.

00:15:58Dan seperti, kami memastikan untuk selalu mencoba agar orang tahu, omong-omong, repo ada di sana

00:16:03dan Anda bisa pergi dan berkontribusi. Dan seperti, sebenarnya pada titik itu, kami memiliki beberapa jenis

00:16:07pengguna terkelola yang memberikan kontribusi dan pada dasarnya hanya pergi dan menerapkan fitur mereka sendiri.

00:16:13Benar. Dan saya pikir itu mengurangi hambatan masuk secara luar biasa untuk kasus penggunaan

00:16:18kontribusi yang tulus. Karena Anda tahu, secara historis proyek-proyek dalam bahasa Go,

00:16:24sebagian besar pengguna kami mungkin bukan pengembang Go sejak awal. Benar. Seperti kami melihat banyak

00:16:28Python, TypeScript, jelas seperti Node.js, seperti, jadi ada hambatan masuk untuk Go. Dan kemudian juga

00:16:35hanya belajar proyek baru untuk berkontribusi adalah hal yang tidak sepele. Benar. Dan jadi

00:16:39saya pikir itu mengurangi hambatan masuk secara substansial. Dan itu sangat bagus.

00:16:42Karena sekarang jika, sebagai pengguna Anda terganggu dengan ini, seperti, oh, hal ini benar-benar mengganggu saya.

00:16:48Dan ditambah lagi, sebagai pengelola, itu adalah sinyal yang kuat bahwa fitur ini layak dibangun.

00:16:53Seseorang berusaha keras dan menghabiskan token mereka untuk mengimplementasikan fitur ini.

00:16:58Itu adalah sinyal bahwa, oke, ini benar-benar penting. Benar. Dalam hal peringkat prioritas,

00:17:02hal apa yang paling penting. Jadi saya pikir mengurangi hambatan untuk masuk itu sangat bagus.

00:17:07Jadi saya pikir jika Anda bisa mengelola dan keluar dari banjir spam dan semua hal itu,

00:17:12ada banyak sisi positifnya.

00:17:14Di halaman arahan, satu hal yang sangat menarik perhatian saya adalah testimoni dari CEO Vercel.

00:17:21Jadi Vercel juga sebenarnya menggunakan Hookdeck sebagai produk.

00:17:25Bahwa jika Anda membaca kutipan spesifik itu, itu juga merekomendasikannya.

00:17:29Oh, begitu.

00:17:29Semacam pengguna Vercel dan hal-hal semacam itu.

00:17:32Hmm, tapi sebenarnya ada cerita lucu di sana.

00:17:35Karena Guillermo men-tweet tentang itu pada Sabtu malam.

00:17:39Saya sama sekali tidak menyangka itu akan terjadi.

00:17:40Saya tidak benar-benar memiliki hubungan sebelumnya dengan Guillermo dan hal-hal semacam itu.

00:17:45Dan itu bisa menunjukkan pengaruh orang-orang tertentu dalam komunitas.

00:17:48Karena jumlah pendaftaran dan kesadaran dan sebagainya yang kami dapatkan dari situ

00:17:53benar-benar gila.

00:17:54Hmm, sejak saat itu Guillermo dan saya sering berhubungan di sana-sini.

00:17:57Dan itu selalu menjadi obrolan yang menyenangkan dan sebagainya.

00:17:59Dan itu menarik.

00:18:00Karena, sebenarnya jika Anda melihat perusahaan seperti Vercel, satu hal yang dikatakan Guillermo kepada saya

00:18:04adalah dia sekarang melihat jauh lebih banyak orang yang menggunakan WebEx.

00:18:07Dan pemahamannya adalah bahwa itu terutama didorong oleh adopsi LLM.

00:18:12Dan itu menciptakan kasus penggunaan baru untuk data.

00:18:15Anda biasanya tidak akan peduli sebelumnya.

00:18:18Seperti memikirkan sistem dukungan pelanggan Anda.

00:18:20Misalnya, Anda memiliki agen dan manusia yang ada di sana.

00:18:23Dan, ada sangat sedikit alasan untuk melakukan apa pun dengan, Anda tahu, acara tiket baru.

00:18:29Dan hal-hal semacam itu.

00:18:30Karena, bagaimanapun, manusialah yang akan pergi dan menjawab pesan itu.

00:18:34Tapi sekarang kita jelas berada di dunia di mana itu benar-benar berubah.

00:18:37Dan ketika Anda beralih dari manusia yang memicu agen, seperti apa yang memicu agen, itu adalah peristiwa.

00:18:42Benar.

00:18:42Dan tiba-tiba sekarang Anda peduli dengan peristiwa dari dukungan pelanggan Anda dan

00:18:46alat pemasaran Anda dan sebagainya.

00:18:48Benar.

00:18:48Jadi, hmm, dan itu pasti sesuatu yang menurut saya sebagai platform yang mereka lihat.

00:18:54Dan itu menjadi poin diskusi yang menarik bagi kami, jelas.

00:18:57Tapi ya, tidak, Vercel secara khusus untuk mengklarifikasi bukan pengguna langsung.

00:19:01Maksud saya, saya yakin banyak pengembang menggunakan CLI lokal Anda dan hal-hal semacam itu

00:19:05di Vercel, tapi, ya.

00:19:06Jadi, apa pelanggan khas bagi seseorang yang menggunakan Hookdeck?

00:19:10Seperti jika saya punya, entahlah, toko e-commerce kaos ukuran kecil atau sesuatu, bagaimana saya

00:19:15akan menggunakan Hookdeck untuk itu?

00:19:17Dan apakah masuk akal untuk menggunakannya dalam kasus ini?

00:19:19Mungkin tidak.

00:19:21Oke.

00:19:22Anda menanyakan saya pertanyaan sejuta dolar dalam arti bahwa saya pikir itu sesuatu

00:19:26yang selalu kami perjuangkan dalam arti bahwa luasnya alasan mengapa Anda akan menggunakan

00:19:32WebEx atau bergantung pada WebEx itu sangatlah luas.

00:19:35Kami mendapatkan WebEx dari, ya, pengguna biasa seperti Stripe dan Shopify, tapi kami juga punya

00:19:40WebEx yang datang dari semua penyedia telekomunikasi Australia dan lembaga kliring Inggris.

00:19:47Dan sebenarnya ada banyak yang datang dari game EVE Online.

00:19:50Ternyata ada juga komunitas orang yang masih menggunakan, masih memainkan game seperti Conan,

00:19:55game barbar, dari sekitar 15 tahun yang lalu atau semacamnya.

00:19:58Dan mereka juga sangat sering menggunakan WebEx.

00:20:00Jangan tanya saya kenapa.

00:20:00Benar.

00:20:01Tetapi intinya adalah ada keluasan yang sangat sulit untuk ditangkap dan mengatakan bahwa ini adalah pelanggan kami.

00:20:06Benar.

00:20:08Benar.

00:20:09Jadi ketika kami melihat orang-orang yang menggunakan ini, tidak ada satu kasus penggunaan

00:20:13atau kelompok atau apa pun.

00:20:14Itu mungkin lebih dari 10%.

00:20:16Tapi kembali ke kasus penggunaan e-commerce Anda atau contohnya.

00:20:19Jadi pertama-tama, toko kaos kecil mungkin belum membangun aplikasi khusus

00:20:25dan hal-hal semacam itu yang akan mengandalkannya.

00:20:27Tapi mereka hampir pasti telah menginstal aplikasi.

00:20:30Seperti contohnya, aplikasi untuk mengumpulkan ulasan dan aplikasi mungkin untuk notifikasi stok kembali

00:20:35dan aplikasi untuk manajemen inventaris dan aplikasi dengan 3PL mereka.

00:20:39Dan hampir semua pihak itu sangat bergantung pada Webhook.

00:20:43Benar.

00:20:43Jadi kalau saya ingin mengirim notifikasi stok tersedia, yang saya lakukan adalah memantau semua pembaruan

00:20:48stok di toko Shopify melalui Webhook mereka.

00:20:50Lalu begitu produk yang tadinya habis kini tersedia,

00:20:53saya langsung berpikir, oke, harus kirim email.

00:20:54Benar.

00:20:55Jadi pada dasarnya, setiap hal yang mereka instal atau tambahkan dan seterusnya akan

00:20:59bergantung pada Webhook di balik layar.

00:21:00Jadi itu pasti salah satu kategori besar.

00:21:02Orang-orang membangun aplikasi dan itu bukan hanya Shopify, jelas seperti Stripe, contohnya,

00:21:07seperti pasar aplikasi besar.

00:21:09Dan banyak dari mereka adalah pelanggan, hal semacam itu.

00:21:11Hal lain yang akan kita lihat adalah toko-toko besar.

00:21:14Seperti memikirkan Gymshark dan Good American dan Rogue dan hal-hal semacam itu

00:21:19di mana mereka memiliki tim teknis sendiri dan mereka membangun aplikasi khusus.

00:21:22Mereka membangun aplikasi khusus untuk integrasi sistem mereka, seringkali sangat operasional dalam

00:21:28hal urutan dan ketika pesanan perlu disinkronkan dengan 3PL dan perlu menambahkan catatan.

00:21:34Dan mungkin ada preferensi khusus pelanggan yang perlu ditambahkan ke data itu

00:21:39sebelum mencapai 3PL, hal-hal semacam itu.

00:21:41Benar.

00:21:41Dan beberapa di antaranya akan memberdayakan pengalaman pengguna, hal-hal seperti, Anda tahu, khusus

00:21:46manajemen langganan atau, Anda tahu, email tertentu yang ingin Anda kirim ketika seseorang membeli

00:21:51kartu hadiah dan ingin mengirimnya ke teman mereka dan, Anda tahu, semua hal semacam itu.

00:21:55Dan itulah yang cenderung kita lihat, toko Shopify kecil mungkin adalah yang bisa Anda

00:21:59yang mungkin Anda pilih dan kami jarang melihat orang menggunakan WebEx, tapi tahukah Anda, hampir di mana pun

00:22:04lain yang Anda tuju, di segmen itu, Anda akan, Anda akan menemukan

00:22:08perusahaan yang menggunakan WebEx.

00:22:09Cukup adil.

00:22:10Cukup adil.

00:22:11Bagaimana ini dibandingkan dengan sesuatu seperti AWS EventBridge?

00:22:14Karena itu salah satu pilihan lain yang pernah saya dengar.

00:22:17Apakah ini hanya pengalaman pengembang yang lebih baik atau?

00:22:19Yah, jelas kita semua tahu AWS, maksud saya seperti yang lebih baik kurang lebih membuat hal yang sama

00:22:24argumen, bukan?

00:22:25Ya.

00:22:26Dan jadi apa pun yang Anda katakan sebagai nilai jual unik Anda versus, Anda tahu,

00:22:31cloud watch dan layanan blog Amazon dan semua hal semacam itu semacam terbawa.

00:22:37Jadi, dan itu sangat seperti argumen pengalaman pengembang, bukan?

00:22:40Anda tahu, seperti API yang tepat dan MCP dan UI yang bagus dan kemampuan kantor yang kokoh dan semua hal

00:22:46semacam itu.

00:22:47Benar.

00:22:47Dan jelas seperti integrasi itu, saya pikir masalah AWS selalu bahwa Anda

00:22:51berakhir dengan, Anda tahu, 20 layanan, yang sebagian besar mungkin sudah lupa namanya sekarang.

00:22:56Dan kemudian semacam datanya tersebar melalui ini dan konfigurasinya terurai

00:22:59melaluinya, tersebar melaluinya dan semua itu.

00:23:01Benar.

00:23:01Jadi, jadi itu satu poin.

00:23:02Tapi saya pikir poin yang lebih luas adalah AWS EventBridge tidak benar-benar terintegrasi dengan siapa pun,

00:23:07semua orang.

00:23:08Jadi vendor perlu terintegrasi dengan AWS EventBridge.

00:23:11Ada cara yang bisa Anda lakukan dengan API gateway dan sebagainya.

00:23:16Tapi, hmm, jadi poinnya adalah ini sangat dibangun untuk ekosistem AWS di mana sebagian besar

00:23:23kasus penggunaan sebenarnya seperti peristiwa internal ke AWS, hal-hal seperti dokumen S3 baru diunggah dan

00:23:31hal semacam itu.

00:23:31Dan kemudian interoperabilitas dengan pihak ketiga, meskipun mereka mendukung 40-an,

00:23:36apa pun vendor, jangan kutip saya tentang ini mungkin sudah diperbarui sekarang, tapi Anda tahu, bukan ribuan.

00:23:40Anda selalu berakhir dalam skenario di mana, oke, Shopify mendukung EventBridge, tapi Twilio tidak.

00:23:45Twilio tidak.

00:23:47Benar.

00:23:47Jadi Anda berakhir dengan masalah-masalah itu di mana Anda benar-benar bisa membawa solusi agnostik

00:23:51dan hanya berfungsi secara menyeluruh.

00:23:52Dan jadi saya pikir, itu satu hal yang kami coba lakukan, benar.

00:23:54Ini seperti membangun kami dengan cara sedemikian rupa sehingga kami tidak membutuhkan vendor untuk ikut serta

00:23:59atau setuju dengannya, atau benar-benar melakukan apa pun di pihak mereka.

00:24:02Dan pada titik itu, cara kami membangun Hookdeck, menurut saya cukup baru dalam arti

00:24:08itu murni bekerja melalui HTTP.

00:24:10Dan jadi idenya adalah Anda, kami memberi Anda URL dan Anda bisa mengganti URL web Anda yang ada

00:24:15dengan URL yang kami berikan kepada Anda.

00:24:17Dan kemudian di Hookdeck, tujuan Anda adalah apa yang akan menjadi URL Hookdeck Anda.

00:24:22Dan jadi kami bekerja sebagai antrean berbasis push di antaranya.

00:24:25Dan jadi kami akan mendapatkan semua web melalui HTTP, dan kemudian kami akan mendorongnya keluar pada tingkat

00:24:28yang Anda tentukan ke titik akhir Anda sendiri.

00:24:31Tapi apa artinya itu adalah Anda bahkan tidak perlu menyebarkan ulang kode Anda.

00:24:34Anda bisa berada di cloud apa pun di tumpukan apa pun agar ini berhasil pada dasarnya segera.

00:24:39Benar.

00:24:40Karena sebenarnya satu-satunya persyaratan adalah memperbarui URL pada akhirnya.

00:24:44Dan itu sangat jauh dari AWS EventBridge, yang merupakan penguncian vendor utama,

00:24:48membutuhkan kompatibilitas khusus, hanya berfungsi di ekosistem AWS.

00:24:53Ya.

00:24:53Saya, tapi saya biasanya menganggap EventBridge sebagai salah satu gateway acara besar lainnya.

00:24:58Kami sebenarnya melihat Azure Event Grid, yang merupakan pesaing, juga mendapatkan beberapa kemajuan.

00:25:04Dan jadi ketika saya memikirkan pesaing kami yang paling langsung atau benar-benar seperti inspirasi kami dalam beberapa

00:25:10cara, itu adalah kedua produk tersebut.

00:25:13Tapi, tapi saya pasti berpikir lingkup dari apa yang kami coba lakukan jauh lebih besar.

00:25:17Dan bagi sebagian orang itu hal yang baik.

00:25:18Bagi sebagian orang itu, itu bukan hal yang baik, bukan?

00:25:20Seperti bagi sebagian orang itulah yang mereka inginkan.

00:25:22Seperti, Anda tahu, mereka sepenuhnya tertanam dalam ekosistem AWS.

00:25:24Mereka menggunakan CloudFormation.

00:25:26Mereka terbiasa dengan semua layanan.

00:25:27Mereka ingin bisa memilih dan memilih kemampuan.

00:25:30Dan Anda tahu, itu tidak apa-apa.

00:25:31Seperti, saya tidak berpikir kami akan pernah memiliki pangsa pasar 100%.

00:25:34Jadi sebenarnya di AS, saya pikir beberapa poin persentase mungkin adalah semua yang Anda butuhkan.

00:25:38Jadi ya, saya pikir kami mencoba membuat kasus bahwa, Anda tahu, untuk perusahaan estetika dan

00:25:45pengembang dan sebagainya, itu akan menjadi solusi yang tepat.

00:25:48Dan Anda tahu, untuk yang lain, AWS EventBridge akan menjadi dan itu tidak apa-apa.

00:25:51Jadi saya pikir saya perhatikan tahun lalu bahwa jumlah waktu henti untuk perusahaan besar

00:25:59telah meningkat.

00:26:00Seperti ada semua meme tentang GitHub yang sedang down.

00:26:02Dan saya ingat dua tahun lalu ketika saya bekerja, seperti P99, jika Anda mau,

00:26:07jika itu turun seperti ke 99,5 atau sesuatu atau lebih rendah, Anda akan melakukan percakapan serius

00:26:13dengan tim Anda.

00:26:14Seperti, bagaimana Anda bisa membuat ini terjadi?

00:26:15Benar, sekarang itu semacam kursus.

00:26:17Ya.

00:26:17Dan sekarang seperti, orang-orang sudah terbiasa dengan GitHub yang down untuk waktu yang lama.

00:26:23Jadi saya berpikir seperti, dari perspektif Anda tentang Hookdeck, apakah Anda melihat bahwa ada juga

00:26:28jauh lebih banyak waktu henti tahun ini daripada tahun-tahun sebelumnya dan bagaimana Anda menghadapi tantangan itu?

00:26:33Ya, itu menarik karena jelas itu pertimbangan yang harus Anda lakukan jika Anda akan

00:26:37untuk mengonsumsi Webhook dari GitHub, khususnya Webhook GitHub, memang cukup bermasalah.

00:26:42Tahu kan, ada kemungkinan besar jika Anda login ke Railway, Vercel, atau lainnya,

00:26:46akan ada sebuah banner.

00:26:47Isinya seperti, deployment sedang down karena Webhook GitHub tidak berfungsi atau semacamnya.

00:26:51Dan sebenarnya CTO GitHub menulis postingan blog tentang stabilitas infrastruktur mereka

00:26:58di tengah-tengah semua meme dan hal-hal semacam itu,

00:27:02berusaha untuk meredam situasinya.

00:27:03Saya rasa itu tidak terlalu berhasil, tapi memang ada saatnya.

00:27:05Namun salah satu hal yang secara eksplisit disalahkan dalam artikel itu adalah stabilitas Webhook

00:27:09dan bagaimana itu bergantung pada MySQL dan bla, bla, bla.

00:27:12Benar.

00:27:13Dan untuk kredit mereka, hanya karena saya pikir cara keluar mungkin bahkan memfrasakan ini agak meremehkan.

00:27:17Seperti saya benar-benar tidak meragukan bahwa tantangan infrastruktur mereka benar-benar gila

00:27:21dengan munculnya agen.

00:27:23Seperti cara yang sama kita berbicara tentang pengelola OSS yang kebanjiran.

00:27:26Itu juga membuat mereka kebanjiran infrastruktur itu.

00:27:30Dan jadi saya minta maaf, saya yakin itu tantangan yang sangat sulit.

00:27:33Tapi poin yang saya dapatkan di mana saya memimpin Anda adalah bahwa, ya, kita bisa melihatnya.

00:27:38Dan tidak hanya itu, seperti kita benar-benar memantaunya untuk beberapa vendor.

00:27:41Jadi sebagai contoh, kami punya fitur yang kami sebut deck radar.

00:27:44Intinya adalah kami bisa melihat statistik gabungan dari semua pelanggan dan semua

00:27:49WebEx yang kami terima melalui deck, lalu menghitung hal-hal seperti latensi pengiriman,

00:27:53seperti berapa latensi pengiriman P99 untuk suatu vendor, berapa uptime mereka, dan sejenisnya.

00:27:58Sebagai contoh, radar kami untuk Shopify cukup populer.

00:28:01Saya punya beberapa ratus pelanggan untuk fitur itu.

00:28:04Jadi idenya adalah kami akan mengirimkan peringatan jika latensi melampaui standar deviasi

00:28:09tertentu dari latensi dasar.

00:28:12Benar.

00:28:12Saya rasa untuk kasus Shopify, latensi dasarnya sekitar empat atau lima detik

00:28:17untuk pengiriman.

00:28:17Saya rasa kalau sudah lebih dari 10 detik,

00:28:19benar.

00:28:20Kami akan mengirimkan peringatan.

00:28:22Jadi, Anda bisa memantau ini seperti data deret waktu dan melihat

00:28:26bagaimana uptime mereka, bukan hanya uptime mentah, tapi juga profil latensi mereka

00:28:31seiring berjalannya waktu.

00:28:32Itu adalah sesuatu yang bisa Anda lihat.

00:28:33Dan saya rasa tim Shopify secara khusus pun menyadari hal itu.

00:28:36Tetapi Anda bisa melihat ada banyak varians dalam waktu pengiriman tersebut.

00:28:41Jadi, akan ada, mungkin sebulan atau dua bulan sekali,

00:28:46insiden latensi yang cukup signifikan.

00:28:49Dan saya rasa itu sesuatu yang biasanya tidak terlihat.

00:28:51Benar.

00:28:52Karena jelas, downtime jauh lebih mudah dideteksi.

00:28:54Anda bisa memeriksanya di Datadog atau Better Stack.

00:28:57Kalian menyebutnya apa lagi? Produk metrik?

00:29:01Observabilitas.

00:29:02Observabilitas, ya.

00:29:03Jadi, Anda bisa cek di Better Stack, karena kalian membangun hal itu.

00:29:05Benar.

00:29:06Dan Anda melihat panggilan HTTP ke endpoint web dan segalanya berhenti total.

00:29:11Benar.

00:29:11Masalahnya cukup jelas dan langsung terlihat.

00:29:14Tetapi jika latensi merayap naik hingga 60 detik, itu akan sangat sulit

00:29:19diketahui hanya dari metrik Anda.

00:29:22Benar.

00:29:23Itu karena latensi tersebut terjadi saat proses, yang mungkin perlu Anda telusuri,

00:29:27dan sebagainya.

00:29:28Tapi ini adalah penundaan di sisi vendor.

00:29:31Sekarang jika Anda memiliki asumsi baru dalam kode, operasi bisnis, dan sebagainya,

00:29:34yang mengasumsikan adanya real-time pada peristiwa tersebut, jika sekarang datangnya 60 detik

00:29:39kemudian, hal itu bisa menimbulkan berbagai masalah baru, bug, dan asumsi yang salah,

00:29:44dan semacamnya di dalam kode.

00:29:46Jadi saya pikir di situlah posisi kami mungkin cukup unik untuk bisa

00:29:50menyediakan data yang baik.

00:29:52Sehingga Anda bisa tahu, oh, ini masalah saya atau masalah vendor?

00:29:55Benar.

00:29:56Itu yang sedang bermasalah.

00:29:57Saya tidak tahu apakah saya bisa berkomentar secara empiris tentang seberapa besar kenaikan atau penurunannya.

00:30:03Dan apakah mereka tersangka biasa yang sering bermasalah dan sebagainya.

00:30:06Itu yang mudah untuk disalahkan.

00:30:08Saya tidak yakin apakah saya akan mengatakan ini masalah terdistribusi yang benar-benar kita lihat sepanjang waktu.

00:30:13Saya rasa masalah ini cenderung lebih terkonsentrasi pada vendor-vendor tertentu.

00:30:16Dan saya rasa bagian yang paling sering merugikan orang adalah latensi pengiriman tersebut.

00:30:23Hal lainnya adalah orang-orang berasumsi bahwa latensi pengiriman lebih rendah daripada kenyataannya

00:30:27di sebagian besar vendor, karena kita pasti berbicara tentang beberapa detik di sebagian besar kasus, yang tergantung

00:30:31bagaimana Anda melihatnya, mungkin waktu yang lama atau mungkin tidak.

00:30:34Tapi saya pikir saat saya menunjukkan diagram latensi ini, misalnya Shopify kepada sekelompok pengembang Shopify,

00:30:40reaksi pertama mereka adalah saya tidak menyangka hal itu.

00:30:43Benar.

00:30:43Ada semacam pemutusan dari ekspektasi yang terjadi.

00:30:46Saya dulu bekerja untuk perusahaan e-commerce yang cukup besar dan kami mengalami masalah yang sama.

00:30:53Latensinya buruk, tapi semua orang seperti meme Spider-Man yang saling menunjuk

00:30:58tim siapa yang bertanggung jawab.

00:30:59Karena biasanya itu adalah vendor pihak ketiga, seperti yang Anda katakan.

00:31:05Dan terkadang memang tidak ada yang bisa Anda lakukan.

00:31:07Anda hanya harus mencari cara untuk mengatasinya.

00:31:08Jadi itu keren.

00:31:09Anda juga harus berhati-hati dalam menyalahkan vendor.

00:31:11Benar.

00:31:11Saya rasa ini adalah sesuatu yang jelas dalam konteks apa yang kalian lakukan,

00:31:16itu selalu menjadi masalah umum.

00:31:18Setiap kali kami mengalami insiden, pertanyaannya adalah, oke, seberapa besar kesalahan yang dilimpahkan ke vendor?

00:31:22Tapi pada titik tertentu, ada juga pertimbangan tentang apa yang wajar dan apa yang tidak.

00:31:27Dan mana yang merupakan kebetulan versus kecelakaan yang tidak disengaja.

00:31:29Contohnya, beberapa hari lalu di Railway, beberapa penyebaran manajemen outpost kami

00:31:34berjalan di Railway karena struktur harga mereka.

00:31:36Karena kami harus menjalankan versi yang sama dengan open source, kami belum membangun

00:31:40sistem multi-tenancy yang tidak akan relevan dengan open source.

00:31:44Jadi pada dasarnya kami melakukan penyebaran aktual untuk setiap pelanggan.

00:31:48Benar.

00:31:49Dan untuk pengguna paket gratis, kami akan menempatkan instance untuk mereka di Railway,

00:31:52yang secara umum bekerja cukup baik.

00:31:54Tapi beberapa hari lalu, akun GCP mereka ditutup dan mereka mengalami down selama sekitar enam jam.

00:31:59Atau sesuatu seperti itu.

00:31:59Benar.

00:31:59Jadi saat seperti itu, bisakah Anda tidak membicarakannya di dalam...

00:32:06Ada satu hal tentang mengalihkan kesalahan.

00:32:09Dan pastinya Anda memiliki tanggung jawab atas vendor Anda.

00:32:11Tapi poinnya adalah, saya pikir batasan itu cukup sulit untuk dilalui.

00:32:14Dan saya melihat adanya kecenderungan alami orang untuk saling menunjuk kesalahan

00:32:18karena itu dapat melepaskan tanggung jawab Anda.

00:32:20Jadi Anda harus berusaha keras melawan hal itu.

00:32:23Benar.

00:32:24Namun dalam kasus di mana Anda bisa memastikan bahwa masalahnya ada pada vendor,

00:32:28menarik rasanya untuk bisa mengidentifikasi itu dan memiliki data

00:32:31pendukung, yang seringkali menjadi masalah pada masalah vendor.

00:32:35Benar.

00:32:35Anda tidak bisa melihat sisi data mereka.

00:32:37Jadi sangat sulit untuk mengatakan dengan pasti atau dengan bukti empiris

00:32:42bahwa itu jelas mereka.

00:32:43Anda harus menarik kesimpulan dari data Anda sendiri, yang bisa benar atau salah.

00:32:46Benar.

00:32:47Jadi saya bertanya-tanya, saat terjadi pemadaman di layanan seperti Shopify atau Stripe,

00:32:51bagaimana acara tersebut melakukan pengejaran dan apakah itu membebani server Anda dengan berat?

00:32:57Ya, pada dasarnya Rex ma'am itulah yang terjadi.

00:33:00Dan karena ada skenario di mana kami selalu mengatakan,

00:33:05Anda tidak boleh berasumsi tentang volume web tertentu.

00:33:09Hmm.

00:33:09Jadi kami memiliki karakteristik di mana setiap vendor akan menerapkan batas waktu (timeout).

00:33:14Benar.

00:33:14Mereka akan memberi Anda waktu tiga detik,

00:33:15atau lima detik tergantung platform untuk merespons.

00:33:18Itu berarti Anda tidak bisa melakukan pekerjaan yang berarti,

00:33:21terutama jika Anda memperhitungkan latensi jaringan dan penundaan semacam itu.

00:33:25Benar.

00:33:25Jadi itulah alasannya, bukan hanya itu,

00:33:28tapi salah satu alasan mengapa hal umum yang perlu dilakukan adalah mengantrekan.

00:33:31Anda tidak bisa memprosesnya secara sinkron.

00:33:33Tapi saya kehilangan fokus.

00:33:39Bisakah Anda mengulangi pertanyaan Anda?

00:33:42Saya tadi bertanya tentang saat ada pemadaman di perusahaan seperti Stripe dan Shopify.

00:33:45Oh, ya.

00:33:45Dan melakukan pengejaran.

00:33:47Ya.

00:33:47Ya.

00:33:47Ya.

00:33:47Jadi, intinya adalah latensi, bla bla bla, cara berbelit-belit untuk mengatakan Anda perlu

00:33:52bisa melakukan autoscaling.

00:33:53Dan Anda perlu bisa melakukan scaling dalam kerangka waktu yang cukup singkat.

00:33:56Dan lonjakan tersebut datang dari berbagai alasan.

00:33:58Mungkin itu terjadi secara alami saat Anda melakukan impor massal ketika pelanggan melakukan impor

00:34:03massal atau semacamnya.

00:34:03Benar.

00:34:03Ada alasan lain mengapa lonjakan bisa terjadi.

00:34:05Tapi downtime adalah salah satunya.

00:34:07Benar.

00:34:07Ada momen di mana jika Shopify down selama setengah jam, saat mereka pulih,

00:34:11mereka hanya akan membajak backlog tersebut, terutama karena mereka akan mencoba mengurangi

00:34:16back pressure pada antrean mereka.

00:34:17Jadi, pada dasarnya mereka akan menyelesaikan semua yang terakumulasi selama downtime.

00:34:22Dan biasanya, apa yang akan Anda lihat adalah mereka bahkan melakukan scaling lebih tinggi dari kapasitas biasanya

00:34:26karena mereka mencoba untuk melakukan pengejaran.

00:34:28Benar.

00:34:28Dan itu menghasilkan pengiriman banyak permintaan ke toko-toko akhir.

00:34:32Jadi, ya, Anda memiliki ketidakteraturan tersebut, tetapi beberapa ketidakteraturan dalam throughput

00:34:37tidak disebabkan oleh Anda.

00:34:38Ini 100% disebabkan oleh vendor karena, Anda tahu, vendor sedang melalui tantangan infrastrukturnya sendiri

00:34:42dan sebagainya.

00:34:44Dan jelas kapasitas Shopify untuk mengirim webhook jauh lebih tinggi daripada kapasitas Anda

00:34:49untuk menerima webhook untuk sebagian besar.

00:34:52Ya.

00:34:52Lucunya, salah satu investor kami adalah CPO di Twilio.

00:34:56Dan saya pikir itulah alasan mengapa saya tertarik untuk berinvestasi.

00:34:59Karena salah satu hal yang dia katakan adalah bahwa Twilio pada dasarnya secara rutin

00:35:04hanya melakukan DDoS kepada pelanggan mereka, untuk semua tujuan.

00:35:07Dan itu sedikit tidak terelakkan dan semacam bagian dari masalah dalam melakukan hal-hal yang

00:35:14berbasis peristiwa vendor.

00:35:17Jadi ini sangat banyak menjadi masalah yang terkenal terkait dengan vendor.

00:35:21Dan mereka pun tahu, karena itu adalah sesuatu yang bisa Anda lacak dalam latensi

00:35:24respons dari server juga, kan?

00:35:26Jika Anda melakukan DDoS kepada pelanggan Anda, latensi respons server meningkat.

00:35:29Dan pada titik tertentu, mereka mulai mengalami timeout.

00:35:31Masalah itu semakin rumit karena lebih sulit untuk memiliki throughput lebih jika ada timeout yang lebih lama.

00:35:34Pada dasarnya semakin lama Anda harus menahan koneksi HTTP, semakin sedikit permintaan yang

00:35:38bisa Anda buat untuk pekerja yang Anda miliki.

00:35:40Jadi sekarang Anda harus melakukan scaling dan kemudian Anda mengirim lebih banyak karena Anda melakukan scaling.

00:35:45Itu hanya menumpuk bersama, kan?

00:35:46Itu cenderung sangat memperkuat diri sendiri karena pada dasarnya semakin sedikit kapasitas yang Anda miliki untuk

00:35:52memproses buku web tersebut, semakin cepat latensi menurun.

00:35:57Dan saat Anda mencapai kejenuhan di server Anda, latensi menjadi sangat buruk.

00:36:01Tapi permintaan tersebut terus melonjak, terus menumpuk.

00:36:04Dan apa yang dilakukan banyak vendor adalah pada titik tertentu, mereka akan menonaktifkan endpoint Anda

00:36:07karena jika tidak, itu akan terus menumpuk.

00:36:10Dan mereka tidak ingin menahan ratusan ribu koneksi HTTP

00:36:14karena server Anda lambat merespons.

00:36:15Tapi begitu mereka menonaktifkannya, Anda kehilangan datanya.

00:36:19Jadi itu titik tangkapannya juga, kan?

00:36:21Jadi memastikan waktu respons melalui varian yang sering di luar kendali Anda

00:36:25adalah bagian besar dari tantangannya.

00:36:29Saya juga ingin bertanya, dengan AI sekarang, bagaimana itu mengubah ruang lingkup web hook?

00:36:37Saya tahu Anda mengatakan LLM sekarang mengirim lebih banyak web hook dan mungkin memprosesnya.

00:36:43Tapi secara internal, bagaimana Anda menggunakan AI untuk Hookdeck?

00:36:48Dan apa yang Anda lihat sebagai masa depan AI di ruang ini?

00:36:51Ya, saya pikir banyak hal yang sedang terjadi di sisi itu.

00:36:54Sebagai sebuah toko pengembangan perangkat lunak.

00:36:57Dan saya merasa kalian sedang mengalami tantangan yang sama terkait

00:37:02alur kerja dan alur kerja yang berubah setiap minggu dan biaya token,

00:37:05dan berapa jumlah biaya token yang masuk akal, dan semua hal semacam itu.

00:37:10Ya, kita tidak perlu melakukan papan peringkat.

00:37:15Saya sangat takut dengan ide papan peringkat.

00:37:18Itu tampak seperti cara yang pasti untuk menghancurkan margin Anda.

00:37:24Jadi ada beberapa pemikiran.

00:37:25Pertama, kembali ke apa yang saya katakan tadi, ada pertumbuhan dan sarana untuk acara

00:37:29yang didorong oleh kasus penggunaan agen karena agen bergerak dari dipicu oleh manusia

00:37:35ke pemicu peristiwa, dan Anda melihat produk agen cloud keluar dan banyak hal dari kami.

00:37:41Semua ini pada dasarnya dipicu oleh jadwal atau peristiwa.

00:37:42Dan beberapa peristiwa tersebut disarikan dari Anda, tapi masih ada hal-hal seperti

00:37:46GitHub PR, saat Anda melakukan commit atau berkomentar di GitHub, itu semua didorong oleh web.

00:37:49GitHub PR atau, tahu kan, saat kamu melakukan commit atau memberikan komentar di GitHub, semua itu berbasis web.

00:37:56Tapi jelas, hal ini akan meluas jauh melebihi itu, seperti dukungan pelanggan

00:38:00dan Slack, dan sebagainya, bahkan mungkin hal-hal waktu nyata yang terjadi

00:38:04di dunia nyata dari data sensor dan semacamnya, benar kan?

00:38:08Menurut saya juga, banyak agen perlu memicu peristiwa untuk agen lain, pada dasarnya,

00:38:12seperti output dari suatu agen yang akan menjadi pemicu, yang mungkin akan memicu

00:38:17agen lain, perusahaan lain, dan sebagainya, yang ya, bisa kamu gambarkan

00:38:21sebagai kasus penggunaan WebEx, dan memang begitu adanya.

00:38:23Tetapi menurut saya, beberapa semantik seputar WebEx saat ini agak cacat

00:38:28seperti masalah keamanan, protokol, efisiensi, dan hal-hal semacam itu.

00:38:33Itulah mengapa kami mendorong destinasi acara sebagai pola yang lebih baik

00:38:36dan pola yang lebih optimal untuk ini. Hal lainnya adalah jika apa yang kamu jalankan

00:38:40sebagai tanggapan terhadap peristiwa adalah alur kerja agen yang tidak deterministik, yang bisa berjalan lama,

00:38:47hal itu membuat jauh lebih sulit untuk menyesuaikan kapasitas dan skala

00:38:51sebagai konsekuensi dari peristiwa yang kamu terima. Jadi saya rasa manajemen throughput dan manajemen

00:38:55kapasitas menjadi jauh lebih sulit. Tingkat kegagalanmu akan lebih tinggi karena

00:39:00cloud yang mengalami timeout, evaluasimu yang tidak lolos, dan hal-hal semacam itu.

00:39:07Jadi, dari sudut pandang pembangunan aplikasi dan primitif inti yang ingin kamu gunakan,

00:39:12serta di mana itu berjalan, berapa lama itu berjalan, dan bagaimana kamu menangani tekanan balik dan hal

00:39:16semacam itu, ada banyak tantangan baru di sana. Dan dalam hal internal kami,

00:39:21saya rasa kami masih berusaha menemukan cara yang tepat. Ada bagian dari diri saya yang merasa

00:39:25benar-benar terpesona oleh kapasitas. Saya tidak mengejutkan siapa pun, saya rasa saya tidak membawa

00:39:29wawasan unik apa pun di sini. Namun, satu hal yang akan saya katakan adalah standar antara

00:39:34beralih dari CLI prompt atau codex atau apa pun ke benar-benar merilis produk yang

00:39:41berkualitas tinggi dan berkelas. Saya rasa beberapa nuansa itu masih hilang dalam meme dan

00:39:45semua paparan itu, di mana saya ragu kamu benar-benar bisa menghabiskan

00:39:50token sebanyak itu dan menghasilkan sesuatu yang benar-benar bernilai bagi dunia.

00:39:55Setidaknya menurut pengalaman kami sejauh ini, jelas ada banyak hal seputar keamanan,

00:40:01yang menjadi pemungkin besar, seperti tinjauan kode dan semacamnya. Tapi saya rasa jika berbicara tentang

00:40:06hal-hal tersebut, itu hanyalah syarat dasar. Itu bukan hal yang benar-benar

00:40:11memberikan nilai lebih, bukan? Jika berbicara tentang membangun sesuatu yang sangat

00:40:14bernilai yang darinya orang lain mendapatkan manfaat, saya rasa masih ada kesenjangan di sana. Dan saya merasa

00:40:19tim kami masih sangat bertanggung jawab untuk membawa tingkat selera, wawasan, dan pemahaman pelanggan

00:40:25serta empati yang tidak bisa kamu dapatkan langsung dari kotak obrolan.

00:40:31Jadi mungkin kamilah yang bodoh karena kami bisa bergerak jauh lebih cepat jika kami

00:40:35langsung melakukan segalanya dalam sekali jalan. Tapi saat ini, pendekatan kami adalah untuk

00:40:42tetap mempertahankan standar yang sama dalam hal output bersih dan apa yang kami berikan kepada pengguna akhir.

00:40:47Ya, tentu saja, itu berarti kami bisa melakukan lebih banyak hal. Dan saya pikir lebih banyak orang

00:40:53yang memiliki selera dan empati tersebut dapat memberikan nilai kepada pengguna karena hambatan utamanya adalah kode,

00:40:57bukan? Jadi sebagai contoh, hampir semua orang di perusahaan sekarang “bisa” menulis kode,

00:41:01desainer kami sekarang adalah coder Vipe residen. Sekarang dialah yang bertanggung jawab penuh atas

00:41:06situs web, atau bahkan ada banyak pekerjaan dasbor, atau pemasar produk

00:41:11atau dari dev rel, semua, bukan melakukan token maxing, tapi jika ada papan peringkat,

00:41:16mereka mungkin berada di urutan teratas. Dan menurut saya itu hal yang sangat baik. Itu adalah pemberdaya,

00:41:20karena orang-orang tersebut harus memiliki pemikiran kritis dan hal-hal yang saya jelaskan tadi,

00:41:25untuk mampu menghasilkan hal-hal yang berkelas bagi pengguna akhir, dan hambatannya lebih ke kodenya.

00:41:30Jadi dalam beberapa hal, saya pikir manfaat terbesar justru datang dari sana dibandingkan

00:41:36dari teknik murni. Sekali lagi, bukan berarti teknik murni tidak mendapatkan banyak nilai

00:41:40dari hal itu, tapi saya rasa hambatan utamanya tetap pada selera tersebut. Ditambah lagi, saya menghabiskan

00:41:45banyak waktu meninjau PR yang tidak penting. Sekarang, ada sisi buruknya juga.

00:41:51Benar. Tentu saja. Dan banyaknya kode yang harus Anda tinjau.

00:41:56Ya. Dan seperti, mari buat kerentanan yang tidak jelas ini yang pada dasarnya tidak mungkin terjadi.

00:42:01Dan saya bahkan tidak yakin itu memenuhi syarat sebagai level rendah, benar. Namun, tentu saja setelah muncul,

00:42:06seperti, Anda merasa bertanggung jawab atas hal itu. Dan menurut saya itu normal. Tapi,

00:42:09pada titik tertentu, seperti, Anda tahu, kami belum pernah memiliki PR sebanyak ini yang terbuka kapan pun.

00:42:14Dan rasanya sedikit gila untuk benar-benar memahami semua ini. Dan,

00:42:18dan saya pikir membawa penilaian bahwa, itu bukan karena Anda bisa melakukan segalanya,

00:42:21Anda harus melakukan segalanya. Dan menurut saya itu sangat seperti datang dengan sikap LLM semacam itu

00:42:26dan menurut saya membawa penilaian tentang apa yang pada akhirnya akan menghasilkan

00:42:31nilai atau memiliki potensi untuk menghasilkan nilai adalah lebih penting dari sebelumnya.

00:42:34Karena ada, um, ada kepuasan daftar tugas semacam itu dalam bekerja dengan agen,

00:42:39Anda tahu, terkadang saya merasa buntu. Rasanya,

00:42:44saya, saya hanya ingin memeriksa daftar saya dan semua hal yang Anda lakukan dan hanya, centang, centang, centang,

00:42:48centang. Benar. Dan ada sesuatu yang muncul dengan hal itu dengan LLM di mana sepertinya, saya memulai

00:42:53percakapan ini, memulai percakapan ini, memulai percakapan ini dan mungkin ada lima atau enam agen yang sedang

00:42:57berjalan dan mereka semua melakukan banyak hal, tetapi dan mereka semua memiliki daftar periksa yang juga mereka centang.

00:43:02Benar. Benar. Benar. Benar. Ya. Ya. Jadi, ada sesuatu tentang kepuasan dan imbalan cepat yang terkait dengan itu.

00:43:06Dan menurut saya terkadang hal itu mengalahkan kita. Benar. Atau setidaknya untuk diri saya sendiri, seberapa besar tim tag hook?

00:43:11Kami ber-10 sekarang. Oh, wow. Itu sangat ramping. Ya. Salut. Itu selalu menjadi ambisi saya.

00:43:15Saya tidak menganggap diri saya sebagai manajer terbaik. Jadi saya pikir itu lebih baik bagi semua orang.

00:43:23Saya tidak menganggap diri saya sebagai manajer terbaik. Jadi saya pikir itu lebih baik bagi semua orang.

00:43:29Tidak, saya setengah mendapatkannya, menurut saya sejak awal, kami lahir di tengah COVID,

00:43:33bukan? Semua orang bekerja jarak jauh. Dan, ada pola pikir sejak awal untuk

00:43:38merekrut, Anda tahu, pengalaman senior, orang-orang yang sangat mandiri untuk,

00:43:45untuk memberikan gambaran. Kami benar-benar hanya melakukan satu panggilan setiap dua minggu untuk membahas

00:43:50produk dan infrastruktur. Dan jadi, kami mencoba untuk memiliki alur kerja yang sangat asinkron.

00:43:56Dan menurut saya, itu juga cocok untuk kasus penggunaan AI. Karena,

00:44:01kami sudah merekrut dan mengoptimalkan untuk orang-orang yang memiliki otonomi ini. Benar. Saya tidak berpikir ada

00:44:06yang benar atau salah. Saya tidak akan berkhotbah tentang cara kami melakukan sesuatu, tapi menurut saya itu berhasil bagi kami.

00:44:11Tidak ada yang berhasil untuk saya dan kewarasan saya. Jadi begitulah.

00:44:14Saya ingin membahas hal yang Anda katakan di awal percakapan bahwa, uh,

00:44:21webhook sudah mati. Cara barunya adalah event gateway. Apakah Anda yang menciptakan istilah itu atau sudah ada

00:44:27di sana? Uh, apa itu event gateway? Saya tidak mengerti sama sekali.

00:44:32Ya, kami yang menciptakannya dan sangat sulit untuk membangun produk dan kategori produk

00:44:37yang belum mapan. Karena Anda memiliki tantangan seputar pemasaran dan

00:44:41komunikasi dan bagaimana Anda bahkan mendeskripsikan hal ini. Benar. Dan untuk sementara kami berbicara,

00:44:46menyebutnya sebagai infrastruktur manajemen webhook dan semacamnya.

00:44:51Tidak ada yang benar-benar mudah diucapkan. Jadi, Anda memiliki tantangan dalam komunikasi,

00:44:54tetapi Anda juga memiliki tantangan pada produk. Karena saat Anda membangun produk dalam kategori yang ada,

00:44:58katakanlah seperti better stack, kemudahan akses, Anda tahu apa yang ingin Anda optimalkan,

00:45:02seperti USP spesifik yang Anda tuju, yang dalam kasus Anda, menurut saya banyak di antaranya adalah seputar harga

00:45:07dan DX dan semacamnya. Benar. Namun intinya adalah semantik intinya ada. Jadi apa

00:45:10yang Anda optimalkan adalah posisi nilai unik itu. Saat Anda membangun sesuatu yang tidak

00:45:14benar-benar ada, Anda harus menciptakan semantik dan kemudian juga membangun proposisi nilai yang menarik

00:45:19di atas semantik tersebut. Benar. Jadi itu menjadi sangat sulit.

00:45:24Dan itu satu pelajaran selama beberapa tahun terakhir, sangat sulit untuk membangun produk dalam

00:45:28kategori yang sudah ada. Dan ide dengan event gateway dan dari mana asalnya adalah

00:45:32mencoba menangkap sebaik mungkin. Dan, Anda tahu, dua atau tiga kata yang mudah

00:45:37diucapkan semacam apa fungsinya. Jadi tujuan kami adalah menjembatani antara bus acara

00:45:43dan pada dasarnya API, API gateway. Benar. Dan menangkap gagasan bahwa gateway ada di sana

00:45:49sebagai antarmuka, antarmuka antara vendor dan sistem Anda sendiri dan sebagainya. Benar. Dan

00:45:55event bus dalam artian, ini adalah manajemen peristiwa dan antrean yang lengkap, dan seterusnya.

00:46:00Benar. Jadi kami mencoba mencari istilah yang menyatukan keduanya. Dan sebenarnya saat

00:46:04Anda memikirkan event bridge, Anda tahu, tidak jauh dari event gateway. Jadi sebenarnya, kami ingin

00:46:10orang menganggap kami sebagai kompetitor dari event bridge, misalnya, kami melihat

00:46:14diri kami sebagai alternatif yang jelas untuk itu. Benar. Jadi saya rasa gagasan tentang event gateway juga

00:46:19seperti memberikan kesan bahwa, lihat, ada produk yang sudah ada saat ini. Tidak ada terminologi umum

00:46:24seputar hal-hal tersebut. Benar. Mereka tidak secara langsung menyebutnya event gateway, tapi kami akan memberikan

00:46:29label itu. Lalu, ada beberapa produk yang sudah bersaing di kategori itu,

00:46:33salah satunya milik kami, tapi ada juga AWS, Azure, dan yang lain seperti Kong yang merupakan event

00:46:39gateway. Sekarang ada gravity. Ada banyak penyedia API gateway yang mulai masuk ke

00:46:45arsitektur berbasis peristiwa juga. Jadi saat ini, mungkin ada setengah lusin produk,

00:46:49setidaknya yang menyebut diri mereka event gateway atau serupa event gateway, dan saya tidak tahu apakah kami

00:46:54ada hubungannya dengan ini, tapi saya bisa katakan saat Kong merilis event gateway mereka, saya berpikir, Oh,

00:46:58sial, itu terjadi dua tahun setelah kami menyebutnya demikian. Tapi bagian yang

00:47:03sebenarnya memuaskan adalah saat pelanggan datang kepada Anda, pengembang datang kepada saya dan mereka bilang, Saya

00:47:08sedang mencari event gateway. Dan itu seperti, Oh, sekarang Anda berpikir, oke,

00:47:12saya rasa istilah ini mulai dipahami, orang mulai memiliki model

00:47:16mental tentang apa itu, atau mulai mencarinya secara eksplisit, atau mereka mungkin berkata,

00:47:20kami mencoba mengganti event gateway kami sendiri. Hal-hal itu muncul dalam

00:47:23percakapan. Tapi saya bisa katakan selama tahun pertama, hal itu tidak muncul. Dan sekarang,

00:47:28seiring berjalannya waktu, itu adalah istilah yang saya lihat digunakan orang lain semakin sering. Saya pikir itu hal yang baik.

00:47:34Saya pikir itu hal yang baik bagi kami sebagai bisnis, tetapi juga dalam artian berusaha untuk

00:47:38menciptakan seperangkat ekspektasi bahwa, oke, ini adalah primitif infrastruktur cloud yang ada.

00:47:43Dan milik Anda adalah, Anda seperti seperangkat ekspektasi dasar yang bisa Anda miliki tentang hal itu. Dan

00:47:48semoga pada suatu saat, hal-hal akan mulai selaras dan semantik serta

00:47:52hal semacam itu juga. Seperti jika Anda menggunakan AWS event bridge dan, terminologinya sangat

00:47:57sedikit yang sama. Sekarang, saya tidak ingin merancang produk saya berdasarkan AWS event bridge karena semua

00:48:01produk yang dimilikinya. Jadi saya jelas tidak akan menggunakan kembali terminologi mereka jika menurut saya tidak

00:48:05masuk akal. Tapi saya pikir seiring berjalannya waktu, seiring dengan

00:48:09banyaknya kondisi dan orang-orang yang membangun dan berkecimpung di sekitar produk itu, hal semacam itu,

00:48:12mungkin akan ada beberapa tingkat konvergensi.

00:48:15Ya.

00:48:15Apakah menurut Anda jika saya meminta event gateway pada LLM, itu akan merekomendasikan kalian?

00:48:20Oh ya. Coba sekarang. Saya pikir kemungkinannya cukup besar.

00:48:24Saya bisa mencobanya secara langsung.

00:48:25Itu sesuatu yang kami pantau, kan?

00:48:27Ya.

00:48:27Itu sesuatu yang kami pantau. Kami dikutip dalam sekitar 60% dari setiap,

00:48:31setiap prompt yang berkaitan dengan WebEx atau event gateway, hal semacam itu.

00:48:35Itu keren. Dan sesuatu yang jelas kami habiskan banyak waktu untuk itu. Dan sejauh data kami

00:48:42berjalan, yang mungkin tidak berkualitas setinggi itu, kami melakukannya dengan cukup baik. Jadi

00:48:46Itu yang pertama dalam daftar.

00:48:48Oh, bagus.

00:48:49Nah, itu dia.

00:48:49Itu yang baru saja diberikan ChatGPT kepada saya. Kerja bagus.

00:48:52Ya. Meskipun saya pikir untuk event gateway, saya pikir kami mungkin melakukan hal yang sama baiknya

00:48:56pada kueri terkait WebEx dan hal semacam itu. Tapi event gateway jelas

00:49:00mendukung kami dalam artian, kami yang menciptakan istilahnya, saya akan,

00:49:03saya akan marah jika kami bukan yang pertama.

00:49:05Saya baru sadar sekarang bahwa saya tidak benar-benar tahu apa arti arsitektur berbasis peristiwa (event driven architecture). Apa bedanya

00:49:11dari arsitektur biasa? Seperti jika saya memasang antrean Kafka di sistem saya,

00:49:17apakah saya secara otomatis menggunakan arsitektur berbasis peristiwa?

00:49:21Ya dan tidak. Dalam artian bahwa menurut saya, ketika Anda berbicara tentang arsitektur berbasis peristiwa, itu seperti

00:49:25lebih sebagai seperangkat paradigma dan ekspektasi yang Anda miliki tentang hal itu. Jadi sebagiannya akan

00:49:31menjadi, ya, alat-alatnya, benar? Seperti Anda menggunakan Kafka, Anda menggunakan antrean pesan atau event

00:49:35streaming yang dimaksudkan untuk memisahkan sistem. Jadi sebenarnya, jika dilihat kembali,

00:49:39idenya adalah mereka memiliki produsen dan konsumen, sistem-sistem tersebut tidak tahu,

00:49:43tidak perlu tahu tentang satu sama lain, benar? Jadi konsumen dapat mengonsumsi dari aliran

00:49:47peristiwa yang bisa dihasilkan dari siapa saja. Dan satu-satunya ekspektasi nyata yang Anda miliki

00:49:53adalah kontrak tentang apa itu peristiwa itu sendiri. Seperti apa payload-nya, bagaimana bentuknya?

00:49:57Ya. Dan seringkali akan ada skema, seperti skema khusus yang akan digunakan orang-orang,

00:50:02seperti skema berbasis Avro dan pro buff serta hal lainnya, benar? Di mana akan ada

00:50:06ekspektasi terstandarisasi tentang seperti apa payload tersebut dan seterusnya. Dan sebenarnya, kontraknya menjadi

00:50:11tentang, oke, peristiwa-peristiwa ini ada. Dan pada saat tertentu saya mungkin memiliki peristiwa dan sebagai konsumen,

00:50:16tanggung jawab saya adalah melakukan apa pun yang seharusnya saya lakukan dengan pemesanan yang dibuat atau pembaruan produk dan sebagainya.

00:50:21Benar. Tapi sekarang sebuah organisasi yang benar-benar menerapkan EDA, apa yang akan Anda lihat adalah seperti

00:50:25pola sistematis di sekitar ini, benar? Di mana akan ada panduan khusus

00:50:29tentang bagaimana Anda seharusnya melakukan ini dan seperti apa bentuk payload-nya.

00:50:32Dan itu akan menjadi pendekatan arsitektur di mana Anda secara sengaja memisahkan

00:50:36layanan mereka dan membuat komunikasi di antara mereka berbasis peristiwa, benar?

00:50:41Saya merasa banyak perusahaan mengambil pendekatan hibrida, benar? Sesuatu berbasis peristiwa,

00:50:45tapi sesuatu tidak, benar? Jadi apakah tujuannya adalah menjadi 100% berbasis peristiwa?

00:50:50Atau apakah itu hanya sebagian dari paradigma arsitektur?

00:50:54Saya rasa tidak 100%. Saya hanya berpikir bahwa seiring waktu, seiring pertumbuhan dan peningkatan kompleksitas,

00:51:00dan adanya lebih banyak dependensi pihak ketiga dan sebagainya, itu seperti cara alami hal-hal cenderung

00:51:04terjadi. Karena pada titik tertentu, sangat sulit untuk membuat semua sistem tersebut digabungkan.

00:51:09Dan kemudian Anda harus memikirkan tentang penskalaan dan interdependensi dan semua hal semacam itu

00:51:14dengan cara yang membuatnya cukup sulit. Tapi secara umum, ketika kita memikirkan tentang

00:51:19arsitektur berbasis peristiwa, dalam artian istilahnya, menurut saya orang-orang,

00:51:23maksud saya, memang benar, memikirkan perusahaan besar, benar? Dan saya pikir selama dekade pertama

00:51:28arsitektur berbasis peristiwa, itu terutama terkonsentrasi di perusahaan besar. Tapi saya pikir sekarang

00:51:32itu berubah sebagian karena orang-orang menjadi lebih nyaman dengan polanya, sebagian karena

00:51:37WebEx adalah obat pembuka untuk itu. Dan juga beberapa peralatan menjadi lebih baik. Seperti saya memikirkan,

00:51:41seperti, misalnya, RabbitMQ, atau BullMQ, yang dibangun di atas

00:51:46Redis, semacam pustaka, ada juga banyak pustaka populer di Python, ada

00:51:51celery dan di Ruby, ada sidekick. Saya pikir ada satu lagi sekarang, seperti foundation, yang juga dari

00:51:57orang-orang di sidekick. Jadi, bagaimanapun, ada progresifitas dalam peralatan di sekitarnya

00:52:01yang juga membuatnya lebih mudah untuk digunakan dan semakin tidak mengintimidasi untuk dimasuki di mana Anda tidak

00:52:05hanya membutuhkan tim arsitektur besar dan penyebaran Kafka yang besar, yang menghabiskan banyak

00:52:11uang dan seterusnya untuk mulai melakukan arsitektur berbasis peristiwa. Tapi saya juga berpikir istilah ini

00:52:15telah sedikit kehilangan maknanya. Saya yakin beberapa orang tidak akan senang dengan saya mengatakan itu. Tapi

00:52:19saya memang berpikir itu sedikit kehilangan maknanya seiring waktu, atau setidaknya airnya keruh dalam hal apa yang kita maksud.

00:52:25Dan saya pikir ketika saya mengatakannya, yang saya maksud terutama adalah pemisahan sistem ini. Dan kemudian

00:52:31juga masalah pemrograman yang tidak akan Anda miliki sebagai insinyur dalam hal,

00:52:37Anda tahu, harus memikirkan independensi dan pengurutan serta semua jenis kekhawatiran itu. Jadi ketika

00:52:43saya mengatakan arsitektur berbasis peristiwa, itu lebih dan saya bermaksud seperti Anda sekarang memasuki dunia di mana

00:52:48ketika Anda membangun aplikasi, Anda akan memiliki serangkaian kekhawatiran yang tidak Anda miliki sebelumnya.

00:52:52Benar. Mengerti. Dan mampu belajar serta mengadopsi cara Anda membangun sesuatu agar mampu

00:52:58mengakomodasi kekhawatiran tersebut. Saya tidak tahu apakah awalnya saya bermaksud seperti

00:53:03cara perusahaan besar. Dan saya rasa dalam beberapa hal, kami hanya mencoba untuk, Anda tahu,

00:53:08membawa hal itu kepada semua orang dengan beberapa cara. Benar. Dan kami bukanlah satu-satunya

00:53:14pemain yang melakukan hal itu. Ada banyak orang lain yang mengambil pendekatan berbeda.

00:53:18Ada banyak mesin alur kerja dan fungsi langkah di sana yang menurut saya tumpang tindih, seperti

00:53:22temporal dan ingest serta trigger.dev dan orang-orang seperti itu juga. Jadi, menurut saya ini adalah

00:53:28ruang di mana banyak hal terjadi. Dan mungkin tidak ada definisi yang benar-benar baku

00:53:34untuk itu lagi. Bagi mereka yang benar-benar tertarik untuk belajar lebih banyak

00:53:38tentang arsitektur berbasis acara dan paradigma yang terkait dengannya dan sebagainya. Ada seseorang

00:53:42bernama David Boyan, yang sebelumnya adalah advokat pengembang di AWS dan sebenarnya mengerjakan event

00:53:49bridge. Itu adalah rangkaian jenis penjelasan gambar. Namun pada titik ini, dia mungkin memiliki

00:53:55ratusan yang juga dia jalankan sebagai proyek sumber terbuka sekarang bernama event catalog, mungkin bisa jadi

00:54:02tamu podcast yang bagus untuk kalian. Tapi intinya, kedalamannya

00:54:07benar-benar hampir tidak masuk akal. Benar. Jadi, saya sangat merekomendasikannya bagi mereka yang

00:54:14penasaran. Keren. Kami akan menambahkannya ke catatan acara. Ya, karena semua pengetahuan Anda tentang acara dan web

00:54:19hook dan segalanya. Jadi, Anda memiliki banyak hal itu, semuanya berasal dari membangun hook deck.

00:54:23Atau apakah ada, Anda pernah bilang sebelumnya bahwa Anda punya beberapa masalah dengan webhook, tapi apakah ini saat Anda

00:54:27benar-benar menyelami acara? Sangat benar. Dan saya pikir pembelajaran itu sangat berasal dari

00:54:34masalah, tetapi juga seperti prinsip pertama dalam arti bahwa, ketika saya menangani masalah

00:54:38itu, saya sebenarnya tidak memiliki banyak pengetahuan tentangnya, yang merupakan bagian dari alasan mengapa saya menangani

00:54:42masalah-masalah itu. Ya. Jadi saya pikir itu sangat berasal dari tempat seperti, oke, mencoba untuk bekerja

00:54:47melalui masalah dan solusi dari masalah itu, daripada bekerja melalui solusi dan

00:54:51menerapkannya kembali pada masalah tersebut. Benar. Tapi pada akhirnya, saat ini,

00:54:55kami telah bekerja dengan ratusan ribu webhook, saya seperti, Anda tahu, dari seluruh

00:54:59spektrum. Jadi saya pikir saya hanya menyerapnya dari percakapan itu. Dan ya, pada dasarnya

00:55:05ini sangat menarik. Saya sebenarnya awalnya mulai sebagai desainer produk. Jadi semacam,

00:55:11Anda tahu, desainer produk, semacam pengembang full stack, kemudian penawaran backend,

00:55:15kemudian insinyur infrastruktur. Dan sekarang, sekarang cukup dalam masuk ke

00:55:21lubang kelinci. Namun, itu datang melalui pekerjaan dengan pelanggan dan mendengarkan

00:55:26kekhawatiran mereka dan meninjau arsitektur dan semua hal semacam itu. Tapi juga dari tim,

00:55:30bukan? Kami juga memiliki orang-orang di tim yang memiliki banyak pengalaman bekerja dengan

00:55:33sistem tersebut dan juga membawa pengetahuan itu ke perusahaan. Ya. Kapan Anda

00:55:38menyadari Anda menemukan pasar untuk ini? Saya asumsikan Anda mulai mengerjakannya dan kemudian

00:55:42mempostingnya di suatu tempat. Dan apakah penerimaannya cukup baik segera? Atau apakah ini cukup lambat

00:55:47untuk membuat orang tahu bahwa ini adalah pilihan yang lebih baik? Lambat, sangat lambat untuk mendefinisikannya

00:55:53dalam arti bahwa itu dimulai dengan artikel medium yang dirujuk, bukan? Seperti semacam web

00:55:57hook dan ada sesuatu yang bisa Anda lakukan tentang hal itu. Saya sangat memiliki pola pikir untuk membangun produk

00:56:01untuk orang-orang. Jadi, versi paling awal adalah semacam swalayan, Anda tahu, Anda bisa

00:56:07masuk dan membuat, Anda tahu, koneksi pertama Anda yang kami sebut, dan semua hal semacam itu.

00:56:12Dan memposting artikel ini dan sebagainya. Dan tidak ada ambisi untuk menjadikannya bisnis atau

00:56:16apa pun. Itu hanya satu dari 20 proyek sampingan gagal lainnya, bukan? Yang telah saya kerjakan

00:56:21pada saat itu. Dan maksud saya, dalam retrospeksi, sekarang jumlahnya

00:56:26terlihat sangat kecil, karena mungkin ada lima orang yang menghubungi

00:56:32dari artikel itu atau semacamnya. Tapi saya tahu bagi semua orang yang telah mengerjakan proyek sampingan,

00:56:37dan telah melalui proses mencoba membuat seseorang menggunakan sesuatu yang

00:56:42telah Anda bangun dan seterusnya. Lima itu benar-benar gila. Lima lebih baik daripada yang mungkin pernah saya

00:56:48dapatkan sebelumnya. Benar. Jadi saya sangat bersemangat karenanya. Saya sebenarnya berada di

00:56:55mobil kemah saya, British Columbia, memanjat tebing. Dan saya sangat jauh dari, Anda tahu, mencoba membangun

00:57:00startup atau apa pun. Hanya berbincang dengan orang-orang itu, mengajak mereka,

00:57:05berjalan melalui itu, seperti yang saya pikirkan dan masalah yang mereka alami dan semacam

00:57:08itu. Dan kemudian terus masuk perlahan, mungkin satu per minggu dan saya seperti, saya sedang

00:57:13memanjat tebing. Dan saya membuka slack dan ada notifikasi slack. Kami memiliki saluran notifikasi

00:57:18untuk setiap pendaftaran, bukan? Sama seperti yang kami miliki selama enam tahun atau semacamnya.

00:57:21Pada titik ini, cukup sulit untuk melacak karena hanya bergulir

00:57:25dengan cepat. Tapi saya akan mendapatkan notifikasi di saluran itu. Saya akan

00:57:31seperti, oh sial, Anda tahu, seseorang mendaftar. Apakah Anda melakukan DDOS pada slack?

00:57:38Tidak, jelas tidak pada masa itu. Tapi saat ini, Anda bilang Anda masih memilikinya sekarang. Jadi itulah mengapa

00:57:44saya bertanya. Benar, benar, benar. Yah, maksud saya, segalanya berjalan dengan baik, tetapi saya tidak berpikir sampai

00:57:48pada titik DDOS slack. Oke. Bagaimanapun, jadi, jadi kawan, maaf dari sana, tetapi saya pikir asumsi inti

00:57:54satu pada awalnya yang bermasalah adalah gagasan bahwa ini terutama dibangun untuk

00:57:58kemampuan observasi. Saya pikir itu tidak cukup jauh. Tetapi begitu Anda beralih dari mengatakan seperti,

00:58:02Saya membangun alat kemampuan observasi menjadi Saya menciptakan kembali bus pesan, tiba-tiba cakupannya

00:58:08meledak secara dramatis. Benar. Jadi saya sebenarnya bertemu CTO dan salah satu pendiri di

00:58:15tengah membangun mesin antrian pertama. Dan ketika saya

00:58:19menyadari bahwa cakupannya akan meledak terbuka lebar mengenai ini. Saat itulah

00:58:23kami juga mencari pendanaan awal, tetapi seperti investor malaikat dan semacamnya.

00:58:28Jelas sekali bahwa itu akan cukup mahal

00:58:32untuk dibangun, yang ternyata memang cukup mahal. Dan setahu saya, Anda tidak mengambil

00:58:36rute SF yang khas. Anda membangunnya di Montreal, kan?

00:58:39Ya, itu mungkin sedikit tidak jujur dengan apa yang sebenarnya terjadi. Jadi kami melakukan, kami melakukan

00:58:44pra-awal sekitar $400.000 hanya dari investor malaikat, bukan VC institusional. Tetapi kemudian

00:58:51beberapa bulan kemudian kami melakukan berita akurat dan saat itulah kami tahu, kembali ke

00:58:56pertanyaan Anda, James, tanggapan dari berita akurat, maksud saya, itu bukan

00:59:00berita akurat terbesar yang pernah ada, tetapi jauh lebih baik daripada yang kami harapkan

00:59:05dan anekdot lucu. Saya ingat pria yang membeli paket seharga $300,

00:59:11setelah HN. Dan saya ingat rekan pendiri saya dan saya berkata, kawan, kita berhasil.

00:59:18Itu sudah pasti. Kita pasti berhasil.

00:59:22Pergi makan malam malam itu, menghabiskan semuanya. Itu lebih.

00:59:25Ya, persis seperti itu. Semangkuk sampanye. Ya. Tapi, um, ya, bagaimanapun,

00:59:31dari HN itu, semacam hal itu. Dan kemudian pada titik itu, kami memiliki banyak

00:59:34minat dari investor yang secara proaktif menghubungi dan semacamnya. Jadi kami,

00:59:38kami akhirnya mengumpulkan putaran dari investor Silicon Valley, perusahaan bernama matrix

00:59:44partners. Jadi kami masih berbasis, tim terpusat, perusahaan Kanada. Kami belum

00:59:50berubah menjadi Delaware LLC, tetapi pada saat yang sama, saya pikir investor kami telah

00:59:55luar biasa dan saya sangat senang kami melakukannya. Dan saya pikir, karena COVID dan

01:00:00sebagainya, mungkin ada penerimaan yang berkembang bahwa perusahaan tidak

01:00:04berbasis pada hal ini dan membangun tim jarak jauh, semacam itu. Maksud saya, banyak orang

01:00:08telah melakukannya, kami tidak menemukan apa pun, masih ada Zapier dan

01:00:12GitLab dan semua orang yang telah melakukan ini jauh lebih lama dari siapa pun.

01:00:17Jadi menurut saya itu mungkin hanya menormalisasinya. Dan itu sesuatu yang saya lihat dari beberapa,

01:00:21mungkin saya hanya naif tentang ini, tapi itu sesuatu yang saya lihat dari beberapa pendiri. Ada seperti,

01:00:27Anda tahu, sebagai pendiri Kanada, stasiun yang lebih besar dan semacam pendiri Kanada Twitter di sekitar,

01:00:32Anda tahu, menggabungkan ke Delaware dan YC berhenti menerima perusahaan Kanada. Dan kemudian

01:00:38mereka akhirnya membatalkan keputusan itu dan sebagainya. Tapi ada pemahaman

01:00:42bahwa setiap investor akan meminta Anda menjadi Delaware LLC. Dan mereka benar.

01:00:47Setiap investor akan bertanya kepada Anda, bagian yang melewatkan cerita itu adalah Anda bisa saja mengatakan tidak.

01:00:54Um, jadi ya, tentu saja. Mereka akan bertanya kenapa tidak? Dan itu lebih mudah bagi mereka,

01:00:58tetapi ternyata jika Anda hanya berkata tidak, itu juga benar-benar baik-baik saja. Jadi setidaknya dalam pengalaman saya dan

01:01:03banyak orang di sekitar saya. Jadi saya pikir itu adalah bagian yang hilang dari cerita itu, bukan? Seperti pada akhirnya, pekerjaan mereka adalah menyebarkan

01:01:07modal. Mereka mencari orang untuk diinvestasikan atau mencari ide orisinal dan semacamnya.

01:01:11Seperti, saya tidak ingin berdebat tentang pro dan kontra berada di sini. Dan saya yakin ada banyak

01:01:15hal positif di dalamnya, tetapi Anda tahu, pada akhirnya, itu adalah pilihan Anda sebagai

01:01:19pendiri dan pembangun, dengan siapa Anda akan melakukannya dan di mana Anda akan melakukannya.

01:01:24Dan saya pikir jika Anda memiliki ide bagus dan Anda berusaha keras, investor masih akan

01:01:27menghargai itu, atau setidaknya beberapa investor masih akan menghargai itu. Benar. Jadi mungkin pekerjaan Anda

01:01:31adalah menemukannya. Jadi mungkin akan tidak jujur jika mengatakan bahwa kita benar-benar

01:01:36di luar gelembung itu, tetapi saya secara pribadi, membuat hidup saya di sini dan

01:01:41saya cukup senang masih berada di Montreal secara pribadi. Yah, sebagai sesama orang Kanada, menyenangkan

01:01:47mendengar kisah sukses Kanada. Jadi salut untuk itu, tapi kemudian Anda pindah ke Toronto dan kemudian Anda

01:01:52hanya mengacaukan semuanya. Wajar, wajar. Bisakah saya katakan sebagai sesama Persemakmuran, hebat, bukan? Sama

01:01:57raja. Itu hal yang sama, Anda tahu. Ya, kami punya ratu. Maksud saya,

01:02:06Saya tidak tahu apakah mereka sudah memperbarui ke raja sekarang, tetapi kami punya ratu di tagihan kami.

01:02:11Ya. Apakah hook deck startup pertama Anda sebagai pendiri atau ada orang lain dalam perjalanan yang memberi Anda

01:02:14alat untuk mengetahui cara menjangkau investor dan menemukannya? Saya selalu

01:02:19sangat berjiwa wirausaha sejak awal di perusahaan kecil ini, pergi ke

01:02:23zona pensiunan, memperbaiki komputer pada usia 14 atau 15 dan seterusnya. Jadi saya kira dalam

01:02:27arti, lebih seperti berbicara tentang semangat wirausaha, tapi tidak, saya pikir

01:02:34sebagian besar adalah proyek sampingan yang gagal, seperti merilis video game yang pada dasarnya tidak pernah

01:02:38sampai ke mana-mana. Anda tahu, banyak hal lain, seperti pada titik tertentu saya sedang mengerjakan beberapa jejaring sosial,

01:02:44meskipun saya mungkin pria terburuk di pertemuan sosial dan mengatur

01:02:48hal-hal dengan teman. Bagaimanapun, melalui proses hal-hal itu. Namun saya akan mengatakan,

01:02:53pengalaman ini, di perusahaan e-commerce, itu sebenarnya cukup formatif dalam arti

01:02:58saya bergabung sebagai karyawan pertama di sana dan sangat terlibat dengan tim pendiri.

01:03:03Dan kami pergi dari, Anda tahu, pada dasarnya empat orang menjadi 40 atau sesuatu

01:03:07dalam tiga tahun. Dan, Anda tahu, semua gerakan membangun bisnis itu dan semua,

01:03:13semua hal itu di sana. Jadi, saya menganggap exec sangat seperti,

01:03:19yang pertama, tetapi akan tidak jujur untuk memposisikannya sepenuhnya seperti itu. Saya pikir ada

01:03:23beberapa paparan terhadap hal-hal itu sebelumnya. Dan jelas saya memiliki perusahaan e-commerce ini.

01:03:27Kami bekerja dengan investor juga dan Anda tahu, dewan dan semacamnya

01:03:31dan membangun hubungan di sana juga. Dan kemudian investor pertama sebenarnya dalam bisnis e-commerce itu

01:03:36juga merupakan investor awal pertama kami di dek. Jadi itu tidak seperti benar-benar memulai

01:03:39dari nol dalam arti seperti, Anda tahu, beberapa orang mungkin menemukan diri mereka masuk, tapi ya,

01:03:44saya kira saya masih tidak berharap untuk berada di sini, Anda tahu, beberapa tahun yang lalu. Dan itu hebat.

01:03:48Saya melihat ada perusahaan bernama Kiwi Mornings, startup sarapan sehat. Apa itu semua tentang?

01:03:54Dan kemudian pekerjaan rumah Anda. Jadi, jadi itu adalah salah satu bisnis gagal di sepanjang jalan.

01:04:02Saya sebenarnya memulainya dengan istri saya. Kami sebenarnya, ceritanya adalah istri saya,

01:04:09membawa sarapannya di tempat kerja dan semua orang penjualan di tempat kerja agak iri dengan sarapannya

01:04:14dan mulai meminta sarapan padanya. Dan saya seperti, apa maksud Anda sarapan Anda adalah orang-orang penjualan di tempat kerja?

01:04:19Apa yang salah? Tapi kemudian satu hal menyukai yang lain dan dia mungkin membuat lima

01:04:24atau enam sarapan setiap pagi untuk tim penjualan. Dan mereka seperti, ah, kenapa kita tidak,

01:04:30Anda tahu, salah satu ide bodoh itu, kenapa kita tidak membuat bisnis dari ini? Jadi

01:04:36kami membangun layanan ini untuk pada dasarnya sarapan nol limbah di tempat kerja. Dan kami mengirimkan semacam

01:04:41yogurt dan smoothie dan puding chia dan semacam itu dalam toples kaca kecil.

01:04:47Dan kami memiliki sedikit kulkas dan kantor dan seterusnya. Dan, saya menjadi saya, mengambilnya

01:04:51terlalu jauh. Dan sisi produk dan teknik, seperti semua pesanan melalui bot slack

01:04:56dan pemberi kerja dapat memilikinya sebagai tunjangan karyawan di mana pada dasarnya

01:05:01mereka membayar 50% dari sarapan. Dan Anda tahu, ada hal semacam ini.

01:05:06Jadi ya, orang akan memesan sarapan mereka melalui bot slack dan semua itu, tidak harus

01:05:11itu berakhir. Hanya saja dalam bisnis itu, semuanya salah pada jam empat pagi

01:05:16dan ditambah tidak ada uang dalam makanan. Jadi ketika Anda menggabungkan kedua hal itu, sangat sulit

01:05:20untuk membangun bisnis yang memuaskan. Jadi pada titik tertentu kami akhirnya menjual

01:05:25bot slack dan semua itu dan berhenti melakukannya. Tapi untungnya,

01:05:29itu pada Januari 2021. Jadi dua bulan sebelum COVID. Dan kemudian pada dasarnya setiap

01:05:34perusahaan yang setara, seperti ada banyak dari mereka yang sudah melakukan makan siang dan semacam

01:05:42itu, makan siang kantor dan semua itu. Pada dasarnya semua orang gulung tikar. Jadi, kami

01:05:46sedikit beruntung pada waktunya karena itu akan berakhir tidak peduli apa. Benar. Seperti,

01:05:52ya. Tapi semuanya, saya pikir kami mungkin telah menjual sekitar 20.000 sarapan atau semacamnya.

01:05:57Oh, cukup keren. Ya. Cukup keren.

01:06:01Oh ya. Jadi kami selalu suka bertanya, ya, kami selalu suka bertanya kepada tamu kami, apa pendapat Anda yang panas

01:06:06tentang industri ini, AI, apa pun, silakan. Saya merasa saya sudah memberikan beberapa dalam percakapan ini.

01:06:12Saya pikir Anda sudah. Apa pendapat terpanas Anda? Seperti sangat panas.

01:06:18Membakar. Oke. Ini mungkin di mana saya akan kehilangan Anda karena ini sangat banyak di

01:06:22gulma arsitektur. Saya yakin beberapa anggota audiens kami akan mengerti apa yang Anda

01:06:29katakan. Sempurna. Jadi pendapat terpanas saya, pendapat terpanas saya adalah sistem antrian berbasis polling

01:06:35sangat bodoh dibandingkan dengan sistem berbasis push. Dan alasan mengapa kami belum mengadopsi

01:06:42sistem berbasis push ini adalah karena tidak ada antrian yang membangun sistem berbasis push yang baik. Dan alasan mengapa saya mengatakan

01:06:49ini, dan sekarang saya akan mencoba memberikan sedikit konteks adalah bahwa ketika Anda membangun semacam antrian

01:06:56dan konsumen untuk setiap antrian yang Anda masukkan acara ke dalamnya, Anda perlu memiliki konsumen untuk itu. Dan itu

01:07:02konsumen mungkin seperti semacam pekerja yang berjalan lama yang menarik antrian itu. Tapi

01:07:07masalahnya adalah jika Anda ingin secara dinamis memiliki antrian, dan katakanlah Anda ingin memiliki antrian per

01:07:12pelanggan, bukan? Karena Anda tidak ingin satu pelanggan mengacaukan seluruh antrian atau

01:07:16masing-masing kapasitas mereka yang dialokasikan, semacam itu. Sekarang Anda perlu memiliki konsumen sebanyak Anda

01:07:21memiliki antrian, yang menjadi gila karena Anda memiliki masalah multipleksing di mana setiap antrian membutuhkan

01:07:26konsumennya. Keuntungan besar dengan sistem berbasis push adalah bahwa semua antrian itu dapat mendorong ke konsumen yang sama.

01:07:31Dan satu konsumen itu bisa menjadi API dengan penyeimbang beban di depannya yang bisa Anda

01:07:36skala secara horizontal, atau saya maksud, atau vertikal, apa pun. Tapi intinya, Anda bisa melakukan

01:07:41itu benar-benar terpisah dari berapa banyak antrian yang Anda miliki. Dan saya pikir satu hal yang kita

01:07:45lihat adalah, begitu Anda masuk ke kasus penggunaan yang semakin kompleks, Anda berakhir dengan cara yang

01:07:49semakin granular yang Anda inginkan untuk mengantre sesuatu. Jadi Anda ingin mengantre per topik dan per kondisi tertentu

01:07:54dan per pelanggan dan semacamnya. Dan itu menjadi gila sepenuhnya karena kemudian Anda

01:07:58memiliki 100 antrian dan 100 konsumen dan 100 antrian dolar dan semua kekacauan yang

01:08:02datang di sekitar mereka. Tapi sangat sulit saat ini untuk menemukan antrian pesan berbasis push.

01:08:07Dan alasannya adalah karena Anda menggeser di mana throughput dikendalikan. Jika throughput

01:08:13dikendalikan di konsumen, setiap konsumen bertanggung jawab untuk mengatakan, hei, saya ingin

01:08:1750 pesan per detik atau secara bersamaan atau apa pun. Dan kemudian berapa banyak pesan yang Anda konsumsi menjadi,

01:08:22apa kapasitas seorang pekerja? Berapa banyak pekerja yang Anda miliki? Dan juga apa kapasitas efektifnya?

01:08:29Bukan karena Anda mengatakan ingin 50 per detik. Itu sebenarnya berjalan pada 50 per detik,

01:08:33karena itu tergantung pada sisa kode dan apakah itu cukup cepat atau tidak dan seterusnya.

01:08:37Benar. Jadi saya pikir alasan mengapa kita belum pindah ke antrian basis bush adalah bahwa sebagian besar dari mereka tidak

01:08:40benar-benar memberi Anda granularitas yang diperlukan dan mengendalikan throughput. Jadi sebagai contoh,

01:08:45GCP Pub/Sub memang memiliki mode push, tetapi dalam mode push, mereka pada dasarnya meningkatkan laju di

01:08:50mana Anda mengirim permintaan Anda sampai API Anda mulai melambat, yang pada titik ini mereka pada dasarnya telah

01:08:55mendegradasi itu. Dan kemudian begitu mulai melambat, mereka mengurangi laju pengiriman. Dan apa yang akhirnya Anda miliki

01:09:00adalah bahwa itu merayap naik, merayap naik, merayap naik, server crash atau mengalami degradasi kinerja yang serius,

01:09:06kembali ke nol, dan kemudian merayap naik, merayap naik, merayap naik, kembali ke nol.

01:09:11Dan itu benar-benar selesai. Seperti itu tidak masuk akal. Benar. Dan saya pikir jika Anda

01:09:15membangun antrian misi berbasis push, dan itu seperti salah satu misi yang saya ikuti di mana Anda memiliki kontrol yang sangat baik

01:09:20atas throughput dan perilaku tepat dari laju konsumsi, itu menyederhanakan begitu banyak arsitektur Anda.

01:09:24Jadi itulah pendapat saya bagi mereka yang tahu dan, saya bersedia mati karenanya.

01:09:29Maksud saya, saya tidak mengerti semuanya, tapi itu terdengar masuk akal, Anda tahu?

01:09:34Saya pikir jika Anda mengerti itu, periksa hookdeck. Ya, tepat sekali.

01:09:40Hargai itu, ya. Nah, terima kasih, Alex. Terima kasih telah mendengarkan episode

01:09:46Better Stack Podcast ini. Temukan kami di mana pun Anda mendapatkan podcast, Spotify, Apple Music, atau di tempat lain.

01:09:50Tapi hari ini selamat tinggal dari saya. Selamat tinggal dari saya. Dan selamat tinggal dari saya.

01:09:57Selamat tinggal dari saya.

핵심 요약

Event Gateway Hookdeck dan proyek sumber terbuka Outpost menstandardisasi pengelolaan webhook serta transisi menuju arsitektur berbasis peristiwa.

하이라이트

Hookdeck membangun dua produk utama yaitu Event Gateway untuk mengelola acara masuk dan Outpost sebagai layanan bersumber terbuka untuk menerbitkan acara.
Proyek sumber terbuka Outpost menduplikasi build Docker yang sama persis dengan versi terkelola tanpa adanya garpu pribadi.
Fitur Deck Radar mengawasi statistik gabungan dan latensi pengiriman P99 dari berbagai vendor seperti Shopify.
Hookdeck memproses ratusan ribu webhook dengan tim beranggotakan 10 orang yang bekerja secara asinkron.
Sistem antrean berbasis push menyederhanakan arsitektur dibandingkan sistem berbasis polling karena mampu mengontrol throughput secara dinamis.

타임라인

Pengenalan Hookdeck dan Pengelolaan Webhook

Hookdeck menyediakan Event Gateway sebagai bus acara khusus untuk menyaring, mengubah, merute, dan mengantrekan data eksternal.
Proyek sumber terbuka Outpost menangani penerbitan acara dan mendukung protokol transportasi seperti RabbitMQ, Kafka, SQS, dan AWS EventBridge.
Kompleksitas penanganan webhook secara manual mendorong terciptanya solusi yang mengintegrasikan semantik arsitektur berbasis peristiwa.

Pengembangan Hookdeck berakar dari frustrasi dalam mengelola webhook e-commerce secara manual tanpa alat yang memadai. Webhook berfungsi sebagai pintu gerbang menuju arsitektur berbasis peristiwa yang memerlukan penanganan jaminan pengiriman, pemesanan, dan antrean surat mati.

Model Sumber Terbuka dan Kontribusi Komunitas

Outpost dirilis sebagai proyek sumber terbuka Apache 2.0 sebelum versi terkelolanya dibuat.
Versi terkelola Outpost menjalankan build Docker yang sama persis dengan repositori sumber terbuka tanpa fitur tersembunyi.
Kontribusi kode dari pengguna memvalidasi prioritas peta jalan produk berdasarkan kebutuhan nyata.

Pendekatan sumber terbuka menyelaraskan insentif bisnis tanpa menciptakan batasan lisensi yang merugikan. Penggunaan build Docker yang identik memberikan kebebasan bagi perusahaan untuk memilih antara mengelola infrastruktur sendiri atau membayar layanan terkelola.

Kasus Penggunaan dan Pemantauan Latensi Vendor

Fitur Deck Radar memantau profil latensi dan waktu aktif vendor secara real-time.
Lonjakan throughput terjadi secara otomatis setelah vendor besar mengalami pemadaman layanan.
AWS EventBridge terikat secara ketat pada ekosistem AWS, sementara Hookdeck bekerja secara agnostik melalui URL HTTP.

Pengguna Hookdeck berasal dari berbagai industri mulai dari e-commerce hingga permainan daring. Deck Radar membantu pengembang mengidentifikasi apakah masalah latensi berasal dari sistem internal atau dari vendor pihak ketiga seperti Shopify dan GitHub.

Dampak AI dan Operasional Tim Ramping

Adopsi agen AI meningkatkan volume pengiriman webhook dan memicu kebutuhan pemrosesan asinkron yang lebih kompleks.
Tim Hookdeck terdiri dari 10 orang yang beroperasi secara jarak jauh dengan siklus kerja asinkron.
Sistem antrean berbasis push menawarkan kontrol throughput yang lebih baik dibandingkan sistem berbasis polling.

Agen AI mengubah pola pemicu dari interaksi manual menjadi peristiwa berbasis web, sehingga manajemen kapasitas menjadi prioritas utama. Dengan tim yang ramping dan budaya kerja mandiri, Hookdeck terus memperluas adopsi event gateway dan menantang pola arsitektur konvensional.

커뮤니티 글

모든 글 보기

이 영상에 대해 글쓰기