فلننتهي من هذا.
سأبدأ بقصة صغيرة ولكنها مفيدة عندما بدأت العمل في Google لأول مرة. أعلم أنني قلت الكثير من الأشياء السيئة عن Google مؤخرًا ، لكن هذا يزعجني عندما تتخذ شركتي الرئيسية بانتظام قرارات عمل غير كفؤة. بعد قولي هذا ، يجب أن نثني على: البنية التحتية الداخلية لـ Google استثنائية حقًا ، ويمكننا أن نقول بأمان أنه لا يوجد شيء أفضل اليوم. كان مؤسسو Google مهندسين أفضل بكثير مما سأصبح عليه في أي وقت مضى ، وهذه القصة تؤكد هذه الحقيقة فقط.
أولاً ، خلفية صغيرة: تمتلك Google تقنية تخزين تسمى Bigtable . لقد كان إنجازًا تقنيًا رائعًا ، وكان من أوائل (إن لم يكن الأول) متجر القيمة الرئيسية (K / V) "القابل للتطوير بشكل لا نهائي" (إن لم يكن الأول): بداية NoSQL. لا يزال Bigtable يشعر بالرضا في مساحة التخزين K / V المزدحمة هذه الأيام ، ولكن في ذلك الوقت (2005) كان رائعًا بشكل مذهل.
أحد الأشياء المضحكة في Bigtable هو أن لديهم كائنات طائرة تحكم داخلية (كجزء من التنفيذ) تسمى خوادم الأجهزة اللوحية ، مع فهارس كبيرة ، وفي مرحلة ما أصبحت عنق الزجاجة عند توسيع نطاق النظام. استنفد مهندسو Bigtable عقولهم حول كيفية تنفيذ قابلية التوسع ، وأدركوا فجأة أنه يمكنهم استبدال خوادم الأجهزة اللوحية بمخازن Bigtable أخرى. لذا فإن Bigtable جزء من تنفيذ Bigtable. توجد مرافق التخزين هذه على جميع المستويات.
هناك تفصيل آخر مثير للاهتمام وهو أن Bigtable أصبح لفترة من الوقت شائعًا ومنتشرًا في كل مكان داخل Google ، وكان لكل فريق مستودع خاص به. لذا في أحد اجتماعات يوم الجمعة ، سأل لاري بيدج عابرًا ، "لماذا لدينا أكثر من طاولة كبيرة واحدة؟ لماذا ليس واحد فقط؟ من الناحية النظرية ، يجب أن يكون التخزين الواحد كافياً لجميع احتياجات التخزين في Google. بالطبع ، لم يقفزوا أبدًا إلى واحدة فقط لأسباب تتعلق بالتنمية العملية (مثل عواقب فشل محتمل) ، لكن النظرية كانت مثيرة للاهتمام. مستودع واحد للكون بأسره ( بالمناسبة ، هل يعرف أي شخص ما إذا كانت أمازون قد فعلت ذلك بالسمور؟ )
على أي حال ، ها هي قصتي.
في ذلك الوقت ، عملت في Google لأكثر من عامين بقليل ، وفي أحد الأيام تلقيت رسالة بريد إلكتروني من فريق Bigtable الهندسي شيء من هذا القبيل:
عزيزي ستيف ،
تحية من فريق Bigtable. نود إعلامك بأنك تستخدم برنامج Bigtable ثنائي قديم جدًا في مركز بيانات [اسم مركز البيانات]. لم يعد هذا الإصدار مدعومًا ونريد مساعدتك في الترقية إلى أحدث إصدار.
يُرجى إعلامي إذا كان بإمكانك تحديد بعض الوقت للعمل معًا بشأن هذه المشكلة. أتمنى لك
كل خير ،
فريق Bigtable
تتلقى الكثير من رسائل البريد على Google ، لذا قرأت للوهلة الأولى شيئًا كهذا:
,
- . , ----. -----, -- .
, , --.
,
-
كدت أن أحذفها على الفور ، ولكن على حافة وعيي شعرت بألم مؤلم أن هذا لا يبدو تمامًا كرسالة رسمية ، على الرغم من أنه من الواضح أن المستلم كان مخطئًا ، لأنني لم أستخدم Bigtable.
لكن هذا كان غريبا.
بالنسبة لبقية اليوم ، فكرت بالتناوب في العمل ونوع لحم سمك القرش الذي يجب تجربته في مطبخ صغير ، كان ثلاثة منها على الأقل قريبًا بما يكفي للخروج من مكاني بكعكة إسفنجية جيدة الهدف ، لكن فكرة الكتابة لم تترك لي شعورًا متزايدًا. قلق طفيف.
من الواضح أنهم نادوا اسمي. ويتم إرسال البريد الإلكتروني إلى عنوان بريدي الإلكتروني ، وليس عنوان شخص آخر ، وهو ليس cc: أو bcc:. النغمة شخصية للغاية وواضحة. ربما هذا نوع من الخطأ؟
أخيرًا ، استحوذ الفضول على نفسي وذهبت لإلقاء نظرة على وحدة تحكم Borg في مركز البيانات الذي ذكروه.
وبالطبع ، كان لدي تخزين BigTable تحت سيطرتي. انا اسف ماذا نظرت إلى محتوياته ، و- واو! كان من حاضنة Codelab حيث قضيت أسبوعي الأول في Google في يونيو 2005. أجبرتك Codelab على بدء Bigtable بحيث تكتب بعض القيم هناك ، وربما لم أغلق المتجر أبدًا بعد ذلك. لا يزال يعمل ، على الرغم من مرور أكثر من عامين.
هناك العديد من الجوانب البارزة لهذه القصة. أولاً ، كان عمل Bigtable ضئيلًا جدًا على مقياس Google لدرجة أنه بعد عامين فقط لاحظ شخص ما سعة التخزين الإضافية ، وحتى ذلك الحين فقط لأن إصدار الثنائي كان قديمًا. للمقارنة ، فكرت مرة واحدة في استخدامBigtable على Google Cloud للعبتي على الإنترنت. في ذلك الوقت ، كانت هذه الخدمة تكلف حوالي 16000 دولار سنويًا مقابل Bigtable فارغ على GCP. أنا لا أقول إنهم يخونونك ، لكن في رأيي الشخصي ، هذا كثير من المال لقاعدة بيانات فارغة.
جانب آخر ملحوظ هو أن التخزين كان لا يزال يعمل بعد عامين... WTF؟ مراكز البيانات تأتي وتذهب ؛ إنهم يتعرضون للانقطاعات ، ويخضعون للصيانة الروتينية ، ويتغيرون طوال الوقت. يتم تحديث الأجهزة ، ويتم تبديل المفاتيح ، ويتم تحسين كل شيء باستمرار. كيف بحق الجحيم تمكنوا من الحفاظ على برنامجي يعمل لمدة عامين مع كل هذه التغييرات؟ قد يبدو هذا إنجازًا متواضعًا في عام 2020 ، لكنه كان مثيرًا للإعجاب في 2005-2007.
والجانب الأكثر روعة هو أن فريقًا هندسيًا خارجيًا في دولة أخرى اتصل بي ، صاحب مثال صغير شبه فارغ من Bigtable ، والذي لم يكن لديه أي حركة مرور خلال العامين الماضيين - ويقدم المساعدة لتحديثه. ...
شكرتهم ونزعت القبو واستمرت الحياة كالمعتاد. لكن بعد ثلاثة عشر عامًا ، ما زلت أفكر في هذه الرسالة. لأنني أحيانًا أتلقى رسائل بريد إلكتروني مثل هذه من Google Cloud. يبدون هكذا:
عزيزي مستخدم Google Cloud ،
نذكرك بأننا سنوقف الخدمة [خدمة مهمة تستخدمها] اعتبارًا من أغسطس 2020 ، وبعد ذلك لن تتمكن من تحديث مثيلاتك. نوصي بأن تقوم بالترقية إلى أحدث إصدار ، والذي هو في مرحلة الاختبار التجريبي ، ولا يحتوي على وثائق ، ولا يوجد مسار ترحيل ، وقد أصبح قديمًا مقدمًا بفضل مساعدتنا الكريمة.
نحن ملتزمون بالحد من تأثير هذا التغيير على جميع مستخدمي Google Cloud Platform.
أفضل أصدقاء للأبد ،
Google Cloud Platform
لكني بالكاد أقرأ مثل هذه الرسائل ، لأنها في الواقع تقول ما يلي:
عزيزي المستلم ،
اللعنة عليك. اللعنة عليك ، اللعنة عليك ، اللعنة عليك. تخلص من كل ما تفعله لأنه لا يهم. ما يهم هو وقتنا. نحن ننفق الوقت والمال لدعم هراءنا وقد سئمنا منه ، لذلك لن ندعمه بعد الآن. لذا تخلص من خططك اللعينة وابدأ في البحث في وثائقنا القذرة ، والتوسل للحصول على قصاصات في المنتديات ، وبالمناسبة ، فإن الهراء الجديد لدينا مختلف تمامًا عن القرف القديم لأننا أفسدنا هذا التصميم بشكل سيء ، ولكن هذه هي مشكلتك ، ليس لنا.
ما زلنا نعمل بجد للتأكد من أن جميع تصميماتك تصبح غير قابلة للاستخدام في غضون عام واحد.
يرجى الذهاب إلى
Google Cloud Platform
والحقيقة هي أنني أتلقى مثل هذه الرسائل مرة في الشهر تقريبًا. يحدث هذا كثيرًا وبشكل مستمر لدرجة أنهم دفعوني حتمًا بعيدًا عن GCP وإلى معسكر السحابة المعارض. لم أعد أوافق على الاعتماد على تطورات الملكية الخاصة بهم ، لأنه في الواقع من الأسهل على المطورين الحفاظ على نظام مفتوح المصدر على آلة افتراضية عارية من محاولة مواكبة Google بسياستها الخاصة بإغلاق المنتجات "القديمة".
قبل العودة إلى Google Cloud لأنني قريب أيضًالم تنته من نقدهم ، فلنلق نظرة على أداء الشركة في بعض المجالات الأخرى. يفتخر مهندسو Google بأنفسهم في تخصصهم في هندسة البرمجيات ، وهذا ما يسبب المشاكل بالفعل. الكبرياء هو مصيدة لمن ليس لديهم حذر ؛ فقد دفع العديد من موظفي Google إلى الاعتقاد بأن قراراتهم صحيحة دائمًا وأن كونك على صواب (من خلال تعريف غامض وغامض) أكثر أهمية من خدمة العملاء.
فيما يلي بعض الأمثلة التعسفية من مشاريع كبيرة أخرى خارج Google ، ولكن أتمنى أن ترى هذا النمط في كل مكان. هذا هو: التوافق مع الإصدارات السابقة يبقي الأنظمة على قيد الحياة ومحدثة لعقود .
التوافق مع الإصدارات السابقة هو هدف التصميم لجميع الأنظمة الناجحة المصممة لالاستخدام المفتوح ، أي يتم تنفيذه بمصدر مفتوح و / أو معايير مفتوحة. أشعر أنني أقول شيئًا واضحًا جدًا لدرجة أن الجميع غير مرتاحين ، لكن لا. هذه قضية سياسية ، لذا هناك حاجة إلى أمثلة.
النظام الأول الذي أختاره هو الأقدم: GNU Emacs ، وهو نوع من الهجين بين Windows Notepad ، و OS kernel ، ومحطة الفضاء الدولية. من الصعب بعض الشيء شرح ذلك ، ولكن باختصار ، Emacs عبارة عن نظام أساسي تم إنشاؤه في عام 1976 (نعم ، منذ نصف قرن تقريبًا) للبرمجة لزيادة إنتاجيتك ، ولكنه يتنكر كمحرر نصوص.
أستخدم إيماكس كل يوم. نعم ، أنا أستخدم IntelliJ أيضًا كل يوم ، فقد أصبح بحد ذاته منصة أدوات قوية. لكن كتابة ملحقات IntelliJ أكثر طموحًا وصعوبة من كتابة ملحقات Emacs. والأهم من ذلك ، أن كل شيء مكتوب لـ Emacs سوف يستمر إلى الأبد .
ما زلت أستخدم البرامج التي كتبتها لـ Emacs في عام 1995. وأنا متأكد من أن شخصًا ما يستخدم وحدات مكتوبة لـ Emacs في منتصف الثمانينيات ، إن لم يكن قبل ذلك. قد تتطلب تعديلات طفيفة من وقت لآخر ، لكن هذا نادر جدًا حقًا. لا أعرف أي شيء كتبته من قبل لـ Emacs (وقد كتبت كثيرًا) والذي يجب أن يعيد تصميم الهندسة المعمارية.
إيماكس لديه وظيفة تسمى تكوين عفا عليها الزمن للكيانات القديمة. غالبًا ما تختلف مصطلحات Emacs لمفاهيم الكمبيوتر الأساسية (مثل ما هي "النافذة") عن اتفاقيات الصناعة لأن Emacs قدمها منذ وقت طويل. هذا خطر نموذجي لمن هم قبل وقتهم: كل شروطك غير صحيحة. لكن لدى Emacs مفهوم التقادم ، والذي يُطلق عليه في مصطلحاتهم التقادم .
ولكن في عالم Emacs يبدو أن هناك تعريفًا عمليًا مختلفًا. فلسفة أساسية أخرى ، إذا صح التعبير.
في عالم Emacs (وفي العديد من المجالات الأخرى التي سنغطيها أدناه) ، تعني حالة إهمال واجهات برمجة التطبيقات بشكل أساسي ، "يجب ألا تستخدم هذا النهج حقًا ، لأنه بينما يعمل ، فإنه يعاني من عيوب مختلفة سنقوم بإدراجها هنا. لكن في النهاية ، هذا هو اختيارك ".
في عالم Google ، تعني حالة المنتج القديم "أننا انتهكنا التزامنا تجاهك". هو حقا. هذا ما تعنيه في الأساس. هذا يعني أنهم سوف يجبرك على القيام ببعض الأعمال بشكل منتظم ، وربما الكثير من العمل ، كعقاب على الإيمان بإعلانهم الملون : لدينا أفضل البرامج. الأسرع! أنت تفعل كل شيء وفقًا للتعليمات ، وتطلق تطبيقك أو خدمتك ، ثم بام ، بعد عام أو عامين من تعطلها.
إنه مثل بيع سيارة مستعملة ستتعطل بالتأكيد بعد 1500 كيلومتر.
هذان تعريفان فلسفيان مختلفان تمامًا لمصطلح "التقادم". رائحة تعريف Google تشبه رائحة التقادم المخطط لها . لا أعتقد أنه كذلك حقًاالتقادم المخطط له بنفس معنى Apple. لكن Google تخطط بالتأكيد لكسر برامجك بطريقة ملتوية. أعرف هذا لأنني عملت هناك كمهندس برمجيات لأكثر من 12 عامًا. لديهم إرشادات داخلية غامضة حول مقدار التوافق مع الإصدارات السابقة ، ولكن في النهاية يعتمد الأمر على كل فريق أو خدمة فردية. لا توجد توصية خاصة بالشركات أو الدرجة الهندسية ، والتوصية الأكثر جرأة من حيث دورات التقادم هي "محاولة منح العملاء 6-12 شهرًا للترقية قبل كسر النظام بأكمله".
المشكلة أكثر خطورة مما يعتقدون ، وستستمر لسنوات قادمة لأن خدمة العملاء ليست في حمضهم النووي. المزيد عن هذا أدناه.
في الوقت الحالي ، سأقوم بتأكيد جريء أن Emacs ناجح إلى حد كبير ، وحتى في الغالب ، لأنهم يأخذون التوافق مع الإصدارات السابقة على محمل الجد. في الواقع ، هذه هي أطروحة مقالتنا. تدين أنظمة المصدر المفتوح الناجحة طويلة العمر بنجاحها للمجتمعات الصغيرة التي عاشت حول الامتدادات / المكونات الإضافية لعقود . هذا هو النظام البيئي. لقد تحدثت بالفعل عن جوهر الأنظمة الأساسية ومدى أهميتها ، وكيف لم تفهم Google أبدًا ، في تاريخ الشركة بأكمله ، ما الذي يدخل في إنشاء نظام أساسي مفتوح ناجح ، باستثناء Android أو Chrome.
في الواقع ، يجب أن أذكر Android باختصار ، لأنك ربما فكرت في الأمر.
أولاً ، Android ليس Google... يكاد لا علاقة لهم ببعضهم البعض. Android هي شركة تم شراؤها من قبل Google في يوليو 2005 ، وقد سُمح لهذه الشركة بالعمل بشكل مستقل إلى حد ما ، وفي الواقع ظلت كما هي إلى حد كبير على مر السنين. Android عبارة عن مكدس تقني سيئ السمعة ومنظمة شائكة بنفس القدر. كما قال أحد موظفي Google ، "لا يمكنك الدخول إلى Android فقط."
في منشور سابق ، ناقشت مدى سوء بعض تصميمات Android المبكرة. هيك ، عندما كتبت هذا المقال ، كانوا ينشرون هراءًا يسمى "التطبيقات الفورية" والتي أصبحت الآن (مفاجأة!) مهملةوتعاطف إذا كنت غبيًا بما يكفي للاستماع إلى Google وجلب المحتوى الخاص بك إلى هذه التطبيقات الفورية.
ولكن هناك فرق ، فرق كبير ، وهو أن مستخدمي Android يفهمون حقًا مدى أهمية الأنظمة الأساسية ، فهم يبذلون قصارى جهدهم للحفاظ على عمل تطبيقات Android القديمة. في الواقع ، جهودهم للحفاظ على التوافق مع الإصدارات السابقة شديدة للغاية لدرجة أنني ، خلال فترة عملي القصيرة في قسم Android قبل بضع سنوات ، وجدت نفسي أحاول إقناعهم بإسقاط الدعم لبعض أقدم الأجهزة وواجهات برمجة التطبيقات (كنت مخطئًا ، كما كان أشياء أخرى كثيرة في الماضي والحاضر. آسف يا شباب Android! الآن بعد أن زرت إندونيسيا ، أفهم سبب حاجتنا إليها).
يحافظ الأشخاص الذين يعملون بنظام Android على التوافق مع الإصدارات السابقة مع التطرف الذي لا يمكن تصوره تقريبًا ، مما يؤدي إلى تراكم قدر كبير من الديون التقنية القديمة في أنظمتهم وسلاسل أدواتهم. يا إلهي ، كان يجب أن ترى بعض الأشياء المجنونة التي يتعين عليهم القيام بها في نظام البناء الخاص بهم ، كل ذلك باسم التوافق.
لهذا ، أمنح Android جائزة You Are Not Google المرغوبة. إنهم لا يريدون حقًا أن يصبحوا Google ، الذين لا يعرفون كيفية إنشاء منصات تدوم ، لكن Android يعرف كيف يفعل ذلك. وبالتالي ، فإن Google حكيمة جدًا من ناحية واحدة: فهي تتيح للأشخاص على Android القيام بالأشياء بطريقتهم الخاصة.
ومع ذلك ، كانت تطبيقات Android الفورية فكرة غبية جدًا. هل تعرف لماذا؟ لأنهم طالبواأعد كتابة وتصميم التطبيق الخاص بك ! كما لو أن الناس سيأخذون ويعيدون كتابة مليوني تطبيق. أعتقد أن التطبيقات الفورية كانت فكرة بعض موظفي Google.
لكن هناك فرق هنا. التوافق مع الإصدارات السابقة باهظ الثمن. يتحمل Android نفسه عبء هذه التكاليف ، بينما تصر Google على أن تتحمل أنت ، العميل المدفوع ، العبء .
يمكنك أن ترى التزام Android بالتوافق مع الإصدارات السابقة في واجهات برمجة التطبيقات الخاصة به. عندما يكون لديك أربعة أو خمسة أنظمة فرعية مختلفة للقيام بنفس الشيء حرفيًا ، فهذه علامة أكيدة على أن الالتزام بالتوافق مع الإصدارات السابقة هو جوهر الأمر. وهو في عالم المنصة مرادف للالتزام بعملائك وسوقك.
تتمثل مشكلة Google الرئيسية هنا في اعتزازهم بنظافتهم الهندسية. إنهم لا يحبون ذلك عندما يكون هناك العديد من الطرق المختلفة لفعل الشيء نفسه ، بطرق أقدم وأقل استحسانًا تجلس بجانب طرق أحدث وأكثر غرابة. إنه يزيد من منحنى التعلم للقادمين الجدد إلى النظام ، ويزيد من عبء الحفاظ على واجهات برمجة التطبيقات القديمة ، ويبطئ سرعة الميزات الجديدة ، والخطيئة الرئيسية قبيحة. Google - مثل ليدي أسكوت من فيلم "أليس في بلاد العجائب" بقلم تيم بيرتون:
ليدي أسكوت:
- أليس ، هل تعرف أكثر ما أخاف منه؟
- تراجع الطبقة الأرستقراطية؟
- كنت أخشى أن يكون لي أحفاد قبيحون .
لفهم المفاضلة بين الجميل والعملي ، دعنا نلقي نظرة على النظام الأساسي الثالث الناجح (بعد Emacs و Android) ونرى كيف يعمل: Java نفسها.
تحتوي Java على الكثير من واجهات برمجة التطبيقات القديمة. يحظى الاستنكار بشعبية كبيرة لدى مبرمجي Java ، بل إنه أكثر شيوعًا من معظم لغات البرمجة. في Java نفسها ، اللغة والمكتبات الرئيسية ، تحدث إهمال واجهة برمجة التطبيقات باستمرار.
إذا أخذت مثالاً واحداً فقط من آلاف الأمثلة ، فسيتم إهمال إغلاق التدفقات . لقد تم إهماله منذ إصدار Java 1.2 في ديسمبر 1998. لقد مرت 22 عامًا منذ أن تم إهمال هذا.
لكن كود الإنتاج الحقيقي الخاص بي لا يزال يقتل الخيوط كل يوم... هل هذا جيد؟ إطلاقا! أعني ، بالطبع ، إذا كنت سأعيد كتابة الكود اليوم ، فسأقوم بتطبيقه بشكل مختلف. لكن رمز لعبتي ، الذي جعل مئات الآلاف من الناس سعداء على مدى العقدين الماضيين ، مكتوب بوظيفة لإغلاق الخيوط التي تتدلى لفترة طويلة جدًا ، ولم أضطر أبدًا إلى تغييرها . أعرف نظامي أفضل من أي شخص آخر ، لديّ 25 عامًا من الخبرة في العمل معه في الإنتاج ، ويمكنني أن أقول على وجه اليقين: في حالتي ، فإن إغلاق مسارات العمل المحددة هذه غير ضار تمامًا . يجب ألا تضيع الوقت والجهد في إعادة كتابة هذا الرمز ، والثناء على لاري إليسون (ربما) أن Oracle لم تجبرني على إعادة كتابته.
من المحتمل أن تكون Oracle على دراية بالنظام الأساسي أيضًا. من تعرف.
يمكن العثور على أدلة لجميع واجهات برمجة تطبيقات Java الأساسية المليئة بموجات التقادم ، مثل خطوط نهر جليدي في واد. يمكنك بسهولة العثور على خمسة أو ستة مديرين مختلفين للتنقل باستخدام لوحة المفاتيح (KeyboardFocusManager) في مكتبة Java Swing. من الصعب في الواقع العثور على واجهة برمجة تطبيقات Java لم يتم إهمالها. لكنهم ما زالوا يعملون! أعتقد أن فريق Java سيقوم بالفعل بإزالة واجهة برمجة التطبيقات فقط إذا تسببت الواجهة في مشكلة أمنية فادحة.
هذا هو الشيء أيها الرجال: نحن مطورو البرامج جميعًا مشغولون جدًا ، وفي كل مجال من مجالات البرامج نواجه بدائل منافسة. في أي وقت ، يرى مبرمجو X أن Y كبديل محتمل. اوه الا تصدقني هل تريد أن تُدعى سويفت؟ مثل ، يهاجر الجميع إلى Swift ولا يتخلى عنها أحد ، أليس كذلك؟ واو ، كم تعرف القليل. تحسب الشركات تكاليف فرق تطوير الأجهزة المحمولة المزدوجة (iOS و Android) - وقد بدأوا في إدراك أن أنظمة التطوير عبر الأنظمة الأساسية المضحكة مثل Flutter و React Native تعمل ويمكن أن تقلل من حجم فرقهم المتنقلة. مرتين أو ، على العكس ، اجعلها أكثر إنتاجية بمرتين. المال الحقيقي على المحك. نعم ، هناك تنازلات ، ولكن من ناحية أخرى ، إزالة النقود الإلكترونية.
لنفترض ، من الناحية النظرية ، أن شركة Apple أخذت مثال Guido van Rossum بحماقة وأعلنت أن Swift 6.0 غير متوافق مع Swift 5.0 ، تمامًا مثل Python 3 غير متوافق مع Python 2.
ربما رويت هذه القصة منذ عشر سنوات ، ولكن قبل خمسة عشر عامًا. ذهب إلى O'Reilly's Foo Camp مع Guido ، وجلس في خيمة مع Paul Graham ومجموعة من المطبات الكبيرة. جلسنا في الحر الشديد وانتظرنا إقلاع لاري بيدج بطائرته المروحية الشخصية ، بينما غمس جيدو بشكل رتيب عن Python 3000 ، والذي سماه على اسم عدد السنوات التي سيستغرقها الجميع للهجرة إلى هناك. سألناه طوال الوقت عن سبب تعطله ، فأجاب: "Unicode". وسألنا ، إذا كان علينا إعادة كتابة الكود الخاص بنا ، فما الفوائد الأخرى التي سنراها؟ وأجاب: "يوووووووووووووووونييييووووود"
إذا قمت بتثبيت Google Cloud Platform SDK ("gcloud") ، فستتلقى الإشعار التالي:
عزيزي المستلم ،
نود أن نذكرك بأن دعم Python 2 قد تم إيقافه ، فهل أنت كذلك؟
... إلخ. دورة الحياة.
لكن النقطة المهمة هي أن كل مطور لديه خيار. وإذا جعلتهم يعيدون كتابة الكود كثيرًا ، فقد يفكرون في خيارات أخرى . إنهم ليسوا رهائن لك ، مهما كنت تريدهم أن يكونوا. هم ضيوفك. لا تزال Python لغة برمجة شائعة جدًا ، ولكن هيك ، خلقت Python 3 (000) مثل هذه الفوضى من تلقاء نفسها ، في مجتمعاتها ، وبين مستخدمي مجتمعاتها بحيث لم يتم توضيح العواقب لمدة خمسة عشر عامًا.
كم عدد برامج Python التي تمت إعادة كتابتها في Go (أو Ruby ، أو أي بديل آخر) بسبب عدم التوافق هذا؟ مقدار البرامج الجديدة التي تمت كتابتها في شيء آخر غير Python ، على الرغم من أنها قد تكون كذلكمكتوبًا بلغة Python ، إذا لم يحرق Guido القرية بأكملها؟ من الصعب القول ، لكن من الواضح أن بايثون عانت. هذه فوضى كبيرة والجميع خاسر.
لنفترض أن Apple تتبع مثال Guido وتكسر التوافق. ماذا تعتقد سوف يحدث بعد ذلك؟ حسنًا ، ربما يقوم 80-90٪ من المطورين بإعادة كتابة برامجهم إذا استطاعوا. بمعنى آخر ، ينتقل 10-20٪ من قاعدة المستخدمين تلقائيًا إلى بعض اللغات المنافسة مثل Flutter.
قم بذلك عدة مرات وستفقد نصف قاعدة المستخدمين الخاصة بك. كما هو الحال في الرياضة ، في عالم البرمجة ، الشكل الحالي يعني أيضًا كل شيء.... أي شخص يفقد نصف مستخدميه في غضون خمس سنوات سيعتبر خاسرًا كبيرًا للدهون. يجب أن تكون رائجًا في عالم النظام الأساسي. ولكن هذا هو المكان الذي سيؤدي فيه التخلي عن دعم الإصدارات الأقدم إلى قتلك بمرور الوقت. لأنه في كل مرة تتخلص فيها من جزء من المطورين ، فإنك (أ) تخسرهم إلى الأبد ، لأنهم غاضبون منك لكسر العقد ، و (ب) منحهم لمنافسيك.
ومن المفارقات ، أنني أيضًا ، ساعدت في تحويل Google إلى نوع من بريما دونا المتوافق مع الإصدارات السابقة عندما أنشأت Grok ، وهو نظام لتحليل وفهم الكود المصدري يسهل الأتمتة والأدوات القائمة على الكود - على غرار IDE ، ولكن هنا تجسدت مخازن الخدمات السحابية تمثيلات لمليارات الأسطر من شفرة مصدر Google في مستودع بيانات كبير.
زود Grok موظفي Google بإطار عمل قوي لإعادة البناء الآلي عبر قاعدة الكود بأكملها (حرفياً في جميع أنحاء Google). لا يحسب النظام تبعيات المنبع (التي تعتمد عليها) فحسب ، بل يحسب أيضًا التبعيات النهائية (التي تعتمد عليك) ، لذلك عندما تقوم بتغيير واجهة برمجة التطبيقات ، فأنت تعرف كل من تفككه! بهذه الطريقة ، عند إجراء تغييرات ، يمكنك التحقق من تحديث كل مستهلك لواجهة برمجة التطبيقات الخاصة بك إلى الإصدار الجديد ، وفي الواقع ، غالبًا باستخدام أداة Rosie التي كتبوها ، يمكنك أتمتة العملية بالكامل.
يسمح هذا لقاعدة بيانات Google بأن تكون "نظيفة" بشكل خارق للطبيعة تقريبًا ، حيث يتجول هؤلاء الخدم الآليون في أرجاء المنزل وينظفون كل شيء تلقائيًا إذا أعادوا تسمية SomeDespicablyLongFunctionName إلى SomeDespicablyLongMethodName ، لأن شخصًا ما اعتقد أنه كان حفيدًا قبيحًا ، تحتاج إلى النوم.
ولكي نكون صادقين ، فهو يعمل بشكل جيد مع Google ... داخليًا. أعني ، نعم ، يتمتع مجتمع Go في Google بالضحك حقًا على مجتمع Java في Google بسبب عادتهم في إعادة البناء المستمر. إعادة تشغيل شيء N مرات يعني أنك لم تفسد الأمر N-1 مرات فحسب ، ولكن بعد فترة يتضح تمامًا أنك ربما أفسدت الأمر في المحاولة N. ولكن بشكل عام ، يظلون فوق العناء ويحافظون على "نظيف" الشفرة.
تبدأ المشاكل عندما يحاولون فرض هذا الموقف على عملاء السحابة ومستخدمي واجهات برمجة التطبيقات الأخرى.
لقد عرّفتك على Emacs و Android و Java قليلاً ؛ دعونا نلقي نظرة على أحدث منصة طويلة الأمد ناجحة: الويب نفسه. يمكنك تخيل عدد التكرارات التي مر بها HTTP منذ عام 1995 ، عندما استخدمنا علامات <blink> الوامضة ورموز قيد الإنشاء على صفحات الويب.
لكنها ما زالت تعمل! وما زالت هذه الصفحات تعمل! نعم يا رفاق ، المتصفحات هي أبطال التوافق مع الإصدارات السابقة في العالم. يعد Chrome مثالًا آخر لمنصة Google النادرة التي تم تثبيت رؤوسها بشكل صحيح ، وتوقعت أن Chrome يعمل بشكل فعال كشركة معزولة منفصلة عن بقية Google.
أود أيضًا أن أشكر أصدقائنا من بين مطوري أنظمة التشغيل: Windows و Linux و NOT APPLE FOLLOW YOU APPLE و FreeBSD وما إلى ذلك ، للقيام بمثل هذا العمل الرائع للتوافق مع الإصدارات السابقة على منصاتهم الناجحة (تحصل Apple في أفضل الأحوال على ثلاثة أضعاف ناقصًا ، نظرًا لأنهم يكسرون كل شيء باستمرار دون سبب وجيه ، ولكن بطريقة ما يتعامل المجتمع مع هذا في كل إصدار ، وحتى الآن لم تعد حاويات OS X قديمة تمامًا ...
لكن انتظر كما تقول. ألا نقارن التفاح بالبرتقال - أنظمة برمجية مستقلة على جهاز واحد مثل Emacs / JDK / Android / Chrome ، مع أنظمة متعددة الخوادم وواجهات برمجة التطبيقات مثل الخدمات السحابية؟
حسنًا ، لقد قمت بالتغريد حول هذا الموضوع بالأمس ، ولكن في أسلوب Larry Wall للامتصاص / القاعدة ، بحثت عن كلمة مهملة على مواقع مطوري Google و Amazon. على الرغم من أن AWS لديها عروض خدمة أكثر بمئات المرات من عروض GCP ، فإن وثائق مطور Google تشير إلى الإهمال بحوالي سبع مرات أكثر.
إذا قرأ شخص ما من Google هذا ، فمن المحتمل أن يكون مستعدًا لسحب الرسوم البيانية التي توضح أسلوب دونالد ترامب أنهم في الواقع يفعلون كل شيء بشكل صحيح ، وأنه لا ينبغي لي إجراء مقارنات غير عادلة ، مثل "عدد الإشارات إلى الكلمة المهملة اعتمادًا على عدد الخدمات ".
ولكن بعد سنوات عديدة، جوجل الغيمة لا يزال # 3 (لم أكن كتبت مقالا عن محاولة فاشلة لتصبح رقم 2)، ولكن إذا كنت تعتقد أن المطلعين، هناك بعض المخاوف التي قد تسقط قريبا # 4.
ليس لدي مقنعة الحجج "لإثبات" أطروحتك. كل ما لدي هو أمثلة ملونة تراكمت لدي على مدار 30 عامًا كمطور. لقد أشرت بالفعل إلى الطبيعة الفلسفية العميقة لهذه المشكلة. بمعنى أنها مسيسة في مجتمعات المطورين. يعتقد بعض الناس أن منشئي النظام الأساسي يجب أن يهتموا بالتوافق ، بينما يعتقد البعض الآخر أن هذا هو مصدر قلق المستخدمين.(المطورين أنفسهم). واحد من اثنين. في الواقع ، أليست قضية سياسية عندما نقرر من يتحمل تكاليف المشاكل المشتركة؟
إذن هذه هي السياسة. وستكون هناك بالتأكيد ردود فعل غاضبة على خطابي.
بصفتي مستخدمًا لمنصة Google السحابية ، وكمستخدم AWS لمدة عامين (في Grab) ، يمكنني القول أن هناك فرقًا كبيرًا بين فلسفات Amazon و Google عندما يتعلق الأمر بالأولويات. لا أعمل بنشاط على تطوير AWS ، لذلك لا أعرف جيدًا عدد المرات التي يقومون فيها بإزالة واجهات برمجة التطبيقات القديمة. ولكن هناك شك في أن هذا لا يحدث كثيرًا كما هو الحال في Google. وأعتقد حقًا أن مصدر الجدل والإحباط المستمر في برنامج "شركاء Google المعتمدون" هو أحد أكبر القيود على تطوير النظام الأساسي.
أعلم أنني لم أقم بتسمية أمثلة محددة لأنظمة GCP التي لم تعد مدعومة. أستطيع أن أقول إن كل شيء استخدمته عمليًا ، من الشبكات (من الأقدم إلى VPC) إلى التخزين (Cloud SQL v1-v2) ، Firebase (الآن Firestore مع واجهة برمجة تطبيقات مختلفة تمامًا) ، App Engine (لنبدأ حتى) ، نقاط النهاية السحابية وما قبلها ... لا أعرف - تمامًا كل هذه إعادة الكتابة القسرية للشفرة في مدة أقصاها 2-3 سنوات ، ولم تتم عملية الترحيل لك مطلقًا ، وغالبًا لم يكن هناك مسار ترحيل موثق على الإطلاق . كما لو كان يجب أن يكون.
وفي كل مرة ألقي فيها نظرة على AWS ، أسأل نفسي لماذا بحق الجحيم ما زلت جالسًا في GCP. من الواضح أنهم لا يحتاجون إلى عملاء. يريدون مشترين . هل تفهم الإختلاف؟ دعني أوضح.
يحتوي Google Cloud على سوق يقدم فيه الأشخاص حلول برمجية ، ولتجنب تأثير مطعم فارغ ، كان عليهم ملؤه ببعض الاقتراحات ، لذلك تعاقدوا مع Bitnami لإنشاء مجموعة من الحلول التي يتم نشرها "بنقرة واحدة" ، أو يجب أن أكتب "الحلول" بنفسي ، لأنها لا تحل شيئًا لعينًا. إنها موجودة فقط كأعلام ، وكمادة حشو للتسويق ، ولم تهتم Google أبدًا بما إذا كانت أي من الأدوات تعمل بالفعل. أعرف مديري المنتجات الذين قادوا ، ويمكنني أن أؤكد لكم أن هؤلاء الناس لا يهتمون.
خذ على سبيل المثال ، حل النشر "بنقرة واحدة" Percona... لقد شعرت بالملل حتى الموت بسبب تصرفات Google Cloud SQL الغريبة ، لذلك بدأت في التفكير في إنشاء مجموعة Percona الخاصة بي كبديل. وهذه المرة بدا أن Google تقوم بعمل جيد ، لقد كانوا سيوفرون لي بعض الوقت والجهد بنقرة زر واحدة!
حسنًا ، رائع ، دعنا نذهب. دعنا نتبع الرابط ونضغط على هذا الزر. حدد "نعم" للموافقة على جميع الإعدادات الافتراضية ونشر المجموعة في مشروع Google cloud الخاص بك. هاها ، لا يعمل. لا شيء من هذا الهراء يعمل. لم يتم اختبار الأداة وبدأت تتعفن من الدقيقة الأولى، وأنه لن يفاجئني إذا كان أكثر من نصف "الحلول" لبنقرة واحدة نشر (ونحن الآن نفهم لماذا الاقتباس) القيام لا تعمل على الإطلاق. هذا ظلام ميؤوس منه تمامًا ، حيث من الأفضل عدم الدخول.
لكن Google تشجعك صراحة على استخدامها. يريدونك أن تشتريهم . بالنسبة لهم ، إنها صفقة. لا يريدون دعم أي شيء . إنه ليس جزءًا من حمض Google. نعم ، يدعم المهندسون بعضهم البعض ، كما يتضح من قصتي مع Bigtable. لكن في المنتجات والخدمات للأشخاص العاديين ، كانوا دائمًا لا يرحمون في إغلاق أي خدمة لا ترقى إلى مستوى الربحية ، حتى لو كان لديها ملايين المستخدمين.
وهذا يمثل تحديًا حقيقيًا لـ GCP ، لأن هذا الحمض النووي وراء كل عروض السحابة. إنهم لا يسعون إلى دعم أي شيء. من المعروف أنهم يرفضون استضافة (كخدمة مدارة) أي برنامج تابع لجهة خارجيةطالما أن AWS لا تفعل الشيء نفسه ولن تبني نشاطًا تجاريًا ناجحًا حوله ، وعندما يطلب العملاء الشيء نفسه. ومع ذلك ، يتطلب الأمر بعض الجهد لجعل Google تدعم شيئًا ما.
هذا النقص في ثقافة الدعم ، إلى جانب مبدأ "دعونا نكسرها لنجعلها جميلة" ، يبعد المطورين عنهم.
وهذا ليس جيدًا إذا كنت ترغب في بناء منصة طويلة العمر.
جوجل استيقظ ، اللعنة. إنه عام 2020 الآن. أنت لا تزال تخسر. حان الوقت لإلقاء نظرة فاحصة في المرآة والإجابة عما إذا كنت تريد حقًا البقاء في الأعمال السحابية.
إذا كنت تريد البقاء ثم توقف عن كسر كل شيء... أنتم يا رفاق أغنياء. نحن المطورين ليسوا كذلك. لذلك عندما يتعلق الأمر بمن سيتحمل عبء التوافق ، فأنت بحاجة إلى تحمل ذلك على عاتقك. ليس لنا.
لأن هناك ما لا يقل عن ثلاث غيوم جيدة حقًا. يلومونهم.
والآن سأستمر في إصلاح جميع أنظمتي المعطلة. إيه.
حتى المرة القادمة!
تحديث PS بعد قراءة بعض المناقشات في هذه المقالة (المناقشات رائعة بالمناسبة). لم يتم إيقاف Firebase ولا توجد خطط أعلم بها. ومع ذلك ، فإن لديهم خطأ دفقًا سيئًا يتسبب في توقف عميل Java في App Engine. ساعدني أحد المهندسين في حل هذه المشكلة عندما كنت أعمل في Google, , , GAE. ! Firestore. , , , Firebase . ? , . , , Firebase GAE, 100 100% , - . , . Redis.
, AWS , AWS , SimpleDB — . , AWS , Google, , .
, , 20 Google App Engine Go, GAE Go. , .
, , ( , !). , , Google . , , AWS, Grab. - , !
, 2005 43, . 2006 . Bigtable 2007 .
Bigtable (-), . , , , , , .
, Apple Microsoft . . , , ! , , ?
.
2, 19.08.2020. Stripe API!
التحديث 3 ، 08/31/2020. اتصل بي مهندس Google في Cloud Marketplace الذي اتضح أنه صديق قديم لي. لقد أراد معرفة سبب عدم عمل C2D ، وفي النهاية اكتشفنا: السبب هو أنني أنشأت شبكتي قبل بضع سنوات ، ولا تعمل C2D على الشبكات القديمة بسبب معلمة الشبكة الفرعية المفقودة في قوالبها. أعتقد أن مستخدمي GCP المحتملين أفضل حالًا للتأكد من أن لديهم ما يكفي من المهندسين المألوفين في Google ...