ملحوظة. ترجمة.: هذه المقالة، التي حققت نجاحًا كبيرًا على موقع Medium، هي نظرة عامة على التغييرات الرئيسية (2010-2019) في عالم لغات البرمجة والنظام البيئي التكنولوجي المرتبط بها (مع التركيز بشكل خاص على Docker وKubernetes). مؤلفها الأصلي هو سيندي سريداران، المتخصصة في أدوات التطوير والأنظمة الموزعة - على وجه الخصوص، كتبت كتاب "قابلية مراقبة الأنظمة الموزعة" - وتحظى بشعبية كبيرة في مجال الإنترنت بين متخصصي تكنولوجيا المعلومات، وخاصة المهتمين بموضوع السحابة الأصلية.
مع اقتراب عام 2019 من نهايته، أردت أن أشارككم أفكاري حول بعض أهم التطورات والابتكارات التكنولوجية في العقد الماضي. بالإضافة إلى ذلك، سأحاول أن أنظر قليلاً إلى المستقبل وأحدد المشاكل والفرص الرئيسية للعقد القادم.
أريد أن أوضح أنني في هذه المقالة لا أغطي التغييرات في مجالات مثل علم البيانات (علم البيانات)والذكاء الاصطناعي وهندسة الواجهة الأمامية وما إلى ذلك لأنني شخصياً لا أملك الخبرة الكافية فيها.
الضربات التصنيفية تعود
كان أحد أكثر الاتجاهات إيجابية في العقد الأول من القرن الحادي والعشرين هو إحياء اللغات المكتوبة بشكل ثابت. ومع ذلك، فإن مثل هذه اللغات لم تختف أبدًا (هناك طلب اليوم على لغة C++ وJava؛ فقد سيطرتا قبل عشر سنوات)، لكن اللغات المكتوبة ديناميكيًا (الديناميكية) شهدت زيادة كبيرة في شعبيتها بعد ظهور حركة Ruby on Rails في عام 2010. . بلغ هذا النمو ذروته في عام 2005 مع المصدر المفتوح لـ Node.js، مما جعل Javascript on the Server حقيقة واقعة.
مع مرور الوقت، فقدت اللغات الديناميكية بعض جاذبيتها في مجال إنشاء برامج الخادم. بدت لغة Go، التي انتشرت خلال ثورة الحاويات، أكثر ملاءمة لإنشاء خوادم عالية الأداء وموفرة للموارد مع معالجة متوازية (والتي من خلالها منشئ Node.js نفسه).
الصدأ، الذي تم تقديمه في عام 2010، شمل التقدم في في محاولة لتصبح لغة آمنة ومطبوعة. في النصف الأول من العقد، كان استقبال الصناعة لفيلم Rust فاترًا إلى حد ما، لكن شعبيته زادت بشكل ملحوظ في النصف الثاني. تشمل حالات الاستخدام الملحوظة لـ Rust استخدامها في , (تحدثنا عن ذلك في - تقريبا. ترجمة.)، مترجم WebAssembly المبكر من Fastly (الآن جزء من bytecodealliance)، وما إلى ذلك. ومع تفكير Microsoft في إمكانية إعادة كتابة بعض أجزاء نظام التشغيل Windows في Rust، فمن الآمن أن نقول إن هذه اللغة لها مستقبل مشرق في عشرينيات القرن الحالي.
حتى اللغات الديناميكية حصلت على ميزات جديدة مثل (أنواع اختيارية). تم تنفيذها لأول مرة في TypeScript، وهي لغة تسمح لك بإنشاء تعليمات برمجية مكتوبة وتجميعها في JavaScript. لدى PHP وRuby وPython أنظمة كتابة اختيارية خاصة بهم (, )، والتي تم استخدامها بنجاح في .
إرجاع SQL إلى NoSQL
NoSQL هي تقنية أخرى كانت أكثر شعبية في بداية العقد مما كانت عليه في النهاية. أعتقد أن هناك سببين لذلك.
أولاً، تبين أن نموذج NoSQL، مع افتقاره إلى المخطط والمعاملات وضمانات الاتساق الأضعف، أكثر صعوبة في التنفيذ من نموذج SQL. في بعنوان "لماذا يجب أن تفضل الاتساق القوي كلما أمكن ذلك" (لماذا يجب عليك اختيار الاتساق القوي، كلما أمكن ذلك) جوجل يكتب:
أحد الأشياء التي تعلمناها في Google هو أن كود التطبيق يكون أبسط وأن وقت التطوير يكون أقصر عندما يتمكن المهندسون من الاعتماد على مساحة التخزين الحالية للتعامل مع المعاملات المعقدة والحفاظ على البيانات منظمة. على حد تعبير وثائق Spanner الأصلية، "نعتقد أنه من الأفضل للمبرمجين التعامل مع مشاكل أداء التطبيق بسبب إساءة استخدام المعاملات عند ظهور اختناقات، بدلاً من وضع غياب المعاملات في الاعتبار باستمرار."
السبب الثاني يرجع إلى ظهور قواعد بيانات SQL الموزعة "الموسعة" (مثل и ) في الفضاء السحابي العام، بالإضافة إلى البدائل مفتوحة المصدر مثل CockroachDB (نحن نتحدث عنها أيضًا - تقريبا. ترجمة.)، والتي تحل العديد من المشكلات الفنية التي تسببت في "عدم توسيع" قواعد بيانات SQL التقليدية. حتى أن MongoDB، الذي كان في يوم من الأيام مثالًا لحركة NoSQL، أصبح الآن المعاملات الموزعة.
بالنسبة للمواقف التي تتطلب عمليات قراءة وكتابة ذرية عبر مستندات متعددة (عبر مجموعة واحدة أو أكثر)، يدعم MongoDB المعاملات متعددة المستندات. في حالة المعاملات الموزعة، يمكن استخدام المعاملات عبر عمليات ومجموعات وقواعد بيانات ومستندات وأجزاء متعددة.
إجمالي التدفق
يعد Apache Kafka بلا شك أحد أهم الاختراعات في العقد الماضي. تم افتتاح الكود المصدري الخاص به في يناير 2011، وعلى مر السنين، أحدث كافكا ثورة في الطريقة التي تتعامل بها الشركات مع البيانات. لقد تم استخدام كافكا في كل شركة عملت بها، من الشركات الناشئة إلى الشركات الكبيرة. يتم استخدام الضمانات وحالات الاستخدام التي توفرها (النشرة الفرعية، والتدفقات، والبنيات المستندة إلى الأحداث) في مجموعة متنوعة من المهام، بدءًا من تخزين البيانات وحتى مراقبة وتحليلات التدفق، وهي مطلوبة في العديد من المجالات مثل التمويل والرعاية الصحية والقطاع العام، التجزئة وغيرها.
التكامل المستمر (وبدرجة أقل النشر المستمر)
التكامل المستمر لم يظهر في السنوات العشر الأخيرة، بل ظهر خلال العقد الماضي انتشر إلى هذا الحد، والذي أصبح جزءًا من سير العمل القياسي (إجراء الاختبارات على جميع طلبات السحب). إنشاء GitHub كمنصة لتطوير وتخزين التعليمات البرمجية، والأهم من ذلك، تطوير سير العمل بناءً على ذلك يعني أن إجراء الاختبارات قبل قبول طلب السحب لإتقانها هو الوحيد سير العمل في التطوير، مألوف للمهندسين الذين بدأوا حياتهم المهنية في السنوات العشر الماضية.
النشر المستمر (نشر كل التزام عندما يصل إلى المستوى الرئيسي) ليس منتشرًا مثل التكامل المستمر. ومع ذلك، مع وجود عدد كبير من واجهات برمجة التطبيقات السحابية المختلفة للنشر، والشعبية المتزايدة لمنصات مثل Kubernetes (التي توفر واجهة برمجة تطبيقات موحدة لعمليات النشر)، وظهور أدوات متعددة المنصات ومتعددة السحابة مثل Spinnaker (المبنية على أعلى تلك الأدوات القياسية واجهات برمجة التطبيقات)، أصبحت عمليات النشر أكثر آلية وانسيابية، وبشكل عام، أكثر أمانًا.
حاويات
ربما تكون الحاويات هي التكنولوجيا الأكثر إثارة للجدل والمناقشة والإعلان عنها وسوء الفهم في العقد الأول من القرن الحادي والعشرين. ومن ناحية أخرى، فهو أحد أهم ابتكارات العقد الماضي. يكمن جزء من السبب وراء كل هذا النشاز في الإشارات المختلطة التي كنا نتلقاها من كل مكان تقريبًا. والآن بعد أن تراجعت هذه الضجة قليلاً، أصبحت بعض الأمور أكثر وضوحاً.
أصبحت الحاويات شائعة ليس لأنها أفضل طريقة لتشغيل تطبيق يلبي احتياجات مجتمع المطورين العالمي. أصبحت الحاويات شائعة لأنها تتناسب بنجاح مع طلب التسويق لأداة معينة تحل مشكلة مختلفة تمامًا. تحول عامل الميناء إلى أن يكون رائع أداة تطوير تعمل على حل مشكلة التوافق الملحة ("تعمل على جهازي").
بتعبير أدق، قامت الثورة صورة عامل الميناء، لأنه حل مشكلة التكافؤ بين البيئات ووفر إمكانية النقل الحقيقية ليس فقط لملف التطبيق، ولكن أيضًا لجميع تبعيات البرامج والتشغيل الخاصة به. وحقيقة أن هذه الأداة حفزت بطريقة أو بأخرى شعبية "الحاويات"، والتي هي في الأساس تفاصيل تنفيذ منخفضة المستوى للغاية، ربما تظل بالنسبة لي اللغز الرئيسي في العقد الماضي.
Serverless
أراهن على أن ظهور الحوسبة "بدون خادم" أكثر أهمية من الحاويات لأنه يجعل حلم الحوسبة عند الطلب حقيقة واقعة (بناء على الطلب). على مدى السنوات الخمس الماضية، رأيت النهج بدون خادم يتوسع تدريجيًا في نطاقه من خلال إضافة دعم للغات وأوقات التشغيل الجديدة. يبدو أن ظهور منتجات مثل Azure Permanent Functions هو الخطوة الصحيحة نحو تنفيذ الوظائف ذات الحالة (وفي نفس الوقت خطوة حاسمة المتعلقة بقيود FaaS). وسوف أشاهد باهتمام كيف يتطور هذا النموذج الجديد في السنوات المقبلة.
الأتمتة
ولعل أكبر المستفيد من هذا الاتجاه هو مجتمع هندسة العمليات، حيث أنه مكن مفاهيم مثل البنية التحتية كرمز (IaC) من أن تصبح حقيقة واقعة. بالإضافة إلى ذلك، تزامن الشغف بالأتمتة مع ظهور "ثقافة SRE"، التي تهدف إلى اتباع نهج أكثر تركيزًا على البرمجيات في العمليات.
عالمية API-fiction
ميزة أخرى مثيرة للاهتمام في العقد الماضي هي إنشاء واجهة برمجة التطبيقات (API) لمهام التطوير المختلفة. تتيح واجهات برمجة التطبيقات الجيدة والمرنة للمطور إنشاء مسارات عمل وأدوات مبتكرة، والتي بدورها تساعد في الصيانة وتحسين تجربة المستخدم.
بالإضافة إلى ذلك، يعد إنشاء واجهة برمجة التطبيقات (API) هو الخطوة الأولى نحو إنشاء SaaS لبعض الوظائف أو الأدوات. تزامن هذا الاتجاه أيضًا مع ارتفاع شعبية الخدمات الصغيرة: أصبحت SaaS مجرد خدمة أخرى يمكن الوصول إليها عبر واجهة برمجة التطبيقات (API). يوجد الآن العديد من أدوات SaaS و FOSS المتاحة في مجالات مثل المراقبة والمدفوعات وموازنة التحميل والتكامل المستمر والتنبيهات وتبديل الميزات (وضع علامة على الميزة)و CDN وهندسة المرور (مثل DNS) وما إلى ذلك، والتي ازدهرت في العقد الماضي.
قابلية الملاحظة
ومن الجدير بالذكر أن اليوم لدينا إمكانية الوصول إليها أكثر تقدما بكثير أدوات لمراقبة وتشخيص سلوك التطبيق أكثر من أي وقت مضى. ربما يمكن تسمية نظام المراقبة بروميثيوس، الذي حصل على حالة المصدر المفتوح في عام 2015 الأفضل نظام المراقبة من تلك التي عملت معها. إنها ليست مثالية، ولكن يتم تنفيذ عدد كبير من الأشياء بالطريقة الصحيحة تمامًا (على سبيل المثال، دعم القياسات [الأبعاد] في حالة المقاييس).
كان التتبع الموزع تقنية أخرى دخلت الاتجاه السائد في العقد الأول من القرن الحادي والعشرين، وذلك بفضل مبادرات مثل OpenTracing (وخليفتها OpenTelemetry). على الرغم من أن تطبيق التتبع لا يزال صعبًا للغاية، فإن بعض التطورات الأخيرة تعطي الأمل في أننا سنطلق العنان لإمكاناته الحقيقية في عشرينيات القرن الحالي. (ملاحظة: اقرأ أيضًا في مدونتنا ترجمة المقال “"للمؤلف نفسه.)
يتطلع إلى المستقبل
ومن المؤسف أن هناك العديد من نقاط الألم التي تنتظر الحل في العقد المقبل. فيما يلي أفكاري بشأنها وبعض الأفكار المحتملة حول كيفية التخلص منها.
حل مشكلة قانون مور
تتطلب نهاية قانون دينارد للقياس والتأخر عن قانون مور ابتكارات جديدة. جون هينيسي في يشرح لماذا مشكلة المدمنين (مجال محدد) قد تكون البنى المعمارية مثل TPU أحد الحلول لمشكلة التخلف عن قانون مور. مجموعات الأدوات مثل يبدو أن Google يمثل بالفعل خطوة جيدة للأمام في هذا الاتجاه:
يجب أن يدعم المترجمون التطبيقات الجديدة، ويمكن نقلهم بسهولة إلى أجهزة جديدة، وربط طبقات متعددة من التجريد بدءًا من اللغات الديناميكية المُدارة إلى مسرعات المتجهات وأجهزة التخزين التي يتحكم فيها البرنامج، مع توفير مفاتيح عالية المستوى للضبط التلقائي، وتوفير في الوقت الوظيفي، والتشخيص، وتوزيع معلومات تصحيح الأخطاء حول عمل الأنظمة وأدائها في جميع أنحاء المكدس، مع توفير أداء قريب بشكل معقول من المجمّع المكتوب بخط اليد في معظم الحالات. نعتزم مشاركة رؤيتنا وتقدمنا وخططنا لتطوير البنية التحتية للتجميع وإتاحتها للعامة.
CI / CD
في حين أن صعود CI أصبح واحدًا من أكبر الاتجاهات في العقد الأول من القرن الحادي والعشرين، إلا أن Jenkins لا يزال هو المعيار الذهبي لـ CI.
وهذا الفضاء في حاجة ماسة إلى الابتكار في المجالات التالية:
- واجهة المستخدم (DSL لمواصفات اختبار التشفير)؛
- تفاصيل التنفيذ التي ستجعله قابلاً للتطوير وسريعًا؛
- التكامل مع البيئات المختلفة (التدريج، الإنتاج، إلخ) لتنفيذ أشكال اختبار أكثر تقدمًا؛
- الاختبار المستمر والنشر.
ادوات المطورين
كصناعة، بدأنا في إنشاء برامج معقدة ومثيرة للإعجاب بشكل متزايد. ومع ذلك، عندما يتعلق الأمر بأدواتنا الخاصة، يمكن أن يكون الوضع أفضل بكثير.
اكتسب التحرير التعاوني والبعيد (عبر SSH) بعض الشعبية، لكنه لم يصبح أبدًا الطريقة القياسية الجديدة للتطوير. إذا كنت، مثلي، ترفض فكرة حاجة اتصال دائم بالإنترنت فقط لتتمكن من القيام بالبرمجة، فمن غير المرجح أن يناسبك العمل عبر ssh على جهاز بعيد.
لا تزال بيئات التطوير المحلية، وخاصة بالنسبة للمهندسين الذين يعملون في تصميمات كبيرة موجهة نحو الخدمة، تمثل تحديًا. تحاول بعض المشاريع حل هذه المشكلة، وسأكون مهتمًا بمعرفة كيف ستبدو تجربة المستخدم الأكثر راحة في حالة استخدام معينة.
سيكون من المثير للاهتمام أيضًا توسيع مفهوم "البيئات المحمولة" ليشمل مجالات أخرى من التطوير مثل إعادة إنتاج الأخطاء (أو ) التي تحدث في ظل ظروف أو إعدادات معينة.
أود أيضًا أن أرى المزيد من الابتكار في مجالات مثل البحث عن التعليمات البرمجية الدلالية والحساسة للسياق، وأدوات لربط حوادث الإنتاج بأجزاء محددة من قاعدة التعليمات البرمجية، وما إلى ذلك.
الحوسبة (مستقبل PaaS)
بعد الضجة التي أثيرت حول الحاويات والخوادم بدون خادم في العقد الأول من القرن الحادي والعشرين، توسع نطاق الحلول في الفضاء السحابي العام بشكل كبير في السنوات القليلة الماضية.
وهذا يثير العديد من الأسئلة المثيرة للاهتمام. بادئ ذي بدء، قائمة الخيارات المتاحة في السحابة العامة تتزايد باستمرار. يتمتع مقدمو الخدمات السحابية بالموظفين والموارد اللازمة لمواكبة أحدث التطورات في عالم مفتوح المصدر بسهولة وإصدار منتجات مثل "القرون بدون خادم" (أظن ببساطة عن طريق جعل أوقات تشغيل FaaS الخاصة بهم متوافقة مع OCI) أو أشياء أخرى مماثلة.
لا يسع المرء إلا أن يحسد أولئك الذين يستخدمون هذه الحلول السحابية. من الناحية النظرية، توفر عروض Kubernetes السحابية (GKE وEKS وEKS on Fargate وما إلى ذلك) واجهات برمجة تطبيقات مستقلة عن موفر السحابة لتشغيل أعباء العمل. إذا كنت تستخدم منتجات مماثلة (ECS، وFargate، وGoogle Cloud Run، وما إلى ذلك)، فمن المحتمل أنك تحقق بالفعل أقصى استفادة من الميزات الأكثر إثارة للاهتمام التي يقدمها مزود الخدمة. بالإضافة إلى ذلك، مع ظهور منتجات أو نماذج حوسبة جديدة، من المرجح أن تكون عملية الترحيل بسيطة وخالية من الضغوط.
وبالنظر إلى مدى سرعة تطور نطاق هذه الحلول (سأفاجأ للغاية إذا لم يظهر خياران جديدان في المستقبل القريب)، فإن فرق "المنصة" الصغيرة (الفرق المرتبطة بالبنية التحتية والمسؤولة عن إنشاء منصات داخلية لـ سيكون من الصعب للغاية التنافس من حيث الأداء الوظيفي وسهولة الاستخدام والموثوقية الشاملة. لقد شهد العقد الأول من القرن الحادي والعشرين أن Kubernetes هي أداة لبناء PaaS (النظام الأساسي كخدمة)، لذلك يبدو من غير المجدي تمامًا بالنسبة لي إنشاء منصة داخلية فوق Kubernetes تقدم نفس الاختيار والبساطة والحرية المتاحة للجمهور مساحة سحابية. إن تأطير PaaS القائم على الحاوية باعتباره "إستراتيجية Kubernetes" يعد بمثابة تجنب متعمد للقدرات السحابية الأكثر ابتكارًا.
إذا نظرت إلى المتاحة اليوم قدرات الحوسبة، يصبح من الواضح أن إنشاء PaaS الخاص بك استنادًا إلى Kubernetes فقط هو بمثابة وضع نفسك في الزاوية (ليس نهجًا تقدميًا جدًا، أليس كذلك؟). حتى لو قرر شخص ما إنشاء PaaS في حاوية على Kubernetes اليوم، فسيبدو في غضون عامين قديمًا مقارنة بالقدرات السحابية. على الرغم من أن Kubernetes بدأ كمشروع مفتوح المصدر، إلا أن سلفه وإلهامه كان أداة داخلية من Google. ومع ذلك، فقد تم تطويره في الأصل في أوائل ومنتصف العقد الأول من القرن الحادي والعشرين عندما كان مشهد الحوسبة مختلفًا تمامًا.
أيضًا، بالمعنى الواسع جدًا، لا يتعين على الشركات أن تصبح خبراء في تشغيل مجموعة Kubernetes، كما أنها لا تقوم ببناء وصيانة مراكز البيانات الخاصة بها. يعد توفير أساس حوسبة موثوق به تحديًا أساسيًا مقدمي الخدمات السحابية.
أخيرًا، أشعر أننا تراجعنا قليلاً كصناعة من حيث تجربة التفاعل (). تم إطلاق Heroku في عام 2007 وما زال واحدًا من أكثرها سهل الاستخدام المنصات. ليس هناك من ينكر أن Kubernetes أقوى بكثير وقابل للتوسعة وقابل للبرمجة، لكنني أفتقد مدى سهولة البدء والنشر في Heroku. لاستخدام هذه المنصة، ما عليك سوى معرفة Git.
كل هذا يقودني إلى الاستنتاج التالي: نحن بحاجة إلى تجريدات أفضل وأعلى مستوى للعمل (وهذا ينطبق بشكل خاص على أعلى مستوى التجريد).
واجهة برمجة التطبيقات الصحيحة على أعلى مستوى
يعد Docker مثالًا رائعًا على الحاجة إلى فصل أفضل للمخاوف في نفس الوقت التنفيذ الصحيح لواجهة برمجة التطبيقات (API) على أعلى مستوى.
تكمن مشكلة Docker في أن أهداف المشروع (على الأقل) في البداية كانت واسعة جدًا: كل ذلك من أجل حل مشكلة التوافق ("يعمل على جهازي") باستخدام تقنية الحاوية. كان Docker عبارة عن تنسيق صورة، ووقت تشغيل بشبكته الافتراضية الخاصة، وأداة CLI، وبرنامج خفي يعمل كجذر، وغير ذلك الكثير. وعلى أية حال، كان تبادل الرسائل أكثر مربكة، ناهيك عن "الأجهزة الافتراضية خفيفة الوزن"، ومجموعات التحكم، ومساحات الأسماء، والعديد من المشكلات والميزات الأمنية الممزوجة بالدعوة التسويقية إلى "إنشاء أي تطبيق وتسليمه وتشغيله في أي مكان".
كما هو الحال مع جميع التجريدات الجيدة، يستغرق الأمر وقتًا (وخبرة وألمًا) لتقسيم المشكلات المختلفة إلى طبقات منطقية يمكن دمجها مع بعضها البعض. لسوء الحظ، قبل أن يصل Docker إلى مرحلة النضج المماثلة، دخل Kubernetes في المعركة. لقد احتكرت دورة الضجيج لدرجة أن الجميع كانوا يحاولون الآن مواكبة التغييرات في النظام البيئي Kubernetes، واتخذ النظام البيئي للحاويات وضعًا ثانويًا.
يشارك Kubernetes العديد من المشكلات نفسها التي يواجهها Docker. لكل الحديث عن التجريد الرائع والقابل للتركيب، فصل المهام المختلفة إلى طبقات ليست مغلفة بشكل جيد للغاية. إنها في جوهرها عبارة عن منسق للحاويات يقوم بتشغيل الحاويات على مجموعة من الأجهزة المختلفة. هذه مهمة منخفضة المستوى إلى حد ما، ولا تنطبق إلا على المهندسين الذين يقومون بتشغيل المجموعة. من ناحية أخرى، Kubernetes كذلك التجريد على أعلى مستوى، أداة CLI يتفاعل معها المستخدمون عبر YAML.
كان عامل الميناء (ولا يزال) رائع أداة التطوير، على الرغم من كل عيوبها. في محاولة لمواكبة جميع "الأرانب" في وقت واحد، تمكن مطوروها من التنفيذ بشكل صحيح التجريد على أعلى مستوى. أعني بالتجريد على أعلى مستوى مجموعة فرعية الوظيفة التي كان الجمهور المستهدف (في هذه الحالة، المطورين الذين أمضوا معظم وقتهم في بيئات التطوير المحلية الخاصة بهم) مهتمين بها حقًا والتي عملت بشكل رائع خارج الصندوق.
الأداة المساعدة Dockerfile وCLI docker يجب أن يكون مثالاً لكيفية بناء "تجربة مستخدم جيدة على أعلى مستوى". يمكن للمطور العادي أن يبدأ العمل مع Docker دون معرفة أي شيء عن التعقيدات التطبيقات التي تساهم في الخبرة التشغيليةمثل مساحات الأسماء ومجموعات التحكم والذاكرة وحدود وحدة المعالجة المركزية وما إلى ذلك. في النهاية، لا تختلف كتابة ملف Dockerfile كثيرًا عن كتابة نص برمجي للصدفة.
Kubernetes مخصص لمجموعات مستهدفة مختلفة:
- مسؤولي الكتلة؛
- مهندسو البرمجيات الذين يعملون على قضايا البنية التحتية، وتوسيع قدرات Kubernetes وإنشاء منصات تعتمد عليها؛
- يتفاعل المستخدمون النهائيون مع Kubernetes عبر
kubectl.
يمثل نهج "واجهة برمجة تطبيقات واحدة تناسب الجميع" الخاص بـ Kubernetes "جبلًا من التعقيد" غير مغلف بشكل كافٍ دون أي توجيهات حول كيفية توسيع نطاقه. كل هذا يؤدي إلى مسار تعليمي طويل الأمد بشكل غير مبرر. كيف آدم جاكوب، "جلبت شركة Docker تجربة مستخدم تحويلية لم يتم تجاوزها من قبل. اسأل أي شخص يستخدم K8s عما إذا كان يرغب في أن يعمل مثل جهازه الأول docker run. الجواب سيكون نعم":
وأود أن أزعم أن أغلب تكنولوجيات البنية الأساسية اليوم منخفضة المستوى للغاية (وبالتالي تعتبر "معقدة للغاية"). يتم تنفيذ Kubernetes بمستوى منخفض إلى حد ما. تتبع الموزعة في (الكثير من الامتدادات التي تم تجميعها معًا لتكوين عرض تتبع) يتم تنفيذها أيضًا على مستوى منخفض جدًا. تميل أدوات المطورين التي تنفذ "التجريدات ذات المستوى الأعلى" إلى أن تكون الأكثر نجاحًا. ويصدق هذا الاستنتاج في عدد مدهش من الحالات (إذا كانت التكنولوجيا معقدة للغاية أو صعبة الاستخدام، فإن "واجهة برمجة التطبيقات/واجهة المستخدم ذات المستوى الأعلى" لهذه التكنولوجيا لم يتم اكتشافها بعد).
في الوقت الحالي، يعد النظام البيئي السحابي الأصلي مربكًا بسبب تركيزه على المستوى المنخفض. ويتعين علينا كصناعة أن نبتكر ونجرب ونثقف المستوى الصحيح من "الحد الأقصى والأعلى من التجريد".
تجارة التجزئة
في العقد الأول من القرن الحادي والعشرين، ظلت تجربة البيع بالتجزئة الرقمية دون تغيير إلى حد كبير. من ناحية، كان من المفترض أن تصل سهولة التسوق عبر الإنترنت إلى متاجر البيع بالتجزئة التقليدية، ومن ناحية أخرى، ظل التسوق عبر الإنترنت دون تغيير تقريبًا خلال عقد من الزمن.
على الرغم من أنه ليس لدي أي أفكار محددة حول كيفية تطور هذه الصناعة خلال العقد المقبل، إلا أنني سأشعر بخيبة أمل كبيرة إذا قمنا بالتسوق في عام 2030 بنفس الطريقة التي نتسوق بها في عام 2020.
صحافة
أشعر بخيبة أمل متزايدة إزاء حالة الصحافة العالمية. لقد أصبح من الصعب بشكل متزايد العثور على مصادر إخبارية غير متحيزة تقدم تقاريرها بموضوعية ودقة. في كثير من الأحيان يكون الخط الفاصل بين الأخبار نفسها والآراء حولها غير واضح. وكقاعدة عامة، يتم تقديم المعلومات بطريقة متحيزة. وينطبق هذا بشكل خاص على بعض البلدان التي لم يكن هناك تاريخياً فصل بين الأخبار والرأي. في مقال نشر مؤخرًا بعد الانتخابات العامة الأخيرة في المملكة المتحدة، قال آلان روسبريدجر، المحرر السابق لصحيفة الغارديان: :
النقطة الأساسية هي أنني كنت أتصفح الصحف الأمريكية لسنوات عديدة وأشعر بالأسف تجاه زملائي هناك، الذين كانوا وحدهم مسؤولين عن الأخبار، تاركين التعليق لأشخاص مختلفين تمامًا. ومع ذلك، مع مرور الوقت، تحولت الشفقة إلى الحسد. أعتقد الآن أن كل الصحف الوطنية البريطانية يجب أن تفصل مسؤوليتها عن الأخبار عن مسؤوليتها عن التعليق. ولسوء الحظ، من الصعب جدًا على القارئ العادي – وخاصة القراء عبر الإنترنت – أن يميز الفرق.
ونظراً لسمعة وادي السليكون المشكوك فيها إلى حد ما عندما يتعلق الأمر بالأخلاق، فأنا لا أثق أبداً في قدرة التكنولوجيا على "إحداث ثورة" في الصحافة. ومع ذلك، سأكون سعيدًا (والعديد من أصدقائي) إذا كان هناك مصدر إخباري محايد وغير مهتم وجدير بالثقة. ورغم أنني لا أملك أي فكرة عن الشكل الذي قد تبدو عليه مثل هذه المنصة، فأنا على ثقة من أنه في عصر حيث أصبح من الصعب على نحو متزايد تمييز الحقيقة، أصبحت الحاجة إلى الصحافة الصادقة أكبر من أي وقت مضى.
الشبكات الاجتماعية
تعد وسائل التواصل الاجتماعي ومنصات الأخبار المجتمعية المصدر الأساسي للمعلومات للعديد من الأشخاص حول العالم، وقد أدى الافتقار إلى الدقة وإحجام بعض المنصات عن القيام حتى بالتدقيق الأساسي في الحقائق إلى عواقب وخيمة مثل الإبادة الجماعية والتدخل في الانتخابات وغير ذلك الكثير. .
تعد وسائل التواصل الاجتماعي أيضًا أقوى أداة إعلامية على الإطلاق. لقد غيروا الممارسة السياسية بشكل جذري. لقد غيروا الإعلان. لقد غيروا الثقافة الشعبية (على سبيل المثال، المساهمة الرئيسية في تطوير ما يسمى بثقافة الإلغاء [ثقافات النبذ - تقريبا. ترجمة.] تساهم الشبكات الاجتماعية). ويزعم المنتقدون أن وسائل الإعلام الاجتماعية أثبتت أنها أرض خصبة للتغيرات السريعة والمتقلبة في القيم الأخلاقية، ولكنها أتاحت أيضا لأعضاء المجموعات المهمشة الفرصة للتنظيم بطرق لم تتح لهم من قبل. في جوهرها، غيرت وسائل التواصل الاجتماعي الطريقة التي يتواصل بها الناس ويعبرون عن أنفسهم في القرن الحادي والعشرين.
ومع ذلك، أعتقد أيضًا أن وسائل التواصل الاجتماعي تبرز أسوأ الدوافع البشرية. غالبًا ما يتم إهمال الاعتبار والتفكير لصالح الشعبية، ويصبح من المستحيل تقريبًا التعبير عن عدم الاتفاق المنطقي مع آراء ومواقف معينة. غالبًا ما يخرج الاستقطاب عن نطاق السيطرة، مما يؤدي ببساطة إلى عدم سماع الجمهور لآراء فردية بينما يتحكم المطلقون في قضايا آداب التعامل مع الإنترنت ومقبوليته.
أتساءل عما إذا كان من الممكن إنشاء منصة "أفضل" تعزز المناقشات ذات الجودة الأفضل؟ ففي نهاية المطاف، فإن ما يحفز "المشاركة" هو الذي غالبا ما يجلب الربح الرئيسي لهذه المنصات. كيف كارا سويشر في نيويورك تايمز:
من الممكن تطوير التفاعلات الرقمية دون إثارة الكراهية والتعصب. السبب الذي يجعل معظم مواقع التواصل الاجتماعي تبدو سامة للغاية هو أنها صُممت من أجل السرعة والانتشار والاهتمام، بدلاً من المحتوى والدقة.
سيكون من المؤسف حقًا أن يكون الإرث الوحيد لوسائل التواصل الاجتماعي، في غضون عقدين من الزمن، هو تآكل الفروق الدقيقة والملاءمة في الخطاب العام.
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com