هندسة البرمجيات القائمة على الأحداث، فوضى الخطافات (Webhooks)، وصعود وكلاء الذكاء الاصطناعي | بودكاست Better Stack الحلقة 17
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술
스크립트
00:00:00مرحباً بكم في بودكاست Better Stack، حيث نجري حوارات حول تطوير البرمجيات،
00:00:04والذكاء الاصطناعي، وكل ما هو جديد في عالم التقنية. أنا أحد مضيفيكم، أندروس، وينضم إلي اليوم
00:00:10جيمس وأليكس. أهلاً أليكس، مرحباً بك في البرنامج. شكراً لاستضافتي يا رفاق. لنبدأ بالحديث
00:00:16عن الشركة التي تديرها، وهي Hookdeck. لمن لا يعرفها،
00:00:22ما هي Hookdeck؟ وماذا تفعل؟ أخبرنا المزيد عنها. حسناً، أحب أن أعتبرها
00:00:27شركة الخطافات البرمجية (Webhooks) التي تحاول القضاء على الخطافات البرمجية. هذه قصة يمكننا الخوض فيها.
00:00:32لكننا نبني منتجين رئيسيين. الأول هو بوابة الأحداث (Event Gateway). تعمل بوابة الأحداث
00:00:37كناقل أحداث متخصص لجميع الأحداث القادمة من خارج بنيتك التحتية.
00:00:41الخطافات البرمجية هي المشتبه به الأول، لكننا نرى الكثير من حالات استخدام إنترنت الأشياء (IoT) ومجموعات تطوير البرمجيات (SDKs) وغيرها.
00:00:47لذا بشكل أساسي، نحن نوفر نقطة نهاية غير موثوقة. يمكنك إرسال أي أحداث إليها.
00:00:51ثم تتوفر كافة الإمكانات لإدارة تلك الأحداث. وهذا يشمل التصفية،
00:00:55والتحويل، والتوجيه، ووضعها في طوابير، والتنبيه، وإدارة المشكلات، وإعادة التشغيل؛ باختصار، كل شيء.
00:01:01لذا فهي تغطي كلاً من جوانب التشغيل البيني، بمعنى أنني بحاجة إلى استقبال
00:01:05الأحداث والخطافات البرمجية من جميع البائعين الذين أعمل معهم، صحيح؟ قد يكون ذلك Stripe، أو Shopify، أو Twilio،
00:01:10أو WhatsApp، أو TikTok، أو أي منصة أخرى. لكل منهم معاييره الخاصة وخصائصه
00:01:16ومتطلباته المحددة. لذا يمكننا توحيد كل ذلك وإدراجه
00:01:20ضمن عقد واحد. وكل ما يتعلق بوجهة نظر الطوابير. فعلى سبيل المثال،
00:01:27في Shopify، قد يحدث تخفيض مفاجئ (Flash Sale) في متجرك وتتعرض
00:01:31لضغط هائل من الأحداث. نحن نقوم بتطبيع ذلك حتى تتمكن من التحكم في الإنتاجية وبوابة الأحداث
00:01:38وكل ذلك. هذا جزء كبير من الأمر. إنه يشبه جانب المستهلك. وهنا
00:01:42بدأت قصة Hookdeck بالفعل. ومؤخراً، أطلقنا أيضاً Outpost. Outpost هو مشروع مفتوح المصدر بالكامل
00:01:49بترخيص Apache 2.0. ولدينا الآن خدمة مُدارة له أيضاً. وهو مخصص لإرسال
00:01:55الأحداث. لذا فهو الجانب الآخر من المعادلة، صحيح؟ أنت كناشر، كمنصة، أو كأداة تطوير،
00:01:59في هذه المرحلة، الجميع يرسلون الأحداث. أنا أتفاجأ
00:02:05كل يوم. لذا Outpost هي خدمة مُدارة أو ذاتية الاستضافة يمكنك استخدامها لتعريف
00:02:12من هم المستأجرون لديك، وما هي الوجهات، ونقاط النهاية التي قاموا بتسجيلها، وتكوين
00:02:17المواضيع ونشر الأحداث إليها. وتتعامل مع كل شيء بدءاً من الرؤية، والمقاييس، وضمانات التسليم،
00:02:23وعمليات إعادة المحاولة، وكل ما هو معتاد حول التوقيعات، وتدوير التوقيعات،
00:02:28وكل ذلك. المزحة التي كنت أقولها حول محاولة القضاء على الخطافات البرمجية هي أن Outpost،
00:02:35نعم، تسمح لك بإرسال الخطافات البرمجية، ولكنها تسمح لك أيضاً بنشر الأحداث مباشرة إلى ناقل رسائل المستخدم الخاص بك.
00:02:39وبالتالي تدعم Outpost محلياً ما يُعرف الآن بوجهات الأحداث. والخطاف البرمجي يُعتبر
00:02:46بمثابة موجه النقل. وأنت تقوم بشكل أساسي بإرسال الأحداث عبر الخطافات البرمجية
00:02:53والخطافات البرمجية هي آلية النقل القياسية، صحيح؟ ويمكنك اختيار بروتوكولات نقل جديدة، مثل MQ
00:02:59لـ RabbitMQ أو Kafka. ونحن ندعم أيضاً النشر المباشر لجميع الخدمات المعتادة مثل Pub/Sub،
00:03:05و SQS و AWS EventBridge، وبالطبع بوابة أحداث YokeDeck، أليس كذلك؟ لذا أحب أن أعتبرها
00:03:12الوجهة الأفضل، لكن سنرى إن كان الناس سيصدقون ذلك. إذاً قلت أنك تريد القضاء على الخطافات البرمجية. أتخيل أن هذه الفكرة
00:03:18في بدايتها جاءت من حقيقة أنكم جميعاً سئمتم من الخطافات البرمجية أو أنها كانت
00:03:25صعبة الإدارة. أخبرنا عن كيفية توصلك لهذه الفكرة. نعم، كنت أحكي القصة
00:03:31لشخص ما بالأمس. قبل حوالي خمس سنوات، نشرت هذا المقال على Medium.
00:03:37ربما نقترب من ست سنوات الآن. وكان عنوان المقال، تماشياً مع ما
00:03:42تقوله: “الخطافات البرمجية سيئة، ولكن هناك شيء يمكنك القيام به حيال ذلك.” وكان ذلك مجرد عملي في
00:03:48القبو، كما تعلم، كنت أعبث وأبني نموذجاً أولياً لـ Hookdeck.
00:03:54لكن الأمر نبع حقاً من ذلك الإحباط. كنت أعمل شخصياً في التجارة الإلكترونية، وقمنا ببناء
00:03:59الكثير من البرمجيات المخصصة لتشغيل التجارة الإلكترونية، من إدارة الاشتراكات المخصصة إلى
00:04:05المستودعات والتنفيذ وكل هذا النوع من الأشياء. وكانت الكثير من مشاكلنا
00:04:10تتلخص في الخطافات البرمجية. وكان الأمر أشبه بنكتة متكررة لأنه من ناحية،
00:04:15كنت أحاول بيع أعمال أزياء نسائية، صحيح؟ كنت أحاول بيع
00:04:18الملابس الداخلية والجوارب وغيرها. ومن ناحية أخرى، كان السؤال: أين بحق الجحيم
00:04:23الخطاف البرمجي؟ ماذا حدث له؟ شعرت بوجود عدم توافق في الاهتمامات.
00:04:28وهكذا نبع الأمر حقاً من ذلك، من كوني محبطاً كمستهلك لتلك الخطافات البرمجية
00:04:33لأنه لا توجد طريقة عملية شاملة (batteries included) للتعامل مع هذه
00:04:38المشكلة. وإذا بحثت عبر الإنترنت عن توصيات،
00:04:43أعني، الخطافات البرمجية ليست جديدة. في نهاية المطاف، إنها طلبات HTTP. هناك
00:04:46بوضوح أنماط ثابتة حول كيفية التعامل مع هذا. لكنك
00:04:50سرعان ما تدخل في دوامة. حسناً، تحتاج إلى مستهلكي استيعاب يمكنهم التوسع تلقائياً،
00:04:55ثم تحتاج إلى طابور مثل SQS. وبعد ذلك، تحتاج إلى نشر مجموعة من
00:05:00المستهلكين الذين سيقومون بالاستهلاك من SQS. وإذا حدث خطأ ما، فسوف ينتهي الأمر
00:05:05في طابور الرسائل الميتة (Dead-letter queue). ثم تحتاج إلى نص برمجي لتتمكن من التعافي من ذلك الطابور
00:05:09وفهم سبب انتهائها هناك في المقام الأول. وهناك كل تلك المخاوف.
00:05:14ومع زيادة التعقيد، سترغب أيضاً في أن تكون قادراً على إعادة تشغيل الأحداث التاريخية التي
00:05:18تلقيتها. وترغب في رؤية ما كانت عليه حمولة الخطاف البرمجي بالتحديد.
00:05:22ثم تبدأ في التعامل مع بائعين مختلفين، فربما Stripe سيعطيك واجهة مستخدم،
00:05:26بينما Intercom لن يعطيك واجهة. ولديك كل تلك
00:05:31الخصائص المختلفة التي يجب أن تتعامل معها. وهكذا نبع الأمر من ذلك الإحباط،
00:05:35ومن سؤال: لماذا لا يوجد حل لهذا؟ في البداية، كنت أنظر للأمر من
00:05:41منظور الملاحظة (Observability) ولم ينجح الأمر حقاً. الجزء الذي فاتني هو أن الملاحظة
00:05:47هي جزء واحد فقط. في النهاية، لدي مقولة أسمي فيها الخطاف البرمجي “المخدر الممهد”
00:05:51للهندسة المعتمدة على الأحداث. والسبب في ذلك، وهو أيضاً سبب إصراري على
00:05:56مصطلح “حدث” بدلاً من “خطاف برمجي”، هو أن وراء كل خطاف برمجي يوجد حدث، ويوجد
00:06:01الآن نماذج هندسية معتمدة على الأحداث تأتي مدمجة مع ذلك الخطاف، صحيح؟ وهكذا في كل مرة
00:06:07تتلقى فيها خطافاً برمجياً لأي نطاق جاد أو مستوى من حالات الاستخدام الحرجة، عليك الآن التفكير في
00:06:14التعامد، والترتيب، وضمانات التسليم، وكل نوع من
00:06:19التحديات التي تواجهها بمجرد أن تبدأ التعامل مع نماذج البرمجة غير المتزامنة المعتمدة على الأحداث.
00:06:25لذا، الكثير مما بنيناه تطور في النهاية إلى بناء طابور كامل
00:06:29في نهاية المطاف. إذاً هناك هذا التشغيل البيني الذي يضمن أننا نتعامل مع أحداث،
00:06:33ولكن كل تلك الدلالات تتعلق بالتعامل مع الأحداث وأنظمة الناشرين والمشتركين
00:06:38وما إلى ذلك بشكل عام. ولم نأت من مكان نحاول فيه إعادة اختراع الطوابير. أعتقد أننا
00:06:43عثرنا على مجموعة من الأفكار الرائعة. وشيء واحد نراه الآن هو أن
00:06:48الناس ينتقلون بالفعل إلى Hookdeck لاستبدال Pub/Sub أو SQS من حزمتهم البرمجية، وهو أمر
00:06:53بالنسبة لي محير للعقل لأننا لا ندير شبكتك الافتراضية الخاصة وكل تلك الأشياء. أعتقد
00:06:57أن هناك الكثير من المشكلات في ذلك ربما في خارطة الطريق. لكن النقطة هي، النقطة
00:07:05هي أنني أعتقد أن هناك الكثير من الدلالات حول الهندسة المعتمدة على الأحداث التي اعتاد الناس عليها
00:07:09ولا أحد يشكك فيها حقاً. السؤال هو: لماذا نستخدم
00:07:13طوابير الرسائل الميتة مرة أخرى؟ ما الخطأ في ذلك؟ لأنني لا أعرف أحداً يعتقد أن
00:07:19طابور الرسائل الميتة هو دلالة ملائمة للتعامل مع الأخطاء في طوابيرك، أليس كذلك؟ على أي حال، وأنا سعيد
00:07:25بأن أتطرق لبعض هذه الأشياء لأن هناك بضعة آراء قوية جداً
00:07:29هناك. لا أعرف مدى تخصصكم في Pub/Sub والهندسة المعتمدة على الأحداث. لا أريد
00:07:35جركم بعيداً في هذا. أشعر بأن معرفتي بطوابير الرسائل الميتة وكل
00:07:40تلك الأشياء سطحية جداً. بعض الأشياء التي أسمعها اليوم هي المرة الأولى لي.
00:07:48نعم، كنت سأقول أن معرفتي سطحية أيضاً، لكنني تعاملت مع الخطافات البرمجية
00:07:53بقدر لا بأس به وعالجت بعض المشكلات التي ذكرتها. وأعتقد أن هذا هو
00:07:57كيف تثبتون وجهة نظركم بأن الخطافات البرمجية هي المخدر الممهد للهندسة المعتمدة على الأحداث،
00:08:01لأنني أراهن على أنه بالنسبة للمطورين ذوي خلفيتكم، الخطافات البرمجية هي
00:08:06ربما أول تعرض واجهتموه مع “انتظر، هذا غير متزامن. كيف أتعامل معه؟”
00:08:12وأعتقد أن هناك منحنى تعلم كاملاً، أليس كذلك؟ إنه مثل الجبل الجليدي الكلاسيكي،
00:08:17أوه، لديك طلب HTTP القادم، ثم، كما تعلم، بقية الجبل الجليدي
00:08:21خلف الماء، صحيح؟ وأعتقد أن أحد الأشياء التي أحاول
00:08:26القيام بها هو جلب مستوى من تجربة المطورين (DX) لم يتم تحقيقه في هذا المجال حتى
00:08:32لا تضطر فعلياً إلى اكتشاف بقية الجبل الجليدي، صحيح؟ هناك بعض الأشياء التي هي
00:08:37حتمية بعض الشيء، لا أريد أن أسيء تمثيلها. أعتقد أنه بمجرد أن تبدأ
00:08:40العمل مع هذا النوع من المشكلات، تحتاج إلى فهم جيد للتعامد،
00:08:45على سبيل المثال، تحتاج إلى فهم جيد لضمانات الترتيب. لذا
00:08:49لا يعني ذلك أنه يمكنك حل كل مشكلة. أعتقد أنك لا تزال تتعامل مع أحداث
00:08:53في نهاية المطاف. لكن أعتقد أن هناك الكثير من الدلالات والتعقيد الذي يأتي بشكل رئيسي
00:08:58من عدم وجود أدوات مدروسة بالكامل أكثر من كونها تعقيداً حقيقياً
00:09:05مرتبطاً بمساحة المشكلة تلك. لذا أعتقد أننا الآن نخدم نوعين
00:09:13من العملاء؛ أولئك الذين يعرفون المشكلة بعمق
00:09:18وسيقومون بهندسة حلول حول إعداد Kafka الحالي الخاص بهم وكل
00:09:23ذلك النوع من الأشياء طوال اليوم. ثم نطرح عليهم بعض هذه الدلالات الجديدة،
00:09:28وهم متحمسون حقاً لها. هذه فئة. لكن الفئة الأخرى هي،
00:09:31أنا لا أريد حقاً أن أتعلم أياً من هذا، وأحاول بشكل أساسي تجاوز
00:09:36هذا الأمر برمته. صحيح. لذا نحن نرى الكثير من هذين النوعين من الملفات التعريفية.
00:09:41هل هذا أيضاً سبب جعلكم أداة Outpost مفتوحة المصدر، لتسهيل الأمر على المطورين
00:09:47للبدء عند استخدامها؟ بطرق معينة. والطريقة الأخرى هي أننا لا نحتاج إلى Outpost
00:09:53لكسب المال. حسناً، لذا قلنا، أعتقد أنه يجب علينا فقط جعلها مفتوحة المصدر إذاً. نعم. إنه مجرد،
00:10:01أعرف أن الكثير من جمهور يوتيوب لدينا يحبون معرفة الأدوات مفتوحة المصدر الجديدة. لهذا السبب
00:10:07ذهبت للسؤال عن ذلك أيضاً. لكن، أولاً، أنا نوعاً ما،
00:10:13أشعر ببعض الندم لأننا في الأيام الأولى لم نتخذ نهجاً مفتوح المصدر بشكل أكبر.
00:10:18وأعتقد أن هناك الكثير من الأشياء المتعلقة بكيفية بناء برمجياتك التي تكون مختلفة جداً عند البناء
00:10:21لشيء مغلق المصدر مقابل مفتوح المصدر. ولكن بالعودة إلى
00:10:26قرار المصدر المفتوح، أعتقد أن أحد الأشياء التي تراها مع الشركات الناشئة المدعومة بمخاطر
00:10:30هو أنك ينتهي بك الأمر مع هذا النوع من المصادر المفتوحة المزيفة، صحيح؟ إنه مفتوح المصدر،
00:10:34ولكن إما أنه مفتوح الجوهر (open core) أو نعم، هو مفتوح المصدر،
00:10:39لكنهم حقاً لا يريدونك أن تستخدم المفتوح المصدر أو ينتهي بهم الأمر بإعادة الترخيص
00:10:44بترخيص غير حقيقي للمصادر المفتوحة. صحيح. وأعتقد أن ذلك جعلني متحمساً جداً لـ Outpost
00:10:49والمصدر المفتوح لأنني شعرت أن لدينا فرصة للحصول على الحوافز الصحيحة.
00:10:54الآن، ربما ندخل قليلاً في تفاصيل كيفية تفكيرنا في العمل التجاري.
00:10:59لكن في ذهني، الأشخاص الذين يحتاجون إلى استقبال الخطافات البرمجية
00:11:03من جانب المستهلك، أكثر بمرتبتين إلى ثلاث مراتب من الأشخاص الذين يحتاجون إلى إرسال خطاف برمجي، صحيح؟ لأن فكر في الأمر،
00:11:09إذا كنت أرسل خطافات برمجية، فأنا أرسلها لجميع عملائي، وقد يكون عملائي، كما تعلم، 10،
00:11:13إذا كنت تبدأ، 100، 1000، أو مليونين. صحيح. لذا حتماً،
00:11:17جانب المستهلك هو عدد أكبر بكثير من الناس. وهكذا عندما أفكر في الأمر من وجهة نظر ريادة أعمال،
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وهذا يضعنا في موقف حيث يمكننا أن نقول بصدق، انظر، إذا كنت ستستخدم Outpost، سواء جعلتها مفتوحة المصدر أو
00:12:19نشرتها مع Hookdeck في النسخة المُدارة، فإنه لا يهمنا حقاً.
00:12:23نحن نحقق هدف العمل التجاري في كلتا الحالتين. صحيح. وهذا الحافز المتوافق جعلني متحمساً جداً.
00:12:29وهناك بضعة أشياء قمنا بها أولاً، مثل إصدار المصدر المفتوح
00:12:35قبل حتى التفكير في بناء نسخة مُدارة. لم تكن هناك خطة لبناء نسخة مُدارة.
00:12:40وقد تم نشر المشروع مفتوح المصدر منذ عامين تقريباً.
00:12:44لذا استغرق الأمر منا عامين قبل أن يطلب عدد كافٍ من الناس النسخة المُدارة.
00:12:48وهذا جزء واحد. والجزء الآخر
00:12:52هو أن النسخة المُدارة من Outpost تشغل نفس بناء Docker المنشور على
00:12:57Docker Hub من المصدر المفتوح. نحن لا نملك نسخة خاصة،
00:13:03ولا نحزم ميزات خارج المصدر المفتوح. نحن نشغل نفس بناء Docker بالضبط.
00:13:08لذا السؤال بالنسبة لك ليس: “هل توفر ميزة X أو Y؟”
00:13:13إنه ببساطة: هل تريد نشرها وتحمل العبء التشغيلي المرتبط بذلك؟
00:13:19أم تريد الدفع لشخص آخر للقيام بذلك نيابة عنك؟
00:13:23صحيح. ولا أعتقد أن هناك إجابة صحيحة أو خاطئة. يعتمد ذلك على كل شركة أو مستوى
00:13:29الراحة، أو المتطلبات الامتثالية، سمِّها ما شئت. صحيح. ولكن بسبب ذلك،
00:13:34أشعر أنه يمكننا أن نكون مساهمين جيدين في مجتمع المصادر المفتوحة بهذا المشروع.
00:13:38نعم، لقد كنت سعيداً جداً بالعمل عليه لأنه أول مشروع مفتوح المصدر كبير أشارك فيه،
00:13:44كمساهم أساسي. لذا نعم، لقد كان أمراً جيداً.
00:13:51كيف وجدت عالم المصادر المفتوحة الآن بعد وجود Claude Code وكل ذلك؟
00:13:55هل تلقيت الكثير من طلبات السحب (PRs) والثغرات الأمنية غير الحقيقية، أم أن الأمر كان مقبولاً؟
00:14:01انظر، لا أعتقد أننا في نطاق يمكنني التحدث فيه عما يعاني منه الآخرون.
00:14:05لذا لا أريد بالتأكيد الإساءة في تمثيل الموقف لأنه يبدو سيئاً بالتأكيد هناك بالنسبة للكثير من الناس.
00:14:09سأقول إنني فوجئت بجودة المساهمات التي تلقيناها، ولكن بالتأكيد تلقينا أيضاً مساهمات
00:14:14بها طلب سحب واحد محدد، أعتقد أنه لا يزال مفتوحاً على المستودع الآن، لإضافة طوابير Cloudflare
00:14:20كجهة وجهة. الوصف يبدو جيداً على طلب السحب. ثم عندما تتعمق في الكود،
00:14:25تجد أنه يستخدم مجموعة من واجهات برمجة تطبيقات Cloudflare المخترعة تماماً.
00:14:30وهم لم يتحققوا منها. من الواضح أن الشخص الذي فتح طلب السحب لم يحاول حتى تشغيله.
00:14:34صحيح. لذا الآن العبء يقع علينا، لأنني قلق قليلاً من أن يُنظر إلينا كأننا لا نحاول
00:14:40تشجيع الناس الذين قد نُعتبر منافسين لهم.
00:14:44لذا أعتقد أنه يجب علينا إضافة طوابير Cloudflare وغيرها، ولكن في الوقت نفسه،
00:14:48لم يكن ذلك على خارطة الطريق المغلقة، ولم يطلبه أحد آخر سوى هذا الشخص.
00:14:52والآن هو في حالة معلقة، حيث إذا أغلقته، ستبدو وكأنك لا تريد دعم الناس
00:14:56الذين قد يُنظر إليهم كمنافسين. صحيح.
00:15:02لكن هل تخصص الموارد فعلياً لتحريكها في خارطة طريقك والتأكد من تنفيذها بشكل صحيح؟
00:15:08لذا كان الأمر أشبه بـ “catch 22” في تلك المواقف.
00:15:12لكن حتى الآن أشعر أنها كانت تجربة جيدة جداً.
00:15:15خاصة لأننا نستخدم نفس البناء. أحد الأشياء التي قمنا بها هو أننا عندما يصل العملاء للحصول
00:15:19على ملاحظات أو يتحدثون إلينا حول ميزات محددة، فإننا نفتح قضايا في GitHub.
00:15:24ونشير إلى طلبات السحب والقضايا الموجودة. ونحرص دائماً على جعل الناس يعرفون
00:15:28أنه بالمناسبة، المستودع موجود ويمكنك الذهاب والمساهمة.
00:15:33وفي الواقع، تلقينا عدة مساهمات من مستخدمين مُدارين قاموا بتنفيذ ميزاتهم الخاصة.
00:15:37وأعتقد أن ذلك قلل من حاجز الدخول بشكل هائل. لأنك تعلم، تاريخياً المشاريع في لغة Go،
00:15:43معظم مستخدمينا ليسوا مطوري Go في المقام الأول. صحيح. لذا هناك حاجز دخول للغة Go.
00:15:48وأيضاً تعلم مشروع جديد للمساهمة فيه أمر ليس تافهاً. صحيح.
00:15:53لذا أعتقد أن ذلك قلل من حاجز الدخول بشكل كبير. وهذا أمر جيد حقاً.
00:15:58لأنه الآن إذا كنت كمستخدم تعاني من حاجة مثل: “أوه، هذا الشيء يزعجني حقاً”.
00:16:03وكمسؤول صيانة، هذه إشارة قوية على أن هذه الميزة تستحق البناء.
00:16:07شخص ما يبذل جهداً ويقضي وقته في تنفيذ ذلك.
00:16:13هذه إشارة على أن هذا الأمر يهم بالفعل. صحيح. من حيث ترتيب الأولويات،
00:16:18ما هو الأكثر أهمية. لذا أعتقد أن تقليل حاجز الدخول أمر جيد حقاً.
00:16:24وإذا تمكنت من تجاوز بوابة البريد المزعج وكل تلك الأشياء،
00:16:28هناك الكثير من الإيجابيات في ذلك.
00:16:35في الصفحة المقصودة، كان هناك شيء لفت انتباهي وهو شهادة من الرئيس التنفيذي لشركة Vercel.
00:16:39إذاً Vercel تستخدم Hookdeck كمنتج أيضاً.
00:16:42وإذا قرأت ذلك الاقتباس المحدد، فهو يوصي به أيضاً.
00:16:48أوه، حسناً. لمستخدمي Vercel وما شابه ذلك.
00:16:53يقوم أحدهم بجهد إضافي وينفق رموز “وورد” الخاصة به لتنفيذ هذه الميزة.
00:16:58إنها إشارة إلى أن هذا الأمر مهم حقاً. من حيث ترتيب الأولويات،
00:17:02وما هو الأكثر أهمية. لذا أعتقد أن تقليل حاجز الدخول أمر جيد حقاً.
00:17:07وأعتقد أنه إذا تمكنت من السيطرة على تدفق الرسائل المزعجة (سبام) وكل تلك الأمور،
00:17:12فإن هناك الكثير من الإيجابيات في ذلك.
00:17:14في الصفحة الرئيسية، أحد الأشياء التي لفتت انتباهي حقاً كان شهادة من الرئيس التنفيذي لشركة فيرسيل.
00:17:21إذ أن فيرسيل تستخدم “هوك ديك” كمنتج أيضاً.
00:17:25إذا قرأت ذلك الاقتباس تحديداً، ستجد أنه يوصي به أيضاً.
00:17:29أوه، حسناً.
00:17:29نوعاً ما لمستخدمي فيرسيل وما شابه ذلك.
00:17:32لكن هناك قصة طريفة في الواقع حول هذا الأمر.
00:17:35لأن غييرمو غرد بشأنه في ليلة سبت.
00:17:39لم أكن أعرف أن ذلك سيحدث.
00:17:40ليس لدي علاقة مسبقة مع غييرمو، ولا شيء من هذا القبيل.
00:17:45وهذا يوضح مدى تأثير بعض الأشخاص في المجتمع.
00:17:48لأن حجم عمليات التسجيل والوعي التي حصلنا عليها من ذلك كان
00:17:53جنونياً.
00:17:54منذ ذلك الحين، تواصلنا أنا وغييرمو من حين لآخر.
00:17:57وكانت دائماً محادثات جيدة وما إلى ذلك.
00:17:59إنه أمر مثير للاهتمام.
00:18:00لأنه في الواقع، إذا نظرت إلى شركة مثل فيرسيل، أحد الأشياء التي أخبرني بها غييرمو
00:18:04هو أنه يرى في الواقع المزيد من الأشخاص يستخدمون WebEx الآن.
00:18:07وتفسيره للأمر هو أن ذلك مدفوع بشكل أساسي بخيارات النماذج اللغوية الكبيرة (LLMs).
00:18:12وهذا يخلق حالات استخدام جديدة للبيانات.
00:18:15لم تكن تهتم بها عادة من قبل.
00:18:18فكر مثلاً في نظام دعم العملاء الخاص بك.
00:18:20على سبيل المثال، لديك وكلاء وبشر يعملون هناك.
00:18:23وهناك سبب ضئيل جداً للقيام بأي شيء بخصوص أحداث التذاكر الجديدة وما شابه ذلك.
00:18:29وما إلى ذلك.
00:18:30لأنه على أي حال، الإنسان هو من سيقوم بالرد على تلك الرسالة.
00:18:34لكننا الآن بوضوح في عالم يتغير فيه ذلك تماماً.
00:18:37وعندما تنتقل من البشر الذين يشغلون الوكلاء إلى الوكلاء الذين يتم تشغيلهم بواسطة الأحداث.
00:18:42صحيح.
00:18:42وفجأة، أصبحت تهتم بالأحداث القادمة من نظام دعم العملاء الخاص بك، وأدوات التسويق، وما إلى ذلك.
00:18:46وهكذا.
00:18:48صحيح.
00:18:48وهذا بالتأكيد شيء أعتقد أن المنصات تلاحظه.
00:18:54وقد كانت هذه نقاط نقاش مثيرة للاهتمام بالنسبة لنا، بالطبع.
00:18:57لكن نعم، فيرسيل تحديداً، للتوضيح، ليست مستخدماً مباشراً.
00:19:01أعني، أنا متأكد من أن عدداً كبيراً من المطورين يستخدمون واجهة سطر الأوامر المحلية وما شابه ذلك في فيرسيل،
00:19:05ولكن، نعم.
00:19:06إذاً، من هو العميل النموذجي لشخص يستخدم “هوك ديك”؟
00:19:10على سبيل المثال، إذا كان لدي متجر تجارة إلكترونية صغير لبيع القمصان، كيف سأستخدم “هوك ديك” لأجله؟
00:19:15وهل سيكون من المنطقي استخدامه في هذه الحالة؟
00:19:17ربما لا.
00:19:19حسناً.
00:19:21حسناً.
00:19:22أنت تطرح علي السؤال المليوني بمعنى أنني أعتقد أنه شيء
00:19:26كافحنا دائماً لفهمه، لأن نطاق الأسباب التي تجعلك تستخدم “ويب هوكس” أو تعتمد عليها واسع بشكل جنوني.
00:19:32خدمة WebEx، أو الاعتماد عليها، أسبابها واسعة جداً.
00:19:35نحصل على WebEx من شركات معتادة مثل Stripe وShopify، ولكن لدينا أيضاً
00:19:40خدمات WebEx قادمة من جميع مزودي الاتصالات الأستراليين وغرفة المقاصة في المملكة المتحدة.
00:19:47وهناك في الواقع الكثير منها قادم من لعبة EVE Online.
00:19:50هناك أيضاً على ما يبدو مجتمع من الأشخاص الذين ما زالوا يستخدمون، وما زالوا يلعبون لعبة Conan
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وجميع هؤلاء يعتمدون بشكل شبه حصري على “ويب هوكس”.
00:20:39وجميع هؤلاء يعتمدون بشكل حصري تقريبًا على الـ Webhooks.
00:20:43صحيح.
00:20:43لذا إذا أردت إرسال إشعار بتوفر المنتج مجددًا، ما أفعله هو مراقبة جميع تحديثات
00:20:48المخزون في متجر Shopify عبر الـ Webhooks الخاصة بهم.
00:20:50وبمجرد أن يصبح المنتج الذي كان غير متوفر متاحًا في المخزون،
00:20:53أقول لنفسي، حسنًا، يجب إرسال البريد الإلكتروني.
00:20:54صحيح.
00:20:55لذا بشكل أساسي، كل شيء سيقومون بتثبيته أو إضافته وما إلى ذلك سيعتمد
00:20:59على الـ Webhooks في الخلفية.
00:21:00الناس يبنون تطبيقات، وليست شوبيفاي فقط، بل “سترايب” أيضاً لديها سوق تطبيقات كبير.
00:21:02والعديد منهم عملاء لنا.
00:21:07الشيء الآخر الذي نراه هو المتاجر الكبيرة.
00:21:09مثل جيم شارك وجود أمريكان وروغ وما شابه.
00:21:11حيث لديهم فرق تقنية خاصة بهم ويبنون تطبيقات مخصصة.
00:21:14إنهم يبنون تطبيقات مخصصة لتكامل أنظمتهم، وغالباً ما تكون عملياتية
00:21:19فيما يتعلق بالتسلسل، ومتى يحتاج الطلب إلى المزامنة مع المزود اللوجستي، وإضافة ملاحظات.
00:21:22وربما تكون هناك تفضيلات خاصة بالعميل يجب إضافتها إلى البيانات
00:21:28قبل وصولها للمزود اللوجستي.
00:21:34صحيح.
00:21:39وبعضها سيعزز تجارب المستخدم، مثل إدارة الاشتراكات المخصصة
00:21:41أو رسائل بريد إلكتروني معينة تريد إرسالها عندما يشتري شخص ما
00:21:41بطاقة هدايا ويريد إرسالها لصديقه، وما إلى ذلك.
00:21:46وهذا ما نراه عادةً. قد يكون متجر شوبيفاي الصغير هو المثال الذي كان بإمكانك اختياره
00:21:51ولا نرى الكثير من الناس يستخدمون “ويب هوكس” لأجله، لكن في أي مكان آخر
00:21:55تستهدفه في هذا القطاع، ستجد شركة تستخدم “ويب هوكس”.
00:21:59الذي اخترته، وهو أمر لا نرى الكثير من الناس يستخدمون WebEx لأجله، ولكن كما تعلم، في كل مكان آخر
00:22:04تستهدفه تقريباً في هذا القطاع، ستجد نفسك أمام
00:22:08شركة تستخدم WebEx.
00:22:09هذا منطقي.
00:22:10هذا منطقي.
00:22:11كيف يمكن مقارنتها بخدمة مثل AWS EventBridge؟
00:22:14نعم.
00:22:17وأي شيء تقولونه أنتم كـ “نقطة بيع فريدة” مقابل خدمات أمازون السحابية وما شابه ذلك، فإنه ينطبق أيضاً.
00:22:19إنه يتعلق جداً بتجربة المطور، أليس كذلك؟
00:22:24واجهات برمجة تطبيقات مناسبة، وواجهة مستخدم لطيفة، وقابلية مراقبة قوية، وكل ذلك.
00:22:25صحيح.
00:22:26ومن الواضح أن مشكلة أمازون دائماً هي أنك ينتهي بك الأمر بوجود 20 خدمة،
00:22:31معظمها ربما نسيت أسماءها الآن.
00:22:37والبيانات مبعثرة من خلالها، والتهيئة مبعثرة أيضاً.
00:22:40صحيح. لذا هذه نقطة واحدة.
00:22:46من هذا القبيل.
00:22:47بالضبط.
00:22:47هناك طرق يمكنك الالتفاف عليها باستخدام بوابة واجهة برمجة التطبيقات وما إلى ذلك.
00:22:51ولكن النقطة هي أنه مبني لنظام أمازون البيئي، حيث معظم حالات الاستخدام هي أحداث داخلية
00:22:56لأمازون، مثل تحميل مستند جديد على S3.
00:22:59أما القابلية للتشغيل البيني مع أطراف ثالثة، رغم أنهم يدعمون حوالي 40 بائعاً،
00:23:01إلا أنهم لا يدعمون الآلاف.
00:23:01ينتهي بك الأمر دائماً في سيناريو حيث تدعم “شوبيفاي” “إيفنت بريدج” ولكن لا تدعمه “تويليو”.
00:23:02لكن أعتقد أن النقطة الأعم هي أن AWS EventBridge لا تتكامل فعلياً مع الجميع،
00:23:07مع الجميع.
00:23:08لذا يجب على المورد أن يكون قد تكامل مع AWS EventBridge.
00:23:11هناك طرق يمكنك من خلالها تجاوز ذلك باستخدام بوابة API وما إلى ذلك.
00:23:16لكن، أمم، النقطة هي أنها مصممة بشكل كبير لنظام AWS البيئي حيث تكون معظم
00:23:23حالات الاستخدام عبارة عن أحداث داخلية لـ AWS، مثل تحميل مستند جديد على S3 و
00:23:31أشياء من هذا القبيل.
00:23:31أما فيما يخص التوافقية مع الأطراف الخارجية، فرغم أنهم يدعمون حوالي 40 أو
00:23:36ما إلى ذلك من الموردين، لا تأخذ كلامي على محمل اليقين فقد يكون الرقم قد تغير، لكن كما تعلم، ليس الآلاف.
00:23:40ينتهي بك الأمر دائماً في سيناريو حيث، حسناً، Shopify تدعم EventBridge، لكن
00:23:45يمكنك العمل على أي سحابة أو أي بنية تقنية.
00:23:47صحيح.
00:23:47لأن المطلب الوحيد هو تحديث رابط URL في نهاية المطاف.
00:23:51وهذا يختلف تماماً عن “إيفنت بريدج” من أمازون، الذي يمثل قفل البائع.
00:23:52نعم.
00:23:54لكنني أفكر عادة في “إيفنت بريدج” كبوابة أحداث كبيرة أخرى.
00:23:59نرى أيضاً “أزور إيفنت غريد” كمنافس يكتسب أرضية.
00:24:02وعندما أفكر في منافسينا المباشرين، فهي تلك المنتجات.
00:24:08لكنني أعتقد بالتأكيد أن نطاق ما نحاول القيام به أكبر بكثير.
00:24:10وبالنسبة للبعض، هذا شيء جيد.
00:24:15وبالنسبة للبعض الآخر، قد لا يكون كذلك، أليس كذلك؟
00:24:17بالنسبة للبعض، هذا ما يريدونه.
00:24:22إنهم منغمسون تماماً في نظام أمازون البيئي.
00:24:25إنهم يستخدمون “كلاود فورميشين”، وهم معتادون على الخدمات.
00:24:28ويريدون القدرة على الاختيار من بين الإمكانيات.
00:24:31وهذا جيد.
00:24:34لا أعتقد أننا سنحصل على حصة سوقية بنسبة 100%.
00:24:39في الواقع، بضع نقاط مئوية هي كل ما تحتاجه.
00:24:40نحن نحاول تقديم الحجة بأن هذا هو الحل الصحيح للشركات والمطورين.
00:24:44وهذا مختلف تماماً عن AWS EventBridge، الذي يعتبر قمة الارتهان لمزود الخدمة
00:24:48لاحظت في العام الماضي أن وقت التوقف عن العمل للشركات الكبرى في ازدياد.
00:24:53هناك كل هذه الميمات عن تعطل “غيت هاب”.
00:24:53أتذكر أنه قبل عامين، إذا انخفض مستوى الأداء (P99) إلى 99.5% أو أقل،
00:24:58كانت ستكون هناك محادثة جادة مع فريقك حول كيفية حدوث ذلك.
00:25:04الآن، أصبح الأمر طبيعياً.
00:25:10نعم.
00:25:13الناس اعتادوا على تعطل “غيت هاب” لفترات طويلة.
00:25:17هل ترى من منظور “هوك ديك” أن هناك المزيد من فترات التوقف هذا العام؟
00:25:18وكيف تتعامل مع هذه التحديات؟
00:25:20نعم، هذا مثير للاهتمام لأنك بالطبع يجب أن تأخذ ذلك في الاعتبار إذا كنت ستستهلك “ويب هوكس”.
00:25:22تحديداً “ويب هوكس” الخاصة بـ “غيت هاب” تكون مزعجة بشكل خاص.
00:25:24هناك فرصة كبيرة إذا سجلت الدخول على منصة ما، ستجد لافتة صغيرة.
00:25:26تخبرك بأن عمليات النشر متوقفة لأن “ويب هوكس غيت هاب” لا تعمل.
00:25:27في الواقع، نشر رئيس التكنولوجيا في غيت هاب تدوينة حول استقرار البنية التحتية لديهم
00:25:30في خضم كل هذه الميمات.
00:25:31لا أعتقد أننا سنحصل يوماً على حصة سوقية بنسبة 100%.
00:25:34لذا في الواقع، أعتقد أن بضع نقاط مئوية في الولايات المتحدة هي كل ما تحتاجه.
00:25:38لذا نعم، أعتقد أننا نحاول إثبات أن هذا هو الحل المناسب للشركات المبدعة
00:25:45والمطورين وغيرهم.
00:25:48وبالنسبة للآخرين، ستكون خدمة “أمازون إيفنت بريدج” هي الأنسب، وهذا جيد.
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لذا كنت أفكر، من منظورك في “Hook”، هل ترى أن هناك أيضًا
00:26:28الكثير من فترات التوقف هذا العام مقارنة بالسنوات السابقة وكيف تتعامل مع هذه التحديات؟
00:26:33أجل، هذا مثير للاهتمام لأنه من الواضح أن هذا اعتبار يجب أن تأخذه في الحسبان إذا كنت ستستهلك
00:26:37خطافات الويب (Webhooks)، وتحديدًا خطافات ويب GitHub تمثل مشكلة بشكل خاص.
00:26:42أنت تعلم، هناك احتمال اثنان من أصل ثلاثة إذا قمت بتسجيل الدخول إلى “Railway” أو “Vercel” أو أي شيء آخر،
00:26:46سيكون هناك شريط صغير.
00:26:47ويقول شيئًا مثل، عمليات النشر متوقفة لأن خطافات ويب GitHub لا تعمل أو شيء من هذا القبيل.
00:26:51وفي الواقع، نشر مدير التكنولوجيا في GitHub هذه التدوينة حول استقرار بنيتهم التحتية
00:26:58في خضم كل تلك الميمات وكل ذلك النوع من الأشياء،
00:27:02محاولًا تهدئة الأمور.
00:27:03لا أعتقد أنها نجحت حقًا، لكنها لم تكن فترة سهلة.
00:27:05ولكن أحد الأشياء التي كانت محل لوم صريح في هذه المقالة هو استقرار خطافات الويب
00:27:09سأكون سعيداً بالتحدث إليك مجدداً في وقت لاحق.
00:27:12بالتأكيد.
00:27:13وللحق، أعتقد أن الطريقة التي تمت بها صياغة هذا الكلام فيها بعض الاستخفاف.
00:27:17فأنا لا أشك أبداً في أن تحديات البنية التحتية لديهم جنونية تماماً
00:27:21إلى اللقاء.
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أعتقد أنه في حالة “شوبيفاي”، يكون زمن الوصول الأساسي حوالي أربع أو خمس ثوانٍ
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وأعني أن فريق “شوبيفاي” نفسه يدرك ذلك تمامًا.
00:28:36لكن يمكنك أن ترى أن هناك الكثير من التباين في أوقات التسليم تلك.
00:28:41لذا سيحدث، كما تعلم، ربما مرة كل شهرين أو شيء من هذا القبيل،
00:28:46حادث كبير نوعًا ما يتعلق بزمن الوصول.
00:28:49وأعتقد أن هذا شيء لا تراه عادةً.
00:28:51صحيح.
00:28:52لأن وقت التوقف عن العمل يكون ملاحظته أسهل بكثير.
00:28:54تذهب إلى “داتادوج” (DataDog) أو “بيتر ستاك” (Better Stack).
00:28:57أنتم تسمونه مجددًا منتج المقاييس.
00:29:01القابلية للملاحظة.
00:29:02القابلية للملاحظة، أجل.
00:29:03إذًا تذهب إلى “بيتر ستاك”، وتراقب هذه الأشياء.
00:29:05صحيح.
00:29:06وتنظر إلى استدعاءات HTTP لنقطة نهاية الويب، وتراها تتوقف تمامًا.
00:29:11صحيح.
00:29:11المشكلة واضحة جدًا ومباشرة.
00:29:14لكن إذا زاد زمن الوصول إلى 60 ثانية، فهذا شيء سيكون من الصعب جدًا
00:29:19معرفته من مقاييسك الفعلية.
00:29:22صحيح.
00:29:23وهذا لأن زمن الوصول الذي تستغرقه للمعالجة هو شيء ربما تقوم بتتبعه وما إلى ذلك.
00:29:27لكن التأخير يحدث من جانب المورد.
00:29:28لكن الآن إذا كان لديك افتراض جديد في الكود الخاص بك، وعملياتك التجارية،
00:29:31تفترض شيئًا من الفورية في تلك الأحداث، إذا كانت الآن تصل بعد 60 ثانية
00:29:34فهذا قد يبدأ في إدخال الكثير من المشكلات الدقيقة والأخطاء والافتراضات السيئة
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صحيح، يحدث نوع من كسر التوقعات.
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على سبيل المثال، في الآونة الأخيرة، “ريلواي” (Railway)، قمنا ببعض عمليات إدارة النشر
00:31:22التي تعمل على “ريلواي” بسبب هيكل التسعير الخاص بهم.
00:31:27بما أننا يجب أن نشغل نفس إصدار المصدر المفتوح، لم نبنِ شيئًا
00:31:29متعدد المستأجرين، حيث لن يكون ذلك مناسبًا في المصدر المفتوح.
00:31:34لذا نقوم بنشر فعلي لكل عميل على حدة.
00:31:36صحيح.
00:31:40وبالنسبة لمستخدمي الخطة المجانية، ننشر نسخة لهم على “ريلواي”،
00:31:44والتي تعمل بشكل جيد عمومًا.
00:31:48لكن في اليوم الآخر، تم إغلاق حساب “GCP” الخاص بهم وكانوا خارج الخدمة لمدة ست
00:31:49وبالنسبة لمستخدمي الخطة المجانية، نقوم بنشر مثيل خاص بهم على منصة Railway،
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كنت أتساءل عندما يكون هناك انقطاع في شيء مثل “شوبيفاي” أو “سترايب” (Stripe)،
00:32:42كيف تلحق الأحداث بالركب وهل يؤثر ذلك بشدة على خوادمك؟
00:32:43أجل، في الأساس يحدث تكدس في الويب.
00:32:46صحيح.
00:32:47لأن هناك سيناريوهات نقول فيها دائمًا:
00:32:51لا ينبغي لك افتراض حجم معين من طلبات الويب.
00:32:57حسنًا.
00:33:00لدينا سمة حيث سيفرض كل مورد مهلة زمنية.
00:33:05صحيح.
00:33:09سيمنحونك ثلاث ثوانٍ،
00:33:09أو خمس ثوانٍ حسب المنصة للاستجابة.
00:33:14وهذا يعني أنك لا تستطيع القيام بأي قدر ذي معنى من العمل،
00:33:14خاصة عندما تأخذ في الاعتبار زمن انتقال الشبكة وتلك التأخيرات.
00:33:15صحيح.
00:33:18ولهذا السبب، ليس فقط السبب،
00:33:21بل هو أحد الأسباب التي تجعل الشيء المشترك هو الحاجة إلى وضعه في طابور انتظار.
00:33:25لا يمكنك معالجة ذلك بشكل متزامن.
00:33:25لكنني فقدت تسلسل أفكاري.
00:33:28هل يمكنك تكرار سؤالك؟
00:33:31كنت أتحدث عن وقت حدوث انقطاع في شركة مثل “سترايب” و”شوبيفاي”.
00:33:33أوه، أجل.
00:33:39ولحاق الأحداث بالركب.
00:33:42أجل.
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الضغط العكسي على طابورهم.
00:34:11لذا، في الأساس، العمل من خلال كل شيء تراكم أثناء وقت التوقف.
00:34:16وعمومًا، ما ستراه هو أنهم سيقيسون أعلى من طاقتهم المعتادة
00:34:17لأنهم يحاولون اللحاق بالركب.
00:34:22صحيح.
00:34:26ويؤدي ذلك إلى إرسال مجموعة من الطلبات إلى المتاجر النهائية.
00:34:28نعم، لديك تلك المخالفات، لكن بعض تلك المخالفات في الإنتاجية
00:34:28ليست بسببك.
00:34:32إنها بسبب المورد بنسبة 100% لأن المورد يمر بتحديات البنية التحتية الخاصة به وما إلى ذلك.
00:34:37ومن الواضح أن قدرة “شوبيفاي” على إرسال خطافات الويب (Webhooks) أعلى بكثير من قدرتك
00:34:38على استقبالها في معظم الأجزاء.
00:34:42أجل.
00:34:44من المثير للاهتمام، في الواقع، أن أحد مستثمرينا كان كبير مسؤولي المنتجات في “تويلو” (Twilio).
00:34:49وأعتقد أن هذا هو جزء من سبب اهتمامه بالاستثمار.
00:34:52لأن أحد الأشياء التي قالها هو أن “تويلو” كانت تقوم بشكل روتيني
00:34:52بشن هجمات حجب الخدمة (DDoS) على عملائها، لأغراض عامة.
00:34:56وهو أمر لا مفر منه إلى حد ما، وجزء من مشكلة القيام بتلك
00:34:59الأحداث التي يحركها المورد.
00:35:04وهي مشكلة معروفة جدًا مع الموردين.
00:35:07وهم يعرفون ذلك أيضًا، لأن هذا شيء يمكنك تتبعه في استجابة
00:35:14زمن الوصول من الخوادم أيضًا، أليس كذلك؟
00:35:17إذا قمت بشن هجوم حجب خدمة على عميلك، يرتفع زمن استجابة الخادم.
00:35:21وفي مرحلة ما، تبدأ المهلة الزمنية في النفاذ.
00:35:24تتفاقم تلك المشكلة لأنه من الصعب الحصول على المزيد من الإنتاجية إذا كانت هناك مهل زمنية أطول.
00:35:26كلما اضطررت إلى الاحتفاظ باتصال HTTP، قل عدد الطلبات التي
00:35:29يمكنك القيام بها لأي عامل لديك من طرفك.
00:35:31والآن عليك القياس، ثم ترسل المزيد لأنك قمت بالقياس، صحيح.
00:35:34يتراكم الأمر معًا، أليس كذلك؟
00:35:38يميل الأمر إلى أن يكون معززًا لذاته لأن كلما قلت قدرتك على
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أعلم أنك قلت إن النماذج اللغوية الكبيرة (LLMs) ترسل الآن المزيد من خطافات الويب وربما تعالجها.
00:36:19ولكن داخليًا، كيف تستخدم الذكاء الاصطناعي لـ “هوك ديك” (Hookdeck)؟
00:36:21وما الذي تراه كمستقبل للذكاء الاصطناعي في هذا المجال؟
00:36:25أجل، أعتقد أن هناك الكثير من الأشياء التي تحدث على هذه الجبهة.
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وكل هذه يتم تحفيزها إما عن طريق الجدول الزمني أو عن طريق الأحداث في نهاية اليوم.
00:37:15وبعض تلك الأحداث مجردة بعيدًا عنك، ولكن لا تزال هناك أشياء مثل
00:37:18طلب سحب (PR) في “غيت هاب”، أو عندما تقوم بالالتزام (commit) أو التعليق، كل هذا يعتمد على الويب.
00:37:24ولكن من الواضح أن الأمر سوف يتفرع إلى ما هو أبعد من ذلك، مثل دعم العملاء
00:37:25و”سلاك” وما إلى ذلك، وحتى الأشياء التي تحدث في الوقت الفعلي في العالم الحقيقي
00:37:29من بيانات المستشعر وكل تلك الأشياء، أليس كذلك؟
00:37:35أعتقد أيضًا أن الكثير من الوكلاء سيحتاجون إلى تحفيز أحداث مع وكلاء آخرين، في الأساس،
00:37:41مخرجات الوكيل ستكون حدثًا، والتي من المحتمل أن تحفز
00:37:42وكيلًا آخر، شركة أخرى، وما إلى ذلك، والتي نعم، يمكنك وصفها كحالة استخدام لخطافات الويب، وهي كذلك.
00:37:46لكنني أعتقد أيضًا أن بعض الدلالات حول خطافات الويب الآن معيبة حول الأمن والبروتوكول والكفاءة.
00:37:49أو طلبات السحب (PR) في GitHub، أو عندما تقوم بالالتزام (commit) أو التعليق على GitHub، كل هذا يعتمد على الويب.
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لكن أعتقد أيضًا أن بعض الدلالات المتعلقة بـ WebEx في الوقت الحالي بها نوع من الخلل
00:38:28فيما يتعلق بالأمان والبروتوكول والكفاءة وما شابه ذلك.
00:38:33ولهذا السبب كنا ندفع باتجاه وجهات الأحداث (event destinations) كنمط أفضل
00:38:36ونمط أكثر تحسينًا لهذا الأمر. الشيء الآخر أيضًا هو أنه إذا كان ما تقوم بتشغيله
00:38:40استجابة للأحداث هو سير عمل وكيل، والتي تكون غير حتمية، ويمكن أن تعمل لفترة طويلة،
00:38:47فإن ذلك يجعل من الصعب جدًا تعديل سعتك وتوسيع نطاقك بناءً على الأحداث
00:38:51التي تتلقاها. لذا أعتقد أن إدارة الإنتاجية وإدارة السعة
00:38:55وكل ذلك يصبح أكثر صعوبة. وستكون معدلات الفشل لديك أعلى بسبب
00:39:00انتهاء وقت السحابة (cloud timing out) وعدم اجتياز عمليات التقييم (evals) الخاصة بك وكل تلك الأمور.
00:39:07لذا أعتقد من منظور بناء التطبيقات، والبدائيات الأساسية التي ترغب في استخدامها،
00:39:12وأين يتم تشغيل ذلك، ومدة تشغيله، وكيفية تعاملك مع الضغط العكسي (back pressure) وما شابه،
00:39:16هناك الكثير من التحديات الجديدة هنا. وفيما يتعلق بنا داخليًا،
00:39:21أعتقد أننا ما زلنا نحاول اكتشاف الطريقة الصحيحة. هناك جزء مني يشعر بالذهول التام
00:39:25من السعة. لا أفاجئ أحدًا، لا أعتقد أنني أقدم أي
00:39:29رؤية فريدة هنا. الشيء الوحيد الذي سأقوله، هو أن الحاجز بين
00:39:34الانتقال من موجه سطر الأوامر (CLI prompt) أو “codex” أو أي شيء آخر إلى طرح منتج
00:39:41عالي الجودة وذوق رفيع. أعتقد أن بعض هذه الفروق الدقيقة لا تزال مفقودة وسط كل الميمات
00:39:45وكل تلك الأمور؛ حيث لدي بعض الشكوك حول ما إذا كان يمكنك حقًا إنفاق
00:39:50هذا المستوى من الرموز (tokens) وإنتاج شيء يضيف قيمة حقيقية للعالم في نهاية
00:39:55اليوم. وعلى الأقل في تجربتنا حتى الآن، من الواضح أن هناك الكثير من الأمور المتعلقة بالأمان،
00:40:01وهي عوامل تمكين هائلة، مثل مراجعات الكود وما شابه. لكن أعتقد عندما يتعلق الأمر بـ
00:40:06هذه الأشياء، فهي بمثابة الحد الأدنى المطلوب. إنها ليست شيئًا يضيف قيمة حقيقية
00:40:11في نهاية اليوم، أليس كذلك؟ عندما يتعلق الأمر ببناء شيء قيم جدًا
00:40:14يستمد منه الآخرون قيمة، أشعر أنه لا تزال هناك فجوة كبيرة. وأشعر أن
00:40:19فريقنا لا يزال مسؤولًا جدًا عن جلب ذلك المستوى من الذوق والبصيرة وفهم العملاء
00:40:25والتعاطف وكل تلك الأمور التي لا تحصل عليها مباشرة من
00:40:31صندوق الدردشة. ربما نحن الذين نتصرف بحماقة وكان بإمكاننا التحرك بشكل أسرع بكثير.
00:40:35ولو قمنا فقط بتشغيل كل شيء بضربة واحدة ومضينا قدمًا. لكن في الوقت الحالي، لا يزال نهجنا هو
00:40:42الحفاظ على نفس مستوى التوقعات من حيث صافي المخرجات وما نقدمه للمستخدم النهائي
00:40:47في نهاية اليوم. نعم، من الواضح أن هذا يعني أنه يمكننا القيام بالمزيد. وأعتقد أيضًا أن المزيد من الأشخاص الذين
00:40:53لديهم ذلك الذوق وهذا التعاطف وما إلى ذلك يمكنهم جلب القيمة للمستخدم لأن الحاجز كان الكود،
00:40:57أليس كذلك؟ وعلى سبيل المثال، تقريبًا كل شخص في الشركة الآن يكتب الكود،
00:41:01أليس كذلك؟ مصممنا هو مبرمج “Vipe” المقيم. الآن هو الشخص المسؤول بالكامل عن
00:41:06الموقع الإلكتروني، ولكن حتى هناك الكثير من أعمال لوحة المعلومات (dashboard) وما شابه،
00:41:11أو مسوق المنتج أو مسؤولي علاقات المطورين، الجميع، كما تعلم، ليسوا بصدد زيادة استهلاك الرموز، ولكن
00:41:16إذا كانت هناك لوحة صدارة (leaderboard)، فمن المحتمل أن يكونوا في مكان ما في الأعلى. وأعتقد أن هذا شيء جيد حقًا. إنهم ممكّنون
00:41:20لأن هؤلاء الأشخاص يجب أن يتمتعوا بنوع من التفكير النقدي وكل ما كنت أصفه
00:41:25ليكونوا قادرين على طرح أشياء ذات ذوق رفيع للمستخدم النهائي، والحاجز هو الكود.
00:41:30لذا، أعتقد بطريقة ما أن بعض الفوائد الأكبر تأتي من هناك أكثر من
00:41:36الهندسة البحتة. مرة أخرى، لا أقول إن الهندسة البحتة لا تحصل على الكثير
00:41:40من القيمة من ذلك، لكن أعتقد أن عنق الزجاجة لا يزال يتمثل في ذلك الذوق. بالإضافة إلى ذلك، أنا أقضي
00:41:45الكثير من الوقت في مراجعة طلبات السحب (PRs) التي لا طائل منها. الآن هناك جانب سلبي لذلك أيضًا.
00:41:51بالضبط. بالتأكيد. وكمية الكود التي يتعين عليك مراجعتها.
00:41:56نعم، مثل هذه الثغرة الغامضة التي لا توجد فرصة تقريبًا لحدوثها.
00:42:01وأنا لست متأكدًا حتى مما إذا كانت تُصنف كمنخفضة الخطورة، أليس كذلك. ولكن بمجرد ظهورها،
00:42:06تشعر بمسؤولية تجاهها. وأعتقد أن هذا طبيعي. لكن في
00:42:09بعض الأحيان، كان الأمر كما لو أننا لم نحصل على هذا العدد الكبير من طلبات السحب المفتوحة في أي وقت.
00:42:14وأصبح الأمر جنونيًا بعض الشيء لاستيعاب كل هذا حقًا. و
00:42:18أعتقد أن جلب الحكم المناسب، بمعنى أنه لمجرد أنك تستطيع فعل كل شيء،
00:42:21فهذا لا يعني أنه يجب عليك فعل كل شيء. وأعتقد أن ذلك يأتي مع نوع من نهج
00:42:26النماذج اللغوية الكبيرة (LLM). وأعتقد أن جلب نوع من الحكم على ما سيستمد منه
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الرضا والمكافأة السريعة المرتبطة بذلك. وأعتقد أن ذلك في بعض الأحيان
00:43:11يتغلب علينا. صحيح. أو على الأقل، متحدثًا عن نفسي، كم يبلغ حجم الفريق؟
00:43:15نحن 10 حاليًا. أوه، واو. هذا فريق نحيف للغاية. نعم. كل الاحترام. لقد كان ذلك دائمًا طموحي.
00:43:23لا أعتقد أنني أفضل مدير. ولذا أعتقد أنه من الأفضل للجميع بهذه الطريقة.
00:43:29لا، أنا أمزح نوعًا ما، أعتقد أننا منذ البداية ولدنا في خضم جائحة كوفيد،
00:43:33أليس كذلك؟ الجميع يعملون عن بعد. وكانت هناك عقلية منذ البداية
00:43:38توظف أشخاصًا ذوي خبرة، ومستقلين للغاية
00:43:45لإعطاء فكرة عن ذلك. نحن حقًا نقوم فقط بإجراء مكالمة واحدة كل أسبوعين، لمناقشة
00:43:50المنتج والبنية التحتية. لذلك، حاولنا جاهدين أن يكون لدينا سير عمل غير متزامن.
00:43:56وأعتقد أنه يفسح المجال جيدًا لحالات استخدام الذكاء الاصطناعي أيضًا. لأننا
00:44:01قمنا بالفعل بالتوظيف والتحسين للأشخاص الذين لديهم هذا الاستقلال. لا أعتقد أن هناك
00:44:06طريقة صحيحة أو خاطئة. لن أقدم وعظًا حول الطريقة التي نقوم بها بالأشياء، لكن أعتقد أنها تعمل معنا.
00:44:11لا شيء يعمل معي ومع سلامتي العقلية. لذا هناك ذلك.
00:44:14أردت التطرق إلى الشيء الذي قلته في بداية المحادثة، وهو أن،
00:44:21خطافات الويب (web hooks) ميتة. الطريقة الجديدة هي بوابة الأحداث (event gateway). هل صغت هذا المصطلح أم كان موجودًا
00:44:27في الأثير بالفعل؟ ما هي بوابة الأحداث؟ ليس لدي أي فهم لذلك.
00:44:32نعم، لقد صغناه وكان من الصعب جدًا بناء منتج وفئة منتجات
00:44:37غير ثابتة. لأن لديك تحديات تتعلق بالتسويق
00:44:41والتواصل وكيف تصف هذا الشيء. لفترة كنا نسميه
00:44:46بنية تحتية لإدارة خطافات الويب (web hook management infrastructure) وما شابه ذلك.
00:44:51لا شيء يسهل نطقه. لذا، لديك التحدي في التواصل،
00:44:54ولكن لديك أيضًا التحدي في المنتج. فعندما تبني منتجًا في فئة موجودة،
00:44:58دعنا نقول مثل stack أو القابلية للملاحظة، فأنت تعرف ما الذي تحاول تحسينه،
00:45:02مثل نقاط البيع الفريدة (USPs) الخاصة بك، والتي في حالتك، أعتقد أن الكثير منها يدور حول التسعير
00:45:07وتجربة المطور (DX) وما إلى ذلك. لكن النقطة هي أن الدلالات الأساسية موجودة. وما
00:45:10تقوم بتحسينه هو عرض القيمة الفريد هذا. عندما تبني شيئًا لا
00:45:14يوجد بالفعل، عليك ابتكار الدلالة ثم بناء عرض قيمة مقنع
00:45:19فوق تلك الدلالات. لذا يصبح ذلك صعبًا للغاية.
00:45:24وهذا أحد الدروس المستفادة خلال العامين الماضيين، من الصعب جدًا بناء منتج في فئة موجودة.
00:45:28لذا فإن الفكرة من وراء “بوابة الأحداث” ومن أين جاءت، هي
00:45:32محاولة التقاط ما نفعله بأفضل ما يمكن، في كلمتين أو ثلاث كلمات سهلة النطق
00:45:37نوعًا ما. وكان هدفنا هو بناء جسر بين ناقل الأحداث (event bus)
00:45:43وبوابات واجهة برمجة التطبيقات (API gateways). والتقاط هذه الفكرة بأن البوابات موجودة
00:45:49كواجهة، الواجهة بين البائع ونظامك الخاص وما إلى ذلك. و
00:45:55ناقل الأحداث بمعنى، هذا هو إدارة الأحداث المتكاملة، ووضعها في قوائم الانتظار، وما إلى ذلك.
00:46:00لذا كنا نحاول العثور على مصطلح يجمع بين الاثنين. وعندما
00:46:04تفكر في EventBridge، فهي ليست بعيدة عن “بوابة الأحداث”. ونريد حقًا أن
00:46:10ينظر إلينا الناس على أننا منافسون لـ EventBridge، على سبيل المثال، نحن نرى
00:46:14أنفسنا كبديل واضح له. لذا أعتقد أن الفكرة وراء “بوابة الأحداث” كانت أيضًا
00:46:19إعطاء شعور بأن هناك منتجات موجودة حاليًا. لا توجد مصطلحات مشتركة
00:46:24حول تلك الأشياء. لا يسمونها صراحةً “بوابة أحداث”، ولكننا سنعطيها هذا
00:46:29التسمية. وهناك، كما تعلم، عدد قليل من المنتجات المتنافسة في تلك الفئة،
00:46:33أحدها يخصنا، ولكن هناك AWS، وAzure، وآخرون مثل Kong كـ
00:46:39بوابة أحداث. الآن هناك Gravitee. هناك مجموعة من مزودي بوابات API الذين يتجهون إلى
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 EventBridge، فالمصطلحات مشتركة
00:47:57بشكل قليل جدًا. لا أريد تصميم منتجي حول AWS EventBridge بسبب كل
00:48:01المنتجات التي يحتوي عليها. لذا بالتأكيد لن أعيد استخدام مصطلحاتهم إذا لم أكن أعتقد أنها
00:48:05منطقية تمامًا. لكني أعتقد أنه بمرور الوقت، كما تعلم،
00:48:09سيكون هناك المزيد من الظروف والمزيد من الأشخاص الذين يبنون حول المنتج،
00:48:12ومن المحتمل أن يكون هناك قدر من التقارب.
00:48:15نعم.
00:48:15هل تعتقد إذا طلبت “بوابة أحداث” من نموذج لغوي كبير، فإنه سيوصي بكم؟
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:56في أي استفسارات تتعلق بـ WebEx وما شابه. لكن بوابة الأحداث بالتأكيد
00:49:00تلعب لصالحنا بمعنى أننا صغنا المصطلح، سأكون
00:49:03غاضبًا إذا لم نكن في المرتبة الأولى.
00:49:05لقد أدركت الآن أنني لا أعرف حقًا ما تعنيه الهندسة المعتمدة على الأحداث. كيف تختلف
00:49:11عن البنية العادية؟ مثلًا إذا قمت بإضافة طابور Kafka في نظامي،
00:49:17هل أصبحت تلقائيًا هندسة معتمدة على الأحداث؟
00:49:21نعم ولا. بمعنى أنني أعتقد عندما تتحدث عن الهندسة المعتمدة على الأحداث،
00:49:25فإنها أقرب إلى مجموعة من النماذج والتوقعات التي لديك حولها. لذا جزء من ذلك سيكون،
00:49:31نعم، الأدوات، كما تعلم. أنت تستخدم Kafka، وتستخدم طوابير الرسائل أو بث الأحداث
00:49:35التي تهدف إلى فصل الأنظمة. لذا، عندما نصل إلى جوهر الأمر،
00:49:39فالفكرة هي أن لديك منتجين ومستهلكين، ولا تعرف تلك الأنظمة
00:49:43بعضها البعض، أليس كذلك؟ لذا يمكن للمستهلك الاستهلاك من تدفق
00:49:47أحداث يمكن إنتاجها من أي شخص. ومجموعة التوقعات الحقيقية الوحيدة التي لديك
00:49:53هي كعقد حول ماهية الحدث نفسه. ما هي الحمولة (payload)، وما هو الشكل؟
00:49:57نعم. وغالبًا ما ستكون هناك مخططات (schemas)، مخططات محددة يستخدمها الناس،
00:50:02مثل المخططات القائمة على Avro وProtobuf وغيرها، أليس كذلك؟ حيث ستكون هناك
00:50:06توقعات موحدة حول ماهية تلك الحمولات وما إلى ذلك. والحق يقال، العقد يصبح
00:50:11حول، حسنًا، هذه الأحداث موجودة. وفي مرحلة ما قد يكون لدي حدث، وكمستهلك،
00:50:16مسؤوليتي هي القيام بأي شيء يُفترض أن أقوم به، مثل إنشاء طلب أو تحديث منتج وما إلى ذلك.
00:50:21صحيح. لكن المؤسسة التي تبنت EDA حقًا، ما ستراه هو نوع من
00:50:25نمط منهجي حول هذا، أليس كذلك؟ حيث ستكون هناك مبادئ توجيهية
00:50:29محددة حول كيفية القيام بذلك وما يُفترض أن تكون عليه أشكال الحمولة.
00:50:32وسيكون نهجًا هندسيًا حيث ستتعمد فصل
00:50:36خدماتهم وجعل التواصل بينها معتمدًا على الأحداث، أليس كذلك؟
00:50:41أشعر أن الكثير من الشركات تتبع نهجًا هجينًا، أليس كذلك؟ شيء ما يعتمد على الأحداث،
00:50:45وشيء ما ليس كذلك، صحيح؟ هل الهدف هو أن يكون الاعتماد على الأحداث بنسبة 100%؟
00:50:50أم أنه مجرد مجموعة فرعية من النموذج المعماري؟
00:50:54لا أعتقد أنها 100%. أعتقد فقط أنه بمرور الوقت، مع نموك وزيادة التعقيد،
00:51:00ووجود المزيد من التبعيات الخارجية وما إلى ذلك، فهي الطريقة الطبيعية التي تميل إليها الأشياء
00:51:04للمضي قدمًا. لأنه في مرحلة ما، من الصعب جدًا إبقاء كل تلك الأنظمة مقترنة.
00:51:09ثم يتعين عليك التفكير في التوسع والترابط البيني وكل تلك الأمور
00:51:14بطريقة تجعل الأمر صعبًا للغاية. ولكن بشكل عام، عندما نفكر في
00:51:19الهندسة المعتمدة على الأحداث، بمعنى المصطلح، أعتقد أن الناس يفكرون،
00:51:23بشكل صحيح، يفكرون في المؤسسات الكبيرة، أليس كذلك؟ وأعتقد أنه ربما للعقد الأول
00:51:28من الهندسة المعتمدة على الأحداث، كان الأمر يتركز بشكل أساسي في المؤسسات الكبيرة. لكن أعتقد الآن
00:51:32أن ذلك يتغير جزئيًا بسبب راحة الناس مع هذه الأنماط، وجزئيًا لأن
00:51:37خطافات الويب (WebEx) هي بوابة للدخول إليها. ولكن أيضًا بفضل تحسن بعض الأدوات. أنا أفكر،
00:51:41أنا أفكر مثلًا في RabbitMQ، أو BullMQ، المبنية على
00:51:46Redis، وبعض المكتبات. هناك أيضًا مجموعة من المكتبات الشهيرة في Python، مثل
00:51:51Celery، وفي Ruby هناك Sidekiq. أعتقد أن هناك واحدة أخرى الآن، Foundation، وهي أيضًا من
00:51:57أشخاص Sidekiq. على أي حال، كانت هناك أدوات تقدمية حول
00:52:01هذا الأمر، مما يجعله أسهل في العمل وأقل ترهيبًا للبدء، حيث لا تحتاج فقط إلى
00:52:05فريق هندسي كبير وعمليات نشر Kafka كبيرة، تكلف الكثير
00:52:11من المال وما إلى ذلك لبدء العمل بالهندسة المعتمدة على الأحداث. لكني أعتقد أيضًا أن المصطلح
00:52:15قد فقد القليل من معناه. أنا متأكد من أن بعض الناس لن يسعدهم سماع ذلك. ولكن
00:52:19أعتقد أنه فقد القليل من معناه بمرور الوقت، أو على الأقل أصبحت المياه عكرة فيما نعنيه.
00:52:25وأعتقد عندما أقول ذلك، ما أشير إليه هو بشكل أساسي فصل الأنظمة. ثم
00:52:31أيضًا المخاوف البرمجية التي لن تضطر إلى التفكير فيها كمهندس من حيث،
00:52:37تعلم، الاضطرار إلى التفكير في التبعية والترتيب وكل تلك المخاوف. لذا عندما
00:52:43أقول “هندسة معتمدة على الأحداث”، فأنا أقصد أنك تدخل الآن في عالم حيث
00:52:48عندما تبني تطبيقك، سيكون لديك تلك المجموعة من المخاوف التي لم تكن لديك من قبل.
00:52:52صحيح، فهمت. والقدرة على التعلم وتبني كيف تبني الأشياء لتكون قادرًا على
00:52:58استيعاب تلك المخاوف. لا أعرف ما إذا كنت أقصد في البداية نوعًا ما
00:53:03الطريقة المؤسسية الكبيرة. وأعتقد أننا نحاول إلى حد ما، كما تعلم،
00:53:08جلب ذلك للجميع بطريقة ما. صحيح. ونحن لسنا اللاعب الوحيد الذي يفعل ذلك.
00:53:14صحيح. هناك مجموعة من الأشخاص الآخرين الذين يتبعون نهجاً مختلفاً.
00:53:18هناك محركات سير العمل وخطوات الدوال (Step Functions) التي أعتقد أنها تتداخل، مثل
00:53:22Temporal و Ingest و Trigger.dev، وغيرهم من هؤلاء الأشخاص أيضاً. لذا أعتقد أن هذا المجال
00:53:28يشهد الكثير من النشاط. وربما لا يوجد تعريف ثابت وجيد له
00:53:34بعد الآن. بالنسبة لأولئك المهتمين حقاً بمعرفة المزيد
00:53:38حول البنية المعتمدة على الأحداث (Event-Driven Architecture) والنماذج المرتبطة بها وما إلى ذلك. هناك هذا الشخص
00:53:42الذي يدعى ديفيد بويان، والذي كان سابقاً مناصراً للمطورين في AWS وكان يعمل فعلياً على
00:53:49EventBridge. تلك السلسلة من الشروحات الرسومية. لكن في هذه المرحلة، ربما لديه
00:53:55مئات منها، كما أنه يدير مشروعاً مفتوح المصدر الآن يسمى Event Catalog، قد يكون ضيفاً جيداً في بودكاستكم.
00:54:02لكن كل ما يمكنني قوله هو أن الأمر يغوص في أعماق غير معقولة.
00:54:07صحيح. لذا أوصي به بشدة لأولئك الفضوليين.
00:54:14رائع. سنضيفه إلى ملاحظات العرض. نعم، بما أن كل معرفتك حول الأحداث وخطافات الويب (Webhooks)
00:54:19وكل شيء. يبدو أن لديك الكثير من الخبرة بفضل بناء Hookdeck.
00:54:23أو هل كان ذلك لأنك واجهت بضع مشكلات مع خطافات الويب، هل كان هذا عندما
00:54:27تعمقت حقاً في الأحداث؟ نعم إلى حد كبير. وأعتقد أن هذا التعلم جاء كثيراً من
00:54:34المشكلات، وأيضاً من المبادئ الأساسية، بمعنى أنه عندما كنت أتعامل مع تلك
00:54:38المشكلات، لم تكن لدي معرفة واسعة حولها، وهو ما كان جزءاً من سبب تعاملي
00:54:42مع تلك المشكلات. لذا أعتقد أن الأمر جاء من محاولة العمل على
00:54:47المشكلة وحلولها، بدلاً من العمل على حلول ومحاولة تطبيقها على المشكلة.
00:54:51صحيح. لكن في نهاية المطاف، في هذه المرحلة،
00:54:55لقد عملنا مع مئات الآلاف من خطافات الويب من جميع أنحاء
00:54:59النطاقات. وأعتقد أنني تشربت الخبرة من تلك المحادثات. وكان الأمر
00:55:05مثيراً للاهتمام حقاً. لقد بدأت في الواقع كمصمم منتجات في البداية. لذا
00:55:11كما تعلم، مصمم منتجات، ثم مطور شامل (Full stack)، ثم مطور خلفية،
00:55:15ثم مهندس بنية تحتية. والآن أنا عميق جداً في
00:55:21هذا المجال. جاء هذا من خلال العمل مع العملاء والاستماع
00:55:26إلى مخاوفهم ومراجعة البنية التحتية وكل تلك الأمور. وكذلك من الفريق،
00:55:30صحيح؟ لدينا أشخاص في الفريق لديهم خبرة واسعة في العمل مع
00:55:33تلك الأنظمة، وقد جلبوا تلك المعرفة للشركة. نعم. متى
00:55:38أدركت أنك وجدت سوقاً لهذا؟ أفترض أنك بدأت العمل عليه ثم
00:55:42نشرته في مكان ما. هل كان الاستقبال جيداً على الفور؟ أم كان الأمر بطيئاً نوعاً ما
00:55:47لإقناع الناس بأن هذا هو الخيار الأفضل؟ إنه بطيء، بطيء جداً،
00:55:53بمعنى أنه بدأ بتلك المقالة على Medium التي أشرت إليها، أليس كذلك؟ نوع من
00:55:57مشاكل خطافات الويب وما يمكنك فعله حيالها. أنا من عقلية بناء المنتج
00:56:01للناس. لذا كانت النسخة الأولى ذاتية الخدمة،
00:56:07يمكنك الدخول وإنشاء أول اتصال لك، كما نسميه، وكل تلك الأمور.
00:56:12ونشرت تلك المقالة. لم تكن لدي أي طموح لبناء عمل تجاري منه
00:56:16أو أي شيء من هذا القبيل. كان مجرد واحد من بين 20 مشروعاً جانبياً فاشلاً،
00:56:21كنت أعمل عليها في ذلك الوقت. ومن منظور استرجاعي، الآن
00:56:26تبدو الأرقام صغيرة بشكل مثير للسخرية، ربما تواصل معي خمسة أشخاص
00:56:32من تلك المقالة أو شيء من هذا القبيل. لكنني أعلم بالنسبة لكل من عمل على مشاريع جانبية،
00:56:37ومر بمحاولات إقناع شخص ما باستخدام شيء قمت ببنائه
00:56:42وما إلى ذلك، فإن خمسة أشخاص هو أمر جنوني. خمسة أفضل مما حصلت عليه من قبل.
00:56:48صحيح. لذا كنت متحمساً جداً لذلك. كنت في الواقع في
00:56:55عربتي للتخييم في بريتيش كولومبيا، أتسلق الصخور. وكنت بعيداً جداً عن
00:57:00محاولة بناء شركة ناشئة. كنت فقط أجري محادثات مع هؤلاء الأشخاص،
00:57:05أشرح لهم ما كنت أفكر فيه والمشكلة التي كانوا يواجهونها
00:57:08وما إلى ذلك. ثم بدأ الناس بالتسجيل واحداً تلو الآخر بينما كنت أتسلق الصخور.
00:57:13أفتح تطبيق Slack، وتصلني إشعارات التسجيل. لدينا قناة إشعارات
00:57:18لكل عمليات التسجيل، صحيح؟ نفس القناة التي لدينا منذ ست سنوات.
00:57:21في هذه المرحلة، أصبح من الصعب جداً تتبعها لأنها تتجدد بسرعة كبيرة.
00:57:25لكن، كنت أتلقى تلك الإشعارات في القناة. وكنت أقول
00:57:31يا للهول، شخص ما سجل. هل أنت تقوم بهجوم DDOS على Slack؟
00:57:38لا، بالتأكيد ليس في تلك الأيام. لكنك قلت للتو أنك ما زلت تملكها الآن. لهذا
00:57:44أسأل. حسناً، الأمور تسير على ما يرام، لكن لا أعتقد أنها وصلت
00:57:48إلى درجة القيام بهجوم DDOS على Slack. على أي حال، أعتقد أن الافتراض الأساسي
00:57:54في البداية الذي كان يمثل مشكلة، هو الفكرة القائلة بأنه بني بشكل رئيسي
00:57:58للمراقبة. أعتقد أن هذا لم يكن كافياً. ولكن بمجرد الانتقال من قول
00:58:02أنا أبني أداة مراقبة إلى أنا أعيد ابتكار ناقل الرسائل (Message Bus)، يتسع النطاق فجأة
00:58:08بشكل كبير. لقد التقيت بشريك المؤسس والمدير التقني في خضم بناء أول محرك قوائم انتظار.
00:58:15وعندما أدركت أن النطاق سيتسع كثيراً،
00:58:19في تلك اللحظة قمنا بالبحث عن تمويل أولي صغير من مستثمرين ملائكيين.
00:58:23كان من الواضح أنه سيكون مكلفاً جداً للبناء، وهو ما حدث بالفعل.
00:58:28وحسب فهمي، لم تتبع طريق سان فرانسيسكو التقليدي. بنيتها في مونتريال، صحيح؟
00:58:32نعم، قد يكون ذلك غير دقيق قليلاً لما حدث بالفعل. لقد حصلنا على
00:58:36تمويل أولي بقيمة 400,000 دولار من مستثمرين ملائكيين فقط،
00:58:39بدون أي صناديق استثمار مؤسسية. ولكن بعد بضعة أشهر، قمنا بالنشر على موقع Hacker News،
00:58:44وهنا أدركنا، بالعودة إلى سؤالك يا جيمس، أن الاستجابة من Hacker News،
00:58:51لم تكن أكبر ظهور على الموقع على الإطلاق، لكنها كانت أفضل بكثير مما توقعنا.
00:58:56قصة طريفة: أتذكر شخصاً اشترى خطة بقيمة 300 دولار
00:59:00بعد Hacker News، وقلت لشريكي المؤسس: يا رجل، لقد نجحنا.
00:59:05الأمر محسوم. نحن بالتأكيد في طريقنا للنجاح.
00:59:11ذهبنا للعشاء في تلك الليلة وأنفقنا المال كله.
00:59:18نعم، هذا بالضبط ما حدث. زجاجة شمبانيا.
00:59:22نعم، لكن على أي حال،
00:59:25من ذلك المنشور، تلقينا الكثير من الاهتمام من المستثمرين الذين تواصلوا معنا بشكل استباقي.
00:59:31وفي النهاية، قمنا بجمع جولة تمويلية من مستثمرين من وادي السيليكون،
00:59:34شركة تدعى Matrix Partners. لذا لا نزال شركة كندية مقرها في مونتريال.
00:59:38لم نتحول إلى شركة Delaware LLC، لكن مستثمرينا كانوا رائعين
00:59:44وأنا سعيد جداً لأننا فعلنا ذلك. وبسبب كوفيد وما إلى ذلك،
00:59:50أصبح هناك قبول متزايد للشركات التي لا تتواجد هناك،
00:59:55وبناء فرق عمل عن بُعد. لقد فعل الكثير من الناس ذلك،
01:00:00لم نبتكر أي شيء، لا تزال هناك شركات مثل Zapier وGitLab التي
01:00:04تقوم بهذا منذ وقت طويل قبل أي شخص آخر. لذا أعتقد أن الأمر أصبح طبيعياً.
01:00:08وهذا شيء رأيته من بعض المؤسسين، ربما أكون ساذجاً بهذا الشأن،
01:00:12ولكن هناك حديثاً كبيراً بين المؤسسين الكنديين على تويتر حول
01:00:17التسجيل في ولاية ديلاوير، وأن YC توقفت عن قبول الشركات الكندية،
01:00:21ثم تراجعوا عن هذا القرار. ولكن كان هناك هذا الفهم بأن
01:00:27كل مستثمر سيطلب منك التحول إلى شركة في ديلاوير. وهم على حق،
01:00:32كل مستثمر سيطلب ذلك، لكن الجزء الغائب من القصة هو أنه يمكنك ببساطة قول لا.
01:00:38سيطلبون ذلك، ولماذا لا؟ والأمر أسهل بالنسبة لهم،
01:00:42ولكن تبين أنه إذا قلت لا، فإن الأمر مقبول تماماً أيضاً. على الأقل في تجربتي،
01:00:47وهذا ما يفتقده الكثير من الناس في تلك القصة. وظيفتهم هي استثمار رأس المال،
01:00:54وهم يبحثون عن أشخاص للاستثمار فيهم وعن أفكار أصلية. لا أريد الجدال
01:00:58حول إيجابيات وسلبيات الوجود هناك، لكن في نهاية المطاف، خيارك كمؤسس وبانٍ
01:01:03هو مع من ستقوم بذلك وأين. وإذا كان لديك أفكار جيدة
01:01:07وعمل جاد، سيحترم المستثمرون ذلك. وربما تكون وظيفتك العثور عليهم.
01:01:11سيكون من غير الصادق القول إننا خارج تلك الفقاعة تماماً،
01:01:15لكنني سعيد شخصياً بالبقاء في مونتريال. حسناً، كزميل كندي،
01:01:19يسعدني سماع قصص نجاح كندية. تهانينا على ذلك، لكنك انتقلت إلى تورنتو ثم
01:01:24أفسدت الأمر برمته. عادل، عادل. هل يمكنني القول كزميل في الكومنولث، عظيم،
01:01:27صحيح؟ نفس الملك. إنه نفس الشيء، أليس كذلك؟ نعم. نحن
01:01:31لدينا الملكة. لا أعرف إن كانوا قد حدثوا العملة للملك الآن،
01:01:36لكننا كنا نملك الملكة على ورقتنا النقدية. نعم. هل كان Hookdeck
01:01:41أول شركة ناشئة لك كمؤسس، أم كانت هناك مشاريع أخرى منحتك
01:01:47الأدوات لمعرفة كيفية التواصل مع المستثمرين؟ كنت دائماً
01:01:52ريادياً جداً منذ البداية، في شركات صغيرة،
01:01:57إصلاح أجهزة الكمبيوتر في سن 14 أو 15 وما إلى ذلك. لذا، أعتقد
01:02:06بمعنى ما، كنت أتحدث إلى الروح الريادية، لكن معظمها كانت مشاريع
01:02:11جانبية فاشلة، مثل إصدار لعبة فيديو لم تذهب إلى أي مكان.
01:02:14وفي مرحلة ما كنت أعمل على شبكة اجتماعية، رغم أنني ربما كنت أسوأ شخص
01:02:19في التجمعات الاجتماعية وتنظيم الأشياء مع الأصدقاء. على أي حال، لقد مررت
01:02:23بتقلبات الأمور. سأقول مع ذلك،
01:02:27هذه التجربة في شركة التجارة الإلكترونية كانت تكوينية جداً،
01:02:34حيث انضممت كموظف أول هناك، وكنت مشاركاً جداً مع الفريق المؤسس.
01:02:38انتقلنا من أربعة أشخاص إلى حوالي 40 شخصاً
01:02:44في غضون ثلاث سنوات. وكل تقلبات بناء ذلك العمل,
01:02:48كل تلك الأمور. لذا أعتقد أن Hookdeck هو إلى حد كبير
01:02:53أول مشروع حقيقي لي، وسيكون من غير الصادق وضعه بالكامل في هذا الإطار. أعتقد أن هناك
01:02:58تعرضاً لتلك الأشياء من قبل. ومن الواضح أنني في شركة التجارة الإلكترونية
01:03:03عملنا مع المستثمرين أيضاً ومجلس الإدارة وبنينا علاقات هناك.
01:03:07وكان أول مستثمر في ذلك العمل التجاري هو أيضاً أول مستثمر في Hookdeck.
01:03:13لذا لم أكن أبدأ من الصفر تماماً. لكنني
01:03:19ما زلت لم أتوقع أن أكون هنا قبل بضع سنوات. وهذا رائع.
01:03:23رأيت شركة تدعى Kiwi Mornings، شركة ناشئة للإفطار الصحي. ما كان هذا الأمر؟
01:03:27لقد قمت بواجبك المنزلي. حسناً، كان ذلك أحد الأعمال التجارية الفاشلة على طول الطريق.
01:03:31بدأتها في الواقع مع زوجتي. القصة تقول إن زوجتي كانت
01:03:36تحضر إفطارها معها للعمل، وكان جميع موظفي المبيعات يشعرون بالغيرة
01:03:39ويطلبون منها تحضير إفطار لهم. وكنت أقول، ماذا تقصدين إفطاركِ وموظفي المبيعات؟
01:03:44ما الخطأ في ذلك؟ لكن الأمور تطورت وكانت تحضر خمس أو
01:03:48ست وجبات إفطار كل صباح لفريق المبيعات. وكانوا يقولون، لماذا لا
01:03:54رأيت أن هناك شركة تدعى “كيوي مورنينغز”، وهي شركة ناشئة للإفطار الصحي. ما قصتها؟
01:04:02لإفطار بدون هدر في العمل. كنا نوصل الزبادي، والعصائر،
01:04:09وبودنج الشيا وما شابه ذلك في أوعية زجاجية صغيرة.
01:04:14وكان لدينا ثلاجة صغيرة في المكاتب. وبحكم طبيعتي،
01:04:19بالغت في الأمر من ناحية المنتج والهندسة. كانت كل الطلبات تأتي
01:04:24عبر بوت Slack، وكان بإمكان أصحاب العمل تقديمها كميزة للموظفين حيث يدفعون
01:04:3050% من تكلفة الإفطار. وكان الموظفون يطلبون إفطارهم عبر البوت.
01:04:36انتهى الأمر ببساطة لأن كل شيء يفسد في الرابعة صباحاً،
01:04:41بالإضافة إلى أنه لا يوجد مال في قطاع الأغذية. لذا كان من الصعب
01:04:47بناء عمل مستدام. قمنا ببيع بوت Slack وتوقفنا عن ذلك.
01:04:51لحسن الحظ، كان ذلك في يناير 2021، قبل شهرين من كوفيد.
01:04:56وخرجت تقريباً كل الشركات المماثلة التي تقدم وجبات الغداء في المكتب من العمل.
01:05:01لذا كنا محظوظين قليلاً بالتوقيت. بعنا حوالي 20,000 وجبة إفطار.
01:05:06أوه، هذا رائع جداً. نعم، رائع حقاً.
01:05:11نعم، نسأل دائماً ضيوفنا، ما هي آرائكم الجريئة حول الصناعة أو الذكاء الاصطناعي؟
01:05:16أشعر أنني قدمت القليل منها في هذه المحادثة.
01:05:20أعتقد ذلك. ما هي أكثر آرائك جرأة؟
01:05:25آراء جريئة. حسناً، ربما سأفقدك هنا لأنها تتعلق بـ
01:05:29تعقيدات البنية المعتمدة على الأحداث. أنا متأكد من أن بعض جمهورنا سيفهم.
01:05:34حدث ذلك في يناير ٢٠٢١. أي قبل كوفيد بشهرين. ومن حيث الأساس، كل
01:05:42مقارنة بالأنظمة القائمة على الدفع (Push-based). والسبب هو أنه لا توجد قائمة انتظار
01:05:46بنت نظاماً جيداً يعتمد على الدفع. والسبب هو أنك عندما تبني قوائم انتظار
01:05:52ومستهلكين لكل قائمة، فأنت بحاجة لمستهلك لكل واحدة.
01:05:57قد يكون ذلك المستهلك عاملاً يعمل لفترة طويلة يسحب من تلك القائمة.
01:06:01المشكلة هي إذا كنت تريد قوائم انتظار ديناميكية،
01:06:06مثلاً قائمة انتظار لكل عميل، لأنك لا تريد أن يقوم عميل واحد بتعطيل القائمة بأكملها.
01:06:12ستحتاج إلى مستهلكين بعدد قوائم الانتظار، مما يخلق مشكلة تعدد الإرسال.
01:06:18الميزة الكبيرة في أنظمة الدفع هي أن كل قوائم الانتظار يمكنها الدفع
01:06:22إلى نفس المستهلك. وهذا المستهلك يمكن أن يكون واجهة برمجة تطبيقات مع موازن حمل،
01:06:29يمكنك توسيعه أفقياً أو عمودياً. النقطة هي أنه يمكنك القيام بذلك
01:06:35منفصلاً تماماً عن عدد قوائم الانتظار. ما نراه هو أنه بمجرد الدخول في حالات استخدام
01:06:42أكثر تعقيداً، ينتهي بك الأمر بطرق أكثر دقة لترتيب قوائم الانتظار.
01:06:49تريد ترتيباً لكل موضوع ولكل عميل، ويصبح الأمر جنونياً لأنك تمتلك
01:06:56100 قائمة انتظار و100 مستهلك وكل هذا الفوضى.
01:07:02من الصعب اليوم العثور على قوائم رسائل تعتمد على الدفع.
01:07:07السبب هو أنك تنقل مكان التحكم في الإنتاجية (Throughput).
01:07:12إذا كان التحكم في الإنتاجية في المستهلك، فهو المسؤول عن قول
01:07:16أريد 50 رسالة في الثانية. ويعتمد عدد الرسائل المستهلكة
01:07:21على سعة العامل وعدد العمال. وليس لأنك تقول 50 في الثانية،
01:07:26يعني أن الأمر يسير بسرعة 50، بل يعتمد على سرعة الكود.
01:07:31لذا أعتقد أن معظمها لا يمنحك الدقة اللازمة في التحكم في الإنتاجية.
01:07:36على سبيل المثال، GCP Pub/Sub لديه وضع دفع، لكنه يقوم برفع معدل
01:07:41إرسال الطلبات حتى تبدأ واجهة البرمجة بالتأثر، مما يؤدي إلى تدهور الأداء.
01:07:45ثم يخفض معدل التوصيل. وما ينتهي بك الأمر إليه هو تدهور
01:07:49مستمر يصل للصفر ثم يعود للارتفاع، تدهور مستمر ثم صفر.
01:07:54لا معنى له. إذا قمت ببناء قوائم رسائل تعتمد على الدفع
01:07:58مع تحكم دقيق جداً في الإنتاجية وسلوك الاستهلاك،
01:08:02تصبح لديك مثلاً 100 قائمة انتظار و100 مستهلك و100 قائمة انتظار للدولار وكل هذا الفوضى التي تصاحب ذلك.
01:08:07مستعد للدفاع عنها.
01:08:13لم أفهم كل شيء، لكنه بدا معقولاً، أليس كذلك؟
01:08:17إذا فهمت ذلك، تحقق من Hookdeck. نعم، بالضبط.
01:08:22نقدر ذلك. حسناً، شكراً لك أليكس. شكراً لاستماعكم لهذه الحلقة من
01:08:29بودكاست Better Stack. ابحثوا عنا أينما تحصلون على بودكاست، Spotify، Apple Music، أو أي مكان آخر.
01:08:33اليوم وداعاً مني. وداعاً مني. ووداعاً مني.
01:08:37لأن الأمر يعتمد على بقية الكود، وما إذا كان سريعًا بما يكفي أم لا، وهكذا.
01:08:40صحيح. لذا أعتقد أن السبب في عدم انتقالنا إلى طوابير الدفع (Push-based) هو أن معظمها لا
01:08:45تمنحك في الواقع الدقة اللازمة للتحكم في الإنتاجية. فمثلاً،
01:08:50خدمة GCP Pub/Sub تمتلك وضع الدفع (Push mode)، لكن في هذا الوضع، يقومون أساسًا برفع معدل
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بودكاست Better Stack. يمكنكم العثور علينا أينما كنتم تحصلون على البودكاست، سواء على Spotify أو Apple Music أو أي مكان آخر.
01:09:57لكن اليوم، وداعًا مني. وداعًا مني. ووداعًا مني.