🥇نظرة على تقنيات العقد الماضي

ملحوظة. ترجمة.:تقدم هذه المقالة التي حققت نجاحًا كبيرًا على Medium نظرة عامة على التغييرات الرئيسية (2010-2019) في عالم لغات البرمجة والنظام البيئي التكنولوجي المرتبط بها (مع التركيز بشكل خاص على Docker وKubernetes). مؤلفها الأصلي هو سيندي سريدهران، المتخصصة في أدوات المطورين والأنظمة الموزعة - على وجه الخصوص، كتبت كتاب "قابلية مراقبة الأنظمة الموزعة" - وهي تحظى بشعبية كبيرة في مجال الإنترنت بين المتخصصين في تكنولوجيا المعلومات، وخاصة المهتمين بموضوع السحابة الأصلية.

نظرة على تقنيات العقد الماضي

مع اقتراب عام 2019 من نهايته، أردت أن أشارككم أفكاري حول بعض أهم التطورات والابتكارات التكنولوجية في العقد الماضي. وبالإضافة إلى ذلك، سأحاول أن أنظر قليلا إلى المستقبل وأسلط الضوء على التحديات والفرص الرئيسية للعقد المقبل.

أريد أن أوضح على الفور أنني في هذه المقالة لا أغطي التغييرات في مجالات مثل علم البيانات (علم البيانات)، الذكاء الاصطناعي، وهندسة الواجهة الأمامية، وما إلى ذلك، حيث أنني شخصياً لا أملك الخبرة الكافية فيها.

النمطية ترد الضربة

كان أحد أكثر الاتجاهات الإيجابية في العقد الثاني من القرن الحادي والعشرين هو إحياء اللغات ذات الكتابة الثابتة. في حين أن مثل هذه اللغات لم تختف (لا يزال الطلب على C++ وJava قائمًا حتى اليوم؛ فقد كانت مهيمنتين قبل عشر سنوات)، فقد شهدت اللغات ذات الكتابة الديناميكية ارتفاعًا كبيرًا في الشعبية منذ ظهور حركة Ruby on Rails في عام 2010. وبلغ هذا النمو ذروته في عام 2005 مع إصدار Node.js مفتوح المصدر، مما جعل Javascript على الخادم حقيقة واقعة.

مع مرور الوقت، فقدت اللغات الديناميكية بعضًا من جاذبيتها في مجال تطوير البرمجيات من جانب الخادم. بدت لغة Go، التي اكتسبت شعبية كبيرة خلال ثورة الحاويات، أكثر ملاءمة لبناء خوادم عالية الأداء وكفاءة في استخدام الموارد ومعالجة متوازية (والتي توافق (منشئ Node.js نفسه).

تم تقديم الصدأ في عام 2010، وتضمن التقدم في نظريات الأنواع في محاولة لتصبح لغة آمنة ومكتوبة. كان الصدأ رائعًا نسبيًا في الصناعة خلال النصف الأول من العقد، لكن شعبيته نمت بشكل كبير في النصف الثاني. تتضمن بعض الاستخدامات البارزة لـ Rust استخدامه في ماجيك بوكيت على دروبوكس, المفرقعات النارية من AWS (تحدثنا عنه في هذا المقال - تقريبا. ترجمة.)، مُجمِّع WebAssembly المبكر لوسيت من شركة فاستلي (التي أصبحت الآن جزءًا من تحالف بايت كود) وغيرها. في ظلّ دراسة مايكروسوفت لإعادة كتابة بعض أجزاء نظام التشغيل Windows بالنسبة للغة Rust، من الآمن القول إن لها مستقبلاً مشرقاً في العقد الثالث من القرن الحادي والعشرين.

حتى اللغات الديناميكية اكتسبت ميزات جديدة مثل أنواع اختيارية (أنواع اختيارية). لقد تم تنفيذها لأول مرة في TypeScript، وهي لغة تسمح لك بإنشاء كود مكتوب وتجميعه إلى JavaScript. لقد اكتسبت PHP وRuby وPython أنظمة الكتابة الاختيارية الخاصة بها (mypy, الإختراق)، والتي يتم استخدامها بنجاح في إنتاج.

عودة SQL إلى NoSQL

NoSQL هي تقنية أخرى كانت أكثر شعبية في بداية العقد مقارنة بنهايته. أعتقد أن هناك سببين لذلك.

أولاً، تبين أن نموذج NoSQL، الذي لا يحتوي على مخطط ولا معاملات ولا ضمانات تناسق أضعف، أكثر صعوبة في التنفيذ من نموذج SQL. في تدوينة بعنوان "لماذا يجب عليك تفضيل الاتساق الصارم كلما أمكن ذلك" (لماذا يجب عليك اختيار الاتساق القوي، كلما أمكن ذلك) يكتب جوجل:

أحد الأشياء التي تعلمناها في Google هي أن كود التطبيق يكون أبسط وأوقات التطوير أقصر إذا كان المهندسون قادرين على الاعتماد على التخزين الحالي للتعامل مع المعاملات المعقدة والحفاظ على تنظيم البيانات. ولنقتبس من وثائق Spanner الأصلية، "نعتقد أنه من الأفضل للمبرمجين التعامل مع مشكلات أداء التطبيق الناتجة عن إساءة استخدام المعاملات مع ظهور الاختناقات، بدلاً من القلق المستمر بشأن نقص المعاملات".

السبب الثاني يتعلق بنمو قواعد بيانات SQL الموزعة "القابلة للتطوير" (مثل سحابة سبانر и أوس أورورا) في مساحة السحابة العامة، بالإضافة إلى البدائل مفتوحة المصدر مثل CockroachDB (تحدثنا عنها أيضًا писали - تقريبا. ترجمة.)، والتي تحل العديد من المشاكل الفنية التي كانت تتسبب في "عدم قابلية التوسع" لقواعد بيانات SQL التقليدية. حتى MongoDB، الذي كان في يوم من الأيام بمثابة الطفل الملصق لحركة NoSQL، أصبح الآن تقدم المعاملات الموزعة.

بالنسبة للمواقف التي تتطلب ذرية القراءة والكتابة إلى مستندات متعددة (في مجموعة واحدة أو أكثر)، يدعم MongoDB معاملات المستندات المتعددة. في حالة المعاملات الموزعة، يمكن استخدام المعاملات عبر عمليات متعددة ومجموعات وقواعد بيانات ومستندات وشظايا.

التبسيط الكامل

لقد أصبح أباتشي كافكا بلا شك أحد أهم الاختراعات في العقد الماضي. تم إطلاق Kafka كمصدر مفتوح في يناير 2011، وقد أحدث ثورة في طريقة تعامل الشركات مع البيانات على مر السنين. لقد تم استخدام كافكا في كل شركة عملت بها، من الشركات الناشئة إلى الشركات الكبرى. يتم استخدام الضمانات وحالات الاستخدام التي توفرها (pub-sub، والتدفقات، والهندسة المعمارية التي تعتمد على الأحداث) في مجموعة متنوعة من المهام: من تنظيم تخزين البيانات إلى مراقبة وتحليلات التدفق - المطلوبة في العديد من المجالات مثل التمويل والرعاية الصحية والقطاع العام وتجارة التجزئة وما إلى ذلك.

التكامل المستمر (وإلى حد أقل النشر المستمر)

إن التكامل المستمر ليس مفهوما جديدا في السنوات العشر الماضية، ولكنه أصبح أكثر شيوعا في العقد الماضي. لقد انتشر إلى حد كبير، والذي أصبح جزءًا من سير العمل القياسي (تشغيل الاختبارات على جميع طلبات السحب). صعود GitHub كمنصة لتطوير وتخزين التعليمات البرمجية، والأهم من ذلك، تطوير سير عمل يعتمد عليها تدفق جيثب يعني أن تشغيل الاختبارات قبل قبول طلب السحب في الجهاز الرئيسي هو الوحيد سير العمل في التطوير، وهو أمر مألوف للمهندسين الذين بدأوا حياتهم المهنية في العقد الماضي.

إن النشر المستمر (نشر كل التزام عندما يصل إلى المرحلة الرئيسية) ليس منتشرًا على نطاق واسع مثل التكامل المستمر. ومع ذلك، مع كثرة واجهات برمجة التطبيقات المختلفة لنشر السحابة، والشعبية المتزايدة لمنصات مثل Kubernetes (التي توفر واجهة برمجة تطبيقات موحدة لنشر السحابة)، وظهور أدوات متعددة المنصات ومتعددة السحابة مثل Spinnaker (مبنية على واجهات برمجة التطبيقات الموحدة المذكورة)، أصبحت عمليات النشر أكثر أتمتة وتبسيطًا وأكثر أمانًا بشكل عام.

حاويات

ربما تكون الحاويات هي التكنولوجيا الأكثر إثارة للضجة والمناقشة والإعلان عنها وسوء فهمها في العقد الثاني من القرن الحادي والعشرين. ومن ناحية أخرى، فهو يعد أحد أهم ابتكارات العقد الماضي. وجزء من السبب وراء كل هذه الضجة يكمن في الإشارات المختلطة التي كنا نتلقاها من كل مكان تقريبا. الآن بعد أن هدأت الضجة قليلاً، أصبحت بعض الأمور أكثر وضوحاً.

أصبحت الحاويات شائعة ليس لأنها الطريقة الأفضل لتشغيل تطبيق يلبي احتياجات مجتمع المطورين العالمي. أصبحت الحاويات شائعة لأنها تتلاءم بشكل جيد مع الطلب التسويقي لأداة معينة تحل مشكلة مختلفة تمامًا. لقد تبين أن Docker هو رائع أداة تطوير تحل مشكلة التوافق الملحة ("تعمل على جهازي").

وبصورة أدق، لقد صنع ثورة صورة عامل الميناء، لأنه حل مشكلة التكافؤ بين البيئات ووفر قابلية النقل الحقيقية ليس فقط لملف التطبيق، ولكن أيضًا لجميع البرامج التابعة له ونظام التشغيل. إن حقيقة أن هذه الأداة حفزت بطريقة ما شعبية "الحاويات" التي هي في الأساس تفاصيل تنفيذ منخفضة المستوى للغاية تظل، بالنسبة لي، ربما اللغز الأعظم في العقد الماضي.

Serverless

أراهن أن ظهور الحوسبة "بدون خادم" أكثر أهمية من الحاويات، لأنه يجعل حلم الحوسبة عند الطلب حقيقة واقعة. (بناء على الطلب). على مدى السنوات الخمس الماضية، رأيت نهج عدم وجود خادم يتوسع تدريجيًا في نطاقه (إضافة الدعم للغات وأوقات تشغيل جديدة). يبدو أن ظهور منتجات مثل Azure Durable Functions هو خطوة صحيحة نحو تنفيذ الوظائف ذات الحالة (وخطوة حاسمة في ذلك). بعض المشاكل(المتعلقة بحدود FaaS). وسوف أتابع باهتمام كيف يتطور هذا النموذج الجديد في السنوات القادمة.

الأتمتة

ولعل المستفيد الأكبر من هذا الاتجاه هو مجتمع هندسة العمليات، حيث مكّن هذا الاتجاه مفاهيم مثل البنية الأساسية ككود (IaC) من أن تصبح حقيقة واقعة. علاوة على ذلك، تزامن الشغف بالأتمتة مع ظهور "ثقافة SRE"، التي تهدف إلى اتباع نهج أكثر تركيزًا على البرمجيات في العمليات.

واجهة برمجة التطبيقات العالمية

من بين الميزات المثيرة للاهتمام الأخرى في العقد الماضي كانت استخدام واجهة برمجة التطبيقات (API) في مهام التطوير المختلفة. تتيح واجهات برمجة التطبيقات الجيدة والمرنة للمطور إنشاء تدفقات عمل وأدوات مبتكرة تساعد بدورها في الصيانة وتحسين تجربة المستخدم.

بالإضافة إلى ذلك، فإن تحويل بعض الوظائف أو الأدوات إلى SaaS هو الخطوة الأولى نحو تحويل بعض الوظائف أو الأدوات إلى SaaS. وتزامن هذا الاتجاه أيضًا مع صعود الخدمات المصغرة: حيث أصبحت SaaS مجرد خدمة أخرى يمكن الوصول إليها عبر واجهة برمجة التطبيقات. تتوفر حاليًا العديد من أدوات SaaS وFOSS في مجالات مثل المراقبة والمدفوعات وموازنة التحميل والتكامل المستمر والتنبيه والتبديل الوظيفي (تمييز الميزة)، CDN، وهندسة المرور (على سبيل المثال DNS)، وما إلى ذلك، والتي ازدهرت في العقد الماضي.

قابلية الملاحظة

ومن الجدير بالذكر أنه لدينا اليوم إمكانية الوصول إلى أكثر تقدما بكثير أصبحت الأدوات اللازمة لمراقبة وتشخيص سلوك التطبيقات متاحة أكثر من أي وقت مضى. ربما يمكن تسمية نظام مراقبة بروميثيوس، الذي حصل على وضع المصدر المفتوح في عام 2015، الأفضل نظام مراقبة لجميع الأشخاص الذين عملت معهم. إنه ليس مثاليًا، لكنه يقوم بالعديد من الأشياء بشكل صحيح تمامًا (مثل دعم القياسات [الأبعاد] في حالة المقاييس).

كان التتبع الموزع تقنية أخرى دخلت التيار الرئيسي في العقد الثاني من القرن الحادي والعشرين بفضل مبادرات مثل OpenTracing (وخليفتها OpenTelemetry). ورغم أن التتبع لا يزال معقداً للغاية من حيث الاستخدام، فإن بعض التطورات الأخيرة تمنحنا الأمل في أن نطلق العنان لإمكاناته الحقيقية في عشرينيات القرن الحادي والعشرين. (ملاحظة المترجم: اقرأ أيضًا ترجمة المقال "التتبع الموزع: لقد فعلنا كل شيء بشكل خاطئ"من نفس المؤلف.)

يتطلع إلى المستقبل

ولسوء الحظ، هناك العديد من نقاط الألم التي تنتظر حلاً في العقد المقبل. فيما يلي أفكاري حول هذه المشكلة وبعض الأفكار المحتملة حول كيفية التخلص منها.

حل مسألة قانون مور

إن نهاية قانون دينارد للتوسع والتأخر عن قانون مور يتطلبان ابتكارات جديدة. جون هينيسي في محاضرته يوضح لماذا المدمنون المشكلون (محددة للمجال) قد تكون الهندسة المعمارية مثل TPU بمثابة حل لمشكلة التأخر عن قانون مور. مجموعات أدوات مثل MLIR يبدو أن ما قدمته جوجل بالفعل بمثابة خطوة جيدة إلى الأمام في هذا الاتجاه:

يجب أن تدعم المجمِّعات التطبيقات الجديدة، وأن تكون قابلة للنقل بسهولة إلى أجهزة جديدة، وأن تربط بين العديد من طبقات التجريد، من اللغات الديناميكية المُدارة إلى مسرعات المتجهات والذاكرة المُدارة بواسطة البرامج، مع توفير مفاتيح عالية المستوى للضبط التلقائي، والوظائف في الوقت المناسب، والتشخيص، ونشر معلومات التصحيح حول عمل وأداء الأنظمة في جميع أنحاء المكدس، ولا تزال توفر أداءً قريبًا بدرجة كافية من لغة التجميع المكتوبة يدويًا في معظم الحالات. ونحن نعتزم مشاركة رؤيتنا وتقدمنا وخططنا لتطوير مثل هذه البنية التحتية للتجميع وإتاحتها للعامة.

CI / CD

في حين أن صعود CI كان أحد أكبر الاتجاهات في العقد الثاني من القرن الحادي والعشرين، إلا أن جينكينز يظل المعيار الذهبي لـ CI.

إن هذا الفضاء في حاجة ماسة إلى الابتكار في المجالات التالية:

واجهة المستخدم (DSL لترميز مواصفات الاختبار)؛
تفاصيل التنفيذ التي ستجعلها قابلة للتطوير وسريعة حقًا؛
التكامل مع بيئات مختلفة (التجهيز والإنتاج وما إلى ذلك) لإجراء أشكال أكثر تقدمًا من الاختبار؛
الاختبار والنشر المستمر.

أدوات المطور

لقد بدأنا كصناعة في إنشاء برامج معقدة ومثيرة للإعجاب بشكل متزايد. ومع ذلك، عندما يتعلق الأمر بأدواتنا الخاصة، يمكننا القول إن الوضع يمكن أن يكون أفضل بكثير.

اكتسب التحرير التعاوني والتحرير عن بعد (عبر SSH) بعض الشعبية، لكنه لم يصبح الطريقة القياسية الجديدة للتطوير. إذا كنت، مثلي، ترفض فكرة حاجة إذا كنت تمتلك اتصالاً دائمًا بالإنترنت فقط لتتمكن من القيام بالبرمجة، فإن العمل عبر SSH على جهاز بعيد من غير المرجح أن يناسبك.

لا تزال بيئات التطوير المحلية، وخاصة بالنسبة للمهندسين الذين يعملون على هياكل ضخمة موجهة نحو الخدمة، تشكل تحديًا. تحاول بعض المشاريع حل هذه المشكلة، وأود أن أعرف ما هو الشكل الأكثر راحة لتجربة المستخدم لهذه الحالة الاستخدامية.

سيكون من المثير للاهتمام أيضًا توسيع مفهوم "البيئات المحمولة" إلى مجالات أخرى من التطوير، مثل إعادة إنتاج الأخطاء (أو اختبارات غير مستقرة)، والتي تحدث في ظل ظروف معينة أو في إعدادات معينة.

وأود أيضًا أن أرى المزيد من الابتكار في مجالات مثل البحث الدلالي والبحث السياقي، والأدوات التي تسمح لك بربط حوادث الإنتاج بأجزاء محددة من قاعدة التعليمات البرمجية، وما إلى ذلك.

الحوسبة (مستقبل PaaS)

مع كل الضجة حول الحاويات والخدمات الخالية من الخوادم في العقد الأول من القرن الحادي والعشرين، توسع نطاق الحلول في مجال السحابة العامة بشكل كبير في السنوات القليلة الماضية.

نظرة على تقنيات العقد الماضي

وهذا يثير العديد من الأسئلة المثيرة للاهتمام. أولاً وقبل كل شيء، تتزايد قائمة الخيارات المتاحة في السحابة العامة باستمرار. يتمتع مزودو الخدمات السحابية بالموظفين والموارد اللازمة لمواكبة أحدث التطورات في عالم المصدر المفتوح بسهولة وإصدار منتجات مثل "وحدات التخزين بدون خادم" (أظن من خلال جعل أوقات تشغيل FaaS الخاصة بهم متوافقة مع OCI) أو أشياء أخرى مشابهة.

لا يمكن إلا أن نحسد أولئك الذين يستخدمون هذه الحلول السحابية. من الناحية النظرية، توفر عروض Kubernetes السحابية الأصلية (GKE، وEKS، وEKS على Fargate، وما إلى ذلك) واجهات برمجة تطبيقات مستقلة عن مزود السحابة لتشغيل أحمال العمل. إذا كنت تستخدم منتجات مماثلة (ECS، Fargate، Google Cloud Run، وما إلى ذلك)، فمن المحتمل أنك تستفيد بالفعل من الميزات الأكثر إثارة للاهتمام التي يقدمها مزود الخدمة. علاوة على ذلك، مع ظهور منتجات أو نماذج حوسبة جديدة، من المرجح أن تكون عملية الهجرة بسيطة وخالية من المتاعب.

ونظراً للسرعة التي يتطور بها طيف هذه الحلول (سأكون مندهشاً للغاية إذا لم يكن هناك خياران جديدان قريباً)، فسوف يكون من الصعب للغاية على فرق "المنصة" الصغيرة (فرق البنية الأساسية المسؤولة عن بناء منصات محلية لتشغيل أحمال العمل للشركات) التنافس من حيث الميزات وسهولة الاستخدام والموثوقية الشاملة. لقد هيمنت Kubernetes على العقد الثاني من القرن الحادي والعشرين كأداة لبناء PaaS (المنصة كخدمة)، لذلك يبدو لي أنه من غير المجدي تمامًا بناء منصة داخلية فوق Kubernetes توفر نفس الاختيار والبساطة والحرية المتوفرة في مساحة السحابة العامة. إن التفكير في PaaS المستند إلى الحاويات باعتباره "استراتيجية Kubernetes" هو فشل متعمد في الاستفادة من أكثر قدرات السحابة ابتكارًا.

إذا نظرت إلى المتاح اليوم مع تزايد قدرات الحوسبة، أصبح من الواضح أن بناء PaaS الخاص بك على رأس Kubernetes فقط هو بمثابة وضع نفسك في الزاوية (وهذا ليس نهجًا تقدميًا للغاية، أليس كذلك؟). حتى لو قرر شخص ما إنشاء حاوية PaaS على Kubernetes اليوم، فسوف تبدو بعد عامين قديمة مقارنة بإمكانيات السحابة. على الرغم من أن Kubernetes بدأ كمشروع مفتوح المصدر، فإن سلفه ومصدر إلهامه هو أداة داخلية من Google. ومع ذلك، فقد تم تطويره في الأصل في أوائل/منتصف العقد الأول من القرن الحادي والعشرين، عندما كان المشهد الحوسبة مختلفًا تمامًا.

بالإضافة إلى ذلك، بمعنى واسع للغاية، لا يتعين على الشركات أن تصبح خبيرة في إدارة مجموعة Kubernetes، تمامًا كما لا يتعين عليها بناء وصيانة مراكز البيانات الخاصة بها. إن توفير أساس حوسبة موثوق به هو التحدي الرئيسي مزودي الخدمات السحابية.

أخيرًا، أشعر وكأننا تراجعنا قليلًا كصناعة من حيث تجربة التفاعل (UX). تم إطلاق Heroku في عام 2007 ويظل واحدًا من أكثر سهل الاستخدام المنصات. لا يمكن إنكار أن Kubernetes أقوى بكثير وقابل للتوسع والبرمجة، ولكنني أفتقد مدى سهولة البدء والنشر على Heroku. لاستخدام هذه المنصة، كل ما تحتاج إليه هو معرفة Git.

كل هذا يقودني إلى الاستنتاج التالي: نحن بحاجة إلى تجريدات أفضل وأعلى مستوى للقيام بوظائفنا (وهذا ينطبق بشكل خاص على أعلى مستوى من التجريد).

واجهة برمجة التطبيقات الصحيحة من أعلى مستوى

يعد Docker مثالاً رائعًا على الحاجة إلى فصل الاهتمامات بشكل أفضل أثناء التنفيذ الصحيح لأعلى مستوى من واجهة برمجة التطبيقات.

المشكلة مع Docker هي أن الأهداف الأولية للمشروع كانت طموحة للغاية (على الأقل): كل هذا من أجل حل مشكلة التوافق ("إنه يعمل على جهازي") باستخدام تقنية الحاويات. كان Docker عبارة عن تنسيق صورة، ووقت تشغيل به شبكته الافتراضية الخاصة، وأداة CLI، وشيطان يعمل كجذر، وأكثر من ذلك بكثير. على أية حال، كانت الرسالة أكثر مربكة، ناهيك عن "الآلات الافتراضية خفيفة الوزن"، ومجموعات التحكم، ومساحات الأسماء، والعديد من مشكلات الأمان والميزات المختلطة مع الملعب التسويقي "بناء، وشحن، وتشغيل أي تطبيق في أي مكان".

نظرة على تقنيات العقد الماضي

كما هو الحال مع جميع التجريدات الجيدة، فإن الأمر يستغرق وقتًا (وخبرة وألمًا) لتقسيم المشكلات المختلفة إلى طبقات منطقية يمكن دمجها مع بعضها البعض. لسوء الحظ، قبل أن يصل Docker إلى هذا المستوى من النضج، دخل Kubernetes إلى المعركة. لقد استحوذت على دورة الضجيج لدرجة أن الجميع الآن يحاولون مواكبة التغييرات في نظام Kubernetes البيئي، وأصبح نظام الحاويات البيئي ثانويًا.

يتشارك Kubernetes في العديد من المشكلات نفسها التي يواجهها Docker. على الرغم من كل الحديث عن التجريد الرائع والقابل للتأليف، فصل المهام المختلفة إلى طبقات لم يتم تغليفها بشكل جيد. في جوهره، هو عبارة عن منظم حاويات يقوم بتشغيل الحاويات على مجموعة من الأجهزة المختلفة. هذه مهمة منخفضة المستوى إلى حد ما، وتنطبق فقط على المهندسين الذين يديرون المجموعة. من ناحية أخرى، Kubernetes هو أيضًا تجريد من أعلى مستوى، وهي أداة CLI يتفاعل معها المستخدمون عبر YAML.

كان Docker (ولا يزال) رائع أداة تطوير، على الرغم من كل عيوبها. في محاولة لمواكبة جميع "الأرانب" في وقت واحد، تمكن مطوروها من تنفيذه بشكل صحيح تجريد من أعلى مستوى. أقصد بأعلى مستوى من التجريد مجموعة فرعية الوظيفة التي كان الجمهور المستهدف (في هذه الحالة، المطورون الذين قضوا معظم وقتهم في بيئات التطوير المحلية الخاصة بهم) مهتمًا بها بالفعل والتي عملت بشكل رائع خارج الصندوق.

ملف Dockerfile وأداة CLI docker يجب أن يصبح مثالاً لبناء "واجهة مستخدم عالية المستوى" جيدة. يمكن للمطور العادي أن يبدأ العمل مع Docker دون معرفة أي شيء عن التعقيدات التنفيذات التي تساهم في الخبرة التشغيليةفي النهاية، لا يختلف كتابة Dockerfile كثيرًا عن كتابة البرنامج النصي shell.

تم تصميم Kubernetes لمجموعات مستهدفة مختلفة:

مسؤولي المجموعة؛
مهندسو البرمجيات الذين يعملون على قضايا البنية التحتية، وتوسيع قدرات Kubernetes وبناء منصات فوقها؛
المستخدمون النهائيون يتفاعلون مع Kubernetes عبر kubectl.

النهج الذي يتبعه Kubernetes والذي يعتمد على واجهة برمجة تطبيقات واحدة تناسب الجميع هو عبارة عن "جبل من التعقيد" غير مغلف بما يكفي دون أي إشارة إلى كيفية توسيع نطاقه. كل هذا يؤدي إلى منحنى تعليمي طويل لا داعي له. كيف يكتب آدم جاكوب، "قدّم Docker تجربة مستخدم تحويلية لم يسبق لأحد أن تجاوزها. اسأل أي شخص يستخدم K8s إذا كان يتمنى أن يعمل مثل أول جهاز استخدمه docker run. "الجواب سيكون بالإيجاب":

نظرة على تقنيات العقد الماضي

أود أن أزعم أن معظم تكنولوجيا البنية التحتية اليوم منخفضة المستوى للغاية (ولذلك تعتبر "معقدة للغاية"). تم تنفيذ Kubernetes على مستوى منخفض إلى حد ما. التتبع الموزع في في شكله الحالي (يتم أيضًا تنفيذ العديد من الامتدادات المخيطة معًا لتشكيل عرض تتبع) على مستوى منخفض للغاية. تميل أدوات المطور التي تنفذ "التجريدات ذات المستوى الأعلى" إلى أن تكون الأكثر نجاحًا. يتبين أن هذا الاستنتاج صحيح في عدد مفاجئ من الحالات (إذا كانت التكنولوجيا معقدة للغاية أو يصعب استخدامها، فلن يتم اكتشاف "واجهة برمجة التطبيقات/واجهة المستخدم ذات المستوى الأعلى" لهذه التكنولوجيا بعد).

في الوقت الحالي، يعتبر النظام البيئي السحابي الأصلي مربكًا في تركيزه على الأشياء ذات المستوى المنخفض. باعتبارنا صناعة، يتعين علينا الابتكار والتجريب والتثقيف حول المستوى الصحيح من "أقصى قدر من التجريد".

تجارة التجزئة

في العقد الثاني من القرن الحادي والعشرين، ظلت تجربة البيع بالتجزئة الرقمية دون تغيير إلى حد كبير. من ناحية أخرى، كان من المؤكد أن سهولة التسوق عبر الإنترنت ستؤثر على متاجر التجزئة التقليدية، ومن ناحية أخرى، لم يتغير التسوق عبر الإنترنت كثيرًا منذ عقد من الزمان.

رغم أنني لا أملك أي أفكار محددة حول الاتجاه الذي ستسلكه هذه الصناعة في العقد المقبل، إلا أنني سأشعر بخيبة أمل كبيرة إذا تسوقنا في عام 2030 بنفس الطريقة التي نتسوق بها في عام 2020.

صحافة

أشعر بخيبة أمل متزايدة إزاء حالة الصحافة العالمية. لقد أصبح من الصعب بشكل متزايد العثور على مصادر إخبارية غير متحيزة تقدم تقارير موضوعية ودقيقة. في كثير من الأحيان يتم محو الخط الفاصل بين الخبر نفسه والرأي حوله. كقاعدة عامة، يتم تقديم المعلومات بطريقة متحيزة. وهذا صحيح بشكل خاص في بعض البلدان حيث لم يكن هناك تاريخيا أي فصل بين الأخبار والرأي. في مقال نُشر مؤخرًا بعد الانتخابات العامة الأخيرة في المملكة المتحدة، كتب آلان روسبريدجر، رئيس تحرير صحيفة الغارديان السابق، يكتب:

والنقطة الرئيسية هي أنني لسنوات عديدة كنت أتابع الصحف الأميركية وأشعر بالأسف على زملائي هناك الذين كانوا مسؤولين وحدهم عن الأخبار، تاركين التعليق لأشخاص مختلفين تماما. لكن مع مرور الوقت، تحولت الشفقة إلى حسد. وأعتقد الآن أن جميع الصحف الوطنية البريطانية يجب أن تفصل بين المسؤولية عن الأخبار والمسؤولية عن التعليق. ومن المؤسف أنه من الصعب للغاية على القارئ العادي ــ وخاصة القارئ عبر الإنترنت ــ أن يميز الفرق.

ونظراً للسمعة المشكوك فيها إلى حد ما التي تتمتع بها منطقة وادي السيليكون عندما يتعلق الأمر بالأخلاق، فلن أثق تحت أي ظرف من الظروف في قدرة التكنولوجيا على "إحداث ثورة" في عالم الصحافة. وفي الوقت نفسه، سوف أكون سعيدًا (وكثير من أصدقائي) إذا ظهرت مصادر إخبارية محايدة وغير أنانية وجديرة بالثقة. لا أستطيع حتى الآن أن أتخيل كيف قد تبدو مثل هذه المنصة، ولكنني واثق من أنه في عصر أصبح فيه من الصعب بشكل متزايد تمييز الحقيقة، فإن الحاجة إلى الصحافة الصادقة أصبحت أكبر من أي وقت مضى.

الشبكات الاجتماعية

تشكل وسائل التواصل الاجتماعي ومنصات الأخبار الجماعية المصدر الأساسي للمعلومات بالنسبة للعديد من الأشخاص في جميع أنحاء العالم، وقد أدى الافتقار إلى الدقة وعدم رغبة بعض المنصات حتى في إجراء التحقق الأساسي من الحقائق إلى عواقب وخيمة مثل الإبادة الجماعية والتدخل في الانتخابات وما إلى ذلك.

كما أن وسائل التواصل الاجتماعي هي أقوى أداة إعلامية موجودة على الإطلاق. لقد غيروا الممارسة السياسية جذريا. لقد غيروا الإعلان. لقد غيروا الثقافة الشعبية (على سبيل المثال، المساهمة الرئيسية في تطوير ما يسمى بثقافة الإلغاء [ثقافات النبذ - المحرر [ترجمة] (الشبكات الاجتماعية هي التي تساهم). يزعم المنتقدون أن وسائل التواصل الاجتماعي أثبتت أنها أرض خصبة للتغيرات السريعة و"المتقلبة" في القيم الأخلاقية، ولكنها قدمت أيضاً للمجموعات المهمشة فرصة للتنظيم بطرق لم تكن متاحة لهم من قبل. في الأساس، لقد غيرت وسائل التواصل الاجتماعي الطريقة التي يتواصل بها الناس ويعبرون عن أنفسهم في القرن الحادي والعشرين.

ومع ذلك، أعتقد أيضًا أن وسائل التواصل الاجتماعي تبرز أسوأ الدوافع البشرية. في كثير من الأحيان يتم إهمال التفكير والرعاية لصالح الشعبية، ويصبح من المستحيل تقريبًا التعبير عن الخلاف المعقول مع آراء ومواقف معينة. في كثير من الأحيان، تخرج الاستقطابات عن السيطرة، مما يؤدي إلى عدم استماع الجمهور للآراء الفردية، في حين يسيطر المطلقون على قضايا آداب الإنترنت وقبولها.

أتساءل عما إذا كان من الممكن إنشاء منصة "أفضل" من شأنها تسهيل المناقشات بشكل أفضل؟ وبعد كل شيء، فإن ما يحرك "المشاركة" هو الذي يجلب في كثير من الأحيان الجزء الأكبر من الأرباح لهذه المنصات. كيف يكتب كارا سويشر في صحيفة نيويورك تايمز:

من الممكن تطوير التفاعلات الرقمية دون إثارة الكراهية والتعصب. السبب الذي يجعل معظم وسائل التواصل الاجتماعي تبدو سامة هو أنها تم إنشاؤها من أجل السرعة والانتشار والاهتمام، وليس المحتوى والدقة.

وسيكون من المؤسف حقا أن يصبح الإرث الوحيد الذي ستخلفه وسائل التواصل الاجتماعي بعد عقدين من الزمن هو تآكل الفروق الدقيقة والملاءمة في الخطاب العام.