इवेंट-ड्रिवन आर्किटेक्चर, वेबहुक का अराजकता, और एआई एजेंट्स का उदय | बेटर स्टैक पॉडकास्ट एपिसोड 17

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

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

스크립트

00:00:00बेटर स्टैक पॉडकास्ट में आपका स्वागत है, जहाँ हम सॉफ्टवेयर डेवलपमेंट,

00:00:04एआई और सभी प्रकार की नई तकनीकों के बारे में बातचीत करते हैं। मैं आपका एक होस्ट एंडरस हूँ, और आज मेरे साथ हैं

00:00:10जेम्स और एलेक्स। हे एलेक्स, शो में आपका स्वागत है। मुझे बुलाने के लिए धन्यवाद। तो चलिए शुरुआत करते हैं

00:00:16उस कंपनी से जिसे आप चलाते हैं। इसका नाम हुकडेक (Hookdeck) है। तो जो लोग इससे परिचित नहीं हैं,

00:00:22हुकडेक क्या है? यह क्या करता है? हमें इसके बारे में और बताएं। हाँ, मैं इसे उस

00:00:27वेबहुक कंपनी के रूप में देखना पसंद करता हूँ जो वेबहुक्स को खत्म करने की कोशिश कर रही है। यह शायद एक ऐसी कहानी है जिस पर हम चर्चा कर सकते हैं।

00:00:32लेकिन हम मुख्य रूप से दो उत्पाद बनाते हैं। एक है इवेंट गेटवे। तो इवेंट गेटवे

00:00:37आपकी बुनियादी सुविधाओं (infrastructure) के बाहर से आने वाले सभी इवेंट्स के लिए एक विशेष इवेंट बस के रूप में कार्य करता है।

00:00:41वेबहुक्स इसका एक प्रमुख उदाहरण है, लेकिन हम कई तरह के आईओटी (IoT) और एसडीके (SDK) आधारित उपयोग के मामले भी देखते हैं।

00:00:47तो मूल रूप से, हम एक तरह का अविश्वसनीय (untrusted) एंडपॉइंट प्रदान करते हैं। आप कोई भी इवेंट भेज सकते हैं।

00:00:51और फिर उन इवेंट्स को प्रबंधित करने की सभी क्षमताएं भी। इसमें फ़िल्टरिंग,

00:00:55ट्रांसफॉर्मेशन, रूटिंग, क्यूइंग, अलर्ट, और इश्यू मैनेजमेंट रिप्ले, ये सब कुछ शामिल है।

00:01:01तो वास्तव में, यह इंटरऑपरेबिलिटी (interoperability) को कवर करता है, जिसका अर्थ है कि मुझे

00:01:05मेरे साथ काम करने वाले सभी वेंडरों से इवेंट्स और वेबहुक्स प्राप्त करने होते हैं, है ना? जैसे स्ट्राइप, शॉपिफ़ाई, ट्विलियो,

00:01:10व्हाट्सएप, टिकटॉक, जो भी हो। उन सभी के अपने मानदंड और quirks

00:01:16और विशिष्ट आवश्यकताएं होती हैं। और इसलिए हम उस सबको मानकीकृत (standardize) कर सकते हैं और

00:01:20उसे एक सिंगल कॉन्ट्रैक्ट में ला सकते हैं। और फिर क्यूइंग (queuing) के नजरिए से सब कुछ। उदाहरण के लिए,

00:01:27शॉपिफाई पर, आपके स्टोर पर फ्लैश सेल होती है और आपको इवेंट्स की बाढ़ आ जाती है,

00:01:31जैसे भगदड़। आप उसे सामान्य करते हैं ताकि आप इवेंट गेटवे पर थ्रूपुट (throughput) को नियंत्रित कर सकें

00:01:38और वह सब। तो वह इसका एक बड़ा हिस्सा है। यह उपभोक्ता पक्ष (consumer side) की तरह है। और वहीं से

00:01:42डेक की कहानी शुरू हुई थी। और हाल ही में, हमने आउटपोस्ट (Outpost) भी जारी किया है। आउटपोस्ट पूरी तरह से

00:01:49ओपन सोर्स, अपाचे 2.0 प्रोजेक्ट है। और हमारे पास अब इसके लिए एक मैनेज्ड सर्विस भी है। और इसका काम

00:01:55इवेंट्स भेजना है। तो यह समीकरण का दूसरा पहलू है, ठीक? यह आप एक प्रकाशक (publisher) के रूप में हैं, एक

00:01:59प्लेटफ़ॉर्म या देव टूल के रूप में। इस बिंदु पर हर कोई इवेंट्स भेज रहा है। मैं हर दिन हैरान होता हूँ।

00:02:05और इसलिए आउटपोस्ट यह मैनेज्ड सर्विस या सेल्फ-होस्टेड सर्विस है जिसका उपयोग आप यह घोषित करने के लिए कर सकते हैं कि

00:02:12आपके टेनेंट कौन हैं, उनके डेस्टिनेशन क्या हैं, उन्होंने कौन से एंडपॉइंट रजिस्टर किए हैं, टॉपिक्स कॉन्फ़िगर करें

00:02:17और उन पर इवेंट्स प्रकाशित करें। और यह दृश्यता, मेट्रिक्स, डिलीवरी गारंटी, रिट्राई,

00:02:23और हस्ताक्षर, हस्ताक्षर रोटेशन जैसी सभी सामान्य चीजों को संभालता है।

00:02:28वेबहुक्स को खत्म करने के बारे में मैंने जो थोड़ा सा मजाक किया था, वह यह है कि आउटपोस्ट,

00:02:35हाँ, आपको वेबहुक्स भेजने की अनुमति देता है, लेकिन आपको सीधे अपने उपयोगकर्ता के मैसेज बस पर

00:02:39इवेंट्स प्रकाशित करने की भी अनुमति देता है। और इसलिए आउटपोस्ट नेटिव रूप से इवेंट डेस्टिनेशन का समर्थन करता है। और वेबहुक को

00:02:46ट्रांसपोर्ट राउटर माना जाता है। और इसलिए आप मूल रूप से वेबहुक्स पर इवेंट्स भेज रहे होते हैं और

00:02:53वेबहुक्स मानक ट्रांसपोर्ट तंत्र है, ठीक? और आप नए ट्रांसपोर्ट प्रोटोकॉल चुन सकते हैं, जैसे कि MQ,

00:02:59RabbitMQ या काफ्का के लिए। और हम Pub/Sub, SQS, AWS इवेंटब्रिज जैसे सभी सामान्य स्थानों पर भी सीधे पब्लिश करने का समर्थन करते हैं,

00:03:05SQS, AWS EventBridge, और निश्चित रूप से YokeDeck इवेंट गेटवे, है ना? तो मैं इसे एक

00:03:12तो आपने कहा कि आप वेबहुक्स को खत्म करना चाहते हैं। तो मुझे कल्पना करनी होगी कि यह विचार और इसकी शुरुआत इस तथ्य से हुई कि

00:03:18आप सभी वेबहुक्स से थक चुके थे या उन्हें प्रबंधित करना बहुत कठिन था। हमें बताएं कि आपको यह विचार कैसे आया।

00:03:25हाँ, मैं वास्तव में दूसरे दिन किसी को यह कहानी बता रहा था। लगभग पाँच साल पहले, मैंने मीडियम पर यह लेख प्रकाशित किया था।

00:03:31मुझे लगता है अब छह साल पूरे होने वाले हैं। और लेख का शीर्षक है, और यह ठीक आपके कहने के अनुसार है,

00:03:37“वेबहुक्स बेकार हैं, लेकिन आप इसके बारे में कुछ कर सकते हैं।” और यह बस मैं अपने बेसमेंट में

00:03:42प्रयोग कर रहा था और डेक का V1 प्रोटोटाइप बना रहा था।

00:03:48लेकिन यह बहुत हद तक उस निराशा से आया था। मैं व्यक्तिगत रूप से ई-कॉमर्स में काम कर रहा था और हमने ई-कॉमर्स

00:03:54को शक्ति देने के लिए बहुत सारा कस्टम सॉफ़्टवेयर बनाया था, जैसे कस्टम सब्सक्रिप्शन मैनेजमेंट से लेकर

00:03:59वेयरहाउसिंग और फुलफिलमेंट तक, और इस तरह की तमाम चीजें। और आपकी बहुत सारी समस्याएं

00:04:05वेबहुक्स पर आकर रुक जाती थीं। और यह एक बार-बार होने वाला मजाक जैसा था क्योंकि एक तरफ,

00:04:10मैं महिलाओं के फैशन व्यवसाय को बेचने की कोशिश कर रहा था, ठीक? मैं नाइलोन और ऐसी चीजें बेचने की कोशिश कर रहा था।

00:04:15और दूसरी तरफ, यह था कि वो वेबहुक कहाँ है? उसका क्या हुआ? यह सब बहुत

00:04:18बेमेल लग रहा था। और इसलिए यह बहुत हद तक वहाँ से आया था, बस मैं उन वेबहुक्स के उपभोक्ता के रूप में निराश था

00:04:23कि इस समस्या से निपटने का कोई आसान तरीका नहीं है। और अगर आप ऑनलाइन जाकर सिफारिशें खोजें,

00:04:28तो मेरा मतलब है, वेबहुक्स नए नहीं हैं। दिन के अंत में, यह HTTP अनुरोध हैं। निश्चित रूप से

00:04:33इससे निपटने के तरीके के बारे में पैटर्न स्थापित हैं। लेकिन फिर आप बहुत जल्दी मुसीबत में पड़ जाते हैं।

00:04:38ठीक है। आपको अपने इनजेशन उपभोक्ता चाहिए जो ऑटो-स्केल कर सकें, और फिर आपको SQS जैसी क्यू में डालना होगा।

00:04:43और फिर आपको उपभोक्ताओं का एक सेट तैनात करना होगा जो SQS से उपभोग करेगा। और फिर अगर कुछ गलत हो जाता है,

00:04:46तो यह डेटा क्यू में समाप्त हो जाएगा। और फिर आपको डेटा क्यू से ठीक होने और यह समझने के लिए कुछ स्क्रिप्ट की आवश्यकता होगी

00:04:50कि चीजें वहां क्यों समाप्त हो गईं। और बस ये सभी चिंताएं हैं।

00:04:55और जैसे-जैसे जटिलता बढ़ती है, आप उन ऐतिहासिक इवेंट्स को भी फिर से चलाना (replay) चाहते हैं जो आपने प्राप्त किए हैं।

00:05:00आप यह देखना चाहते हैं कि वेबहुक का पेलोड विशेष रूप से क्या था।

00:05:05और फिर आप विभिन्न वेंडरों के साथ निपटते हैं क्योंकि शायद स्ट्राइप आपको एक यूआई देगा और इंटरकॉम आपको यूआई नहीं देगा।

00:05:09और इसलिए आपको उन अलग-अलग quirks से निपटना पड़ता है। और इसलिए यह बहुत हद तक उस निराशा से पैदा हुआ था और

00:05:14बस यही कि इसका कोई समाधान क्यों नहीं था, है ना? और पहले मैं इसे बहुत अधिक

00:05:18अवलोकन (observability) के नजरिए से देख रहा था और यह वास्तव में काम नहीं किया। जो हिस्सा मैं थोड़ा भूल गया हूँ वह यह है कि अवलोकन

00:05:22इसका केवल एक हिस्सा है। अंततः मेरे पास एक कहावत है, मैं वेबहुक को इवेंट-संचालित आर्किटेक्चर की

00:05:26प्रवेश दवा (gateway drug) कहता हूँ। और इसका कारण यह है, और यही कारण है कि मैं

00:05:31वेबहुक के बजाय इवेंट शब्द पर जोर देना पसंद करता हूँ, कि हर वेबहुक के पीछे एक इवेंट होता है और

00:05:35अब इवेंट-संचालित आर्किटेक्चर प्रतिमान (paradigms) हैं जो उस वेबहुक के साथ पैक होकर आते हैं, है ना? और इसलिए हर बार जब आप

00:05:41किसी गंभीर स्तर या महत्वपूर्ण उपयोग के मामलों के लिए वेबहुक प्राप्त करते हैं, तो अब आपको

00:05:47इन-पोटेंसी (idempotency), ऑर्डरिंग, डिलीवरी गारंटी और उस प्रकार की सभी चुनौतियों के बारे में सोचना होगा

00:05:51जो आपके पास तब आती हैं जब आप एसिंक्रोनस इवेंट-संचालित प्रोग्रामिंग प्रतिमान के साथ निपटना शुरू करते हैं।

00:05:56और इसलिए वास्तव में हमने जो कुछ भी बनाया वह अंततः एक पूर्ण कतार (queue) बनाने में विकसित हुआ।

00:06:01तो यह इंटरऑपरेबिलिटी है कि आप सुनिश्चित हैं कि हम इवेंट्स से निपट रहे हैं,

00:06:07लेकिन फिर उस तरह के सभी शब्द इवेंट्स और पब सब सिस्टम से निपटने के बारे में अधिक हैं।

00:06:14और हम कतारों को फिर से ईजाद (reinvent) करने की कोशिश करने वाली जगह से नहीं आए थे। मुझे लगता है कि हम कुछ

00:06:19वास्तव में अच्छे विचारों पर ठोकर खा गए। और एक बात जो हम अब देख रहे हैं वह यह है कि लोग

00:06:25अपने स्टैक से पब सब या SQS को स्वैप करने के लिए डेक पर जा रहे हैं, जो

00:06:29मेरे लिए थोड़ा दिमाग घुमाने वाला है क्योंकि हम आपका वीपीसी (VPC) नहीं चलाते। मुझे लगता है कि

00:06:33इसमें बहुत सारी समस्याएं हैं, शायद रोड मैप में। लेकिन बात यह है,

00:06:38मुझे लगता है कि इवेंट-संचालित आर्किटेक्चर के आसपास बहुत सारे शब्दार्थ (semantics) हैं जिनके लोग आदी हो गए हैं

00:06:43और कोई वास्तव में सवाल नहीं करेगा। और यह है, हम फिर से डेड लेटर क्यू (dead letter queues) क्यों बना रहे हैं?

00:06:48इसमें क्या गलत है? क्योंकि मैं किसी ऐसे व्यक्ति को नहीं जानता जो सोचता है कि डेड लेटर क्यू

00:06:53आपकी कतारों में त्रुटियों से निपटने के लिए एक सुविधाजनक शब्दार्थ है, है ना? तो वैसे, और मुझे खुशी है

00:06:57कि शायद उनमें से कुछ चीजों को स्पर्श करूँ क्योंकि वहाँ कुछ मजबूत राय हैं।

00:07:05मुझे नहीं पता कि आप लोग पब सब और इवेंट-संचालित आर्किटेक्चर के कितने बड़े जानकार हैं। मैं आपको ज्यादा गहराई में नहीं ले जाना चाहता।

00:07:09मुझे लगता है कि हाँ, डेड लेटर क्यू और उन सभी चीजों के बारे में मेरी समझ बहुत बहुत कम है।

00:07:13जैसे आज मैं जो कुछ चीजें सुन रहा हूँ, उन्हें मैं पहली बार सुन रहा हूँ।

00:07:19हाँ, हाँ। मैं कहने वाला था कि मेरी समझ भी काफी सतही है, लेकिन मैंने वेबहुक्स के साथ

00:07:25काफी काम किया है और आपके द्वारा बताई गई कुछ समस्याओं से निपटा है। और मुझे लगता है कि, और आप लोग

00:07:29इस वेबहुक्स, इवेंट-संचालित आर्किटेक्चर के लिए प्रवेश दवा है वाली बात को साबित कर रहे हैं,

00:07:35क्योंकि मुझे यकीन है कि आपकी पृष्ठभूमि के डेवलपर्स के लिए, वेबहुक्स

00:07:40शायद पहला अनुभव है जो आपने किया है, रुको, यह एसिंक्रोनस है। मैं इससे कैसे निपटूँ?

00:07:48और मुझे लगता है कि यह पूरा सीखने का कर्व है, है ना? यह क्लासिक हिमशैल (iceberg) की तरह है जहाँ

00:07:53ओह, आपके पास HTTP अनुरोध है जो अंदर आता है और फिर बाकी का हिमशैल

00:07:57पानी के पीछे है, है ना? और मुझे लगता है कि मैं जो करने की कोशिश कर रहा हूँ,

00:08:01वह उस स्तर का डीएक्स (DX) लाना है जो वास्तव में उस स्थान पर हासिल नहीं हुआ है ताकि

00:08:06आपको वास्तव में हिमशैल के बाकी हिस्सों का पता लगाने की आवश्यकता न हो, है ना? कुछ चीजें हैं जो थोड़ी

00:08:12अनिवार्य हैं, मैं इसे गलत तरीके से प्रस्तुत नहीं करना चाहता। मुझे लगता है कि एक बार जब आप

00:08:17उन प्रकार की समस्याओं के साथ काम करना शुरू करते हैं, तो आपको इन-पोटेंसी की अच्छी समझ होनी चाहिए,

00:08:21उदाहरण के लिए, आपको ऑर्डरिंग गारंटी की अच्छी समझ होनी चाहिए। इसलिए

00:08:26ऐसा नहीं है कि आप हर समस्या को हल कर सकते हैं। मुझे लगता है कि दिन के अंत में आप अभी भी इवेंट्स के साथ निपट रहे हैं।

00:08:32लेकिन मुझे लगता है कि बहुत सारे शब्दार्थ और जटिलता मुख्य रूप से

00:08:37पूरी तरह से सोचे गए टूल्स न होने से आ रही है, न कि उस समस्या क्षेत्र से जुड़ी वास्तविक जटिलता से।

00:08:40तो मुझे लगता है कि अभी हम दो प्रकार के ग्राहकों की सेवा कर रहे हैं, हम उन ग्राहकों की सेवा कर रहे हैं

00:08:45जो समस्या को गहराई से जानते हैं और

00:08:49अपने मौजूदा काफ्का सेटअप के आसपास समाधान इंजीनियरिंग करेंगे। और फिर,

00:08:53हम उन्हें उन नए शब्दार्थों में से कुछ के बारे में बताते हैं, और वे वास्तव में इससे उत्साहित हैं। यह एक श्रेणी है।

00:08:58लेकिन दूसरी श्रेणी यह है कि मैं वास्तव में इनमें से कुछ भी नहीं सीखना चाहता। और मूल रूप से मैं इस पूरी चीज को

00:09:05किनारे करने की कोशिश करता हूँ। ठीक है। तो हम उन दो प्रोफाइलों में से बहुत सारे देखते हैं।

00:09:13क्या यह भी एक कारण है कि आपने इस टूल आउटपोस्ट को ओपन सोर्स किया है ताकि डेवलपर्स के लिए

00:09:18शुरू करना आसान हो? कुछ मायनों में। दूसरा तरीका यह है कि हमें पैसे कमाने के लिए आउटपोस्ट की जरूरत नहीं है।

00:09:23ठीक है। और इसलिए हम ऐसे थे, मुझे लगता है कि हमें इसे ओपन सोर्स कर देना चाहिए। हाँ। यह सिर्फ है,

00:09:28मुझे पता है कि हमारे YouTube दर्शकों को नए ओपन सोर्स टूल्स के बारे में जानना बहुत पसंद है। इसीलिए

00:09:31मैंने उस बारे में पूछने के लिए कहा। लेकिन मैं थोड़ा पछताता हूँ कि शुरुआती दिनों में

00:09:36ओपन सोर्स-फर्स्ट दृष्टिकोण नहीं अपनाया। और मुझे लगता है कि बहुत सारी चीजें हैं कि आप अपना सॉफ़्टवेयर कैसे बनाते हैं,

00:09:41जो क्लोज्ड सोर्स बनाम ओपन सोर्स के लिए निर्माण करने पर बहुत अलग होता है। लेकिन ओपन सोर्स के फैसले पर,

00:09:47मुझे लगता है कि आप जो देख रहे हैं, वेंचर-बैक्ड स्टार्टअप्स और उस तरह की चीजों के साथ,

00:09:53वह यह है कि आप उन नकली ओपन सोर्स के साथ समाप्त होते हैं, ठीक? यह ओपन सोर्स जैसा है, लेकिन या तो यह ओपन कोर है या

00:10:01मुझे पता है कि हमारे YouTube दर्शक नए ओपन सोर्स टूल्स के बारे में जानना वाकई पसंद करते हैं। इसीलिए

00:10:07री-लाइसेंस करना पड़ता है। ठीक। और मुझे लगता है, उस बात ने मुझे आउटपोस्ट और ओपन सोर्स के लिए वास्तव में उत्साहित किया

00:10:13कि मुझे लगा कि हमारे पास सही प्रोत्साहन रखने का अवसर है। अब, शायद हम व्यवसाय के बारे में सोचने के तरीके की गहराई में जा सकते हैं।

00:10:18लेकिन मेरे दिमाग में, जो लोग उपभोक्ता पक्ष पर वेबहुक्स प्राप्त करते हैं, उनकी संख्या वेबहुक्स भेजने वाले लोगों की तुलना में

00:10:21कम से कम दो से तीन गुना अधिक है, ठीक? क्योंकि अगर मैं वेबहुक्स भेजता हूँ, तो मैं इसे अपने सभी ग्राहकों को भेज रहा हूँ,

00:10:26और मेरे ग्राहक 10 हो सकते हैं, या यदि आप शुरुआत कर रहे हैं तो 100, 1000, 2 मिलियन हो सकते हैं।

00:10:30और इसलिए, उपभोक्ता पक्ष में निश्चित रूप से बहुत अधिक लोग हैं। और इसलिए जब मैं इसे एक उद्यमी के दृष्टिकोण से

00:10:34सोचता हूँ, तो मैं उपभोक्ता पक्ष पर जोर देने के व्यवसाय के बारे में अधिक उत्साहित हूँ। ठीक है। लेकिन मुझे लगता है कि

00:10:39हमने जो महसूस किया वह यह है कि अच्छे उत्पादकों के बिना आपके पास उपभोक्ता नहीं होते। और मुझे लगता है कि

00:10:44सामान्य तौर पर उन ऐप्स में वेबहुक्स की मांग बढ़ती जा रही है जिन्हें आप विकसित करते हैं। और इसलिए, अधिक लोग

00:10:49इसे पेश करना चाहते हैं और ई-डीएक्स (EDX) और ओवरहेड से नहीं गुजरना चाहते। लेकिन मेरे नजरिए से, वेबहुक्स भेजना

00:10:54सिर्फ एक सरल समस्या है, क्योंकि आप मापदंडों को नियंत्रित करते हैं, जबकि प्राप्त करने वाले पक्ष पर, आप नहीं करते, वेंडर तय करता है कि मापदंड क्या हैं।

00:10:59तो यह सरल तो नहीं है, लेकिन,

00:11:03निश्चित रूप से ऐसे कई तरीके हैं जिनसे आप इसे गलत कर सकते हैं। लेकिन समस्या क्षेत्र के मामले में,

00:11:09यह निश्चित रूप से निर्माता पक्ष पर उपभोक्ता पक्ष की तुलना में अधिक सीमित है। और दूसरा, हमारा काम

00:11:13इवेंट्स के उत्पादन को प्रोत्साहित करना है। और वह चीज है जिसे हम अंततः परवाह करते हैं क्योंकि हम चाहते हैं कि अधिक लोग

00:11:17शुरुआत में 100, जैसे 1000, 20 लाख। सही। और इसलिए, अनिवार्य रूप से, उपभोक्ता पक्ष पर बस बहुत अधिक लोग हैं।

00:11:24जहाँ हम वास्तव में कह सकते हैं, देखो, यदि आप आउटपोस्ट का उपयोग करने जा रहे हैं, चाहे आप इसे ओपन सोर्स करें या,

00:11:28या आप इसे हुकडेक के साथ मैनेज्ड संस्करण पर तैनात करें, यह हमारे लिए कोई मायने नहीं रखता। हम

00:11:33किसी भी तरह से व्यावसायिक लक्ष्य को पूरा कर रहे हैं। ठीक है। और इसलिए उस संरेखण प्रोत्साहन ने मुझे वास्तव में

00:11:37उत्साहित किया। और मुझे लगता है कि हमने कुछ चीजें कीं, पहले, हमने ओपन सोर्स को

00:11:42मैनेज्ड संस्करण बनाने पर विचार करने से पहले ही जारी कर दिया। जब हमने ओपन सोर्स बनाया था,

00:11:46तब मैनेज्ड संस्करण बनाने की कोई योजना नहीं थी। और ओपन सोर्स प्रोजेक्ट लगभग दो साल पहले

00:11:51प्रकाशित किया गया था। इसलिए हमें लगभग दो साल लग गए इससे पहले कि पर्याप्त लोग मैनेज्ड संस्करण मांग रहे थे,

00:11:57और हमने इसे बनाया। तो वह एक हिस्सा है। और दूसरा हिस्सा,

00:12:02मैनेज्ड संस्करण भी उसी डॉकर बिल्ड को चलाता है जो ओपन सोर्स से डॉकर हब पर प्रकाशित होता है,

00:12:06यह सही मायनों में निर्माण करता है कि हमारे पास कोई निजी फोर्क नहीं है। हम ओपन सोर्स के बाहर सुविधाएँ पैक नहीं कर रहे हैं।

00:12:10हम वास्तव में वही डॉकर बिल्ड चला रहे हैं। और इसलिए आपके लिए सवाल यह नहीं है कि,

00:12:15ओह, क्या यह दोनों संस्करणों में X या Y सुविधा प्रदान करता है? यह सचमुच सिर्फ यह है कि क्या आप इसे तैनात करना चाहते हैं,

00:12:19और उससे जुड़ी परिचालन संबंधी कठिनाइयों का ध्यान रखना चाहते हैं? या क्या आप किसी और को ऐसा करने के लिए भुगतान करना चाहते हैं?

00:12:23ठीक है। और मुझे नहीं लगता कि इसका कोई सही या गलत जवाब है। यह हर व्यवसाय या स्तर के

00:12:29आराम या स्टैक, उनकी अनुपालन आवश्यकताओं, आप जो भी नाम दें, पर निर्भर करता है। ठीक है। लेकिन उस वजह से,

00:12:35मुझे लगता है कि हम उस प्रोजेक्ट के साथ ओपन सोर्स समुदाय के लिए अच्छा योगदान दे सकते हैं। और हाँ,

00:12:40मैं इस पर काम करके बहुत खुश हूँ क्योंकि यह पहला बड़ा ओपन सोर्स प्रोजेक्ट है

00:12:44जिसमें मैं शामिल हूँ, एक मुख्य मेंटेनर के रूप में। और इसलिए, हाँ, नहीं, यह अच्छा रहा है।

00:12:48अब जब क्लाउड कोड और ऐसी चीजें मौजूद हैं, तो आपने ओपन सोर्स की दुनिया को कैसा पाया है?

00:12:52क्या आपके पास बहुत सारे पीआर (PRs) और सुरक्षा कमजोरियाँ आई हैं जो वास्तविक नहीं हैं या इसे प्रबंधित करना ठीक रहा है?

00:12:57अम, देखो, मुझे नहीं लगता कि हम उस पैमाने पर हैं जहाँ मैं इस बारे में बात कर सकूँ कि दूसरे लोग क्या अनुभव कर रहे हैं।

00:13:03तो मैं निश्चित रूप से स्थिति को गलत तरीके से प्रस्तुत नहीं करना चाहता क्योंकि बहुत से लोगों के लिए यह निश्चित रूप से बुरा लग रहा है।

00:13:08मैं यह कहूँगा कि मैं गुणवत्ता और योगदान से हैरान हूँ, लेकिन हमने निश्चित रूप से ऐसे योगदान भी देखे हैं जहाँ यह एक

00:13:13विशिष्ट पीआर है, मुझे लगता है कि यह अभी भी रेपो पर खुला है, जो क्लाउडफ्लेयर क्यू को डेस्टिनेशन के रूप में जोड़ना है।

00:13:19क्योंकि सतह पर, विवरण पीआर और उस तरह की चीजों पर अच्छा लगता है। और फिर जब आप वास्तव में कोड के माध्यम से खोदते हैं,

00:13:23तो यह पूरी तरह से मनगढ़ंत क्लाउडफ्लेयर एपीआई का उपयोग कर रहा है।

00:13:29और उन्होंने इसे दोबारा जांचा भी नहीं। स्पष्ट रूप से जिस व्यक्ति ने पीआर खोला, उसने इसे चलाने की कोशिश भी नहीं की।

00:13:34ठीक है। और अब बोझ हम पर है कि, ठीक है, अब यह खुला पीआर है, क्योंकि जाहिर है मुझे इस बात की चिंता है कि

00:13:38हम उन लोगों को प्रोत्साहित नहीं करना चाहते जिनसे हम प्रतिस्पर्धा कर सकते हैं।

00:13:44इसलिए, मुझे लगता है कि हमें क्लाउडफ्लेयर क्यू जोड़ना चाहिए, लेकिन साथ ही, यह बंद रोडमैप पर था,

00:13:51और किसी ने इसके अलावा अन्य लोगों ने इसके लिए नहीं कहा। ठीक है। और अब यह इस अजीब स्थिति में है

00:13:55कि अगर आप इसे बंद करते हैं, तो आप ऐसे दिखते हैं कि आप उन लोगों का समर्थन नहीं करना चाहते जिन्हें प्रतिस्पर्धी माना जा सकता है। ठीक है।

00:14:01लेकिन क्या आप वास्तव में संसाधनों को समर्पित करते हैं और अपने रोडमैप को आगे बढ़ाते हैं,

00:14:05और यह सुनिश्चित करते हैं कि आप इसे सही ढंग से लागू करें? ठीक है। तो यह उन स्थितियों के साथ थोड़ा कैच-22 रहा है।

00:14:09अम, लेकिन मैं अब तक महसूस करता हूँ कि यह एक बहुत अच्छा अनुभव रहा है

00:14:14विशेष रूप से क्योंकि हम वही बिल्ड का उपयोग करते हैं। एक चीज जो हमने की है, वह यह है कि जब भी

00:14:20ग्राहक प्रतिक्रिया के लिए पहुंचते हैं या वे हमसे विशिष्ट सुविधाओं के बारे में बात करते हैं,

00:14:25हम गेटअप पर मुद्दे खोलते हैं, या हम मौजूदा पीआर, मौजूदा मुद्दों और उस तरह की चीजों की ओर इशारा करते हैं।

00:14:30और हम यह सुनिश्चित करते हैं कि लोगों को हमेशा पता चले कि रेपो वहां है

00:14:34और आप जा सकते हैं और योगदान कर सकते हैं। और वास्तव में उस बिंदु तक, हमारे पास कई मैनेज्ड उपयोगकर्ता हैं

00:14:40जिन्होंने योगदान दिया है और मूल रूप से अपनी खुद की सुविधाएँ लागू की हैं।

00:14:44ठीक है। और मुझे लगता है कि इसने उन प्रकार के वास्तविक उपयोग के मामलों के लिए प्रवेश की बाधा को बहुत कम कर दिया है।

00:14:48क्योंकि आप जानते हैं, ऐतिहासिक रूप से गो (Go) में प्रोजेक्ट्स, हमारे अधिकांश उपयोगकर्ता गो डेवलपर नहीं हैं।

00:14:52ठीक है। हम बहुत सारे पायथन, टाइपस्क्रिप्ट, नोड जेएस देखते हैं, इसलिए गो के लिए प्रवेश की बाधा है। और फिर

00:14:56योगदान करने के लिए एक नई परियोजना सीखना गैर-तुच्छ (non-trivial) है। ठीक है। और इसलिए

00:15:02मुझे लगता है कि इसने प्रवेश की उस बाधा को काफी हद तक कम कर दिया है। और वह वास्तव में अच्छा है।

00:15:08क्योंकि अब यदि एक उपयोगकर्ता के रूप में आप इससे संघर्ष कर रहे हैं, कि यह चीज वास्तव में मुझे परेशान करती है।

00:15:12और प्लस एक मेंटेनर के रूप में, यह एक मजबूत संकेत है कि यह सुविधा बनाने लायक है।

00:15:15कोई अपने रास्ते से हटकर इसे लागू करने में अपना समय खर्च करता है।

00:15:19जैसे यह एक संकेत है कि यह वास्तव में मायने रखता है। ठीक है। स्टॉक रैंकिंग के मामले में,

00:15:24क्या सबसे महत्वपूर्ण है। इसलिए मुझे लगता है कि प्रवेश की बाधा को कम करना वास्तव में अच्छा है।

00:15:28और इसलिए मुझे लगता है कि यदि आप स्पैम और उस तरह की चीजों के फ्लडगेट से बाहर निकलने का प्रबंधन कर सकते हैं,

00:15:33तो इसके बहुत सारे सकारात्मक पहलू हैं।

00:15:37लैंडिंग पेज में, एक चीज जो वास्तव में मुझे प्रभावित कर गई, वह थी वर्सेल (Vercel) के सीईओ की प्रशंसापत्र।

00:15:43तो वर्सेल वास्तव में एक उत्पाद के रूप में हुकडेक का उपयोग कर रहा है।

00:15:48कि यदि आप उस विशिष्ट उद्धरण को पढ़ते हैं, तो यह इसकी सिफारिश भी कर रहा है।

00:15:53ओह, ठीक है।

00:15:58एक तरह से वर्सेल उपयोगकर्ता और उस तरह की चीजें।

00:16:03और आप जाकर योगदान दे सकते हैं। और सच कहूं तो, हमने कई तरह के

00:16:07प्रबंधित उपयोगकर्ताओं को योगदान देते हुए और मूल रूप से अपने फीचर्स को लागू करते हुए देखा है।

00:16:13बिल्कुल। और मुझे लगता है कि इसने इस तरह के योगदानों के लिए

00:16:18प्रवेश की बाधा को बहुत कम कर दिया है। क्योंकि आप जानते हैं, ऐतिहासिक रूप से Go में जो प्रोजेक्ट्स हैं,

00:16:24हमारे अधिकांश उपयोगकर्ता शायद शुरुआत में Go डेवलपर्स नहीं होते। सही। जैसे हम देखते हैं बहुत सारे

00:16:28Python, TypeScript, जाहिर तौर पर Node.js, और इसलिए Go के लिए प्रवेश की एक बाधा है। और फिर

00:16:35योगदान करने के लिए किसी नए प्रोजेक्ट को सीखना भी कोई मामूली बात नहीं है। सही। और इसलिए

00:16:39मुझे लगता है कि इसने उस प्रवेश बाधा को काफी हद तक कम कर दिया है। और यह बहुत अच्छी बात है।

00:16:42क्योंकि अब यदि आप एक उपयोगकर्ता के रूप में इस जरूरत के साथ आते हैं कि, ओह, यह चीज वास्तव में मुझे परेशान करती है।

00:16:48और साथ ही, एक मेंटेनर के रूप में, यह एक बहुत मजबूत संकेत है कि यह फीचर बनाने लायक है।

00:16:53कोई व्यक्ति अपनी मेहनत की कमाई और टोकन्स खर्च करके इसे लागू करने के लिए अपना समय निकालता है।

00:16:58यह इस बात का संकेत है कि, ठीक है, यह वास्तव में मायने रखता है। प्राथमिकता तय करने के लिहाज से,

00:17:02कि क्या सबसे महत्वपूर्ण है। तो मुझे लगता है कि प्रवेश की बाधा को कम करना वाकई बहुत अच्छा है।

00:17:07और इसलिए मुझे लगता है कि यदि आप स्पैम और उस तरह की सभी चीजों की बाढ़ से बाहर निकल सकते हैं,

00:17:12तो इसके बहुत सारे सकारात्मक पहलू हैं।

00:17:14लैंडिंग पेज पर, एक चीज जिसने मेरा ध्यान आकर्षित किया, वह Vercel के CEO का एक प्रशंसापत्र (testimonial) था।

00:17:21तो Vercel वास्तव में एक उत्पाद के रूप में हुक डेक (Hookdeck) का उपयोग कर रहा है।

00:17:25कि यदि आप उस विशिष्ट उद्धरण को पढ़ें, तो वह इसकी अनुशंसा भी कर रहा है।

00:17:29ओह, ठीक है।

00:17:29एक तरह से Vercel उपयोगकर्ता और उस तरह की चीजें।

00:17:32हम्म, लेकिन वहां वास्तव में एक मजेदार कहानी है।

00:17:35क्योंकि गुइलेर्मो (Guillermo) ने शनिवार की रात इसके बारे में ट्वीट किया था।

00:17:39मुझे बिल्कुल अंदाजा नहीं था कि यह होने वाला है।

00:17:40गुइलेर्मो के साथ मेरा पहले से कोई संबंध नहीं है, और उस तरह की चीजें।

00:17:45और यह समुदाय के कुछ लोगों के प्रभाव के बारे में बता सकता है।

00:17:48क्योंकि उससे हमें जो साइन अप और जागरूकता मिली, वह

00:17:53पागल कर देने वाली थी।

00:17:54हम्म, तब से गुइलेर्मो और मैं यहाँ और वहाँ संपर्क में रहे हैं।

00:17:57और हमेशा अच्छी बातचीत हुई है और सब कुछ।

00:17:59और यह दिलचस्प है।

00:18:00क्योंकि, उह, वास्तव में यदि आप Vercel जैसी कंपनी को देखें, तो गुइलेर्मो मुझे एक बात बता रहे थे

00:18:04वह यह है कि वह अब वास्तव में WebEx का उपयोग करने वाले अधिक लोगों को देख रहे हैं।

00:18:07और उनका मानना था कि यह मुख्य रूप से LLM विकल्पों द्वारा संचालित है।

00:18:12और यह डेटा के लिए नए उपयोग के मामले (use cases) बना रहा है।

00:18:15जिसकी आप पहले परवाह नहीं करते थे।

00:18:18जैसे अपने ग्राहक सहायता सिस्टम के बारे में सोचें।

00:18:20उदाहरण के लिए, आपके पास एजेंट और इंसान हैं जो वहां मौजूद हैं।

00:18:23और वहां नए टिकट इवेंट के साथ कुछ भी करने का बहुत कम कारण है।

00:18:29और उस तरह की चीजें।

00:18:30क्योंकि वैसे भी, यह वही इंसान है जो जाकर उस संदेश का जवाब देगा।

00:18:34लेकिन अब हम स्पष्ट रूप से ऐसी दुनिया में हैं जहां यह पूरी तरह से बदल रहा है।

00:18:37और जब आप इंसानों से एजेंटों को ट्रिगर करने की ओर बढ़ते हैं, तो एजेंटों को क्या ट्रिगर करता है, वे इवेंट्स हैं।

00:18:42सही।

00:18:42और अचानक अब आप अपने ग्राहक सहायता सिस्टम, अपने मार्केटिंग टूल और अपने बाकी चीजों से आने वाले इवेंट्स की परवाह करते हैं।

00:18:46और इसी तरह।

00:18:48सही।

00:18:48और इसलिए, यह निश्चित रूप से कुछ ऐसा है जो मुझे लगता है कि प्लेटफॉर्म के रूप में वे देख रहे हैं।

00:18:54और यह हमारे लिए दिलचस्प चर्चा के बिंदु रहे हैं, स्पष्ट रूप से।

00:18:57लेकिन हां, यह Vercel है, विशेष रूप से यह स्पष्ट करने के लिए कि वे सीधे उपयोगकर्ता नहीं हैं।

00:19:01मेरा मतलब है, मुझे यकीन है कि बहुत सारे डेवलपर्स Vercel में आपके स्थानीय CLI और उस तरह की चीजों का उपयोग करते हैं,

00:19:05लेकिन, उह, हां।

00:19:06तो हुक डेक (Hookdeck) का उपयोग करने वाले किसी व्यक्ति के लिए विशिष्ट ग्राहक कौन है?

00:19:10जैसे अगर मेरे पास, मुझे नहीं पता, एक छोटे आकार की टी-शर्ट की ई-कॉमर्स दुकान या कुछ और हो, तो मैं हुक डेक का उपयोग कैसे करूंगा?

00:19:15और क्या इस मामले में इसका उपयोग करना समझदारी होगी?

00:19:17शायद नहीं।

00:19:19ठीक है।

00:19:21ठीक है।

00:19:22आप मुझसे एक तरह से दस लाख डॉलर का सवाल पूछ रहे हैं, इस अर्थ में कि मुझे लगता है कि यह

00:19:26कुछ ऐसा है जिससे हम हमेशा संघर्ष करते रहे हैं, इस अर्थ में कि WebEx का उपयोग करने के कारणों का दायरा

00:19:32या WebEx पर निर्भरता बहुत अधिक है।

00:19:35जैसे हमें स्ट्राइप्स (Stripes) और शॉपिफाई (Shopify) जैसे सामान्य संदिग्धों से WebEx मिलता है, लेकिन हमारे पास

00:19:40ऑस्ट्रेलियाई दूरसंचार प्रदाताओं और यूके क्लियरिंगहाउस जैसी जगहों से भी WebEx आ रहा है।

00:19:47और वास्तव में EVE ऑनलाइन गेम से भी काफी मात्रा में आ रहा है।

00:19:50ऐसा लगता है कि लोगों का एक समुदाय अभी भी इसे खेल रहा है, जैसे कोनन,

00:19:55द बारबेरियन गेम, जो 15 साल पहले का था या कुछ और।

00:19:58और वे WebEx पर भी बहुत अधिक निर्भर हैं।

00:20:00मुझसे मत पूछो कि क्यों।

00:20:00सही।

00:20:01लेकिन मुद्दा यह है कि यहाँ एक ऐसा दायरा है जिसे परिभाषित करना बहुत कठिन है कि यह हमारा ग्राहक है।

00:20:06सही।

00:20:08सही।

00:20:09और इसलिए जब हम उन लोगों को देखते हैं जो इसका उपयोग करते हैं, तो कोई एक उपयोग का मामला

00:20:13या समूह नहीं है।

00:20:14जो शायद 10% से अधिक हो।

00:20:16लेकिन आपके ई-कॉमर्स उपयोग के मामले या उदाहरण पर आते हैं।

00:20:19तो सबसे पहले, एक छोटी टी-शर्ट दुकान ने शायद कस्टम ऐप्स नहीं बनाए हैं

00:20:25और उस तरह की चीजें जिन पर यह निर्भर करेगा।

00:20:27लेकिन उन्होंने लगभग निश्चित रूप से ऐप्स इंस्टॉल किए हैं।

00:20:30जैसे उदाहरण के लिए, समीक्षाएं एकत्र करने के लिए एक ऐप, बैक-इन-स्टॉक सूचनाओं के लिए एक ऐप,

00:20:35और इन्वेंट्री प्रबंधन के लिए एक ऐप, और उनके 3PL के साथ एक ऐप।

00:20:39और उन सभी लोगों के लिए, वे लगभग विशेष रूप से WebEx पर निर्भर हैं।

00:20:43सही।

00:20:43तो अगर मैं बैक-इन-स्टॉक अधिसूचना भेजना चाहता हूं, तो मैं क्या कर रहा हूं, मैं Shopify स्टोर में सभी स्टॉक

00:20:48अपडेट्स को उनके WebEx के माध्यम से सुन रहा हूं।

00:20:50और फिर जैसे ही कोई उत्पाद जो पहले स्टॉक से बाहर था, अब स्टॉक में है,

00:20:53मैं ऐसा हूँ, ठीक है, ईमेल भेजना होगा।

00:20:54सही।

00:20:55और इसलिए मूल रूप से वे जो कुछ भी इंस्टॉल करने वाले हैं या जोड़ने वाले हैं, वह पर्दे के पीछे WebEx पर निर्भर करेगा।

00:20:59और इसलिए यह निश्चित रूप से एक बड़ा वर्ग है।

00:21:00लोग ऐप्स बना रहे हैं और यह सिर्फ Shopify नहीं है, स्पष्ट रूप से स्ट्राइप जैसे,

00:21:02जिसका एक बड़ा ऐप्स मार्केटप्लेस है।

00:21:07और इनमें से बहुत सारे ग्राहक हैं, उस तरह की चीजें।

00:21:09दूसरी चीज जो हम देखेंगे वह बड़ी दुकानें हैं।

00:21:11जैसे जिम शार्क, गुड अमेरिकन्स, रोग और उस तरह की चीजें।

00:21:14जहां उनकी अपनी तकनीकी टीमें हैं और वे कस्टम ऐप्स बना रहे हैं।

00:21:19वे अपने सिस्टम इंटीग्रेशन के लिए कस्टम ऐप्स बना रहे हैं, अक्सर ऑर्डर को 3PL के साथ सिंक करने,

00:21:22नोट जोड़ने के क्रम के संदर्भ में बहुत परिचालन (operational) होते हैं।

00:21:28और शायद ग्राहक-विशिष्ट प्राथमिकताएं हैं जिन्हें 3PL तक पहुंचने से पहले उस डेटा में जोड़ा जाना चाहिए, उस तरह की चीजें।

00:21:34सही।

00:21:39और कुछ उपयोगकर्ता अनुभवों को सशक्त बनाने जा रहा है,

00:21:41जैसे कस्टम

00:21:41सदस्यता प्रबंधन या विशिष्ट ईमेल जो आप भेजना चाहते हैं जब कोई उपहार कार्ड खरीदता है

00:21:46और उसे अपने दोस्त को भेजना चाहता है, और वह सब कुछ।

00:21:51और इसलिए हम जो देखते हैं, छोटी Shopify दुकान शायद वह है जिसे आप चुन सकते थे,

00:21:55जिसके बारे में हम WebEx का उपयोग करते हुए बहुत सारे लोगों को नहीं देखते हैं, लेकिन लगभग हर जगह आप उस खंड में लक्ष्य रखते हैं,

00:21:59आप एक ऐसी कंपनी पर उतरेंगे जो WebEx का उपयोग करती है।

00:22:04उचित है।

00:22:08उचित है।

00:22:09ठीक है।

00:22:10ठीक है।

00:22:11यह AWS EventBridge जैसी किसी चीज़ की तुलना में कैसा है?

00:22:14खैर, जाहिर है हम सभी AWS को जानते हैं, मेरा मतलब है बेहतर स्टॉक अधिक या कम वही मामला बना रहा है, है ना?

00:22:17हां।

00:22:19और इसलिए जो कुछ भी आप लोग अपने अद्वितीय बिक्री बिंदु के रूप में क्लाउड वॉच और अमेज़ॅन ब्लॉग सेवाओं और उस तरह की चीजों के विपरीत कहते हैं, वे बने रहते हैं।

00:22:24बात सही है ना?

00:22:25हाँ।

00:22:26सही।

00:22:31और जाहिर है कि इसका एकीकरण, मुझे लगता है कि AWS की समस्या हमेशा यह है कि आप 20 सेवाओं के साथ समाप्त होते हैं,

00:22:37जिनमें से अधिकांश शायद अब तक नाम भूल गए हैं।

00:22:40और फिर डेटा इस तरह से विरल है और कॉन्फ़िगरेशन पार्सिंग के माध्यम से विरल है और वह सब।

00:22:46सही।

00:22:47तो, तो यह एक बिंदु है।

00:22:47लेकिन मुझे लगता है कि व्यापक बिंदु यह है कि AWS EventBridge वास्तव में किसी के साथ एकीकृत नहीं होता है,

00:22:51हर कोई।

00:22:56तो विक्रेता को AWS EventBridge के साथ एकीकृत होना चाहिए।

00:22:59ऐसे तरीके हैं जिनसे आप API गेटवे और बाकी चीजों के साथ काम कर सकते हैं।

00:23:01लेकिन, उह, तो मुद्दा यह है कि यह AWS इकोसिस्टम के लिए बनाया गया है जहां

00:23:01अधिकांश उपयोग के मामले वास्तव में AWS के आंतरिक इवेंट्स हैं,

00:23:02जैसे कि कोई नई S3 दस्तावेज़ अपलोड की गई थी और उस तरह की चीजें।

00:23:07और फिर तीसरे पक्ष के साथ इंटरऑपरेबिलिटी, हालांकि वे 40 से अधिक का समर्थन करते हैं,

00:23:08जो भी विक्रेता, इस पर मेरा उद्धरण न लें शायद अब अपडेट किया गया हो, लेकिन हजारों नहीं।

00:23:11आप हमेशा उस परिदृश्य में समाप्त होते हैं जहां, ठीक है, शॉपिफाई EventBridge का समर्थन करता है, लेकिन फिर ट्विलियो (Twilio) नहीं करता है।

00:23:16सही।

00:23:23और इसलिए आप उन समस्याओं के साथ समाप्त होते हैं जहां आप वास्तव में एक अज्ञेयवादी समाधान ला सकते हैं

00:23:31और बस हर जगह काम करता है।

00:23:31और इसलिए मुझे लगता है कि यह एक चीज है जिसे हम करने की कोशिश कर रहे हैं, सही।

00:23:36यह हमें इस तरह से बनाना है कि हमें विक्रेता को ऑप्ट-इन करने की या उनके अंत में कुछ भी करने की आवश्यकता न हो।

00:23:40आप हमेशा ऐसी स्थिति में पहुँच जाते हैं जहाँ ठीक है, Shopify तो EventBridge को सपोर्ट करता है, लेकिन फिर जैसे

00:23:45पूरी तरह से HTTP पर काम करता है।

00:23:47और इसलिए विचार यह है कि आप, हम आपको एक URL प्रदान करते हैं और आप अपने मौजूदा वेब URL को

00:23:47उस URL के साथ बदल सकते हैं जो हमने आपको प्रदान किया है।

00:23:51और फिर हुक डेक में, आपका गंतव्य वह होगा जो आपका डेक URL होता।

00:23:52और इसलिए हम उसके बीच एक पुश आधारित कतार (queue) के रूप में काम करते हैं।

00:23:54और इसलिए हमें HTTP के माध्यम से सभी वेब प्राप्त होंगे, और फिर हम उन्हें उस दर पर पुश करेंगे

00:23:59जो आप अपने स्वयं के एंडपॉइंट पर निर्दिष्ट करते हैं।

00:24:02लेकिन इसका मतलब यह है कि आपको अपना कोड फिर से तैनात (redeploy) करने की भी आवश्यकता नहीं है।

00:24:08आप किसी भी क्लाउड पर किसी भी स्टैक पर हो सकते हैं ताकि यह लगभग तुरंत काम कर सके।

00:24:10सही।

00:24:15क्योंकि वास्तव में एकमात्र आवश्यकता दिन के अंत में URL को अपडेट करना है।

00:24:17और यह AWS EventBridge से बहुत दूर है, जो अंतिम विक्रेता लॉक-इन है, विशिष्ट संगतता की आवश्यकता है, केवल AWS इकोसिस्टम में काम करता है।

00:24:22हां।

00:24:25मुझे लगता है कि most event bridge को मैं अन्य बड़े इवेंट गेटवे के रूप में सोचता हूं।

00:24:28हम वास्तव में Azure event grid देख रहे हैं, जो एक प्रतियोगी है, उसने भी कुछ जमीन हासिल की है।

00:24:31और इसलिए जब मैं अपने सबसे सीधे प्रतिद्वंद्वी के बारे में सोचता हूं या वास्तव में प्रेरणा के रूप में,

00:24:34यह वे दो उत्पाद हैं।

00:24:39लेकिन मैं निश्चित रूप से सोचता हूं कि हम जो करने की कोशिश कर रहे हैं उसका दायरा काफी बड़ा है।

00:24:40और कुछ लोगों के लिए, यह एक अच्छी बात है। कुछ लोगों के लिए, यह अच्छी बात नहीं है, सही?

00:24:44और यह AWS EventBridge से काफी अलग है, जो पूरी तरह वेंडर के

00:24:48वे पूरी तरह से AWS इकोसिस्टम में निहित हैं। वे क्लाउड फॉर्मेशन का उपयोग कर रहे हैं।

00:24:53वे सभी सेवाओं से परिचित हैं। वे क्षमताओं को चुनना चाहते हैं।

00:24:53और आप जानते हैं, यह ठीक है।

00:24:58मुझे नहीं लगता कि हमारे पास कभी 100% बाजार हिस्सेदारी होगी।

00:25:04तो वास्तव में, मुझे लगता है कि कुछ प्रतिशत अंक शायद आपको चाहिए।

00:25:10तो हां, मुझे लगता है कि हम यह मामला बनाने की कोशिश कर रहे हैं कि, आप जानते हैं, एस्थेटिक कंपनियों और डेवलपर्स के लिए, यह सही समाधान होने वाला है।

00:25:13और आप जानते हैं, दूसरों के लिए AWS event bridge होने वाला है और यह ठीक है।

00:25:17तो मुझे लगता है कि मैंने पिछले एक साल में गौर किया है कि बड़ी कंपनियों के लिए डाउनटाइम की मात्रा बढ़ रही है।

00:25:18जैसे गिटहब (GitHub) के डाउन होने के ये सभी मेम्स हैं।

00:25:20और मुझे याद है जैसे दो साल पहले जब मैं काम कर रहा था, P99,

00:25:22अगर यह 99.5 या उससे कम हो जाता, तो आप अपनी टीम के साथ गंभीर बातचीत करते।

00:25:24सही, अब यह पाठ्यक्रम का हिस्सा है।

00:25:26हां।

00:25:27और अब लोग गिटहब के इतने लंबे समय तक डाउन रहने के आदी हो गए हैं।

00:25:30तो मैं सोच रहा हूं, हुक डेक (Hookdeck) पर आपके दृष्टिकोण से क्या आप देख रहे हैं कि इस साल पिछले वर्षों की तुलना में बहुत अधिक डाउनटाइम हैं

00:25:31मतलब, मुझे नहीं लगता कि हम कभी 100% मार्केट शेयर हासिल कर पाएंगे।

00:25:34तो असल में, अमेरिका में मुझे लगता है कि बस कुछ प्रतिशत ही काफी है।

00:25:38तो हाँ, मुझे लगता है कि हम यह साबित करने की कोशिश कर रहे हैं कि एस्थेटिक कंपनियों और

00:25:45डेवलपर्स आदि के लिए, यही सही समाधान होने वाला है।

00:25:48और दूसरों के लिए, AWS इवेंट ब्रिज ही होगा और यह ठीक है।

00:25:51तो मैंने पिछले एक साल में जो गौर किया है, वह यह है कि बड़ी कंपनियों के लिए डाउनटाइम

00:25:59की मात्रा बढ़ रही है।

00:26:00जैसे कि GitHub के डाउन होने को लेकर तमाम मीम्स बनते रहते हैं।

00:26:02और मुझे याद है कि दो साल पहले जब मैं काम कर रहा था, तो P99 अगर,

00:26:07अगर यह 99.5 या उससे नीचे गिर जाता, तो आपको अपनी टीम के साथ गंभीर चर्चा करनी पड़ती।

00:26:13कि ऐसा कैसे हो सकता है?

00:26:14सही है, अब यह आम बात हो गई है।

00:26:15अब यह सब चलता रहता है।

00:26:17हाँ।

00:26:17और अब तो लोग GitHub के इतनी देर तक डाउन रहने के आदी हो गए हैं।

00:26:23तो मैं सोच रहा हूँ, आपके नजरिए से क्या आप देख रहे हैं कि इस साल पिछले सालों की तुलना में

00:26:28कहीं ज्यादा डाउनटाइम हो रहे हैं और आप इन चुनौतियों से कैसे निपटते हैं?

00:26:33हाँ, यह दिलचस्प है क्योंकि जाहिर तौर पर यह एक ऐसी बात है जिसे आपको ध्यान में रखना होगा अगर आप

00:26:37GitHub वेबहुक्स (Webhooks) का उपयोग करना विशेष रूप से समस्याग्रस्त है।

00:26:42आपको पता है, अगर आप रेलवे या वर्सेल (Vercel) जैसे प्लेटफॉर्म्स पर लॉग इन करते हैं,

00:26:46तो अक्सर वहां एक छोटा सा बैनर दिख जाता है।

00:26:47जिसमें लिखा होता है कि डिप्लॉयमेंट डाउन हैं क्योंकि GitHub वेबहुक्स काम नहीं कर रहे हैं।

00:26:51GitHub के CTO ने अपनी इंफ्रास्ट्रक्चर स्थिरता को लेकर एक ब्लॉग पोस्ट भी लिखा था।

00:26:58जब हर तरफ मीम्स बन रहे थे, तब उन्होंने स्थिति को संभालने की कोशिश की थी।

00:27:02मुझे नहीं लगता कि इसका कोई खास असर हुआ,

00:27:03लेकिन वो काफी समय तक चर्चा में रहा।

00:27:05उस लेख में स्पष्ट रूप से वेबहुक्स की अस्थिरता को दोषी ठहराया गया था

00:27:09और यह कि कैसे यह MySQL वगैरह पर निर्भर करता है।

00:27:12और इसलिए विचार यह है कि हम आपको अलर्ट भेजेंगे यदि लेटेंसी एक निश्चित

00:27:13मानक विचलन (standard deviation) से बाहर हो जाती है।

00:27:17सही।

00:27:21मुझे लगता है कि शॉपिफाई के मामले में, बेसलाइन लेटेंसी लगभग 4 या 5 सेकंड है।

00:27:23और,

00:27:26मुझे लगता है कि जो चीज़ हम करने की कोशिश कर रहे हैं वह काफी हद तक वही है।

00:27:30और यदि आप इसे देख सकते हैं,

00:27:33तो बहुत से लोग इसका आनंद लेंगे।

00:27:38और आप जानते हैं, मुझे लगता है कि यह एक अच्छा समाधान है।

00:27:41तो उदाहरण के लिए, हमारे पास एक चीज़ है जिसे हम 'डेक रडार' कहते हैं।

00:27:44लेकिन विचार यह है कि हम सभी ग्राहकों से प्राप्त सांख्यिकी को देख सकते हैं और वो सभी

00:27:49वेबेक्स जो हमें डेक के जरिए मिलता है और फिर उससे डिलीवरी लेटेंसी जैसी चीजों की गणना करते हैं

00:27:53कैसी है, किसी वेंडर के लिए P99 डिलीवरी लेटेंसी क्या है, उनका अपटाइम क्या है, आदि।

00:27:58तो उदाहरण के लिए, Shopify के लिए हमारा रडार काफी लोकप्रिय है।

00:28:01मेरे पास इसके लिए कुछ सौ सब्सक्राइबर्स हैं।

00:28:04तो विचार यह है कि यदि लेटेंसी एक निश्चित सीमा से बाहर जाती है, तो हम आपको अलर्ट भेजते हैं,

00:28:09जैसे कि बेसलाइन लेटेंसी का मानक विचलन।

00:28:12सही।

00:28:12मुझे लगता है कि Shopify के मामले में, डिलीवरी के लिए बेसलाइन लेटेंसी

00:28:17लगभग चार या पांच सेकंड है।

00:28:17मुझे लगता है कि यह 10 सेकंड से ऊपर हो जाता है,

00:28:19तो हम एक अलर्ट भेज देंगे।

00:28:20सही।

00:28:22लेकिन विचार यह है कि आप इसे टाइम सीरीज़ डेटा की तरह मॉनिटर कर सकते हैं और देख सकते हैं कि

00:28:26उनकी अपटाइम, न केवल रॉ अपटाइम के संदर्भ में, बल्कि उनकी लेटेंसी प्रोफाइल भी कैसी है

00:28:31सही।

00:28:32और यह निश्चित रूप से कुछ ऐसा है जो आप देखते हैं।

00:28:33और मेरा मतलब है, Shopify की टीम खुद भी इससे पूरी तरह वाकिफ है।

00:28:36लेकिन आप देख सकते हैं कि उन डिलीवरी समय में काफी अंतर होता है।

00:28:41तो, शायद हर दो महीने में एक बार या ऐसा कुछ,

00:28:46लेटेंसी पर एक काफी महत्वपूर्ण घटना होती है।

00:28:49और मुझे लगता है कि यह ऐसी चीज़ है जिसे आप आमतौर पर नहीं देखते हैं।

00:28:51सही।

00:28:52क्योंकि जाहिर है, डाउनटाइम को पहचानना बहुत आसान होता है।

00:28:54आप अपने डेटाडॉग या अपने बेटर स्टैक में जाते हैं।

00:28:57आप लोग इसे फिर से क्या कहते हैं, मेट्रिक उत्पाद?

00:29:01ऑब्जर्वेबिलिटी (अवलोकनीयता)।

00:29:02ऑब्जर्वेबिलिटी, हाँ।

00:29:03तो आप अपने बेटर स्टैक में जाते हैं, जाहिर है कि ऐसी चीजें बनाते हैं।

00:29:05सही।

00:29:06और आप वेबहूक एंडपॉइंट पर एचटीटीपी कॉल्स देखते हैं और वो बस अचानक बंद हो जाती हैं।

00:29:11सही।

00:29:11तो आप जानते हैं, समस्या काफी स्पष्ट है और यह सीधा है।

00:29:14लेकिन अगर लेटेंसी बढ़कर 60 सेकंड हो जाती है, तो यह कुछ ऐसा है जिसे बताना बहुत मुश्किल होगा

00:29:19आपके वास्तविक मेट्रिक्स से।

00:29:22सही।

00:29:23और ऐसा इसलिए है क्योंकि यह लेटेंसी वह है जो आपको इसे प्रोसेस करने में लगती है, जो शायद कुछ ऐसा है

00:29:27जिसे आप ट्रैक कर रहे होंगे, वगैरह।

00:29:28लेकिन यह वेंडर की तरफ से देरी है।

00:29:31लेकिन अब यदि आपके कोड, आपके व्यावसायिक संचालन आदि में कोई नई धारणा है,

00:29:34जो उन घटनाओं की वास्तविक समयबद्धता को मानती है, यदि वे अब 60 सेकंड बाद आ रही हैं,

00:29:39तो यह कई तरह की सूक्ष्म समस्याओं और कोड में गलत धारणाओं को जन्म दे सकता है।

00:29:44तो मुझे लगता है कि यह एक ऐसी जगह है जहाँ शायद हम थोड़ा बेहतर डेटा प्रदान करने के लिए स्थित हैं।

00:29:46और ताकि आप जान सकें कि, ओह, क्या यह मेरी समस्या है या मेरे वेंडर की?

00:29:50सही।

00:29:52कि किसे समस्या हो रही है।

00:29:55सही।

00:29:56मुझे नहीं पता कि मैं अनुभवजन्य रूप से कह सकता हूँ या नहीं कि

00:29:57यह कितना बढ़ा या घटा है।

00:30:03और क्या वे सामान्य संदिग्ध हैं जो बार-बार सामने आते हैं।

00:30:06ये किसी पर उंगली उठाना आसान है।

00:30:08मुझे नहीं पता कि क्या मैं कहूँगा कि यह वास्तव में एक वितरित समस्या है जिसे हम हर समय देखते हैं।

00:30:13मुझे लगता है कि यह विशिष्ट वेंडरों में अधिक केंद्रित होती है।

00:30:16और मुझे लगता है कि जहाँ लोग थोड़ा और फंसते हैं, वह उन डिलीवरी लेटेंसी पर है।

00:30:23दूसरी बात यह भी है कि मुझे लगता है कि लोग मानते हैं कि डिलीवरी लेटेंसी वास्तव में अधिकतर वेंडरों में इससे कम है,

00:30:27क्योंकि हम निश्चित रूप से अधिकांश मामलों में कुछ सेकंड की बात कर रहे हैं, जो इस बात पर निर्भर करता है कि

00:30:31आप इसे कैसे देखते हैं, यह लंबा समय हो सकता है, या नहीं भी हो सकता है।

00:30:34लेकिन मुझे लगता है कि जब मैं यह लेटेंसी चार्ट, उदाहरण के लिए Shopify का, Shopify डेवलपर्स के समूह को दिखाता हूँ,

00:30:40तो उनका पहला रिएक्शन होता है कि 'मुझे इसकी उम्मीद नहीं थी'।

00:30:43सही।

00:30:43तो एक प्रकार से अपेक्षाएं टूटती हैं जो होती है।

00:30:46मैं एक काफी बड़ी ई-कॉमर्स कंपनी के लिए काम करता था और हमारे पास भी यही समस्या थी।

00:30:53लेटेंसी खराब है, लेकिन हर कोई स्पाइडर-मैन मीम की तरह उस टीम पर उंगली उठा रहा था

00:30:58जो इसके लिए जिम्मेदार है।

00:30:59क्योंकि आमतौर पर यह मूल रूप से एक थर्ड-पार्टी वेंडर होता है, जैसा कि आपने कहा।

00:31:05और कभी-कभी आप कुछ नहीं कर सकते।

00:31:07आपको बस इसके साथ काम करना पड़ता है।

00:31:08तो यह अच्छा है।

00:31:09आप वेंडर को दोष देने में भी सावधान रहना चाहते हैं।

00:31:11सही।

00:31:11मुझे लगता है कि यह कुछ ऐसा है और जाहिर है आप जो करते हैं उसके संदर्भ में,

00:31:16यह हमेशा एक आम समस्या होती है।

00:31:18जब भी हमारे पास कोई घटना होती है, तो यह होता है, 'ठीक है, आप वेंडर पर कितना दोष डालते हैं?'

00:31:22लेकिन किसी बिंदु पर, आप जानते हैं, यह भी होता है कि क्या उचित है बनाम क्या उचित नहीं है।

00:31:27और क्या एक fluke है बनाम fluke दुर्घटना नहीं है।

00:31:29उदाहरण के लिए, दूसरे दिन, रेलवे, हमारे कुछ आउटपोस्ट मैनेजमेंट डिप्लॉयमेंट

00:31:34उनकी मूल्य संरचना के कारण रेलवे पर चल रहे हैं।

00:31:36चूंकि हमें ओपन सोर्स जैसा ही संस्करण चलाना पड़ता है, हमने

00:31:40मल्टी-टेनेंट नहीं बनाया है जो ओपन सोर्स में प्रासंगिक नहीं होगा।

00:31:44तो मूल रूप से हम हर एक ग्राहक के लिए वास्तविक डिप्लॉयमेंट करते हैं।

00:31:48सही।

00:31:49और इसलिए फ्री प्लान उपयोगकर्ताओं के लिए, हम रेलवे पर उनके लिए एक इंस्टेंस डिप्लॉय करेंगे,

00:31:52जो सामान्य तौर पर, काफी ठीक काम करता है।

00:31:54लेकिन दूसरे दिन, उनका जीसीपी अकाउंट बंद हो गया और फिर वे छह घंटे या कुछ समय के लिए बंद थे।

00:31:59सही।

00:31:59और फिर यह है कि, 'ठीक है', क्या आप इसके बारे में बात नहीं कर सकते...

00:31:59तो फिर यह होता है, ठीक है, क्या आप इसके बारे में अपने इसमें बात नहीं कर सकते

00:32:06दोष टालने के बारे में एक बात है।

00:32:09और मुझे निश्चित रूप से लगता है कि आपको अपने वेंडर्स की जिम्मेदारी लेनी चाहिए।

00:32:11लेकिन बात यह है कि, मुझे लगता है कि यह संतुलन बनाए रखना काफी मुश्किल है।

00:32:14और मैं निश्चित रूप से देखता हूँ कि लोगों में उंगलियाँ उठाने की एक स्वाभाविक प्रवृत्ति होती है,

00:32:18क्योंकि यह आपको जिम्मेदारी से मुक्त कर देता है।

00:32:20तो आपको इसके खिलाफ थोड़ा संघर्ष करना पड़ता है।

00:32:23सही।

00:32:24और उन मामलों में जहाँ आप सुनिश्चित हो सकते हैं कि यह वेंडर की गलती है,

00:32:28मुझे लगता है कि इसे पहचान पाना दिलचस्प है और,

00:32:31आप जानते हैं, इसके बारे में सही डेटा होना, जो अक्सर वेंडर की समस्याओं के साथ एक समस्या होती है।

00:32:35सही।

00:32:35आप उनका डेटा वाला पक्ष नहीं देख पाते।

00:32:37तो यह कहना बहुत मुश्किल है कि किसी निश्चितता या अनुभवजन्य साक्ष्य के साथ,

00:32:42कि यह स्पष्ट रूप से उनकी गलती है।

00:32:43आपको इसे अपने डेटा से निकालना होगा, जो सही भी हो सकता है, गलत भी।

00:32:46सही।

00:32:47तो मैं सोच रहा था कि जब Shopify या Stripe जैसी किसी चीज़ में आउटेज (बंद) हो,

00:32:51तो इवेंट्स कैसे रिकवर करते हैं और क्या इससे आपके सर्वर पर बहुत दबाव पड़ता है?

00:32:57हाँ, मूल रूप से यही होता है।

00:33:00और क्योंकि ऐसी स्थितियाँ होती हैं जहाँ हम हमेशा कहते हैं कि,

00:33:05आपको किसी विशिष्ट वेब वॉल्यूम का अनुमान नहीं लगाना चाहिए।

00:33:09हम्म।

00:33:09तो हमारे पास यह विशेषता है कि हर वेंडर एक टाइमआउट लागू करेगा।

00:33:14सही।

00:33:14वे आपको तीन सेकंड देंगे,

00:33:15पाँच सेकंड, यह रिस्पॉन्स देने के लिए प्लेटफ़ॉर्म पर निर्भर करता है।

00:33:18और इसका मतलब है कि आप वास्तव में कोई सार्थक काम नहीं कर सकते,

00:33:21विशेषकर जब आप उस देरी में नेटवर्क लेटेंसी और इस तरह की चीज़ों को ध्यान में रखते हैं।

00:33:25सही।

00:33:25और इसीलिए मेरा मतलब है, केवल यही कारण नहीं है,

00:33:28लेकिन यह उन कारणों में से एक है कि सामान्य बात यह है कि आपको इसे कतार (queue) में डालना होगा।

00:33:31आप इसे सिंक्रोनस रूप से प्रोसेस नहीं कर सकते।

00:33:33लेकिन मैं अपनी बात भूल गया।

00:33:39क्या आप अपना सवाल दोहरा सकते हैं?

00:33:42मैं Stripe और Shopify जैसी कंपनी में आउटेज के बारे में बात कर रहा था।

00:33:45ओह, हाँ।

00:33:45और कैच अप करने के बारे में।

00:33:47हाँ।

00:33:47हाँ।

00:33:47हाँ।

00:33:47तो खैर, इन सबका मतलब है लेटेंसी, वगैरह, वगैरह, घुमा-फिराकर कहने का मतलब है कि आपको

00:33:52ऑटो स्केल करने में सक्षम होना चाहिए।

00:33:53और इसलिए आपको बहुत कम समय सीमा में स्केल करने में सक्षम होना चाहिए।

00:33:56और वे स्पाइक्स कई अलग-अलग कारणों से आते हैं।

00:33:58यह ऐसा हो सकता है कि स्वाभाविक रूप से आपने बल्क इम्पोर्ट किया जब आपके ग्राहक ने

00:34:03बल्क इम्पोर्ट किया या कुछ और।

00:34:03सही।

00:34:03स्पाइक होने के अन्य कारण भी हैं।

00:34:05लेकिन डाउनटाइम वास्तव में उनमें से एक है।

00:34:07सही।

00:34:07ऐसा क्षण आता है जहाँ अगर Shopify आधे घंटे के लिए डाउन हो गया, तो उनके रिकवर होने तक,

00:34:11वे बस बैकलॉग को पूरा करेंगे, विशेषकर वे अपनी कतार पर दबाव को कम करने की कोशिश करेंगे।

00:34:16तो मूल रूप से डाउनटाइम के दौरान जो कुछ भी जमा हुआ, उसे पूरा करना।

00:34:17और इसलिए बोलते समय, आप देखेंगे कि वे अपनी सामान्य क्षमता से भी ज्यादा स्केल करेंगे

00:34:22क्योंकि वे चीजों को कैच अप करने की कोशिश कर रहे हैं।

00:34:26सही।

00:34:28और इसका परिणाम मूल रूप से यही है कि वे एंड स्टोर्स को बहुत सारे अनुरोध भेजते हैं।

00:34:28हाँ, और यह भी कि वे एंड स्टोर्स को बहुत सारे अनुरोध भेजते हैं।

00:34:32तो, हाँ, आपके पास वे अनियमितताएँ हैं, लेकिन थ्रूपुट में कुछ अनियमितताएँ

00:34:37आपके कारण नहीं होती हैं।

00:34:38यह 100% वेंडर के कारण होती है क्योंकि, आप जानते हैं, वेंडर खुद अपनी

00:34:42बुनियादी ढाँचे की चुनौतियों से गुजर रहा होता है।

00:34:44और स्पष्ट रूप से वेबहुक भेजने की Shopify की क्षमता वेबहुक प्राप्त करने की आपकी क्षमता से बहुत अधिक है।

00:34:49ज्यादातर मामलों में।

00:34:52हाँ।

00:34:52मजेदार बात यह है कि हमारे एक निवेशक Twilio में CPO थे।

00:34:56और मुझे लगता है कि यही कारण है कि मुझे निवेश करने में रुचि थी।

00:34:59क्योंकि उन्होंने जो बातें कहीं उनमें से एक यह थी कि मूल रूप से Twilio नियमित रूप से

00:35:04अपने ग्राहकों को DDoS कर रहा था, आप जानते हैं, सभी उद्देश्यों के लिए।

00:35:07और यह थोड़ा अपरिहार्य है और उन वेंडर-संचालित घटनाओं के साथ समस्याओं का हिस्सा है।

00:35:14तो यह वेंडर्स के साथ एक बहुत ही जानी-मानी समस्या है।

00:35:17और उन्हें भी यह पता है, क्योंकि यह वह चीज़ है जिसे आप सर्वर की रिस्पॉन्स लेटेंसी में भी ट्रैक कर सकते हैं, है ना?

00:35:21यदि आप अपने ग्राहक को DDoS करते हैं, तो सर्वर रिस्पॉन्स लेटेंसी बढ़ जाती है।

00:35:24और किसी बिंदु पर, वे टाइम आउट होने लगते हैं।

00:35:26वह समस्या बढ़ जाती है क्योंकि यदि लंबे टाइमआउट हों तो अधिक थ्रूपुट प्राप्त करना कठिन होता है।

00:35:29मतलब मूल रूप से जितनी देर आपको HTTP कनेक्शन होल्ड करना पड़ता है, उतनी ही कम अनुरोध आप अपने एंड पर कर सकते हैं।

00:35:31और इसलिए अब आपको स्केल करना होगा और फिर आप और अधिक भेजते हैं क्योंकि आपने स्केल किया।

00:35:34यह सब एक साथ ढेर हो जाता है, है ना?

00:35:38यह बहुत ही आत्म-प्रबलित (self-reinforcing) होता है।

00:35:40क्योंकि मूल रूप से आपके पास उन वेबहुक्स को प्रोसेस करने की जितनी कम क्षमता होगी, लेटेंसी उतनी ही तेजी से खराब होगी।

00:35:45और इसलिए जैसे ही आप अपने सर्वर पर सैचुरेशन (संतृप्ति) तक पहुँचते हैं, तो लेटेंसी बहुत खराब हो जाती है।

00:35:46लेकिन वे अनुरोध आते रहते हैं, ढेर होते रहते हैं।

00:35:52और बहुत से वेंडर क्या करते हैं, किसी बिंदु पर, वे बस आपके एंडपॉइंट को डिसेबल कर देंगे।

00:35:57क्योंकि अन्यथा यह ढेर होता रहता है।

00:36:01और वे सैकड़ों-हजारों HTTP कनेक्शन होल्ड नहीं करना चाहते क्योंकि आपका सर्वर रिस्पॉन्स देने में धीमा है।

00:36:04लेकिन जैसे ही वे इसे डिसेबल करते हैं, आप डेटा खो देते हैं।

00:36:07तो यह भी एक समस्या है, है ना?

00:36:10इसलिए वास्तव में उन विविधताओं के माध्यम से रिस्पॉन्स समय सुनिश्चित करना अक्सर आपके नियंत्रण से बाहर होता है।

00:36:14यह वहाँ चुनौती का एक बड़ा हिस्सा है।

00:36:15मैं यह भी पूछना चाहता था कि अब AI के साथ, यह वेबहुक्स के पूरे क्षेत्र को कैसे बदल रहा है?

00:36:19मुझे पता है कि आपने कहा था कि LLMs अब अधिक वेबहुक्स भेज रहे हैं और शायद उन्हें प्रोसेस कर रहे हैं।

00:36:21लेकिन आंतरिक रूप से, आप Hookdeck के लिए AI का उपयोग कैसे करते हैं?

00:36:25और आप इस क्षेत्र में AI का भविष्य क्या देखते हैं?

00:36:29हाँ, मुझे लगता है कि उस मोर्चे पर बहुत कुछ चल रहा है।

00:36:37जैसे स्पष्ट रूप से, हम केवल एक सॉफ़्टवेयर विकास शॉप हैं।

00:36:43और मुझे लगता है कि आप लोग वर्कफ़्लो, हर हफ्ते बदलते वर्कफ़्लो, टोकन लागत और

00:36:48टोकन लागत की कितनी उचित राशि है, इन सब चुनौतियों से गुजर रहे हैं।

00:36:51हाँ, हमें लीडरबोर्ड करने की आवश्यकता नहीं है।

00:36:54मैं लीडरबोर्ड के विचार से बहुत डरता हूँ।

00:36:57ऐसा लगता है कि यह आपके मार्जिन को नष्ट करने का एक पक्का तरीका है।

00:37:02तो कुछ विचार।

00:37:05सबसे पहले, जैसा कि मैं पहले कह रहा था, आप जानते हैं, उन घटनाओं के लिए विकास और साधन हैं

00:37:10जो उन एजेंटिक (agentic) उपयोग के मामलों द्वारा संचालित होते हैं।

00:37:15क्योंकि एजेंट मानव-ट्रिगर से इवेंट-ट्रिगर की ओर बढ़ रहे हैं।

00:37:18और आप देख रहे हैं कि सभी क्लाउड एजेंट उत्पाद सामने आ रहे हैं।

00:37:24और ये सभी मूल रूप से या तो समय-सारणी द्वारा या अंत में घटनाओं द्वारा ट्रिगर होते हैं।

00:37:25और उनमें से कुछ घटनाएँ आपसे दूर हैं, लेकिन अभी भी GitHub PR जैसी चीज़ें हैं।

00:37:29या जब आप कमेंट करते हैं, तो यह सब वेब संचालित है।

00:37:35लेकिन स्पष्ट रूप से, यह उससे कहीं आगे बढ़ जाएगा, जैसे ग्राहक सहायता और स्लैक,

00:37:41और शायद सेंसर डेटा से वास्तविक दुनिया में होने वाली वास्तविक समय की चीज़ें।

00:37:42मुझे लगता है कि बहुत सारे एजेंटों को अनिवार्य रूप से अन्य एजेंटों के साथ घटनाओं को ट्रिगर करने की आवश्यकता होगी।

00:37:46यह बहुत ही रोचक क्षेत्र है।

00:37:49GitHub PR हो, या जब आप GitHub पर कोई कमिट या कमेंट करते हैं, तो ये सब वेब-संचालित (web-driven) है।

00:37:56लेकिन जाहिर है, यह उससे कहीं आगे तक फैलेगा, जैसे कि कस्टमर सपोर्ट,

00:38:00स्लैक (Slack), वगैरह-वगैरह, और शायद रियल-टाइम चीजें भी जो वास्तविक दुनिया में होती हैं,

00:38:04जैसे सेंसर डेटा और इस तरह की तमाम चीजें, है ना?

00:38:08मुझे लगता है कि बहुत सारे एजेंट्स को मूल रूप से दूसरे एजेंट्स के साथ इवेंट ट्रिगर करने की आवश्यकता होगी,

00:38:12जैसे कि एजेंट का आउटपुट एक इवेंट होगा, जो संभवतः किसी

00:38:17दूसरे एजेंट, दूसरी कंपनी वगैरह को ट्रिगर करेगा, जिसे, हाँ, आप एक तरह से

00:38:21वेबहुक (WebEx) यूज़ केस के तहत वर्णित कर सकते हैं, और यह वैसा ही है।

00:38:23लेकिन मुझे लगता है कि अभी वेबहुक के आसपास की कुछ शब्दार्थ (semantics) थोड़ी त्रुटिपूर्ण हैं,

00:38:28जैसे कि सुरक्षा, प्रोटोकॉल, दक्षता और उस तरह की चीजों के बारे में।

00:38:33और इसीलिए हम एक बेहतर पैटर्न के रूप में इवेंट डेस्टिनेशंस को बढ़ावा दे रहे हैं,

00:38:36और इसके लिए एक अधिक अनुकूलित पैटर्न। दूसरी बात यह भी है कि यदि आप जो

00:38:40इवेंट्स के जवाब में चलाते हैं, वे एजेंटिक वर्कफ़्लो हैं, जो अनिर्धारित (undeterministic) हैं और लंबे समय तक चल सकते हैं,

00:38:47तो आपको मिलने वाले इवेंट्स के परिणामस्वरूप अपनी क्षमता (capacity) और स्केल को समायोजित करना बहुत कठिन हो जाता है।

00:38:51इसलिए मुझे लगता है कि थ्रूपुट प्रबंधन और क्षमता प्रबंधन जैसी चीजें बहुत अधिक कठिन हो जाती हैं।

00:38:55आपकी विफलता दर (failure rates) अधिक होगी क्योंकि क्लाउड का टाइम आउट होना,

00:39:00और आपके ईवल्स (evals) का पास न होना, इस तरह की चीजों के कारण।

00:39:07इसलिए, मुझे लगता है कि एप्लिकेशन बनाने के दृष्टिकोण से और उन मुख्य प्रिमिटिव्स (primitives) के संदर्भ में जिन्हें आप उपयोग करना चाहते हैं,

00:39:12वे कहाँ चलते हैं, कब तक चलते हैं, और आप अपने बैक प्रेशर (back pressure) से कैसे निपटते हैं,

00:39:16इनमें बहुत सारी नई चुनौतियाँ हैं। और जहाँ तक आंतरिक रूप से हमारी बात है,

00:39:21मुझे लगता है कि हम अभी भी सही रास्ता खोजने की कोशिश कर रहे हैं। मेरा एक हिस्सा बस

00:39:25क्षमता (capacity) से पूरी तरह चकित है। मैं किसी को हैरान नहीं कर रहा हूँ, मुझे नहीं लगता कि मैं कोई

00:39:29अद्वितीय अंतर्दृष्टि (unique insight) ला रहा हूँ। हालाँकि, एक बात जो मैं कहूँगा, वह यह है कि,

00:39:34आपके CLI प्रॉम्प्ट या कोडेक्स (Codex) या जो कुछ भी है, उससे वास्तव में उच्च गुणवत्ता वाले,

00:39:41रुचिकर उत्पाद (tasteful product) शिप करने के बीच का अंतर कम हो रहा है। मुझे लगता है कि उस बारीकी में से कुछ अभी भी खो रही है,

00:39:45और सारे मीम्स और एक्सपोज़ के चक्कर में, मुझे संदेह है कि क्या आप वास्तव में इतनी मात्रा में

00:39:50टोकन खर्च कर सकते हैं और दिन के अंत में दुनिया के लिए वास्तव में मूल्यवान कुछ बना सकते हैं।

00:39:55और कम से कम हमारे अनुभव में अब तक, जाहिर है कि सुरक्षा के आसपास बहुत कुछ है,

00:40:01जो कि बहुत बड़ा इनेबलर है, जैसे कोड रिव्यूज और उस तरह की चीजें। लेकिन मुझे लगता है कि जब

00:40:06बात आती है, तो ये चीजें बस बुनियादी जरूरतें (table stakes) हैं। वे ऐसी चीजें नहीं हैं जो वास्तव में

00:40:11दिन के अंत में मूल्य जोड़ती हैं, है ना? जैसे कि जब वास्तव में कुछ बहुत मूल्यवान बनाने की बात आती है,

00:40:14जिससे दूसरे लाभान्वित हों, मुझे लगता है कि अभी भी काफी अंतर है। और मुझे लगता है कि

00:40:19हमारी टीम अभी भी उस स्तर की समझ (taste), अंतर्दृष्टि, ग्राहक की समझ,

00:40:25सहानुभूति और उस तरह की तमाम चीजों के लिए जिम्मेदार है, जो आपको सीधे चैट बॉक्स से नहीं मिलती।

00:40:31और इसलिए शायद हम ही मूर्ख बन रहे हैं और हमें बहुत तेजी से आगे बढ़ना चाहिए था,

00:40:35और अगर हम बस एक बार में सब कुछ कर लेते। लेकिन अभी के लिए, हमारा दृष्टिकोण वही है,

00:40:42अंतिम परिणाम और जो हम उपयोगकर्ता को डिलीवर करते हैं, उसके मामले में समान उम्मीदें रखना।

00:40:47हाँ, जाहिर है, इसका मतलब है कि हम और अधिक कर सकते हैं। और साथ ही, मुझे लगता है कि जिन लोगों में

00:40:53वह समझ (taste) और सहानुभूति आदि है, वे उपयोगकर्ता को मूल्य दे सकते हैं क्योंकि बाधा कोड थी,

00:40:57है ना? और इसलिए उदाहरण के लिए, अब कंपनी में लगभग हर कोई कोड करता है,

00:41:01है ना? जैसे हमारा डिज़ाइनर अब रेजिडेंट वाइप कोडर है। अब वह पूरी तरह से जिम्मेदार है,

00:41:06वेबसाइट के लिए, लेकिन वहाँ डैशबोर्ड का भी बहुत सारा काम है, या प्रोडक्ट मार्केटर या डेव-रेल (DevRel) वाले,

00:41:11सब, आप जानते हैं, टोकन मैक्सिंग नहीं, लेकिन अगर कोई लीडरबोर्ड होता,

00:41:16तो वे शायद कहीं ऊपर होते। और मुझे लगता है कि यह बहुत अच्छी बात है। यह इनेबलर्स हैं,

00:41:20क्योंकि उन लोगों में आलोचनात्मक सोच (critical thinking) होनी चाहिए, जिसका मैं वर्णन कर रहा था,

00:41:25ताकि वे अंत-उपयोगकर्ता के लिए रुचिकर चीज़ें शिप कर सकें, और बाधा कोड से ज्यादा कुछ और है।

00:41:30तो कुछ मायनों में, मुझे लगता है कि सबसे बड़ा लाभ वहीं से मिल रहा है, बजाय

00:41:36शुद्ध इंजीनियरिंग के। फिर से, यह नहीं कह रहा कि शुद्ध इंजीनियरिंग इससे बहुत अधिक मूल्य प्राप्त नहीं कर रही है,

00:41:40लेकिन मुझे लगता है कि बाधा अभी भी उस समझ (taste) पर टिकी है। और ऊपर से, मैं बहुत समय

00:41:45बेकार के पीआर (PRs) की समीक्षा करने में बिता रहा हूँ। तो, इसका नकारात्मक पक्ष भी है।

00:41:51सही। निश्चित रूप से। और आपको जितनी कोड की समीक्षा करनी पड़ती है।

00:41:56हाँ। और जैसे, इस अस्पष्ट भेद्यता (vulnerability) को ही लें जिसकी संभावना लगभग नहीं है।

00:42:01और मुझे तो पक्का नहीं पता कि यह कम (low) की श्रेणी में भी आती है या नहीं। लेकिन जाहिर है, एक बार जब यह सामने आ जाती है,

00:42:06तो आप इसके प्रति जिम्मेदारी महसूस करते हैं। और मुझे लगता है कि यह सामान्य है। लेकिन,

00:42:09एक समय पर ऐसा था कि हमने कभी इतने सारे पीआर खुले नहीं रखे थे।

00:42:14और यह सब वास्तव में समझने के लिए थोड़ा पागलपन जैसा लग रहा है। और,

00:42:18मुझे लगता है कि यह निर्णय लेना कि 'ऐसा नहीं है कि आप सब कुछ कर सकते हैं',

00:42:21तो आपको सब कुछ करना चाहिए। और मुझे लगता है कि यह बहुत हद तक एलएलएम (LLM) के उस रवैये के साथ आता है,

00:42:26और मुझे लगता है कि इस निर्णय को लाना कि 'क्या अंततः मूल्य उत्पन्न करेगा',

00:42:31या जिसमें मूल्य उत्पन्न करने की क्षमता है, पहले से कहीं अधिक महत्वपूर्ण है।

00:42:34क्योंकि एजेंटों के साथ काम करने में एक प्रकार की 'चेकबॉक्स' संतुष्टि होती है,

00:42:39जो कि कभी-कभी मुझे बिल्कुल सुस्त कर देती है। जैसे, मैं बस अपनी सूची और उन चीजों से गुजरना चाहता हूँ,

00:42:44और बस चेक, चेक, चेक, चेक करना चाहता हूँ।

00:42:48सही। और एलएलएम के साथ कुछ ऐसा होता है जहाँ मैं यह बातचीत शुरू करता हूँ, वह बातचीत शुरू करता हूँ,

00:42:53यह बातचीत शुरू करता हूँ, और शायद पाँच या छह एजेंट चल रहे होते हैं,

00:42:57और वे सभी चीजें कर रहे होते हैं, लेकिन उन सभी के पास चेकलिस्ट होती हैं जिन्हें वे भी चेक कर रहे होते हैं।

00:43:02सही। सही। सही। सही। हाँ। हाँ। तो, कुछ तो है जो संतुष्टि के साथ,

00:43:06और त्वरित इनाम (quick reward) जो उसके साथ जुड़ा होता है, उसके बारे में।

00:43:11मुझे लगता है कि कभी-कभी यह हम पर हावी हो जाता है। सही, या कम से कम खुद की बात करूँ तो। हूक टैग टीम कितनी बड़ी है?

00:43:15हम अभी 10 हैं। ओह, वाह। वह बहुत छोटी टीम है। हाँ। तारीफ के काबिल है। यह हमेशा से मेरी महत्वाकांक्षा रही है।

00:43:23मैं खुद को सबसे अच्छा मैनेजर नहीं मानता। और इसलिए मुझे लगता है कि यह सबके लिए उस तरह बेहतर है।

00:43:29नहीं, मुझे लगता है कि शुरुआत से ही, हमारा जन्म कोविड के बीच हुआ था,

00:43:33सही? हर कोई रिमोट है। और, शुरुआत से ही यह मानसिकता थी कि,

00:43:38वरिष्ठ अनुभव वाले, बेहद स्वायत्त (autonomous) प्रकार के लोगों को काम पर रखना,

00:43:45ताकि एक समझ मिल सके। हम वास्तव में हर दो सप्ताह में बस एक सिंगल कॉल करते हैं, उत्पाद और बुनियादी ढांचे पर चर्चा करने के लिए।

00:43:50और इसलिए हम एक तरह का एसिंक्रोनस (asynchronous) वर्कफ़्लो रखने की कोशिश करते हैं।

00:43:56और मुझे लगता है कि यह एआई यूज़ केसेस के लिए भी अच्छा है। क्योंकि, हम पहले ही उन लोगों के लिए काम पर रख चुके हैं और अनुकूलित कर चुके हैं जिनमें यह स्वायत्तता है।

00:44:01सही। मुझे नहीं लगता कि कुछ सही या गलत है। मैं प्रचार नहीं करूँगा कि हम चीजें कैसे करते हैं, लेकिन मुझे लगता है कि यह हमारे लिए काम करता है।

00:44:06मैं कुछ और नहीं प्रचार करूँगा, मुझे लगता है कि यह हमारे लिए काम करता है।

00:44:11मेरे लिए और मेरी मानसिक शांति के लिए कुछ काम नहीं करता। तो वह है।

00:44:14मैं उस बात को फिर से छूना चाहता था जो आपने बातचीत की शुरुआत में कही थी, कि, अह,

00:44:21वेबहुक (webhooks) खत्म हो चुके हैं। नया तरीका इवेंट गेटवे है। क्या आपने वह शब्द गढ़ा है या वह पहले से ही मौजूद था?

00:44:27अह, इवेंट गेटवे क्या है? मुझे इसकी कोई समझ नहीं है।

00:44:32हाँ, हमने इसे गढ़ा है और एक ऐसा उत्पाद और उत्पाद श्रेणी बनाना बहुत मुश्किल रहा है जो स्थापित नहीं है।

00:44:37अह, क्योंकि आपके पास मार्केटिंग और संचार जैसी चुनौतियाँ हैं, और आप इस चीज़ का वर्णन कैसे करते हैं, सही?

00:44:41और कुछ समय के लिए हम इसके बारे में बात कर रहे थे, इसे 'वेबहुक प्रबंधन बुनियादी ढांचा' कह रहे थे।

00:44:46ऐसा कुछ नहीं जो वास्तव में मुँह से आसानी से निकले।

00:44:51तो, संचार पर चुनौती है, लेकिन उत्पाद पर भी चुनौती है।

00:44:54क्योंकि जब आप मौजूदा श्रेणी में उत्पाद बना रहे होते हैं, मान लीजिए बेहतर स्टैक, आप जानते हैं कि आप किसके लिए अनुकूलित करने की कोशिश कर रहे हैं,

00:44:58अपने विशिष्ट यूएसपी (USPs) के लिए, जो आपके मामले में, मुझे लगता है कि बहुत कुछ मूल्य निर्धारण और डीएक्स (DX) और उस तरह की चीजों के बारे में है।

00:45:02सही। लेकिन बात यह है कि मूल शब्दार्थ मौजूद हैं। और इसलिए आप किसके लिए अनुकूलित कर रहे हैं,

00:45:07वह अनूठी मूल्य स्थिति (value position) है।

00:45:10जब आप कुछ ऐसा बना रहे होते हैं जो वास्तव में पहले से मौजूद नहीं है, तो आपको शब्दार्थ का आविष्कार करना पड़ता है,

00:45:14और फिर उन शब्दार्थों के ऊपर एक सम्मोहक मूल्य प्रस्ताव (compelling value proposition) बनाना पड़ता है। सही। तो वह बहुत मुश्किल हो जाता है।

00:45:19सही। तो यह बहुत मुश्किल हो जाता है।

00:45:24और पिछले कुछ वर्षों से यह एक सीख है, मौजूदा श्रेणी में उत्पाद बनाना बहुत मुश्किल है।

00:45:28और इसलिए इवेंट गेटवे के साथ विचार और वह कहाँ से आया,

00:45:32उतना बेहतर तरीके से कैप्चर करने की कोशिश करना है, और, आप जानते हैं, दो या तीन शब्द जो उम्मीद है कि,

00:45:37आसानी से समझ आ सकें कि यह क्या करता है। और हमारा लक्ष्य इवेंट बस (event bus) के बीच पुल बनाना था,

00:45:43और मूल रूप से एपीआई (API), एपीआई गेटवे। सही। और इस धारणा को कैप्चर करना कि गेटवे वहाँ हैं,

00:45:49एक इंटरफ़ेस के रूप में, एक विक्रेता और आपके अपने सिस्टम के बीच का इंटरफ़ेस वगैरह। सही। और

00:45:55इवेंट बस इस अर्थ में कि यह पूरी तरह से इवेंट प्रबंधन और कतार (queuing) वगैरह है।

00:46:00सही। तो हम एक ऐसा शब्द खोजने की कोशिश कर रहे थे जो उन दोनों को मिला दे। और वास्तव में जब

00:46:04आप 'इवेंट ब्रिज' के बारे में सोचते हैं, तो इवेंट गेटवे से ज्यादा दूर नहीं है। और इसलिए वास्तव में हम चाहते हैं,

00:46:10कि लोग हमें इवेंट ब्रिज के साथ प्रतिस्पर्धा करने वाले के रूप में देखें, उदाहरण के लिए, जैसे हम देखते हैं,

00:46:14खुद को एक स्पष्ट विकल्प के रूप में। सही। और मुझे लगता है कि इवेंट गेटवे के आसपास का विचार यह भी था,

00:46:19कि 'देखो, अभी मौजूदा उत्पाद हैं। उनके आसपास कोई सामान्य शब्दावली नहीं है'। सही।

00:46:24वे इसे सीधे 'इवेंट गेटवे' नहीं कहते, लेकिन हम उसे एक लेबल देंगे। और फिर, आप जानते हैं,

00:46:29कुछ पहले से ही प्रतिस्पर्धा करने वाले उत्पाद उस श्रेणी में हैं,

00:46:33एक, अह, हमारा, लेकिन फिर AWS है, Azure है, दूसरे जैसे Kong एक इवेंट गेटवे है।

00:46:39अब ग्रेविटी (Gravity) है। बहुत सारे एपीआई गेटवे प्रदाता इवेंट-ड्रिवन आर्किटेक्चर की ओर बढ़ रहे हैं।

00:46:45तो इस बिंदु पर, शायद आधे दर्जन उत्पाद हैं,

00:46:49कम से कम जो खुद को इवेंट गेटवे या इवेंट गेटवे जैसा कहेंगे, और मुझे नहीं पता कि हमारा इसमें क्या हाथ था,

00:46:54लेकिन मैं आपको बता सकता हूँ कि जब Kong ने अपना इवेंट गेटवे जारी किया, तो मुझे लगा,

00:46:58ओह, शिट, ये हमारे उस तरह से बुलाने के दो साल बाद था। लेकिन जो हिस्सा,

00:47:03वास्तव में पुरस्कृत है, वह है जब ग्राहक आपके पास आते हैं, शुरुआती डेवलपर्स मेरे पास आते हैं और कहते हैं, 'मैं

00:47:08एक इवेंट गेटवे की तलाश कर रहा हूँ'। और यह, 'ओह, अब आप, ठीक है',

00:47:12मुझे लगता है कि शब्द कहीं न कहीं पहुँच रहा है, इस अर्थ में कि लोगों के पास इसका एक मानसिक

00:47:16मॉडल है, या वे इसे स्पष्ट रूप से खोजना शुरू कर रहे हैं, या वे कह सकते हैं,

00:47:20हम अपना खुद का इवेंट गेटवे बदलना चाह रहे हैं। ये बातें बातचीत में सामने आई हैं।

00:47:23लेकिन मैं आपको बता सकता हूँ कि पहले साल के लिए, यह नहीं आता था। और अब,

00:47:28जैसे-जैसे समय बीतता है, यह एक ऐसा शब्द है जिसे मैं दूसरों को अधिक से अधिक उपयोग करते हुए देखता हूँ। मुझे लगता है कि यह अच्छी बात है।

00:47:34मुझे लगता है कि यह एक व्यवसाय के रूप में हमारे लिए अच्छी बात है, लेकिन केवल,

00:47:38यह उम्मीदें पैदा करने के अर्थ में कि, ठीक है, यह वह क्लाउड इंफ्रास्ट्रक्चर प्रिमिटिव है जो मौजूद है।

00:47:43और आपके पास बुनियादी उम्मीदों का सेट है जो आप इसके आसपास रख सकते हैं। और

00:47:48उम्मीद है कि कभी न कभी, चीजें संरेखित होना शुरू हो जाएंगी, शब्दार्थ और उस तरह की चीजें भी।

00:47:52अगर आप AWS इवेंट ब्रिज और कुछ इस्तेमाल कर रहे हैं, तो शब्दावली में बहुत कम समानता है।

00:47:57अब, मैं अपने उत्पाद को AWS इवेंट ब्रिज के चारों ओर डिज़ाइन नहीं करना चाहता, क्योंकि इसमें बहुत सारे उत्पाद हैं।

00:48:01तो मैं निश्चित रूप से उनकी शब्दावली का पुन: उपयोग नहीं करूँगा यदि मुझे नहीं लगता कि यह,

00:48:05पूरी तरह से सही समझ में आता है। लेकिन मुझे लगता है कि समय के साथ, जैसा कि आप जानते हैं,

00:48:09अधिक लोग निर्माण कर रहे हैं और उत्पाद के आसपास लोग हैं, उस तरह की चीजें,

00:48:12शायद कुछ मात्रा में अभिसरण (convergence) होगा।

00:48:15हाँ।

00:48:15क्या आपको लगता है कि अगर मैंने किसी एलएलएम (LLM) से इवेंट गेटवे के बारे में पूछा तो वह आप लोगों की सिफारिश करेगा?

00:48:20ओह हाँ। अभी आज़माएँ। मुझे लगता है, मुझे लगता है कि ऑड्स काफी अच्छे हैं।

00:48:24मैं इसे लाइव आज़मा सकता हूँ।

00:48:25यह कुछ ऐसा है जिसे हम ट्रैक करते हैं, सही?

00:48:27हाँ।

00:48:27यह कुछ ऐसा है जिसे हम ट्रैक करते हैं। हमें लगभग 60% हर एक में उद्धृत किया जाता है,

00:48:31हर एक प्रॉम्प्ट जो वेबहुक (WebEx) या इवेंट गेटवे के आसपास होता है, उस तरह की चीजें।

00:48:35यह कूल है। और कुछ ऐसा जिस पर हमने स्पष्ट रूप से बहुत समय बिताया। और जहाँ तक हमारे डेटा

00:48:42का सवाल है, जो शायद उतनी उच्च गुणवत्ता का न हो, हम इस पर काफी अच्छा काम कर रहे हैं। तो

00:48:46यह सूची में पहला था।

00:48:48ओह, बढ़िया।

00:48:49वहाँ आप हैं।

00:48:49जो ChatGPT ने मुझे दिया। तो बहुत अच्छा।

00:48:52हाँ। हालाँकि मुझे लगता है कि इवेंट गेटवे पर, मुझे लगता है कि हम शायद उतना ही अच्छा करेंगे,

00:48:56WebEx से संबंधित किसी भी तरह की क्वेरी और उस तरह की चीज़ों पर। लेकिन इवेंट गेटवे निश्चित रूप से

00:49:00हमारे पक्ष में है, हमने शब्द गढ़ा है, मुझे गुस्सा आता अगर हम पहले न होते।

00:49:03मुझे बुरा लगता अगर हम पहले न होते।

00:49:05मुझे अब एहसास हुआ कि मुझे वास्तव में नहीं पता कि इवेंट-ड्रिवन आर्किटेक्चर का क्या अर्थ है। यह कैसे अलग है,

00:49:11एक नियमित आर्किटेक्चर से? जैसे कि अगर, अगर मैं अपने सिस्टम में काफ्का (Kafka) कतार लगा दूँ,

00:49:17तो क्या मैं स्वचालित रूप से एक इवेंट-ड्रिवन आर्किटेक्चर हूँ?

00:49:21हाँ और नहीं। इस अर्थ में कि मुझे लगता है कि जब आप इवेंट-ड्रिवन आर्किटेक्चर के बारे में बात कर रहे हैं,

00:49:25तो यह प्रतिमानों (paradigm) और अपेक्षाओं का एक सेट है जो आप इसके आसपास रखते हैं। तो इसका एक हिस्सा होगा,

00:49:31हाँ, उपकरण, सही? जैसे आप काफ्का का उपयोग कर रहे हैं, आप मैसेज कतार या इवेंट का उपयोग कर रहे हैं,

00:49:35स्ट्रीमिंग जो सिस्टम को डीकपल (decouple) करने के लिए होती है। तो वास्तव में जब बात आती है,

00:49:39विचार यह है कि उनके पास उत्पादक और उपभोक्ता हैं, वे सिस्टम एक-दूसरे के बारे में नहीं जानते,

00:49:43एक-दूसरे के बारे में जानने की जरूरत नहीं है, सही? तो उपभोक्ता किसी स्ट्रीम से उपभोग कर सकता है,

00:49:47घटना की जो किसी के द्वारा भी निर्मित की जा सकती है। और अपेक्षा का एकमात्र वास्तविक सेट जो आपके पास है,

00:49:53वह इवेंट के आसपास एक अनुबंध (contract) है। जैसे पेलोड क्या है, आकार क्या है?

00:49:57हाँ। और अक्सर स्कीमा (schemas) होंगे, जैसे विशिष्ट स्कीमा जिनका लोग उपयोग करेंगे,

00:50:02जैसे एव्रो (Avro) आधारित स्कीमा और प्रोटोकॉल बफ़र (pro buff) और अन्य चीज़ें, सही? जहाँ उम्मीदें होंगी,

00:50:06मानकीकृत अपेक्षाएँ कि वे पेलोड क्या हैं वगैरह। और वास्तव में, तो अनुबंध इसके आसपास हो जाता है,

00:50:11ठीक है, ये घटनाएं मौजूद हैं। और किसी बिंदु पर मेरे पास एक घटना हो सकती है और एक उपभोक्ता के रूप में,

00:50:16मेरी जिम्मेदारी है कि मैं जो कुछ भी करने के लिए हूँ, वह करूँ, जैसे कोई ऑर्डर बनाया गया या उत्पाद अपडेट, आदि।

00:50:21सही। लेकिन अब एक संगठन जिसने वास्तव में ईडीए (EDA) को अपनाया है, आप क्या देखेंगे,

00:50:25इसके चारों ओर एक व्यवस्थित पैटर्न, सही? जहाँ विशिष्ट,

00:50:29दिशानिर्देश होंगे कि आपको यह कैसे करना है और पेलोड आकार क्या होने चाहिए।

00:50:32और यह एक वास्तुशिल्प दृष्टिकोण (architectural approach) होगा जहाँ आप जानबूझकर डीकपल करेंगे,

00:50:36उनकी सेवाओं और उनके बीच संचार को इवेंट-ड्रिवन बनाएँगे, सही?

00:50:41मुझे लगता है कि बहुत सारी कंपनियाँ एक हाइब्रिड दृष्टिकोण लेती हैं, सही? कुछ इवेंट-ड्रिवन है,

00:50:45लेकिन कुछ नहीं है, सही? तो क्या लक्ष्य 100% इवेंट-ड्रिवन होना है?

00:50:50या यह सिर्फ एक वास्तुशिल्प प्रतिमान (architectural paradigm) का एक सबसेट है?

00:50:54मुझे नहीं लगता कि यह 100% है। मुझे बस लगता है कि समय के साथ, जैसे-जैसे आप बढ़ते हैं और जटिलता बढ़ती है,

00:51:00और अधिक तृतीय-पक्ष निर्भरताएँ (third party dependencies) वगैरह होती हैं, तो यह एक स्वाभाविक तरीका है जो चीजें,

00:51:04अपनाती हैं। क्योंकि किसी बिंदु पर, उन सभी सिस्टम को जोड़े रखना बहुत कठिन होता है।

00:51:09और फिर आपको स्केलिंग और अन्योन्याश्रितताओं (interdependencies) वगैरह के बारे में सोचना पड़ता है,

00:51:14इस तरह से जो इसे काफी कठिन बना देता है। लेकिन आम तौर पर बात करें, जब हम सोचते हैं,

00:51:19इवेंट-ड्रिवन आर्किटेक्चर के बारे में, जिस तरह से शब्द का प्रयोग होता है, मुझे लगता है लोग सोचते हैं,

00:51:23मुझे लगता है, और सही भी है, बड़े उद्यम (big enterprise) के बारे में, सही? और मुझे लगता है,

00:51:28शायद पहले दशक तक, यह बड़े उद्यमों तक ही केंद्रित था। लेकिन मुझे लगता है अब,

00:51:32यह बदल रहा है, आंशिक रूप से क्योंकि लोग पैटर्न के साथ अधिक सहज हो रहे हैं, आंशिक रूप से क्योंकि,

00:51:37वेबहुक (WebEx) इसके लिए एक प्रवेश द्वार (gateway drug) हैं। और, कुछ टूलिंग बेहतर हो रही है। जैसे मैं सोच रहा हूँ,

00:51:41मैं सोच रहा हूँ, जैसे रैबिट एमक्यू (RabbitMQ), या बुल एमक्यू (Bull MQ), जो रेडिस (Redis) पर आधारित है,

00:51:46लाइब्रेरीज़, पायथन में भी बहुत सारी लोकप्रिय लाइब्रेरीज़ हैं, सेलरी (Celery) है,

00:51:51रूबी में साइडकिक (Sidekiq) है। मुझे लगता है कि अब एक और है, फाउंडेशन, जो साइडकिक के लोगों से ही है।

00:51:57तो वैसे भी, टूलिंग में प्रगति हुई है,

00:52:01जो इसे काम करने में आसान बनाती है और इसमें प्रवेश करना कम डरावना होता है जहाँ आपको,

00:52:05सिर्फ बड़ी आर्किटेक्चर टीम और काफ्का (Kafka) पर बड़ी तैनाती की जरूरत नहीं होती, जो बहुत सारा पैसा खर्च करती है,

00:52:11इवेंट-ड्रिवन आर्किटेक्चर शुरू करने के लिए। लेकिन मुझे यह भी लगता है कि शब्द,

00:52:15ने अपना कुछ अर्थ खो दिया है। मुझे यकीन है कि कुछ लोग मेरी यह बात सुनकर खुश नहीं होंगे। लेकिन,

00:52:19मुझे लगता है कि समय के साथ इसने थोड़ा अर्थ खो दिया है, या कम से कम पानी गंदला हो गया है।

00:52:25और मुझे लगता है कि जब मैं यह कहता हूँ, तो मैं मुख्य रूप से सिस्टम के डीकप्लिंग (decoupling) को संदर्भित कर रहा हूँ। और फिर,

00:52:31वे प्रोग्रामिंग चिंताएं भी जो आपके पास एक इंजीनियर के रूप में नहीं होंगी, जैसे,

00:52:37स्वतंत्रता और ऑर्डरिंग और उन सभी चिंताओं के बारे में सोचना। और इसलिए जब,

00:52:43मैं इवेंट-ड्रिवन आर्किटेक्चर कहता हूँ, तो इसका मतलब है कि आप अब उस दुनिया में प्रवेश कर रहे हैं जहाँ,

00:52:48जब आप अपना ऐप बनाते हैं, तो आपके पास चिंता के वे सेट होंगे जो पहले नहीं थे।

00:52:52सही। समझ गया। और उन चिंताओं को समायोजित करने के लिए सीखने और अपनाने में सक्षम होना कि आप चीजें कैसे बनाते हैं।

00:52:58मुझे नहीं पता कि मैं शुरू में बड़े उद्यम (big enterprise) के तरीके के बारे में बात कर रहा था।

00:53:03बड़े एंटरप्राइज़ वाली चीज़ों की तरह। और मुझे लगता है कि हम जो कर रहे हैं वह एक तरह से इसे,

00:53:08आप जानते हैं, हर किसी तक किसी न किसी तरह पहुँचाने की कोशिश कर रहे हैं। सही। और हम ही

00:53:14अकेले खिलाड़ी नहीं हैं जो ऐसा कर रहे हैं। ऐसे कई अन्य लोग हैं जो अलग-अलग दृष्टिकोण अपना रहे हैं।

00:53:18वहां सभी वर्कफ़्लो इंजन और स्टेप फंक्शन्स हैं, जो मुझे लगता है कि एक-दूसरे से ओवरलैप करते हैं, जैसे

00:53:22टेम्पोरल (Temporal), इनजेस्ट (Ingest) और ट्रिगर डॉट डेव (trigger.dev) और वे लोग भी। तो मुझे लगता है कि यह वास्तव में एक

00:53:28ऐसी जगह है जहाँ बहुत कुछ हो रहा है। और शायद इसके लिए कोई अच्छी निश्चित परिभाषा

00:53:34अब नहीं बची है। जो लोग वास्तव में और अधिक जानने में रुचि रखते हैं,

00:53:38इवेंट-ड्रिवन आर्किटेक्चर और उससे जुड़े प्रतिमानों (paradigms) के बारे में, तो यह व्यक्ति है,

00:53:42डेविड बॉयन (David Boyan), जो पहले AWS में डेवलपर एडवोकेट थे और वास्तव में इवेंट ब्रिज (EventBridge) पर काम कर रहे थे।

00:53:49वह उस तरह की ड्रॉइंग-टाइप व्याख्याओं की श्रृंखला है। लेकिन अब तक, उनके पास शायद

00:53:55कई सौ हैं, वह अब एक ओपन-सोर्स प्रोजेक्ट भी चलाते हैं जिसका नाम 'इवेंट कैटलॉग' है, जो आप लोगों के लिए पॉडकास्ट के अगले

00:54:02अच्छे मेहमान हो सकते हैं। लेकिन कुल मिलाकर यह है कि यह उस गहराई तक जाता है

00:54:07जो लगभग अकल्पनीय है। तो निश्चित रूप से उन लोगों के लिए इसकी अनुशंसा करता हूँ जो

00:54:14जिज्ञासु हैं। बहुत बढ़िया। हम इसे शो नोट्स में जोड़ देंगे। हाँ, घटनाओं (events) और वेब

00:54:19हुक (webhooks) और बाकी सब चीज़ों के बारे में आपका ज्ञान। तो देखिए, आपके पास यह सब केवल हुक डेक (Hookdeck) बनाने से आया है।

00:54:23या क्या वहां... आपने पहले कहा था कि आपको वेब हुक के साथ कुछ समस्याएं थीं, लेकिन क्या यह तब था जब आपने

00:54:27वास्तव में इवेंट्स में गहराई से उतरना शुरू किया था? बिल्कुल। और मुझे लगता है कि यह सीखना समस्याओं से बहुत आया है,

00:54:34लेकिन 'फर्स्ट प्रिंसिपल्स' (मूल सिद्धांतों) से भी, कि, जब मैं उन

00:54:38समस्याओं से निपट रहा था, तो मेरे पास वास्तव में इसके बारे में बहुत अधिक ज्ञान नहीं था, जो कि इसका एक कारण था कि मैं

00:54:42उन समस्याओं से निपट रहा था। हाँ। तो मुझे लगता है कि यह इस बात से आया है कि, ठीक है, समस्या

00:54:47और उस समस्या के समाधानों पर काम करने की कोशिश करना, बजाय इसके कि समाधानों पर काम किया जाए और

00:54:51उन्हें समस्या के लिए रेट्रोफिट किया जाए। सही। लेकिन दिन के अंत में, इस बिंदु पर,

00:54:55हमने लाखों हुक के साथ काम किया है... मैंने... आप जानते हैं, हर क्षेत्र से।

00:54:59और इसलिए मुझे लगता है कि मैंने उन बातचीत से बहुत कुछ सोख लिया है। और हाँ, यह मूल रूप से

00:55:05काफी दिलचस्प रहा है। मैंने वास्तव में मूल रूप से एक प्रोडक्ट डिज़ाइनर के रूप में शुरुआत की थी। तो एक प्रकार से...

00:55:11आप जानते हैं, प्रोडक्ट डिज़ाइनर, फिर फुल-स्टैक डेवलपर, फिर बैक-एंड,

00:55:15फिर इंफ्रास्ट्रक्चर इंजीनियर। और अब यह है, अब एक तरह से खरगोश के बिल में बहुत, बहुत गहराई तक।

00:55:21लेकिन यह ग्राहकों के साथ काम करने और उनकी चिंताओं को सुनने

00:55:26और आर्किटेक्चर की समीक्षा करने और उस तरह की सभी चीजों के माध्यम से आया। लेकिन टीम से भी,

00:55:30है ना? हमारे पास टीम में ऐसे लोग भी हैं जिनके पास उन सिस्टम के साथ

00:55:33काम करने का बहुत अनुभव है और उन्होंने भी कंपनी में वह ज्ञान लाया है। हाँ। आपने कब,

00:55:38आपको एहसास हुआ कि आपने इसके लिए एक बाज़ार ढूंढ लिया है? मेरा मानना है कि जाहिर तौर पर आपने इस पर काम करना शुरू किया और फिर

00:55:42इसे कहीं पोस्ट किया। और क्या इसे तुरंत अच्छी प्रतिक्रिया मिली? या लोगों को यह जानने में कि यह बेहतर विकल्प है,

00:55:47काफी धीमी शुरुआत रही? 'धीमी शुरुआत' शायद इसे परिभाषित नहीं कर सकती,

00:55:53इस अर्थ में कि यह उस मीडियम लेख से शुरू हुआ जिसका मैं उल्लेख कर रहा हूँ, है ना? जैसे कि ये वेब

00:55:57हुक्स और इसके बारे में आप कुछ कर सकते हैं। मेरी मानसिकता बहुत ज्यादा थी कि 'लोगों के लिए प्रोडक्ट बनाओ'।

00:56:01तो बहुत पहला संस्करण एक तरह का सेल्फ-सर्विस था, आप जानते हैं, आप अंदर जा सकते हैं और

00:56:07अपना पहला 'कनेक्शन' बना सकते हैं, जैसा कि हम इसे कहते हैं, और उस तरह की सभी चीजें।

00:56:12और, और यह लेख पोस्ट किया और सब। और इससे व्यवसाय बनाने की कोई महत्वाकांक्षा नहीं थी या

00:56:16जो कुछ भी हो। यह सिर्फ अन्य 20 असफल साइट प्रोजेक्ट्स में से एक था, है ना? जिस पर मैं

00:56:21उस समय काम कर रहा था। और, और मेरा मतलब है, एक तरह के पूर्वव्यापी संदर्भ में, अब

00:56:26संख्याएं हास्यास्पद रूप से छोटी लगती हैं, क्योंकि शायद पांच लोग थे जिन्होंने

00:56:32उस लेख से संपर्क किया या कुछ और। लेकिन मैं जानता हूँ, हर उस व्यक्ति के लिए जिसने साइड प्रोजेक्ट्स पर काम किया है,

00:56:37और, और किसी को आपके द्वारा बनाई गई किसी चीज़ का उपयोग करने के लिए प्रेरित करने की कोशिश करने

00:56:42के चरणों से गुज़रा है। तो पांच बहुत ज्यादा है। पाँच तो उससे बेहतर है जो मुझे शायद पहले कभी

00:56:48मिले होंगे। सही। और इसलिए, मैं इससे बहुत उत्साहित था। मैं वास्तव में

00:56:55ब्रिटिश कोलंबिया में अपने कैंपर वैन में था, रॉक क्लाइंबिंग कर रहा था। और मैं, आप जानते हैं, स्टार्टअप बनाने

00:57:00या जो कुछ भी हो, उससे बहुत दूर था। बस उन लोगों के साथ बातचीत कर रहा था, उन्हें

00:57:05वॉकथ्रू दे रहा था, जैसे मैं सोच रहा था और समस्या जो वे झेल रहे थे और उस तरह की

00:57:08चीजें। और फिर, और फिर धीरे-धीरे कुछ आता रहा, जैसे शायद सप्ताह में एक और मैं रॉक

00:57:13क्लाइंबिंग कर रहा होता। और मैं स्लैक (Slack) खोलता और यह स्लैक नोटिफिकेशन होता। हमारे पास हर

00:57:18साइनअप के लिए एक नोटिफिकेशन चैनल होता है, है ना? वही जो हमारे पास छह साल या उससे अधिक समय से है।

00:57:21इस बिंदु पर, यह नज़र रखना भी बहुत मुश्किल है क्योंकि यह बस

00:57:25तेज़ी से स्क्रॉल होता है। लेकिन, लेकिन हमारे पास उस चैनल में वह नोटिफिकेशन होता था। मैं

00:57:31कहता, 'ओह शिट', आप जानते हैं, किसी ने साइन अप किया है। क्या आप स्लैक को DDOS कर रहे हैं?

00:57:38नहीं, उन दिनों में बिल्कुल नहीं। लेकिन अभी, आपने कहा कि आपके पास अभी भी है। तो इसलिए

00:57:44मैं पूछ रहा हूँ। सही, सही, सही। मेरा मतलब है, चीजें अच्छी चल रही हैं, लेकिन मुझे नहीं लगता कि यह

00:57:48स्लैक को DDOS करने के स्तर पर है। ठीक है। खैर, तो दोस्तों, वहां से आगे बढ़ते हैं, लेकिन मुझे लगता है कि शुरुआत में एक मूल

00:57:54धारणा जो समस्याग्रस्त थी, वह यह विचार था कि यह मुख्य रूप से 'ऑब्ज़र्वेबिलिटी' (दृश्यता) के लिए बनाया गया है।

00:57:58मुझे लगता है कि यह पर्याप्त नहीं था। लेकिन एक बार जब आप यह कहते हैं कि,

00:58:02'मैं एक ऑब्ज़र्वेबिलिटी टूल बना रहा हूँ' से 'मैं एक मैसेज बस (message bus) का पुनर्निवेश कर रहा हूँ' तक जाते हैं, तो अचानक दायरा

00:58:08नाटकीय रूप से खुल जाता है। सही। इसलिए मैंने वास्तव में CTO और सह-संस्थापक से, पहले

00:58:15क्यूइंग इंजन बनाने के बीच में ही मुलाकात की। और, और इसलिए जब मुझे एहसास हुआ,

00:58:19कि दायरा इस पर पूरी तरह से खुल जाएगा। तो तभी

00:58:23हमने एक छोटे से प्री-सीड (pre-seed) के लिए, लेकिन एंजेल निवेशकों और उस तरह की चीजों के लिए भी

00:58:28प्रयास किया। सही। यह स्पष्ट था कि, आप जानते हैं, इसे बनाना काफी महंगा होगा,

00:58:32जो कि यह साबित हुआ कि इसे बनाना काफी महंगा था। और जैसा कि मैं समझता हूँ, आप

00:58:36विशिष्ट SF (सैन फ्रांसिस्को) रूट पर नहीं गए। आपने इसे मॉन्ट्रियल में बनाया, है ना?

00:58:39अह, हाँ, जो वास्तव में हुआ उसके लिए यह थोड़ा भ्रामक हो सकता है। तो हमने एक, हमने एक

00:58:44प्री-सीड राउंड किया, लगभग $400,000, सिर्फ एंजेल निवेशकों से, कोई संस्थागत VC (वेंचर कैपिटल) नहीं। लेकिन फिर

00:58:51कुछ महीनों के भीतर हमने अपना 'हैकर न्यूज़' (Hacker News) वाला राउंड किया और वास्तव में तभी हमें पता चला, अह, वापस

00:58:56आपके प्रश्न पर आता हूँ, जेम्स, जैसे, मुझे लगता है कि 'हैकर न्यूज़' की प्रतिक्रिया, मेरा मतलब है, यह

00:59:00सबसे बड़ी 'हैकर न्यूज़' वाली 'शो HN' (Show HN) नहीं थी, लेकिन यह उससे कहीं बेहतर थी जिसकी हमने

00:59:05कभी उम्मीद की थी, और एक मज़ेदार किस्सा है। लेकिन मुझे याद है, मुझे याद है वह एक व्यक्ति जिसने $300 का प्लान खरीदा था,

00:59:11है ना? HN के बाद। और मुझे याद है कि मेरे सह-संस्थापक और मुझे लगा, यार, हमने कर दिखाया।

00:59:18जैसे यह एक पक्का सौदा है। जैसे हम, हम निश्चित रूप से सफल हो रहे हैं।

00:59:22उस रात बाहर डिनर पर गए, सब खर्च कर दिया। यह कुछ अधिक है।

00:59:25हाँ, बिल्कुल वैसा ही है। सही। जैसे शैंपेन का कटोरा। हाँ। लेकिन, अह, खैर, वैसे,

00:59:31तो उस 'शो HN' से, उस तरह की चीजें। और फिर उस बिंदु पर, हमारे पास

00:59:34निवेशकों से बहुत रुचि थी जो सक्रिय रूप से संपर्क कर रहे थे और उस तरह की चीजें। और इसलिए हम,

00:59:38अंततः हमने सिलिकॉन वैली के निवेशकों से एक राउंड उठाया, एक फर्म जिसका नाम है मैट्रिक्स

00:59:44पार्टनर्स। तो हम अभी भी एक तरह से केंद्रित टीम पर आधारित हैं, कनाडाई कंपनी। हमने नहीं बदला है,

00:59:50डेलावेयर LLC (Delaware LLC) में, लेकिन उसी समय, मुझे लगता है कि हमारे निवेशक

00:59:55बहुत जबरदस्त रहे हैं और मुझे बहुत खुशी है कि हमने ऐसा किया। और मुझे लगता है कि, कोविड और

01:00:00बाकी सब चीजों की वजह से, शायद कंपनियों की बढ़ती स्वीकृति रही है जो इस पर आधारित

01:00:04नहीं हैं और रिमोट टीमें बनाती हैं, उस तरह की चीजें। मेरा मतलब है, बहुत से लोग

01:00:08ऐसा कर रहे हैं, हमने कुछ भी आविष्कार नहीं किया है, जैसे, अह, अभी भी ज़ैपियर (Zapier) और

01:00:12गिटलैब (GitLab) और वे सभी लोग हैं जो किसी और से कहीं अधिक समय से ऐसा कर रहे हैं।

01:00:17सही। तो मुझे लगता है कि इसने शायद इसे सामान्य कर दिया। और, यह कुछ ऐसा है जिसे मैंने कुछ देखा है,

01:00:21शायद मैं इस बारे में भोला हूँ, लेकिन यह कुछ ऐसा है जिसे मैंने कुछ संस्थापकों से देखा है। ऐसा लगता है, जैसे,

01:00:27आप जानते हैं, कनाडाई संस्थापकों के रूप में, यह बड़ी चर्चा और एक तरह का कनाडाई संस्थापक ट्विटर है,

01:00:32आप जानते हैं, डेलावेयर में निगमित होना और YC ने कनाडाई कंपनियों को स्वीकार करना बंद कर दिया था। और फिर

01:00:38उन्होंने उस निर्णय को वापस ले लिया और सब कुछ। लेकिन यह समझ थी

01:00:42कि हर निवेशक आपसे डेलावेयर LLC बनने के लिए कहेगा। और, और वे सही हैं।

01:00:47हर निवेशक आपसे पूछेगा, उस कहानी में जो कमी है वह यह है कि आप बस 'नहीं' कह सकते हैं।

01:00:54अह, तो हाँ, निश्चित रूप से। वे पूछेंगे कि, आप जानते हैं, 'क्यों नहीं?' और यह उनके लिए आसान है,

01:00:58लेकिन पता चला कि अगर आप बस 'नहीं' कहते हैं, तो यह भी पूरी तरह से ठीक है। तो कम से कम मेरे अनुभव में और

01:01:03बहुत से लोग जो मेरे आसपास हैं, वगैरह। तो मुझे लगता है कि यह उस कहानी का गुमनाम हिस्सा है, सही।

01:01:07दिन के अंत में, वे देख रहे हैं, उनका काम पूंजी तैनात करना है। वे निवेश करने के लिए

01:01:11लोगों की तलाश कर रहे हैं या मूल विचारों की तलाश कर रहे हैं और उस तरह की चीजें। मेरा

01:01:15मतलब, मैं इसके फायदे और नुकसान के बारे में बहस नहीं करना चाहता। और मुझे यकीन है कि इसके बहुत सारे

01:01:19सकारात्मक पहलू हैं, लेकिन आप जानते हैं, दिन के अंत में, यह एक संस्थापक और

01:01:24बिल्डर के रूप में आपकी पसंद है, कि आप किसके साथ यह करने वाले हैं और कहां करने वाले हैं।

01:01:27और मुझे लगता है कि यदि आपके पास अच्छे विचार हैं और आप इसके पीछे काम करते हैं, तो निवेशक अभी भी

01:01:31इसका सम्मान करेंगे, या कम से कम, कम से कम कुछ निवेशक अभी भी इसका सम्मान करेंगे। सही। और शायद आपका

01:01:36काम उन्हें खोजना है, लेकिन हाँ। तो मुझे लगता है कि यह कहना भ्रामक होगा कि हम पूरी तरह से

01:01:41उस बुलबुले के बाहर हैं, लेकिन, अह, लेकिन जैसे मैं व्यक्तिगत रूप से,

01:01:47आप जानते हैं, मैंने अपना जीवन यहाँ बनाया है और आप जानते हैं, मैं व्यक्तिगत रूप से अभी भी मॉन्ट्रियल में रहकर बहुत खुश हूँ। खैर, एक साथी कनाडाई के रूप में, यह

01:01:52कनाडाई सफलता की कहानियों के बारे में सुनना अच्छा है। तो उसके लिए बधाई, लेकिन फिर आप टोरंटो चले गए और फिर आपने

01:01:57बस सब कुछ खराब कर दिया। उचित, उचित। क्या मैं एक साथी कॉमनवेल्थ (Commonwealth) के रूप में कह सकता हूँ, जैसे महान, सही? समान

01:02:06राजा। यह एक ही बात है, आप जानते हैं, सही? हाँ। हाँ। हमारे पास रानी है। मेरा मतलब है,

01:02:11मुझे नहीं पता कि क्या उन्होंने अब राजा को अपडेट कर दिया है, लेकिन हमारे पास हमारे नोट पर रानी थी।

01:02:14हाँ। क्या हुक डेक (Hookdeck) एक संस्थापक के रूप में आपका पहला स्टार्टअप था या यात्रा में अन्य लोग थे जिन्होंने आपको

01:02:19निवेशकों तक पहुंचने और उन्हें खोजने का तरीका सिखाया। मैं हमेशा

01:02:23शुरुआत से ही बहुत उद्यमी रहा हूँ, इस तरह की छोटी कंपनियों में, जैसे

01:02:27सेवानिवृत्त क्षेत्र में जाना, 14 या 15 साल की उम्र में कंप्यूटर मरम्मत करना आदि। सही। उम, तो मुझे लगता है कि

01:02:34इस अर्थ में, कि अधिक उद्यमी भावना से बात करना, लेकिन नहीं, मुझे लगता है कि

01:02:38अधिकांश भाग असफल साइट प्रोजेक्ट्स थे, जैसे एक वीडियो गेम जारी करना जो मूल रूप से कहीं नहीं

01:02:44पहुंचा। आप जानते हैं, बहुत सी अन्य चीजें, जैसे किसी बिंदु पर मैं कुछ सोशल

01:02:48नेटवर्क पर काम कर रहा था, इस तथ्य के बावजूद कि मैं शायद सामाजिक समारोहों में सबसे

01:02:53बुरा व्यक्ति हूँ और दोस्तों के साथ चीजों को व्यवस्थित करने में। वैसे भी, चीजों के चरणों से गुज़रा हूँ। मैं कहूँगा,

01:02:58यह अनुभव, ई-कॉमर्स कंपनी में, यह वास्तव में बहुत प्रभावशाली था,

01:03:03जैसे मैं वहां पहले कर्मचारी के रूप में शामिल हुआ और बहुत अधिक संस्थापक टीम के साथ जुड़ा हुआ था।

01:03:07और हम, आप जानते हैं, मूल रूप से चार लोगों से लगभग 40 हो गए

01:03:13तीन साल में। और, आप जानते हैं, उस व्यवसाय के निर्माण की सभी प्रक्रिया और सब कुछ,

01:03:19वह सब कुछ वहां। तो, तो मुझे लगता है कि मैं हुक डेक के बारे में बहुत कुछ इस तरह सोचता हूँ,

01:03:23पहला वाला, लेकिन इसे पूरी तरह से उस रूप में रखना भ्रामक होगा। मुझे लगता है कि वहां

01:03:27उससे पहले उन चीजों का कुछ अनुभव था। और स्पष्ट रूप से मेरे पास यह ई-कॉमर्स

01:03:31कंपनी थी। जैसे हम, हमने निवेशकों के साथ भी काम किया और आप जानते हैं, बोर्ड और उस तरह की चीजें

01:03:36और वहां भी संबंध बनाए। और फिर उस ई-कॉमर्स

01:03:39व्यवसाय में पहला निवेशक हुक डेक में हमारा पहला प्रारंभिक निवेशक भी था। तो यह पूरी तरह से

01:03:44शून्य से शुरू नहीं करना था, जैसा कि कुछ लोग खुद को पाते हैं, लेकिन हाँ,

01:03:48मुझे लगता है कि मुझे अभी भी यहां होने की उम्मीद नहीं थी, आप जानते हैं, कुछ साल पहले। और यह बहुत अच्छा है।

01:03:54मैंने देखा कि 'कीवी मॉर्निंग्स' (Kiwi Mornings) नाम की एक कंपनी है, स्वस्थ नाश्ते का स्टार्टअप। वह सब क्या था?

01:04:02और फिर आपका होमवर्क। तो, तो वह रास्ते में असफल व्यवसायों में से एक था।

01:04:09मैंने इसे अपनी पत्नी के साथ शुरू किया था। हम वास्तव में, कहानी यह है कि मेरी पत्नी,

01:04:14काम पर अपना नाश्ता ला रही थी और काम पर सभी सेल्स वाले उसके नाश्ते से थोड़े ईर्ष्यालु थे

01:04:19और उससे नाश्ता मांगने लगे। और मैं कह रहा था, आप सेल्स

01:04:24वालों के नाश्ते का क्या मतलब है? क्या गलत है? लेकिन फिर एक चीज़ से दूसरी चीज़ हुई और वह शायद हर सुबह

01:04:30सेल्स टीम के लिए पाँच या छह नाश्ते बना रही थी। और वे कहते थे, आह, हम क्यों नहीं,

01:04:36आप जानते हैं, उन बेवकूफी भरे विचारों में से एक, हम इससे व्यवसाय क्यों नहीं बना लेते? और इसलिए

01:04:41हमने काम पर शून्य-अपशिष्ट नाश्ते के लिए यह सेवा बनाई। और इसलिए हम डिलीवर करते हैं जैसे

01:04:47दही और स्मूदी और चिया पुडिंग और उस तरह की चीजें और कांच के छोटे जार।

01:04:51और हमारे पास कार्यालयों में छोटा फ्रिज होता है। और, और मैं, मैं इसे

01:04:56बहुत दूर ले गया। और जैसे प्रोडक्ट और इंजीनियरिंग पक्ष, जैसे यह सब ऑर्डर स्लैक

01:05:01बॉट के माध्यम से होते थे और, अह, नियोक्ता इसे कर्मचारी लाभ के रूप में रख सकते थे, जहाँ अनिवार्य रूप से

01:05:06वे नाश्ते का 50% भुगतान करते थे। और आप जानते हैं, यह एक पूरी चीज थी।

01:05:11और इसलिए हाँ, लोग स्लैक बॉट के माध्यम से अपना नाश्ता ऑर्डर करते थे और सब कुछ, जरूरी नहीं

01:05:16कि यह खत्म हो गया। बस इतना ही कि उस व्यवसाय में, सब कुछ सुबह चार बजे गलत हो जाता है

01:05:20और साथ ही भोजन में कोई पैसा नहीं है। और जब आप उन दो चीजों को जोड़ते हैं, तो यह एक

01:05:25संतोषजनक व्यवसाय बनाना बहुत मुश्किल है। और फिर किसी बिंदु पर हम, हमने स्लैक बॉट को बेचना समाप्त

01:05:29कर दिया और सब कुछ और इसे बंद कर दिया। उम, लेकिन शुक्र है,

01:05:34वह जनवरी, 2021 में था। तो कोविड से दो महीने पहले। उम, और फिर अनिवार्य रूप से हर

01:05:42समतुल्य कंपनी, जैसे उनमें से बहुत से लोग पहले से ही लंच कर रहे थे और उस तरह की

01:05:46चीजें, जैसे कार्यालय का लंच और वह सब। मूल रूप से हर कोई व्यवसाय से बाहर हो गया। तो, अह, हम

01:05:52टाइमिंग के मामले में थोड़े भाग्यशाली थे क्योंकि यह चाहे जो भी हो, समाप्त हो जाना था। सही। जैसे,

01:05:57हाँ। लेकिन कुल मिलाकर, मुझे लगता है कि हमने शायद 20,000 नाश्ते बेचे थे या कुछ और।

01:06:01ओह, बहुत बढ़िया। हाँ। यह बहुत अच्छा है।

01:06:06ओह हाँ। तो हम हमेशा, हाँ, हम हमेशा अपने मेहमानों से पूछते हैं, आपके 'हॉट टेक्स' (hot takes) क्या हैं

01:06:12उद्योग के बारे में, AI के बारे में, जो कुछ भी हो, आगे बढ़ें। मुझे लगता है कि मैंने इस बातचीत में पहले ही कुछ दे दिए हैं।

01:06:18मुझे लगता है कि आपने दिए हैं। हाँ। आपका सबसे हॉट टेक क्या है? जैसे बिल्कुल जलता हुआ।

01:06:22जलता हुआ टेक। ठीक है। यह शायद वह जगह है जहाँ मैं आपको खो दूँगा क्योंकि यह बहुत ज्यादा

01:06:29इवेंट-ड्रिवन आर्किटेक्चर की गहराई में है। मुझे यकीन है कि हमारे दर्शकों के कुछ सदस्य समझेंगे कि आप क्या

01:06:35कह रहे हैं। बिल्कुल। तो मेरा सबसे हॉट टेक, अह, हॉट टेक यह है कि पोल-आधारित उपभोक्ता या पोल-आधारित क्यूइंग

01:06:42सिस्टम, पुश-आधारित सिस्टम की तुलना में बहुत गूंगे होते हैं। और हम इस

01:06:49पुश-आधारित सिस्टम को क्यों नहीं अपना पाए हैं, इसका कारण यह है कि कोई भी क्यू (queue) अच्छा पुश-आधारित सिस्टम नहीं बनाता है। और मैं यह क्यों कह रहा हूँ,

01:06:56और अब मैं इसे थोड़ा संदर्भ देने की कोशिश करूँगा, वह यह है कि जब आप क्यूज़

01:07:02और उपभोक्ता बनाते हैं, तो हर उस क्यू के लिए जिसमें आप इवेंट डालते हैं, आपको उसके लिए एक उपभोक्ता चाहिए। और वह

01:07:07उपभोक्ता एक तरह का लंबे समय तक चलने वाला वर्कर हो सकता है जो उस क्यू को खींच रहा हो। लेकिन

01:07:12समस्या यह है कि यदि आप गतिशील रूप से क्यूज़ रखना चाहते हैं, तो चलिए कहते हैं कि आप प्रति ग्राहक एक क्यू रखना चाहते हैं,

01:07:16क्योंकि आप नहीं चाहते कि एक ग्राहक पूरी क्यू को खराब कर दे या

01:07:21उनकी आवंटित क्षमता को, उस तरह की चीजें। अब आपको उतने ही उपभोक्ता चाहिए जितने आपके पास

01:07:26क्यूज़ हैं, जो पागलपन हो जाता है क्योंकि आपके पास यह मल्टीप्लेक्सिंग समस्या है जहाँ प्रत्येक क्यू को अपने

01:07:31उपभोक्ता की आवश्यकता होती है। पुश-आधारित सिस्टम का बड़ा फायदा यह है कि वे सभी क्यूज़ एक ही

01:07:36उपभोक्ता को पुश कर सकती हैं। और इसलिए वह एक उपभोक्ता एक API हो सकता है जिसके सामने एक लोड बैलेंसर हो जिसे आप

01:07:41क्षैतिज रूप से, या मेरा मतलब है, या लंबवत रूप से, जो भी हो, स्केल कर सकते हैं। लेकिन बात यह है कि, आप

01:07:45यह पूरी तरह से इस बात से अलग कर सकते हैं कि आपके पास वास्तव में कितनी क्यूज़ हैं। और मुझे लगता है कि एक बात जो हम

01:07:49देख रहे हैं, वह यह है कि जैसे ही आप अधिक से अधिक जटिल उपयोग के मामलों में जाते हैं, तो आपके पास अधिक

01:07:54और अधिक बारीक तरीके होते हैं जिनसे आप चीजों को क्यू करना चाहते हैं। तो आप प्रति विषय और प्रति विशिष्ट

01:07:58शर्तों और प्रति ग्राहक और उस तरह की चीजों के आधार पर क्यू करना चाहते हैं। और यह पूरी तरह से पागलपन हो जाता है क्योंकि तब आपके पास

01:08:02100 क्यूज़ और 100 उपभोक्ता और 100 डॉलर क्यूज़ और वह सारी गंदगी होती है जो उनके साथ आती है।

01:08:07लेकिन आज पुश-आधारित मैसेज क्यूज़ ढूंढना बहुत मुश्किल है।

01:08:13और इसका कारण यह है कि आप बदल रहे हैं कि थ्रूपुट कहाँ नियंत्रित किया जा रहा है। यदि

01:08:17थ्रूपुट उपभोक्ता में नियंत्रित किया जा रहा है, तो प्रत्येक उपभोक्ता यह कहने के लिए जिम्मेदार है कि, 'हे, मैं चाहता हूँ

01:08:2250 संदेश प्रति सेकंड या समवर्ती रूप से या जो भी हो। और फिर आप कितने संदेशों का उपभोग कर रहे हैं, वह क्या बन जाता है,

01:08:29एक वर्कर की क्षमता क्या है? आपके पास कितने वर्कर हैं? और प्रभावी

01:08:33क्षमता क्या है? ऐसा नहीं है कि आप कहते हैं कि आप प्रति सेकंड 50 चाहते हैं। यह वास्तव में 50 प्रति सेकंड पर जा रहा है,

01:08:37क्योंकि यह बाकी कोड पर निर्भर करता है और वह पर्याप्त तेज़ है या नहीं, आदि।

01:08:40सही। तो मुझे लगता है कि हम पुश-आधारित क्यूज़ की ओर क्यों नहीं बढ़े हैं, वह यह है कि उनमें से अधिकांश

01:08:45वास्तव में आपको आवश्यक ग्रैन्युलैरिटी और थ्रूपुट नियंत्रण नहीं देते हैं। तो उदाहरण के लिए,

01:08:50जैसे GCP पब/सब (Pub/Sub) में पुश मोड है, लेकिन पुश मोड में, वे मूल रूप से उस दर को बढ़ाते हैं जिस पर

01:08:55आप अपने अनुरोध भेजते हैं जब तक कि आपका API धीमा होना शुरू न हो जाए, जिस बिंदु पर उन्होंने इसे मूल रूप से

01:09:00घटा दिया है। और फिर एक बार जब यह धीमा होना शुरू हो जाता है, तो वे डिलीवरी दर को वापस नीचे कर देते हैं। और तो आप

01:09:06अंततः पाते हैं कि यह रेंगता है, रेंगता है, रेंगता है, सर्वर क्रैश या गंभीर प्रदर्शन गिरावट,

01:09:11वापस शून्य पर चला जाता है, और फिर रेंगता है, रेंगता है, रेंगता है, रेंगता है, सब कुछ

01:09:15वापस शून्य पर चला जाता है। और यह बिल्कुल गूंगा है। इसका कोई मतलब नहीं है। सही। और मुझे लगता है कि यदि आप

01:09:20पुश-आधारित मैसेज क्यूज़ बनाते हैं, और वह उन खोजों में से एक है जिसमें मैं हूँ जहाँ आपके पास थ्रूपुट पर बहुत सटीक

01:09:24नियंत्रण होता है और उपभोग दर का सटीक व्यवहार, यह आपके आर्किटेक्चर के बहुत कुछ को सरल बनाता है।

01:09:29तो यह मेरा हॉट टेक है उन लोगों के लिए जो जानते हैं, लेकिन, लेकिन, मैं मरने के लिए तैयार हूँ।

01:09:34मेरा मतलब है, मुझे इसका सब कुछ समझ नहीं आया, लेकिन यह उचित लग रहा था, आप जानते हैं?

01:09:40मुझे लगता है कि यदि आपको वह समझ में आया, तो हुक डेक (Hookdeck) देखें। हाँ, बिल्कुल।

01:09:46इसकी सराहना करता हूँ, हाँ। खैर, धन्यवाद, एलेक्स। बेटर स्टैक पॉडकास्ट के इस एपिसोड को सुनने के लिए धन्यवाद।

01:09:50हमें वहां ढूंढें जहाँ भी आप अपने पॉडकास्ट प्राप्त करते हैं, स्पॉटिफ़ाई, एप्पल म्यूज़िक, या कहीं और।

01:09:57लेकिन आज मेरे लिए अलविदा है। मेरे लिए अलविदा। और मेरे लिए अलविदा।

핵심 요약

वेबहुक्स को एक इवेंट गेटवे के जरिए मानकीकृत और प्रबंधित करना, रीयल-टाइम एआई एजेंट वर्कफ़्लोज़ और जटिल सिस्टम इंटीग्रेशन के लिए स्केलेबल और विश्वसनीय आधार प्रदान करता है।

하이라이트

हुकडेक (Hookdeck) वेबहुक्स के लिए एक इवेंट गेटवे प्रदान करता है जो फिल्टरिंग, ट्रांसफॉर्मेशन, रूटिंग और अलर्टिंग जैसी क्षमताएं देता है।
आउटपोस्ट (Outpost) एक ओपन-सोर्स Apache 2.0 प्रोजेक्ट है जो संगठनों को अपने एंडपॉइंट्स पर सीधे इवेंट प्रकाशित करने और प्रबंधित करने की अनुमति देता है।
इवेंट गेटवे का उपयोग वेबहुक के ट्रांसपोर्ट को मानकीकृत करने के लिए किया जाता है, जिससे डेवलपर्स को कस्टम इनजेशन और SQS जैसी जटिल कतारों को दोबारा बनाने की आवश्यकता नहीं होती।
एआई एजेंट्स के उदय ने इवेंट-ड्रिवन आर्किटेक्चर की मांग को बढ़ा दिया है क्योंकि एजेंट्स को ट्रिगर करने के लिए रीयल-टाइम इवेंट्स की आवश्यकता होती है।
पुश-आधारित क्यूइंग सिस्टम, पोल-आधारित सिस्टम की तुलना में अधिक कुशल हैं क्योंकि वे प्रति-ग्राहक क्यू के बजाय एक ही उपभोक्ता को अनुरोध भेज सकते हैं।

타임라인

वेबहुक्स और इवेंट गेटवे की भूमिका

हुकडेक वेबहुक्स को मानकीकृत करने के लिए एक इवेंट गेटवे के रूप में कार्य करता है।
आउटपोस्ट प्रोजेक्ट इवेंट्स के प्रकाशक (publisher) के लिए एक मैनेज्ड सर्विस प्रदान करता है।
इवेंट गेटवे वेबहुक्स के अलावा अन्य IoT और SDK-आधारित उपयोग के मामलों का भी समर्थन करता है।

हुकडेक का उद्देश्य वेबहुक्स को खत्म करना नहीं, बल्कि उन्हें एक सिंगल कॉन्ट्रैक्ट में मानकीकृत करना है। यह इवेंट गेटवे के माध्यम से फ़िल्टरिंग, क्यूइंग और अलर्ट प्रबंधन की सुविधा देता है। आउटपोस्ट का उपयोग करके डेवलपर्स अपने इवेंट डेस्टिनेशंस और डिलीवरी गारंटी को व्यवस्थित कर सकते हैं।

इवेंट-संचालित आर्किटेक्चर और चुनौतियां

वेबहुक्स अक्सर एसिंक्रोनस प्रोग्रामिंग की जटिलताओं को छुपाते हैं।
इवेंट-संचालित आर्किटेक्चर को अपनाने के लिए इन-पोटेंसी और ऑर्डरिंग गारंटी महत्वपूर्ण है।
डेवलपर्स अक्सर जटिलता के कारण डेड लेटर क्यू और रिट्राई सिस्टम को सही से नहीं बना पाते।

यह टूल उन डेवलपर्स की निराशा से पैदा हुआ है जो वेबहुक्स को संभालते समय HTTP अनुरोधों की सीमाओं से जूझते हैं। बड़ी प्रणालियों में, वेबहुक्स की अनिश्चितता और विभिन्न वेंडरों के अलग-अलग मानकों को सुलझाना कठिन होता है। सही टूल्स न होने के कारण डेवलपर्स को अक्सर अपना स्वयं का क्यूइंग इन्फ्रास्ट्रक्चर बनाना पड़ता है।

AI का प्रभाव और आउटपोस्ट ओपन सोर्स

ओपन सोर्स दृष्टिकोण से डेवलपर्स को टूलिंग शुरू करने में आसानी होती है।
LLM-आधारित ऐप्स के बढ़ते उपयोग से रीयल-टाइम इवेंट्स की मांग बढ़ी है।
इवेंट्स अब मानवीय हस्तक्षेप के बजाय एआई एजेंट्स को ट्रिगर करने के लिए उपयोग किए जा रहे हैं।

LLM विकल्पों के कारण अब ग्राहक सहायता और मार्केटिंग जैसे क्षेत्रों में भी रीयल-टाइम इवेंट्स की आवश्यकता हो रही है। आउटपोस्ट के ओपन-सोर्स होने से समुदाय ने अपने स्वयं के फीचर्स लागू किए हैं, जो टूल की उपयोगिता को बढ़ाते हैं। यह दृष्टिकोण उन डेवलपर्स के लिए है जो जटिलता के बिना इवेंट्स का लाभ उठाना चाहते हैं।

AWS इवेंटब्रिज और प्रतिस्पर्धा

AWS इवेंटब्रिज मुख्य रूप से AWS इकोसिस्टम के लिए सीमित है।
हुकडेक का लक्ष्य विक्रेता-अज्ञेयवादी (vendor-agnostic) समाधान प्रदान करना है।
इवेंट गेटवे का उद्देश्य किसी वेंडर द्वारा ऑप्ट-इन की आवश्यकता को खत्म करना है।

AWS इवेंटब्रिज के विपरीत, जो केवल AWS सेवाओं के साथ अच्छी तरह एकीकृत होता है, इवेंट गेटवे किसी भी URL को एक इवेंट डेस्टिनेशन के रूप में उपयोग कर सकता है। यह बिना किसी कोड रिडेप्लॉयमेंट के विभिन्न क्लाउड स्टैक के साथ काम करता है। इससे डेवलपर्स को वेंडर लॉक-इन से आजादी मिलती है।

डाउनटाइम और वेंडर की जिम्मेदारी

डिलीवरी लेटेंसी का पता लगाना डेटा-संचालित इवेंट मॉनिटरिंग के बिना कठिन है।
वेंडर आउटेज के दौरान बड़ी मात्रा में इवेंट्स का बैकलॉग सर्वर पर भारी दबाव डाल सकता है।
एजेंटिक वर्कफ़्लो में इवेंट्स की समयबद्धता अत्यंत महत्वपूर्ण हो जाती है।

बड़ी कंपनियों में डाउनटाइम के मीम्स आम हो गए हैं, जिससे डिलीवरी लेटेंसी को ट्रैक करना और भी जरूरी है। जब वेंडर (जैसे Shopify या Stripe) रिकवर होते हैं, तो वे एक साथ बहुत सारे इवेंट्स भेजते हैं। एक पुश-आधारित सिस्टम डेवलपर्स को यह समझने में मदद करता है कि लेटेंसी वेंडर के कारण है या उनके अपने कोड के कारण।

भविष्य की संभावनाएं और हॉट टेक

इवेंट गेटवे एक उभरती हुई उत्पाद श्रेणी है जो पब/सब और एपीआई गेटवे को जोड़ती है।
पुश-आधारित क्यूइंग सिस्टम पोल-आधारित सिस्टम की तुलना में बेहतर स्केलेबिलिटी प्रदान करते हैं।
एजेंटिक सिस्टम के लिए थ्रूपुट प्रबंधन और क्षमता प्रबंधन में सुधार आवश्यक है।

एलेक्स का मानना है कि पोल-आधारित सिस्टम जटिलता को बढ़ाते हैं क्योंकि प्रत्येक क्यू के लिए एक अलग उपभोक्ता की आवश्यकता होती है। पुश-आधारित क्यूइंग सिस्टम इस समस्या को सुलझाते हुए एक ही उपभोक्ता को कई क्यूज़ से डेटा लेने की अनुमति देते हैं। यह आर्किटेक्चरल दृष्टिकोण इवेंट-ड्रिवन सिस्टम को सरल और अधिक कुशल बनाने का भविष्य है।

커뮤니티 글

모든 글 보기

이 영상에 대해 글쓰기