الدكتور مارتن كليبمان باحث في النظم الموزعة في جامعة كامبريدج ، ومؤلف كتاب
"تصميم التطبيقات المكثفة للبيانات" (O'Reilly Media ، 2017).
قال كيفن سكوت ، مدير قسم التسويق في شركة مايكروسوفت: "يجب أن يكون هذا الكتاب مطلوبًا لمهندسي البرمجيات. "تصميم تطبيقات كثيفة البيانات هو مورد نادر يربط بين النظرية والتطبيق لمساعدة المطورين على اتخاذ قرارات ذكية أثناء تصميم وتنفيذ البنية التحتية للبيانات وأنظمتها."
تشمل اهتمامات مارتن البحثية الرئيسية برامج التعاون و CRDTs والتحقق الرسمي من الخوارزميات الموزعة. عمل سابقًا كمهندس برمجيات ورائدًا في العديد من شركات الإنترنت بما في ذلك LinkedIn و Rapportive ، حيث عمل على البنية التحتية للبيانات على نطاق واسع.
Vadim Tsesko (
incubos ) هو مهندس برمجيات رئيسي في
Odnoklassniki يعمل في فريق Core Platform. تشمل اهتمامات Vadim العلمية والهندسية الأنظمة الموزعة ومستودعات البيانات والتحقق من أنظمة البرمجيات.
المحتويات:
- الانتقال من الأعمال إلى البحث الأكاديمي ؛
- مناقشة "تصميم تطبيقات البيانات المكثفة" ؛
- الحس السليم ضد الضجيج الاصطناعي والتسويق العدواني.
- مطبات نظرية CAP وغيرها من أخطاء الصناعة.
- فوائد اللامركزية ؛
- Block Block ، Dat ، IPFS ، Filecoin ، WebRTC ؛
- CRDTs جديدة. التحقق الرسمي مع إيزابيل ؛
- مصادر الحدث. نهج مستوى منخفض. معاملات XA
- Apache Kafka، PostgreSQL، Memcached، Redis، Elasticsearch؛
- كيفية تطبيق كل تلك الأدوات على الحياة الحقيقية ؛
- الجمهور المستهدف المتوقع لمحادثات مارتن ومؤتمر هيدرا.
الانتقال من الأعمال إلى البحث الأكاديمي
فاديم : السؤال الأول الذي أود طرحه عليك مهم حقاً بالنسبة لي. لقد قمت بتأسيس Go Test It و Rapportive ، وكنت تقوم بتصميم وهندسة النظم واسعة النطاق في LinkedIn لفترة من الوقت. ثم قررت التحول من الهندسة الصناعية إلى الأوساط الأكاديمية. هل يمكن أن توضح الدافع وراء هذا القرار؟ ماذا ربحت وماذا اضطرت للتضحية؟
مارتن : لقد كانت عملية مثيرة للاهتمام للغاية. كما يبدو أنك تلمح إلى ، لا يقوم الكثير من الأشخاص بعمل التبديل في هذا الاتجاه. الكثير من الناس ينتقلون من الأوساط الأكاديمية إلى الصناعة ، لكن ليس الكثير منهم. وهذا أمر مفهوم ، لأنني اضطررت إلى خفض كبير في الأجور من أجل العودة إلى الأوساط الأكاديمية. لكن ما أحبه حقًا في البحث هو حرية العمل في مواضيع أجدها مثيرة للاهتمام وأعتقد أنها مهمة ، حتى لو لم تؤدي هذه الموضوعات على الفور إلى منتج قابل للتطبيق تجاريًا خلال الستة أشهر القادمة أو نحو ذلك. بطبيعة الحال ، في الشركة تحتاج إلى أن تتحول إلى منتج يمكن بيعه بشكل أو بآخر. من ناحية أخرى ، فإن الأشياء التي أعمل عليها الآن هي موضوعات مهمة حقًا بالنسبة لمستقبل كيفية بناء البرامج وكيفية عمل الإنترنت. لكننا لا نفهم حقًا هذه الموضوعات جيدًا بما يكفي حتى نبدأ وبدء بناء المنتجات التجارية: لا نزال على مستوى محاولة اكتشاف ، في الأساس ، ما تحتاج هذه التقنيات لتبدو عليه. وبما أن هذا بحث أساسي ، فقد أدركت أنه من الأفضل القيام بذلك في إحدى الجامعات بدلاً من محاولة القيام بذلك في إحدى الشركات ، لأنني في الجامعة أحرار في العمل على أشياء قد لا تصبح قابلة للتطبيق تجاريًا لمدة عشر سنوات أخرى ، و هذا جيد لا بأس بالعمل مع أفق زمني أطول بكثير عندما تكون في البحث.
"تصميم تطبيقات كثيفة البيانات"
فاديم : سنعود بالتأكيد إلى اهتماماتك البحثية الحالية. وفي الوقت نفسه ، دعنا نتحدث عن كتابك الأخير "
تصميم تطبيقات كثيفة البيانات" أنا معجب كبير بكتابك وأعتقد أنه أحد أفضل الأدلة لبناء أنظمة موزعة حديثة. لقد قمت بتغطية جميع الإنجازات البارزة تقريبًا.
مارتن : شكرا لك ، أنا سعيد لأنك وجدت أنه مفيد.
فاديم : فقط لأولئك القراء السيئين الذين لم يقرأوا كتابك بعد ، هل يمكن أن تذكروا العديد من الإنجازات الرئيسية في مجال النظم الموزعة في الوقت الحاضر؟
مارتن : حسنًا ، ليس هدف الكتاب هو شرح تقنية معينة ؛ الهدف هو بالأحرى تزويدك بدليل للمشهد الطبيعي للأنظمة المختلفة المستخدمة لتخزين ومعالجة البيانات. هناك الكثير من قواعد البيانات المختلفة ومعالجات الدفق وأدوات معالجة الدُفعات وجميع أنواع أدوات النسخ المتماثل وما إلى ذلك ، ومن الصعب حقًا الحصول على نظرة عامة. إذا كنت تحاول إنشاء تطبيق معين ، فمن الصعب حقًا معرفة قاعدة البيانات التي يجب عليك استخدامها ، وأي الأدوات هي الأنسب للمشكلة التي تحاول حلها. الكثير من كتب الحوسبة الموجودة ببساطة لم تستجب لهذه المشكلة بطريقة مرضية. لقد وجدت أنه إذا كنت تقرأ كتابًا عن كاساندرا على سبيل المثال ، فسوف يخبرك سبب كون كاساندرا رائعًا ، لكنه عمومًا لن يخبرك بالأشياء التي لا تناسبك. لذا فإن ما أردت فعله حقًا في هذا الكتاب هو تحديد الأسئلة الرئيسية التي تحتاج إلى طرحها على نفسك إذا كنت تحاول بناء نظام واسع النطاق. ومن خلال الإجابة على هذه الأسئلة ، يمكنك حينئذ المساعدة في تحديد التقنيات المناسبة والأقل ملاءمة للمشكلة الخاصة التي تحاول حلها - لأنه بشكل عام ، لا توجد تقنية واحدة مثالية لكل شيء. وهكذا ، يحاول الكتاب مساعدتك في التعرف على إيجابيات وسلبيات التقنيات المختلفة في بيئات مختلفة.
الحس السليم ضد الضجيج الاصطناعي والتسويق العدواني
فاديم : في الواقع ، كثيرًا - إن لم يكن دائمًا - هناك العديد من التقنيات ذات الوظائف المتداخلة والميزات ونماذج البيانات. ولا يمكنك تصديق كل هذه الكلمات الطنانة التسويقية. تحتاج إلى قراءة الأوراق البيضاء لتعلم اللغة الداخلية ، وحتى محاولة قراءة التعليمات البرمجية المصدر لفهم كيفية عملها بالضبط.
مارتن : لقد وجدت أنه عليك غالبًا أن تقرأ بين السطور لأن الوثائق في كثير من الأحيان لا تخبرك عن الأشياء التي تمتصها قاعدة بيانات معينة. الحقيقة هي أن كل قاعدة بيانات تمتص عبء العمل ، والسؤال هو فقط معرفة أي منها. لذا ، نعم ، في بعض الأحيان يجب عليك قراءة إرشادات النشر لأشخاص العمليات ومحاولة إجراء هندسة عكسية لما يحدث بالفعل على النظام.
فاديم : ألا تشعر أن الصناعة تفتقر إلى المفردات الشائعة أو مجموعة من المعايير لمقارنة الحلول المختلفة لنفس المشكلة؟ تسمى الأشياء المتشابهة بأسماء مختلفة ، يتم حذف بعض الأشياء التي يجب أن تكون دائمًا واضحة ومذكورة صراحة ، مثل ضمانات المعاملات. ما رايك
مارتن : نعم ، أعتقد أن المشكلة التي تواجه صناعتنا هي أنه في كثير من الأحيان ، عندما يتحدث الناس عن أداة معينة ، هناك الكثير من الضجيج حول كل شيء. وهذا أمر مفهوم ، لأن الأدوات يتم تصنيعها من قبل العديد من الشركات ، ومن الواضح أن تلك الشركات ترغب في الترويج لمنتجاتها ، وبالتالي فإن هذه الشركات سترسل أشخاصًا إلى المؤتمرات للتحدث عن مدى جمال منتجهم بشكل أساسي. سيتم تنكره كحديث تقني ، لكنه في الأساس لا يزال نشاط مبيعات. كصناعة ، يمكننا حقًا القيام بمزيد من الصدق حول مزايا وعيوب بعض المنتجات. وجزء من ذلك يتطلب مصطلحات مشتركة ، لأنه بخلاف ذلك لا يمكنك ببساطة مقارنة الأشياء على قدم المساواة. ولكن فيما وراء المصطلحات المشتركة ، نحتاج إلى طرق للتفكير في الأشياء التي تكون فيها بعض التقنيات جيدة أو سيئة.
مطبات نظرية CAP وأخطاء الصناعة الأخرى
فاديم : سؤالي التالي مثير للجدل. هل يمكن أن تذكر أي أخطاء كبيرة في الصناعة التي تعثرت عليها خلال حياتك المهنية؟ ربما التقنيات المبالغة في التقدير أو الحلول التي تمارس على نطاق واسع كان ينبغي أن نتخلص منها منذ زمن طويل؟ قد يكون هذا مثالًا سيئًا ، لكن قارن JSON عبر HTTP / 1.1 مقابل gRPC الأكثر فاعلية على HTTP / 2. أم أن هناك وجهة نظر بديلة؟
مارتن : أعتقد في كثير من الحالات أن هناك أسبابًا وجيهة للغاية وراء سبب قيام التكنولوجيا بأداء شيء ما وليس بأخرى. لذلك أنا متردد للغاية في تسمية أخطاء الأشياء ، لأنها في معظم الحالات هي مسألة المقايضات. في مثالك على JSON عبر HTTP / 1.1 مقابل Protocol Buffers عبر HTTP / 2 ، أعتقد أن هناك بالفعل حجج معقولة للغاية لكلا الجانبين هناك. على سبيل المثال ، إذا كنت ترغب في استخدام Protocol Buffers ، فيجب عليك تحديد المخطط الخاص بك ، ويمكن أن يكون المخطط شيئًا رائعًا لأنه يساعد في توثيق ما يجري من اتصالات بالضبط. لكن بعض الناس يجدون المخططات مزعجة ، خاصة إذا كانوا في المراحل الأولى من التطوير ويقومون بتغيير تنسيقات البيانات بشكل متكرر. إذاً فهناك ، هناك مسألة مفاضلات ؛ في بعض الحالات يكون أحدهما أفضل ، وفي حالات أخرى يكون الآخر أفضل.
من حيث الأخطاء الفعلية التي أشعر أنها ببساطة سيئة ، لا يوجد سوى عدد صغير إلى حد ما من الأشياء. رأي واحد أن لدي هو أن نظرية CAP سيئة في الأساس وليس فقط مفيدة. كلما استخدم الناس نظرية CAP لتبرير قرارات التصميم ، أعتقد في كثير من الأحيان أنهم إما يسيئون تفسير ما يقوله CAP في الواقع ، أو يوضحون ذلك بطريقة أو بأخرى. CAP كأحد النظريات لديه مشكلة أنه في الحقيقة مجرد ذكر ما هو واضح. علاوة على ذلك ، يتحدث عن نموذج تناسق واحد محدد بشكل ضيق للغاية ، وهو الخطية ، ونموذج التوفر المحدد للغاية ، وهو: تريد أن تكون كل نسخة متماثلة متاحة بالكامل للقراء والكتابة ، حتى لو لم تتمكن من التواصل مع أي نسخ متماثلة أخرى. هذه تعاريف معقولة ، لكنها ضيقة للغاية ، والكثير من التطبيقات ببساطة لا تندرج في حالة الحاجة إلى هذا التعريف للاتساق بالتحديد أو هذا التعريف المتاح. ولجميع التطبيقات التي تستخدم تعريفًا مختلفًا لتلك الكلمات ، لا يخبرك CAP Theorem بأي شيء على الإطلاق. انها ببساطة بيان فارغ. لذلك ، أشعر ، هو خطأ.
وبينما نحن نردد ، إذا كنت تطلب مني تسمية الأخطاء ، فهناك خطأ كبير آخر أراه في صناعة التكنولوجيا وهو استخراج العملات المشفرة ، والتي أعتقد أنها مضيعة للغاية للكهرباء. لا أستطيع أن أفهم لماذا يعتقد الناس أن هذه فكرة جيدة.
فاديم : عند الحديث عن نظرية CAP ، فإن العديد من تقنيات التخزين قابلة للضبط بالفعل ، من حيث أشياء مثل AP أو CP. يمكنك اختيار الوضع الذي تعمل فيه.
مارتن : نعم. علاوة على ذلك ، هناك العديد من التقنيات التي ليست متسقة أو متوفرة بموجب التعريف الصارم لنظرية CAP. هم حرفيا فقط ف! لا CP ، وليس CA ، وليس AP ، فقط P. لا أحد يقول ذلك ، لأن ذلك قد يبدو سيئًا ، ولكن بصراحة ، قد يكون هذا قرارًا معقولًا للتصميم. هناك العديد من النظم التي في الواقع على ما يرام تماما. هذا في الواقع أحد الأسباب التي تجعلني أعتقد أن CAP هي وسيلة غير مفيدة للتحدث عن الأشياء: لأن هناك جزءًا كبيرًا من مساحة التصميم التي لا تلتقطها ببساطة ، حيث توجد تصميمات جيدة معقولة تمامًا للبرامج التي ببساطة لا يسمح لك بالتحدث عنه.
فوائد اللامركزية
فاديم : نتحدث اليوم عن التطبيقات كثيفة الاستخدام للبيانات ، ما هي التحديات الرئيسية الأخرى ، أو المشكلات التي لم يتم حلها ، أو الموضوعات البحثية الساخنة التي يمكنك ذكرها؟ بقدر ما أعرف ، فأنت من المؤيدين الرئيسيين للحساب اللامركزي والتخزين.
مارتن : نعم. واحدة من الأطروحات وراء بحثي هو أننا نعتمد في الوقت الحالي بشكل كبير على الخوادم والمركزية. إذا كنت تفكر في كيفية تصميم الإنترنت أصلاً في اليوم الذي تطورت فيه من ARPANET ، فقد كان المقصود به أن يكون شبكة مرنة للغاية حيث يمكن إرسال الحزم عبر عدة طرق مختلفة ، وسيظلون يصلون إلى الوجهة. وإذا أصابت قنبلة نووية مدينة أمريكية معينة ، فستظل بقية الشبكة تعمل لأنها ستتحرك فقط حول الأجزاء الفاشلة من النظام. كان هذا تصميمًا للحرب الباردة.
ثم قررنا وضع كل شيء في السحابة ، والآن كل شيء يجب أن يمر عبر أحد مراكز بيانات AWS ، مثل us-1-one في مكان ما في فرجينيا. لقد اتخذنا هذا المثل الأعلى المتمثل في القدرة على استخدام أجزاء مختلفة مختلفة من الشبكة بشكل لا مركزي ، ولقد وضعنا في هذه الخوادم التي يعتمد عليها كل شيء ، وهو الآن مركزي للغاية. لذلك أنا مهتم باللامركزية ، بمعنى نقل بعض القوة والتحكم في البيانات بعيدًا عن تلك الخوادم والعودة إلى المستخدمين النهائيين.
شيء واحد أود إضافته في هذا السياق هو أن الكثير من الأشخاص الذين يتحدثون عن اللامركزية يتحدثون عن أشياء مثل العملات المشفرة ، لأنهم يحاولون أيضًا شكلاً من أشكال اللامركزية حيث يتم نقل السيطرة بعيدًا عن سلطة مركزية مثل البنك وإلى شبكة العقد المتعاونة. ولكن هذا ليس نوع اللامركزية الذي يهمني فعلاً: أجد أن هذه العملات المشفرة لا تزال في الواقع مركزية للغاية ، بمعنى أنه إذا كنت تريد إجراء معاملة Bitcoin ، فعليك القيام بذلك على شبكة Bitcoin - أنت يجب أن تستخدم شبكة Bitcoin ، لذلك كل شيء مركزي على تلك الشبكة بالذات. الطريقة التي يتم بناؤها غير مركزية ، بمعنى أنه لا يحتوي على عقدة تحكم واحدة ، ولكن الشبكة ككل مركزية للغاية في أي معاملة يجب عليك إجراؤها عليك من خلال هذه الشبكة. لا يمكنك القيام بذلك بطريقة أخرى. أشعر أنه لا يزال شكلاً من أشكال المركزية.
في حالة وجود عملة مشفرة ، قد تكون هذه المركزية أمرًا لا مفر منه ، لأنك تحتاج إلى القيام بأشياء مثل تجنب الإنفاق المزدوج ، وفعل ذلك صعب بدون وجود شبكة تحقق توافقًا حول المعاملات التي حدثت بالضبط والتي لم تحدث. وهذا هو بالضبط ما تفعله شبكة البيتكوين. ولكن هناك العديد من التطبيقات التي لا تتطلب شيئًا ما مثل blockchain ، والتي يمكنها بالفعل التعامل مع نموذج أكثر مرونة للبيانات تتدفق حول النظام. وهذا هو نوع النظام اللامركزي الذي أهتم به أكثر.
فاديم : هل يمكن أن
تذكروا أي تقنيات واعدة أو مقومة بأقل من قيمتها في مجال الأنظمة اللامركزية بصرف النظر عن blockchain؟ لقد تم استخدام IPFS لفترة من الوقت.
مارتن : بالنسبة إلى IPFS ، لقد بحثت فيه قليلاً رغم أنني لم أستخدمه بنفسي بالفعل. لقد أنجزنا بعض العمل مع مشروع
Dat ، والذي يشبه إلى حد ما
IPFS ، بمعنى أنه أيضًا تقنية تخزين غير مركزية. الفرق هو أن IPFS يحتوي على
Filecoin ، وهي
عملة مشفرة ، مرتبطة بها كوسيلة لدفع تكاليف التخزين ، في حين أن Dat ليس لديها أي blockchain مرفق به - إنها طريقة محض لتكرار البيانات عبر أجهزة متعددة بطريقة P2P.
بالنسبة للمشروع الذي كنت أعمل عليه ، كانت Dat مناسبة تمامًا ، لأننا أردنا إنشاء برنامج تعاون حيث يمكن لعدة مستخدمين مختلفين تحرير بعض المستندات أو قواعد البيانات ، وسيتم إرسال أي تغييرات على تلك البيانات إلى أي شخص آخر الذي يحتاج إلى نسخة من هذه البيانات. يمكننا استخدام Dat للقيام بهذا النسخ المتماثل بطريقة P2P ، وتعتني Dat بجميع الأشياء على مستوى الشبكات ، مثل اجتياز NAT والحصول على جدران الحماية - إنها مشكلة صعبة تمامًا لمجرد الحصول على الحزم من طرف إلى آخر . ثم قمنا ببناء طبقة فوق ذلك ، باستخدام CRDTs ، وهي طريقة للسماح للعديد من الأشخاص بتحرير بعض المستندات أو مجموعة البيانات وتبادل تلك التعديلات بطريقة فعالة. أعتقد أنه من المحتمل أن تقوم ببناء هذا النوع من الأشياء على IPFS أيضًا: ربما يمكنك تجاهل جانب Filecoin واستخدام جانب النسخ المتماثل P2P فقط ، ومن المحتمل أن يؤدي المهمة أيضًا.
فاديم : بالتأكيد ، على الرغم من أن استخدام IPFS قد يؤدي إلى انخفاض الاستجابة ، لأن WebRTC الأساسي Dat يربط العقد P2P مباشرة ، ويعمل IPFS مثل شيء جدول التجزئة الموزع.
مارتن : حسنًا ، WebRTC في مستوى مختلف من المكدس ، لأنه مخصص في الغالب لربط شخصين معًا قد يكون لديهم اتصال فيديو ؛ في الواقع ، فإن البرنامج الذي نستخدمه لهذه المقابلة في الوقت الحالي ربما يستخدم WebRTC. يوفر لك WebRTC قناة بيانات يمكنك استخدامها لإرسال بيانات ثنائية تعسفية عليها ، ولكن بناء نظام نسخ متماثل كامل بالإضافة إلى ذلك لا يزال كثيرًا من العمل. وهذا شيء تقوم به Dat أو IPFS بالفعل.
لقد ذكرت الاستجابة - وهذا بالتأكيد شيء واحد للتفكير فيه. قل أنك تريد إنشاء محرّر مستندات Google التالي بطريقة لا مركزية. باستخدام محرّر مستندات Google ، تكون وحدة التغييرات التي تجريها بمثابة ضغطة مفتاح واحدة. قد يتم إرسال كل حرف منفرد تكتبه على لوحة المفاتيح الخاصة بك في الوقت الفعلي إلى المتعاونين ، وهو أمر رائع من وجهة نظر التعاون السريع في الوقت الفعلي. ولكن هذا يعني أيضًا أنه على مدار فترة كتابة مستند كبير ، قد يكون لديك مئات الآلاف من هذه التعديلات الفردية التي تتراكم ، والكثير من هذه التقنيات في الوقت الحالي ليست جيدة في ضغط هذا النوع من تحرير البيانات. يمكنك الاحتفاظ بجميع التعديلات التي أجريتها على مستندك ، ولكن حتى إذا أرسلت مائة بايت فقط لكل ضغطة مفتاح تقوم بإجرائها وتكتب وثيقة أكبر بقليل ، على سبيل المثال ، ضغطات المفاتيح 100000 ، فأنت الآن فجأة لديك 10 ميغابايت من البيانات للمستند الذي سيكون سوى بضع عشرات من الكيلوبايت بشكل طبيعي. لذلك لدينا هذه النفقات العامة الضخمة للحصول على كمية البيانات التي يجب إرسالها حولها ، ما لم نحصل على قدر أكبر من الذكاء في ضغط التغييرات وتعبئتها.
بدلاً من إرسال شخص ما قائمة كاملة بكل حرف تمت كتابته على الإطلاق ، قد نرسل فقط الحالة الحالية للمستند ، وبعد ذلك نرسل أي تحديثات حدثت منذ ذلك الحين. لكن الكثير من أنظمة الند للند لا تملك حتى الآن طريقة للقيام بهذه لقطات الحالة بطريقة تكون فعالة بما يكفي لاستخدامها في شيء مثل محرّر مستندات Google. هذا في الواقع مجال أعمل عليه بنشاط ، وأحاول إيجاد خوارزميات أفضل لمزامنة مختلف المستخدمين لشيء مثل مستند نصي ، حيث لا نريد الاحتفاظ بكل ضغطة مفتاح لأن ذلك سيكون مكلفًا للغاية ، ونحن نريد لتحقيق استخدام أكثر كفاءة لعرض النطاق الترددي للشبكة.
CRDTs جديدة. التحقق الرسمي مع إيزابيل
فاديم : هل تمكنت من ضغط بيانات ضغط المفاتيح هذه بشكل كبير؟ هل اخترعت CRDTs جديدة أو أي شيء مماثل؟
مارتن : نعم. حتى الآن ليس لدينا سوى نماذج أولية لذلك ، لم يتم تنفيذها بالكامل حتى الآن ، وما زلنا بحاجة إلى إجراء المزيد من التجارب لقياس مدى فعاليتها في الواقع العملي. ولكن قمنا بتطوير بعض مخططات الضغط التي تبدو واعدة للغاية. في النموذج الأولي الخاص بي ، قمت بخفضه من حوالي 100 بايت لكل تعديل إلى شيء مثل 1.7 بايت من الحمل لكل تعديل. وهذا معقول أكثر بكثير بالطبع. لكن كما قلت ، لا تزال هذه التجارب مستمرة ، وقد يتغير الرقم قليلاً. لكنني أعتقد أن الخلاصة هي أنه لا يزال هناك مجال كبير للتحسين ، لذلك لا يزال بإمكاننا تحسينه.
فاديم : إذن هذا هو ما سيكون
حديثك في مؤتمر هيدرا ، هل أنا على حق؟
مارتن : نعم بالضبط. سأقدم مقدمة سريعة لمجال CRDTs والبرامج التعاونية وبعض المشاكل التي تنشأ في هذا السياق. بعد ذلك سوف أصف بعض الأبحاث التي أجريناها في هذا المجال. لقد كان ممتعًا للغاية لأن البحث الذي أجريناه كان عبر مجموعة كاملة من الاهتمامات المختلفة. من الجانب المطبق للغاية ، لدينا تطبيق JavaScript لهذه الخوارزميات ، ونحن نستخدم ذلك لإنشاء أجزاء حقيقية من البرامج ، في محاولة لاستخدام هذا البرنامج بأنفسنا لنرى كيف يتصرف. على الطرف الآخر من الطيف ، كنا نعمل بطرق رسمية لإثبات صحة هذه الخوارزميات ، لأن بعض هذه الخوارزميات خفية تمامًا ونريد أن نكون متأكدين تمامًا من أن الأنظمة التي نصنعها صحيحة بالفعل ، أي أن انهم دائما الوصول إلى حالة متسقة. لقد كانت هناك الكثير من الخوارزميات في الماضي والتي فشلت بالفعل في القيام بذلك ، والتي كانت ببساطة خاطئة ، أي في حالات معينة ، ستبقى غير متسقة بشكل دائم. وهكذا ، لتجنب هذه المشكلات التي واجهتها الخوارزميات في الماضي ، نستخدم طرقًا رسمية لإثبات صحة الخوارزميات الخاصة بنا.
فاديم : واو. هل حقا استخدام مثيلات نظرية ، مثل كوك أو إيزابيل أو أي شيء آخر؟
مارتن : بالضبط ، نحن نستخدم إيزابيل لذلك.
يمكنك حضور حديث مارتن "أدلة البراهين الصحيحة للأنظمة الموزعة مع إيزابيل" في مؤتمر The Strange Loop في سبتمبر.
فاديم : أصوات رائعة! هل سيتم نشر هذه الأدلة؟
مارتن : نعم ، مجموعتنا الأولى من البراهين علنية بالفعل. لقد
نشرنا ذلك منذ عام ونصف: لقد كان إطارًا للتحقق من CRDTs ، وتحققنا من ثلاث CRDTs معينة في ذلك الإطار ،
وأهمها RGA (
Replicated Growable Array ) ، وهو CRDT لتحرير النص التعاوني. على الرغم من أنها ليست معقدة للغاية ، إلا أنها خوارزمية خفية تمامًا ، ولذا فهي حالة جيدة حيث يلزم وجود دليل ، لأنه ليس من الواضح فقط من النظر إليها أنه صحيح بالفعل. وبالتالي فإن الدليل يوفر لنا اليقين الإضافي بأنه صحيح بالفعل. كان عملنا السابق هناك للتحقق من اثنين من CRDTs الحالية ، وعملنا الأحدث في هذا المجال هو حول CRDTs الخاصة بنا لنماذج البيانات الجديدة التي نقوم بتطويرها ، وإثبات CRDTs الخاصة بنا كذلك.
فاديم : إلى أي مدى يكون البرهان أكبر مقارنة بوصف الخوارزمية؟ لأنه يمكن أن يكون مشكلة في بعض الأحيان.
مارتن : نعم ، هذه مشكلة - غالبًا ما تكون الأدلة كثيرة في العمل. أعتقد في مثالنا الأخير ... في الواقع ، اسمحوا لي أن ألق نظرة سريعة على الكود. وصف الخوارزمية وهياكل البيانات حوالي 60 سطر من التعليمات البرمجية. لذلك انها خوارزمية صغيرة جدا. الإثبات هو أكثر من 800 خطوط. لذلك لدينا نسبة 12: 1 تقريبًا بين الإثبات والرمز. وهذا هو للأسف نموذجي تماما. والدليل هو كمية كبيرة من العمل الإضافي. من ناحية أخرى ، بمجرد حصولنا على الدليل ، اكتسبنا يقينًا قويًا للغاية في صحة الخوارزمية. علاوة على ذلك ، لدينا أنفسنا ، كبشر ، فهم الخوارزمية بشكل أفضل. غالبًا ما أجد أنه من خلال محاولة إضفاء الطابع الرسمي عليه ، ينتهي بنا الأمر إلى فهم الشيء الذي نحاول إضفاء الطابع الرسمي عليه بشكل أفضل بكثير مما فعلنا من قبل. وهذا في حد ذاته هو في الواقع نتيجة مفيدة من هذا العمل: إلى جانب الدليل نفسه ، نكتسب فهمًا أعمق ، وغالبًا ما يكون ذلك مفيدًا جدًا في إنشاء تطبيقات أفضل.
فاديم : هل يمكن أن تصف الجمهور المستهدف في كلامك ، ما مدى المتشددين سيكون؟ ما هي المعرفة الأولية التي تتوقعها من الجمهور؟
مارتن : أود أن أجعل محادثاتي متاحة مع أقل قدر ممكن من المعرفة السابقة ، وأحاول رفع الجميع إلى نفس المستوى. أغطي الكثير من المواد ، لكنني أبدأ من قاعدة منخفضة. أتوقع أن يتمتع الأشخاص ببعض الخبرة العامة في الأنظمة الموزعة: كيف يمكنك إرسال بعض البيانات عبر شبكة تستخدم TCP ، أو ربما فكرة تقريبية عن كيفية عمل Git ، وهو نموذج جيد جدًا لهذه الأشياء. ولكن هذا عن كل ما تحتاجه ، حقا. ثم ، فهم العمل الذي نقوم به بالإضافة إلى ذلك ليس بالأمر الصعب للغاية. أشرح كل شيء على سبيل المثال ، باستخدام الصور لتوضيح كل شيء. نأمل أن يتمكن الجميع من المتابعة.
مصادر الحدث. نهج مستوى منخفض. معاملات XA
فاديم : يبدو رائعًا حقًا. في الواقع ، لدينا بعض الوقت وأود أن أناقش أحد
مقالاتك الحديثة حول معالجة الأحداث عبر الإنترنت. أنت من كبار المؤيدين لفكرة تحديد مصادر الحدث ، هل هذا صحيح؟
مارتن : نعم بالتأكيد.
فاديم : يزداد هذا النهج في الوقت الحالي ، وفي السعي لتحقيق جميع مزايا سجل العمليات العالمي ، يحاول العديد من المهندسين نشره في كل مكان. هل يمكن أن تصف بعض الحالات التي لا يكون فيها تحديد مصدر الحدث هو الخيار الأفضل؟ فقط لمنع سوء الاستخدام وخيبة الأمل المحتملة مع النهج نفسه.
مارتن : هناك طبقتان مختلفتان من المكدس نحتاج إلى التحدث عنهما أولاً. يُقصد بمصادر الأحداث ، كما اقترح Greg Young وبعض الآخرين ، كآلية لنمذجة البيانات ، أي: إذا كان لديك مخطط قاعدة بيانات وبدأت تفقد السيطرة عليه بسبب وجود العديد من الجداول المختلفة وهي ' يتم تعديل كل ذلك من خلال معاملات مختلفة - ثم يعد مصدر الحدث وسيلة لتحقيق وضوح أفضل لنموذج البيانات هذا ، لأن الأحداث يمكن أن تعبر بشكل مباشر جدًا عما يحدث على مستوى العمل. ما هو الإجراء الذي قام به المستخدم؟ وبعد ذلك ، قد تكون عواقب هذا الإجراء هي تحديث الجداول المختلفة وما إلى ذلك. على نحو فعال ، ما تفعله بمصادر الحدث هو أنك تفصل الإجراء (الحدث) عن آثاره ، التي تحدث في مكان ما في اتجاه المصب.
لقد جئت إلى هذه المنطقة من زاوية مختلفة قليلاً ، وهي وجهة نظر ذات مستوى أدنى لاستخدام أنظمة مثل كافكا لبناء أنظمة قابلة للتطوير بدرجة عالية. يشبه هذا الرأي بمعنى أنه إذا كنت تستخدم شيئًا مثل Kafka ، فأنت تستخدم الأحداث ، لكن هذا لا يعني بالضرورة أنك تستخدم مصادر الأحداث. وعلى العكس من ذلك ، فأنت لست بحاجة إلى استخدام كافكا من أجل القيام بمصادر الحدث ؛ يمكنك القيام بمصادر الحدث في قاعدة بيانات عادية ، أو يمكنك استخدام قاعدة بيانات خاصة تم تصميمها خصيصًا لمصادر الأحداث. إذن هاتان الفكرتان متشابهان ، لكن لا يتطلب أي منهما الآخر ، فكل منهما له بعض التداخل.
إن حجة الرغبة في استخدام نظام مثل Kafka هي في معظمها حجة قابلية التوسع: في هذه الحالة كنت قد حصلت ببساطة على الكثير من البيانات الواردة بحيث لا يمكنك معالجتها بشكل واقعي على قاعدة بيانات ذات عقدة واحدة ، لذلك عليك تقسيمها في بعض الطريقة ، واستخدام سجل أحداث مثل Kafka يمنحك طريقة جيدة لنشر هذا العمل على أجهزة متعددة. إنه يوفر طريقة جيدة ومبدئية لأنظمة القياس. إنها مفيدة بشكل خاص إذا كنت تريد دمج العديد من أنظمة التخزين المختلفة. لذلك ، على سبيل المثال ، إذا كنت تريد تحديث ليس فقط قاعدة بياناتك العلائقية ولكن أيضًا ، على سبيل المثال ، فهرس البحث عن النص الكامل مثل Elasticsearch أو نظام التخزين المؤقت مثل Memcached أو Redis أو شيء من هذا القبيل ، وتريد أن يكون لحدث واحد حدث تحديث التأثير على كل هذه الأنظمة المختلفة ، ثم شيء مثل Kafka مفيد للغاية.
فيما يتعلق بالسؤال الذي طرحته (ما هي المواقف التي لن أستخدم فيها مصادر الحدث أو نهج سجل الأحداث) - أعتقد أنه من الصعب القول بدقة ، ولكن كقاعدة عامة ، أقول: استخدم ما هو أبسط . وهذا هو ، كل ما هو الأقرب إلى المجال الذي تحاول تنفيذه. وهكذا ، إذا كان الشيء الذي تحاول تطبيق الخرائط به جيدًا لقاعدة بيانات علائقية ، حيث يمكنك فقط إدراج وتحديث وحذف بعض الصفوف ، فما عليك سوى استخدام قاعدة بيانات علائقية وإدراج وتحديث وحذف بعض الصفوف. لا حرج في قواعد البيانات العلائقية واستخدامها كما هي. لقد عملوا بشكل جيد بالنسبة لنا لفترة طويلة وما زالوا يفعلون ذلك. ولكن إذا كنت تجد نفسك في موقف تكافح فيه حقًا لاستخدام هذا النوع من قواعد البيانات ، على سبيل المثال لأن تعقيد نموذج البيانات بدأ ينفد ، فمن المنطقي أن نتحول إلى شيء مثل تحديد مصدر الحدث الاقتراب.
وبالمثل ، على المستوى الأدنى (قابلية التوسع) ، إذا كان حجم البيانات الخاصة بك بحيث يمكنك وضعها في PostgreSQL على جهاز واحد - ربما يكون ذلك جيدًا ، فقط استخدم PostgreSQL على جهاز واحد. ولكن إذا كنت في المرحلة التي لا توجد فيها طريقة واحدة يمكن بها لجهاز واحد التعامل مع حملك ، فيجب عليك التوسع عبر نظام كبير ، ثم يبدأ التفكير في أنظمة أكثر توزيعًا مثل Kafka. أعتقد أن المبدأ العام هنا هو: استخدام كل ما هو أبسط للمهمة المحددة التي تحاول حلها.
فاديم : إنها نصيحة جيدة حقًا. مع تطور نظامك ، لا يمكنك التنبؤ بدقة بتوجه التطوير ، وجميع الاستعلامات والأنماط وتدفقات البيانات.
مارتن : بالضبط ، وبالنسبة لتلك الأنواع من الحالات ، تكون قواعد البيانات العلائقية مذهلة ، لأنها مرنة للغاية ، خاصة إذا قمت بتضمين دعم JSON الذي لديهم الآن. يتمتع PostgreSQL الآن بدعم جيد لـ JSON. يمكنك فقط إضافة فهرس جديد إذا كنت تريد الاستعلام بطريقة مختلفة. يمكنك فقط تغيير المخطط والاستمرار في تشغيل البيانات في بنية مختلفة. وهكذا ، إذا لم يكن حجم مجموعة البيانات كبيرًا جدًا وكان التعقيد غير كبير جدًا ، تعمل قواعد البيانات العلائقية بشكل جيد وتوفر قدرًا كبيرًا من المرونة.
فاديم : دعنا نتحدث أكثر قليلاً عن مصادر الحدث. لقد ذكرت مثالًا مثيرًا للاهتمام مع العديد من المستهلكين الذين يستهلكون الأحداث من قائمة انتظار واحدة على أساس كافكا أو شيء مشابه. تخيل أن يتم نشر المستندات الجديدة ، وأن العديد من الأنظمة تستهلك الأحداث: نظام بحث يعتمد على Elasticsearch ، مما يجعل المستندات قابلة للبحث ، ونظام تخزين مؤقت يضعها في ذاكرة التخزين المؤقت ذات القيمة الرئيسية استنادًا إلى Memcached ، ونظام قاعدة بيانات علائقية يقوم بتحديث بعض الجداول وفقا لذلك. قد يكون المستند عرض بيع سيارة أو إعلان عقاري. كل هذه الأنظمة المستهلكة تعمل بشكل متزامن ومتزامن.
مارتن : إذن ، سؤالك هو كيف تتعامل مع حقيقة أنه إذا كان لديك هؤلاء المستهلكين العديدين ، فربما تم تحديث بعضهم ، لكن الآخرين لم يروا تحديثًا بعد وما زالوا متأخرين قليلاً؟
فاديم : نعم ، بالضبط. يأتي المستخدم إلى موقع الويب الخاص بك ، ويدخل استعلام البحث ، ويحصل على بعض نتائج البحث وينقر فوق رابط. لكنها تحصل على 404 رمز حالة HTTP لأنه لا يوجد مثل هذا الكيان في قاعدة البيانات ، والتي لم تتمكن من استهلاك المستند واستمراره حتى الآن.
مارتن : نعم ، هذا بعض التحدي في الواقع. من الناحية المثالية ، ما تريده هو ما نسميه "الاتساق السببي" عبر أنظمة التخزين المختلفة هذه. إذا كان أحد الأنظمة يحتوي على بعض البيانات التي تعتمد عليها ، فإن الأنظمة الأخرى التي تنظر إليها ستحتوي أيضًا على تلك التبعيات. لسوء الحظ ، من الصعب جدًا تجميع هذا النوع من الاتساق السببي عبر تقنيات التخزين المختلفة ، وهذا ليس خطأ في تحديد مصادر الأحداث ، لأنه بغض النظر عن النهج أو النظام الذي تستخدمه لإرسال التحديثات إلى مختلف الأنظمة ، يمكن أن ينتهي دائما مع نوع من قضايا التزامن.
في مثالك على كتابة البيانات إلى كل من Memcached و Elasticsearch ، حتى إذا حاولت القيام بالكتابة على النظامين في وقت واحد ، فقد يكون لديك بعض التأخير في الشبكة ، مما يعني أنها تصل في أوقات مختلفة قليلاً على تلك الأنظمة المختلفة ، و الحصول على معالجتها مع توقيت مختلف قليلا. وهكذا قد يرى شخص ما يقرأ عبر هذين النظامين حالة غير متسقة. الآن ، هناك بعض المشاريع البحثية التي تعمل على الأقل لتحقيق هذا النوع من الاتساق السببي ، ولكن لا يزال من الصعب إذا كنت ترغب فقط في استخدام شيء ما مثل Elasticsearch أو Memcached أو هكذا خارج الرف.
الحل الجيد هنا هو أن تحصل على عرض مفاهيمي ، مع لقطة متسقة في الوقت المناسب عبر كل من فهرس البحث وذاكرة التخزين المؤقت وقاعدة البيانات. إذا كنت تعمل داخل قاعدة بيانات علائقية ، فستحصل على شيء يُسمى عزل اللقطة ، ونقطة عزل اللقطة هي أنه إذا كنت تقرأ من قاعدة البيانات ، فيبدو أنك حصلت على نسختك الخاصة من قاعدة البيانات. أي شيء تنظر إليه في قاعدة البيانات ، فإن أي بيانات تستفسر عنها ستكون الحالة اعتبارًا من تلك النقطة الزمنية ، وفقًا للقطعة. لذلك حتى إذا تم تغيير البيانات بعد ذلك بواسطة معاملة أخرى ، فسترى البيانات القديمة بالفعل ، لأن هذه البيانات القديمة تشكل جزءًا من لقطة ثابتة.
والآن ، في حالة حصولك على Elasticsearch و Memcached ، فإن ما تريده حقًا هو لقطة متسقة عبر هذين النظامين. لكن لسوء الحظ ، ليس لدى Memcached و Redis ولا Elasticsearch آلية فعالة لصنع تلك الأنواع من اللقطات التي يمكن تنسيقها مع أنظمة تخزين مختلفة. كل نظام تخزين يفكر فقط في نفسه ويعرض لك عادة أحدث قيمة لكل مفتاح ، وليس لديه هذا المرفق للنظر إلى الوراء وتقديم نسخة أقدم من البيانات ، لأن أحدث نسخة من البيانات لم يتم بعد متسقة.
ليس لدي حقًا إجابة جيدة عما سيكون عليه الحل. أخشى أن الحل يتطلب تغييرات في الكود لأي من أنظمة التخزين التي تشارك في هذا النوع من الأشياء. لذلك سوف يتطلب الأمر تغييرات في Elasticsearch و Redis و Memcached وأي أنظمة أخرى. وسيتعين عليهم إضافة آلية ما للقطات المحددة زمنياً والتي تكون رخيصة بما يكفي بحيث يمكنك استخدامها طوال الوقت ، لأنك قد ترغب في الحصول على اللقطة عدة مرات في الثانية - إنها ليست مجرد مرة واحدة يوم-لقطة ، انها دقيقة جدا الحبيبات. وفي الوقت الحالي ، لا توجد الأنظمة الأساسية من حيث القدرة على القيام بهذه الأنواع من اللقطات عبر أنظمة تخزين مختلفة. إنه موضوع بحث مثير للاهتمام حقًا. آمل أن يعمل شخص ما على ذلك ، لكنني لم أر أي إجابات مقنعة لهذه المشكلة حتى الآن.
فاديم : نعم ، نحن بحاجة إلى نوع من
التحكم في التزامن المتعدد .
مارتن : بالضبط ، مثل أنظمة المعاملات الموزعة. ستتيح لك المعاملات الموزعة من XA بعض الطريق إلى هناك ، لكن لسوء الحظ ، XA ، كما هي ، ليست مناسبة تمامًا لأنها تعمل فقط إذا كنت تستخدم التحكم في التزامن المستند إلى القفل. هذا يعني أنه إذا قرأت بعض البيانات ، فيجب عليك قفلها حتى لا يستطيع أي شخص تعديل تلك البيانات بينما يكون لديك هذا القفل. وهذا النوع من التحكم في التزامن القائم على القفل له أداء فظيع ، لذلك لا يوجد نظام يستخدم ذلك في الواقع في الوقت الحاضر. ولكن إذا لم يكن لديك هذا القفل ، فلن تحصل على سلوك العزلة اللازم في نظام مثل المعاملات الموزعة XA. لذلك ربما ما نحتاج إليه هو بروتوكول جديد للمعاملات الموزعة التي تتيح عزل اللقطة كآلية عزل عبر أنظمة مختلفة. لكنني لا أعتقد أنني رأيت أي شيء ينفذ ذلك حتى الآن.
فاديم : نعم ، آمل أن يعمل شخص ما على ذلك.
مارتن : نعم ، سيكون من المهم حقا. أيضًا في سياق الخدمات المصغرة ، على سبيل المثال: الطريقة التي يروج بها الأشخاص لإنشاء هذه الخدمات هي أن كل خدمة ميكروية لها تخزينها الخاص بها ، وقاعدة بياناتها الخاصة ، وليس لديك خدمة واحدة يمكنها الوصول مباشرة إلى قاعدة بيانات خدمة أخرى ، لأن هذا من شأنه كسر تغليف الخدمة. لذلك ، كل خدمة تدير بياناتها فقط.
على سبيل المثال ، لديك خدمة لإدارة المستخدمين ، ولديها قاعدة بيانات للمستخدمين ، وأي شخص آخر يريد معرفة شيء عن المستخدمين يجب أن يذهب من خلال خدمة المستخدم. من وجهة نظر التغليف الجميل: أنت تخفي تفاصيل مخطط قاعدة البيانات عن الخدمات الأخرى على سبيل المثال.
But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.
Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.
Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.
Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?
Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.
Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.
Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.
What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.
Vadim : It's a different point of view to building systems.
Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.
Professional growth and development
Vadim : Do you think that conferences like
Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.
Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to
think about the systems they are building.
Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?
Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.
So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.
Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?
Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.
A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people
interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.
Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.
Martin : No problem, yeah, it's been nice talking to you.
Vadim : Let's meet
at the conference .