القابلية للتنبؤ هي البعد الخفي لأداء الشبكات
يحب من يعملون في الشبكات الأساسية الحديث عن TPS وزمن الاستجابة وعرض النطاق. بالطبع هذه مؤشرات مهمة، لكنها لا تجيب إلا عن سؤال واحد: ما السرعة التي يمكن أن تعمل بها؟—بينما نادرًا ما تجيب عن سؤال آخر أكثر أهمية: هل تكون مستقرة أثناء التشغيل أم لا؟
أعادتني بروتوكول Kadcast من Dusk إلى التفكير في هذا الأمر. لم يسلك مسار الانتشار العشوائي للأخبار الشائعة المعتاد، بل استخدم شبكة تغطية مُهيكلة لتثبيت مسار النقل. والنتيجة ليست أسرع مرةً واحدة، بل تقريبًا بنفس السرعة في كل مرة. تحول زمن الاستجابة من توزيع احتمالي إلى ثابت تقريبي.
بمجرد انتقال هذا الفرق إلى الطبقات العليا، تكون آثاره هائلة. إن كانت الشبكة غير قابلة للتنبؤ، فهي كأنها تقول للمطورين: لستُ بالضرورة موثوقًا، تصرّفوا بأنفسكم. ومن ثم تظهر حالات انتهاء المهلة، وإعادة المحاولة، والارتداد الأُسّي، والذاكرة المؤقتة الاحتياطية… كل ذلك من التعقيد الذي كان ينبغي أن يبقى في الطبقة الأساسية، يُدفع إلى طبقة التطبيق. والأسوأ أن هذا النوع من الكود غالبًا هو الأصعب في الاختبار والأكثر عرضة لظهور الأخطاء.
لذلك أفضّل اليوم تعريف الأداء على هذا النحو: الشبكة الجيدة لا تجعل المطور يكتب كودًا أسرع، بل تجعلهم يكتبون أقل قدر ممكن من أكواد كثيرة لا ينبغي أصلًا أن تكون موجودة.
وهذا الأمر خطير بشكل خاص في سيناريوهات التمويل. في أنظمة التداول، ليست أغلى تكلفة هي الآلة، بل العبء الإدراكي—عندما ينشغل ذهنك بالسؤال: هل ستترنح الشبكة؟ لن تستطيع التركيز على منطق المطابقة واستراتيجيات إدارة المخاطر وغيرها من الجوانب التي تخلق قيمة فعلية. إن أكبر قيمة للقابلية للتنبؤ هي أنها تسمح للمطورين بحذف الافتراضات من داخل الكود.
أفضل البنية التحتية هي تلك التي، بعد نشرها، تكاد لا تتذكر أنها ما زالت تعمل.
@Dusk #dusk $DUSK
يحب من يعملون في الشبكات الأساسية الحديث عن TPS وزمن الاستجابة وعرض النطاق. بالطبع هذه مؤشرات مهمة، لكنها لا تجيب إلا عن سؤال واحد: ما السرعة التي يمكن أن تعمل بها؟—بينما نادرًا ما تجيب عن سؤال آخر أكثر أهمية: هل تكون مستقرة أثناء التشغيل أم لا؟
أعادتني بروتوكول Kadcast من Dusk إلى التفكير في هذا الأمر. لم يسلك مسار الانتشار العشوائي للأخبار الشائعة المعتاد، بل استخدم شبكة تغطية مُهيكلة لتثبيت مسار النقل. والنتيجة ليست أسرع مرةً واحدة، بل تقريبًا بنفس السرعة في كل مرة. تحول زمن الاستجابة من توزيع احتمالي إلى ثابت تقريبي.
بمجرد انتقال هذا الفرق إلى الطبقات العليا، تكون آثاره هائلة. إن كانت الشبكة غير قابلة للتنبؤ، فهي كأنها تقول للمطورين: لستُ بالضرورة موثوقًا، تصرّفوا بأنفسكم. ومن ثم تظهر حالات انتهاء المهلة، وإعادة المحاولة، والارتداد الأُسّي، والذاكرة المؤقتة الاحتياطية… كل ذلك من التعقيد الذي كان ينبغي أن يبقى في الطبقة الأساسية، يُدفع إلى طبقة التطبيق. والأسوأ أن هذا النوع من الكود غالبًا هو الأصعب في الاختبار والأكثر عرضة لظهور الأخطاء.
لذلك أفضّل اليوم تعريف الأداء على هذا النحو: الشبكة الجيدة لا تجعل المطور يكتب كودًا أسرع، بل تجعلهم يكتبون أقل قدر ممكن من أكواد كثيرة لا ينبغي أصلًا أن تكون موجودة.
وهذا الأمر خطير بشكل خاص في سيناريوهات التمويل. في أنظمة التداول، ليست أغلى تكلفة هي الآلة، بل العبء الإدراكي—عندما ينشغل ذهنك بالسؤال: هل ستترنح الشبكة؟ لن تستطيع التركيز على منطق المطابقة واستراتيجيات إدارة المخاطر وغيرها من الجوانب التي تخلق قيمة فعلية. إن أكبر قيمة للقابلية للتنبؤ هي أنها تسمح للمطورين بحذف الافتراضات من داخل الكود.
أفضل البنية التحتية هي تلك التي، بعد نشرها، تكاد لا تتذكر أنها ما زالت تعمل.
@Dusk #dusk $DUSK