اللعنة يا جوجل، لم أرغب في التدوين مرة أخرى. لدي الكثير للقيام به. يستغرق التدوين وقتًا وطاقة وإبداعًا، وهو ما يمكنني استغلاله بشكل جيد: كتبي، ولعبتي وما إلى ذلك. لكنك أغضبتني بما فيه الكفاية لدرجة أنني اضطررت إلى كتابة هذا.
لذلك دعونا ننتهي من هذا.
اسمحوا لي أن أبدأ بقصة قصيرة ولكن مفيدة منذ أن بدأت العمل في Google لأول مرة. أعلم أنني كنت أقول الكثير من الأشياء السيئة عن Google مؤخرًا، ولكن ما يزعجني هو أن تتخذ شركتي بانتظام قرارات تجارية غير كفؤة. وفي الوقت نفسه، يتعين علينا أن نعطيها حقها: فالبنية الأساسية الداخلية لشركة Google غير عادية حقا، ومن الآمن أن نقول إنه لا يوجد شيء أفضل اليوم. لقد كان مؤسسو جوجل مهندسين أفضل بكثير مني في أي وقت مضى، وهذه القصة تؤكد هذه الحقيقة.
أولاً، خلفية بسيطة: لدى Google تقنية لتخزين البيانات تسمى . لقد كان إنجازًا تقنيًا رائعًا، وهو أحد أول (إن لم يكن الأول) مخزن القيمة الرئيسية (K/V) "القابل للتطوير بشكل لا نهائي": بداية NoSQL. في هذه الأيام، لا يزال أداء Bigtable جيدًا في مساحة تخزين K/V المزدحمة إلى حد ما، ولكن في ذلك الوقت (2005) كان الأمر رائعًا بشكل مذهل.
أحد الأشياء المضحكة في Bigtable هو أن لديهم كائنات مستوى التحكم الداخلي (كجزء من التنفيذ) تسمى خوادم الأجهزة اللوحية، مع فهارس كبيرة، وفي مرحلة ما أصبحت عنق الزجاجة عند توسيع نطاق النظام. كان مهندسو Bigtable في حيرة من أمرهم بشأن كيفية تنفيذ قابلية التوسع، وأدركوا فجأة أنه يمكنهم استبدال خوادم الأجهزة اللوحية بوحدات تخزين Bigtable أخرى. لذا فإن Bigtable جزء من تطبيق Bigtable. مرافق التخزين هذه موجودة على جميع المستويات.
هناك تفصيل آخر مثير للاهتمام وهو أن Bigtable أصبح لفترة من الوقت مشهورًا ومنتشرًا في كل مكان داخل Google، حيث كان لكل فريق مستودعه الخاص. لذا، في أحد اجتماعات يوم الجمعة، سأل لاري بيج عرضًا: "لماذا لدينا أكثر من طاولة كبيرة واحدة؟ لماذا لا يكون واحدا فقط؟ من الناحية النظرية، يجب أن تكون مساحة التخزين الواحدة كافية لجميع احتياجات التخزين لدى Google. وبطبيعة الحال، لم يذهبوا إلى واحدة فقط لأسباب تتعلق بالتنمية العملية (مثل عواقب الفشل المحتمل)، ولكن النظرية كانت مثيرة للاهتمام. مستودع واحد للكون بأكمله (بالمناسبة، هل يعرف أحد ما إذا كانت أمازون فعلت هذا مع السمور الخاص بها؟)
على أية حال، ها هي قصتي.
في ذلك الوقت، كنت أعمل في Google لمدة تزيد قليلاً عن عامين، وفي أحد الأيام تلقيت رسالة بريد إلكتروني من الفريق الهندسي في Bigtable تقول شيئًا من هذا القبيل:
عزيزي ستيف،
مرحبًا من فريق Bigtable. نود أن نعلمك أنك في [اسم مركز البيانات] تستخدم ملفًا ثنائيًا قديمًا جدًا من Bigtable. لم يعد هذا الإصدار مدعومًا ونريد مساعدتك في الترقية إلى الإصدار الأحدث.
يرجى إعلامي إذا كان بإمكانك تحديد بعض الوقت للعمل معًا بشأن هذه المشكلة.
أتمنى لك كل خير،
فريق بيج تابل
تتلقى الكثير من رسائل البريد على Google، لذا قرأت للوهلة الأولى شيئًا كهذا:
عزيزي المتلقي،
مرحبا من بعض الفريق. نريد أن ننقل ذلك بلاه بلاه بلاه بلاه. بلاه بلاه بلاه بلاه بلاه، بلاه بلاه بلاه على الفور.
يرجى إعلامنا إذا كان بإمكانك جدولة بعض وقتك الثمين بلاه بلاه.
أتمنى لك كل خير،
نوع من الأوامر
كدت أن أحذفها على الفور، لكن على حافة وعيي شعرت بإحساس مؤلم ومزعج بوجودها ليس حقا يبدو وكأنه خطاب رسمي بالرغم من ذلك بوضوحأن المستلم كان مخطئًا لأنني لم أستخدم Bigtable.
ولكن كان غريبا.
قضيت بقية اليوم أفكر في العمل ونوع لحم القرش الذي يجب تجربته في المطبخ الصغير، والذي كان ثلاثة منه على الأقل قريبين بما يكفي لرمي قطعة بسكويت من مقعدي، ولكن لم تتركني فكرة الكتابة أبدًا مع شعور متزايد بالقلق الخفيف.
قالوا اسمي بوضوح. وتم إرسال البريد الإلكتروني إلى عنوان بريدي الإلكتروني، وليس إلى عنوان شخص آخر، وهو ليس نسخة إلى: أو نسخة مخفية الوجهة:. النغمة شخصية وواضحة للغاية. ربما هذا هو نوع من الخطأ؟
أخيرًا، تغلب علي الفضول وذهبت لإلقاء نظرة على وحدة تحكم Borg في مركز البيانات الذي ذكروه.
وبالطبع، كان لديّ مساحة تخزين BigTable تحت الإدارة. أنا آسف، ماذا؟ نظرت إلى محتوياته، واو! لقد كان من حاضنة Codelab التي جلست فيها خلال الأسبوع الأول لي في Google في يونيو 2005. أجبرك Codelab على تشغيل Bigtable لكتابة بعض القيم هناك، ويبدو أنني لم أغلق وحدة التخزين بعد ذلك مطلقًا. وكان لا يزال يعمل على الرغم من مرور أكثر من عامين.
هناك عدة جوانب جديرة بالملاحظة لهذه القصة. أولاً، كان عمل Bigtable ضئيلًا جدًا على نطاق Google لدرجة أنه بعد عامين فقط لاحظ أي شخص وجود سعة تخزينية إضافية، وذلك فقط لأن إصدار الملف الثنائي كان قديمًا. للمقارنة، فكرت ذات مرة في استخدام للعبتي على الانترنت. في ذلك الوقت، كانت تكلفة هذه الخدمة حوالي 16 دولار سنويًا. فارغ Bigtable على Google Cloud Platform. أنا لا أقول أنهم يحتالون عليك، ولكن في رأيي الشخصي، هذا مبلغ كبير مقابل قاعدة بيانات فارغة.
جانب آخر جدير بالملاحظة هو أن التخزين لا يزال يعمل بعد عامين. ماهذا الهراء؟ مراكز البيانات تأتي وتذهب؛ فهي تعاني من انقطاع الخدمة، وتخضع لصيانة مجدولة، وتتغير طوال الوقت. يتم تحديث الأجهزة، وتبديل المفاتيح، ويتم تحسين كل شيء باستمرار. كيف بحق الجحيم تمكنوا من إبقاء برنامجي قيد التشغيل لمدة عامين مع كل هذه التغييرات؟ قد يبدو هذا إنجازًا متواضعًا في عام 2020، لكنه كان مثيرًا للإعجاب في الفترة 2005-2007.
والجانب الأكثر روعة هو أن فريقًا هندسيًا خارجيًا في ولاية أخرى يقترب مني، وأنا مالك بعض الأمثلة الصغيرة والفارغة تقريبًا من Bigtable، الذي لديه صفر حركة المرور على مدى العامين الماضيين - ونقدم المساعدة لتحديثه.
شكرتهم، وحذفت المخزن، واستمرت الحياة كالمعتاد. لكن بعد مرور ثلاثة عشر عامًا، ما زلت أفكر في تلك الرسالة. لأنني أحيانًا أتلقى رسائل بريد إلكتروني مماثلة من Google Cloud. تبدو مثل هذا:
عزيزي مستخدم Google Cloud،
للتذكير، سنوقف خدمة [الخدمة الأساسية التي تستخدمها] اعتبارًا من أغسطس 2020، وبعد ذلك لن تتمكن من ترقية مثيلاتك. نوصي بالترقية إلى الإصدار الأحدث، الذي هو في مرحلة الاختبار التجريبي، ولا يحتوي على وثائق، ولا يوجد مسار ترحيل، وقد أصبح قديمًا مسبقًا بفضل مساعدتنا الكريمة.
نحن ملتزمون بضمان أن يكون لهذا التغيير تأثير ضئيل على جميع مستخدمي نظام Google Cloud الأساسي.
افضل اصدقاء للابد،
منصة جوجل السحابية
لكنني لم أقرأ مثل هذه الرسائل أبدًا، لأن ما تقوله في الواقع هو:
عزيزي المتلقي،
اذهب إلى الجحيم. اللعنة عليك، اللعنة عليك، اللعنة عليك. أسقط كل ما تفعله لأنه لا يهم. ما يهم هو وقتنا. نحن نضيع الوقت والمال في الحفاظ على حماقتنا وقد سئمنا منها لذلك لن ندعمها بعد الآن. لذا، توقف عن خططك اللعينة وابدأ في البحث في وثائقنا السيئة، وتوسل للحصول على قصاصات من المنتديات، وبالمناسبة، يختلف هراءنا الجديد تمامًا عن القديم، لأننا أفسدنا هذا التصميم بشكل سيء للغاية، لكن هذا هو هدفك المشكلة، وليس لدينا.
نحن نواصل بذل الجهود لضمان أن جميع التطورات الخاصة بك تصبح غير قابلة للاستخدام في غضون عام واحد.
يرجى اللعنة
منصة جوجل السحابية
والحقيقة هي أنني أتلقى مثل هذه الرسائل مرة واحدة في الشهر تقريبًا. يحدث هذا كثيرًا وبشكل مستمر لدرجة أنهم لا محالة دفعه بعيدا من Google Cloud Platform إلى معسكر مكافحة السحابة. لم أعد أوافق على الاعتماد على تطورات الملكية الخاصة بهم، لأنه في الواقع من الأسهل على المطورين الحفاظ على نظام مفتوح المصدر على جهاز افتراضي مجرد بدلاً من محاولة مواكبة سياسة Google المتمثلة في إغلاق المنتجات "القديمة".
قبل أن أعود إلى Google Cloud لأنني أقرب بكثير ولم أنتهي من انتقادهم، فلننظر إلى أداء الشركة في بعض المجالات الأخرى. يفخر مهندسو Google بمجالهم في هندسة البرمجيات، وهذا ما يسبب المشاكل بالفعل. الكبرياء هو فخ لغير الحذرين، وقد دفع العديد من موظفي جوجل إلى الاعتقاد بأن قراراتهم صحيحة دائمًا وأن كونهم على حق (وفقًا لبعض التعريفات الغامضة) أكثر أهمية من الاهتمام بالعملاء.
سأقدم بعض الأمثلة العشوائية من مشاريع كبيرة أخرى خارج Google، ولكن أتمنى أن ترى هذا النمط في كل مكان. وهي كالاتي: يعمل التوافق مع الإصدارات السابقة على إبقاء الأنظمة حية ومحدثة لعقود من الزمن.
التوافق مع الإصدارات السابقة هو هدف التصميم لجميع الأنظمة الناجحة المصممة من أجله فتح الاستخدام، أي يتم تنفيذه باستخدام كود مفتوح المصدر و/أو معايير مفتوحة. أشعر وكأنني أقول شيئًا واضحًا جدًا لدرجة أن الجميع غير مرتاحين، لكن لا. هذه قضية سياسية، لذا نحتاج إلى أمثلة.
أول نظام سأختاره هو الأقدم: GNU Emacs، وهو نوع من الهجين بين Windows Notepad، ونواة نظام التشغيل، ومحطة الفضاء الدولية. من الصعب بعض الشيء شرح ذلك، ولكن باختصار، Emacs عبارة عن منصة تم إنشاؤها في عام 1976 (نعم، منذ ما يقرب من نصف قرن) للبرمجة لتجعلك أكثر إنتاجية، ولكنها تتنكر في هيئة محرر نصوص.
أستخدم إيماكس كل يوم. نعم، أنا أيضًا أستخدم IntelliJ كل يوم، لقد تطور ليصبح منصة أدوات قوية في حد ذاته. لكن كتابة الامتدادات لـ IntelliJ هي مهمة أكثر طموحًا وتعقيدًا من كتابة الامتدادات لـ Emacs. والأهم من ذلك، أن كل ما كتب لـ Emacs محفوظ أبدا.
ما زلت أستخدم البرنامج الذي كتبته لـ Emacs في عام 1995. وأنا متأكد من أن شخصًا ما يستخدم وحدات مكتوبة لـ Emacs في منتصف الثمانينات، إن لم يكن قبل ذلك. قد تتطلب بعض التغيير والتبديل من وقت لآخر، ولكن هذا نادر جدًا حقًا. لا أعرف أي شيء كتبته من قبل لـ Emacs (وقد كتبت الكثير) يتطلب إعادة التصميم.
يحتوي Emacs على وظيفة تسمى "make-Ossolete" للكيانات القديمة. غالبًا ما تختلف مصطلحات Emacs الخاصة بمفاهيم الكمبيوتر الأساسية (مثل تعريف "النافذة") عن اتفاقيات الصناعة لأن Emacs قدمتها منذ وقت طويل. وهذا خطر نموذجي بالنسبة لأولئك الذين سبقوا عصرهم: كل مصطلحاتك غير صحيحة. لكن لدى Emacs مفهوم الإهمال، وهو ما يطلق عليه في لغتهم تقادم.
ولكن في عالم Emacs يبدو أن هناك تعريفًا عمليًا مختلفًا. فلسفة أساسية مختلفة، إذا صح التعبير.
في عالم Emacs (وفي العديد من المجالات الأخرى، التي سنغطيها أدناه)، تعني حالة واجهة برمجة التطبيقات المهملة بشكل أساسي: "لا ينبغي عليك حقًا استخدام هذا الأسلوب، لأنه أثناء عمله، فإنه يعاني من العديد من أوجه القصور التي سنحاول حلها". قائمة هنا. ولكن في نهاية المطاف، هذا هو اختيارك."
في عالم جوجل، كوننا متقادمين يعني "أننا نخرق التزامنا تجاهك". هذا صحيح. وهذا هو ما يعنيه في الأساس. هذا يعني أنهم سوف يجبرونك بانتظام القيام ببعض الأعمال، وربما الكثير من العمل، كعقاب على الإيمان بها : لدينا أفضل البرامج. الأسرع! أنت تفعل كل شيء وفقًا للتعليمات، وتطلق تطبيقك أو خدمتك، ثم تنقطع بعد عام أو عامين.
إنه مثل بيع سيارة مستعملة ستتعطل بالتأكيد بعد 1500 كيلومتر.
هذان تعريفان فلسفيان مختلفان تمامًا لـ "التقادم". تعريف جوجل للرائحة . أنا لا أصدق هذا في الحقيقة التقادم المخطط له بنفس معنى أبل. لكن جوجل تخطط بالتأكيد لكسر برامجك بطريقة ملتوية. أعرف هذا لأنني عملت هناك كمهندس برمجيات لأكثر من 12 عامًا. لديهم إرشادات داخلية غامضة حول مقدار التوافق مع الإصدارات السابقة الذي يجب اتباعه، ولكن الأمر في النهاية متروك لكل فريق أو خدمة على حدة. لا توجد توصيات على مستوى المؤسسة أو الهندسة، والتوصية الأكثر جرأة فيما يتعلق بدورات التقادم هي "محاولة منح العملاء من 6 إلى 12 شهرًا للترقية قبل كسر نظامهم بالكامل".
المشكلة أكبر بكثير مما يعتقدون، وسوف تستمر لسنوات قادمة لأن رعاية العملاء ليست في حمضهم النووي. المزيد عن هذا أدناه.
عند هذه النقطة سأدلي ببيان جريء مفاده أن Emacs ناجحة إلى حد كبير وحتى أساسيا لأنهم يأخذون التوافق مع الإصدارات السابقة على محمل الجد. في الواقع، هذه هي أطروحة مقالتنا. إن الأنظمة المفتوحة الناجحة وطويلة الأمد تدين بنجاحها للمجتمعات الصغيرة التي عاشت حولها لعقود من الزمن ملحقات/الإضافات. هذا هو النظام البيئي. لقد تحدثت بالفعل عن طبيعة المنصات ومدى أهميتها، وكيف أن Google لم تفهم أبدًا طوال تاريخها المؤسسي ما الذي يحدث في إنشاء نظام أساسي مفتوح ناجح خارج Android أو Chrome.
في الواقع، يجب أن أذكر Android باختصار لأنك ربما تفكر فيه.
أولا، أندرويد ليس جوجل. ليس لديهم أي شيء مشترك تقريبًا مع بعضهم البعض. Android هي شركة تم شراؤها بواسطة Google في يوليو 2005، وتم السماح للشركة بالعمل بشكل مستقل إلى حد ما، وظلت في الواقع دون تغيير إلى حد كبير في السنوات الفاصلة. Android عبارة عن كومة تقنية سيئة السمعة ومنظمة شائكة سيئة السمعة بنفس القدر. وكما قال أحد موظفي Google: "لا يمكنك تسجيل الدخول إلى Android فحسب".
في مقال سابق، ناقشت مدى سوء بعض قرارات التصميم المبكرة لنظام Android. تبا، عندما كتبت هذا المقال كانوا يطلقون حماقة تسمى "التطبيقات الفورية" والتي أصبحت الآن (مفاجأة!) وأنا أتعاطف إذا كنت غبيًا بما يكفي للاستماع إلى Google ونقل المحتوى الخاص بك إلى هذه التطبيقات الفورية.
ولكن هناك فرق هنا، فرق كبير، وهو أن مستخدمي Android يفهمون حقًا مدى أهمية المنصات، فهم يبذلون قصارى جهدهم للحفاظ على عمل تطبيقات Android القديمة. في الواقع، إن جهودهم للحفاظ على التوافق مع الإصدارات السابقة شديدة للغاية لدرجة أنني، خلال الفترة القصيرة التي أمضيتها في قسم Android قبل بضع سنوات، وجدت نفسي أحاول إقناعهم بالتخلي عن الدعم لبعض أقدم الأجهزة وواجهات برمجة التطبيقات (كنت مخطئًا ، كما كان الحال في العديد من الأشياء الأخرى في الماضي والحاضر. آسف يا شباب Android! الآن بعد أن زرت إندونيسيا، أفهم سبب حاجتنا إليها).
يدفع موظفو Android التوافق إلى الوراء إلى أقصى الحدود التي لا يمكن تصورها تقريبًا، مما يؤدي إلى تراكم كميات هائلة من الديون التقنية القديمة في أنظمتهم وسلاسل الأدوات الخاصة بهم. يا إلهي، يجب أن ترى بعض الأشياء المجنونة التي يتعين عليهم القيام بها في نظام البناء الخاص بهم، كل ذلك باسم التوافق.
ولهذا السبب، أمنح Android جائزة "أنت لست Google" المرغوبة. إنهم حقًا لا يريدون أن يصبحوا Google، الذين لا يعرفون كيفية إنشاء منصات متينة، ولكن Android لأنه يعلم، كيف افعلها. ولذلك فإن Google ذكية للغاية في جانب واحد: السماح للأشخاص بفعل الأشياء بطريقتهم الخاصة على Android.
ومع ذلك، كانت التطبيقات الفورية لنظام Android فكرة غبية جدًا. وهل تعرف لماذا؟ لأنهم طالبوا إعادة كتابة وإعادة تصميم التطبيق الخاص بك! يبدو الأمر كما لو أن الناس سيعيدون كتابة مليوني طلب ببساطة. أعتقد أن التطبيقات الفورية كانت فكرة أحد موظفي Google.
ولكن هناك فرق. التوافق مع الإصدارات السابقة يأتي بتكلفة عالية. ويتحمل أندرويد نفسه عبء هذه التكاليف، في حين تصر جوجل على تحمل العبء أنت، دفع العميل.
يمكنك رؤية التزام Android بالتوافق مع الإصدارات السابقة في واجهات برمجة التطبيقات الخاصة به. عندما يكون لديك أربعة أو خمسة أنظمة فرعية مختلفة تقوم بنفس الشيء حرفيًا، فهذه علامة أكيدة على وجود التزام بالتوافق مع الإصدارات السابقة في جوهرها. والذي يعتبر في عالم المنصات مرادفًا للالتزام تجاه عملائك وسوقك.
مشكلة Google الرئيسية هنا هي اعتزازهم بنظافتهم الهندسية. إنهم لا يحبون أن يكون هناك العديد من الطرق المختلفة للقيام بنفس الشيء، مع وجود الطرق القديمة الأقل استحسانًا بجانب الطرق الجديدة الأكثر روعة. فهو يزيد من منحنى التعلم لأولئك الجدد على النظام، ويزيد من عبء الحفاظ على واجهات برمجة التطبيقات القديمة، ويبطئ سرعة الميزات الجديدة، والخطيئة الأساسية هي أنها ليست جميلة. Google - مثل Lady Ascot من فيلم Alice in Wonderland لتيم بيرتون:
سيدة أسكوت:
- أليس، هل تعرفين ما الذي أخاف منه أكثر؟
- تراجع الأرستقراطية؟
- كنت أخشى أن أفعل ذلك أحفاد قبيحون.
لفهم المفاضلة بين الجميل والعملي، دعونا نلقي نظرة على المنصة الناجحة الثالثة (بعد Emacs وAndroid) ونرى كيف تعمل: Java نفسها.
تحتوي Java على الكثير من واجهات برمجة التطبيقات القديمة. يحظى الإهمال بشعبية كبيرة بين مبرمجي Java، بل إنه أكثر شيوعًا من معظم لغات البرمجة. تعمل Java نفسها، واللغة الأساسية، والمكتبات على إيقاف واجهات برمجة التطبيقات باستمرار.
لنأخذ واحدًا فقط من آلاف الأمثلة، تعتبر عفا عليها الزمن. لقد تم إهماله منذ إصدار Java 1.2 في ديسمبر 1998. لقد مرت 22 سنة منذ أن تم إهمال هذا.
لكن الكود الفعلي في الإنتاج لا يزال يقتل الخيوط كل يوم. هل تعتقد حقا أن هذا جيد؟ قطعاً! أعني، بالطبع، إذا كنت سأعيد كتابة الكود اليوم، فسوف أقوم بتنفيذه بشكل مختلف. لكن كود لعبتي، التي أسعدت مئات الآلاف من الأشخاص خلال العقدين الماضيين، مكتوب بوظيفة إغلاق الخيوط المعلقة لفترة طويلة جدًا، وأنا لم يكن لتغييره. أنا أعرف نظامي أفضل من أي شخص آخر، ولدي حرفيًا 25 عامًا من الخبرة في العمل معه في الإنتاج، ويمكنني أن أقول على وجه اليقين: في حالتي، يعد إغلاق سلاسل العمليات المحددة هذه أمرًا مستحيلًا تمامًا غير مؤذية. لا يستحق الأمر الوقت والجهد لإعادة كتابة هذا الرمز، وأشكر لاري إليسون (على الأرجح) لأن Oracle لم تجبرني على إعادة كتابته.
ربما تفهم Oracle الأنظمة الأساسية أيضًا. من تعرف.
يمكن العثور على الأدلة في جميع أنحاء واجهات برمجة تطبيقات Java الأساسية، والتي مليئة بموجات من التقادم، مثل خطوط نهر جليدي في الوادي. يمكنك بسهولة العثور على خمسة أو ستة مديري تنقل مختلفين للوحة المفاتيح (KeyboardFocusManager) في مكتبة Java Swing. من الصعب في الواقع العثور على Java API لم يتم إهمالها. لكنهم ما زالوا يعملون! أعتقد أن فريق Java لن يقوم بإزالة واجهة برمجة التطبيقات (API) إلا إذا كانت الواجهة تمثل مشكلة أمنية صارخة.
هذا هو الأمر أيها الناس: نحن مطورو البرامج مشغولون للغاية، وفي كل مجال من مجالات البرمجيات نواجه بدائل منافسة. في أي وقت من الأوقات، يفكر المبرمجون في اللغة 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 مع جويدو، وجلست في خيمة مع بول جراهام ومجموعة من الشخصيات البارزة. جلسنا في الحر الشديد في انتظار أن يطير لاري بيج في مروحيته الشخصية بينما تحدث جويدو عن "Python 3000"، والتي أطلق عليها اسم "Python XNUMX"، والتي أطلق عليها اسم عدد السنوات التي سيستغرقها الجميع للهجرة إلى هناك. ظللنا نسأله عن سبب خرقه التوافق، فأجاب: "Unicode". وسألنا، إذا كان علينا إعادة كتابة الكود الخاص بنا، ما هي الفوائد الأخرى التي سنراها؟ فأجاب: "يوووووووووووووووونييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييييين".
إذا قمت بتثبيت Google Cloud Platform SDK ("gcloud")، فستتلقى الإشعار التالي:
عزيزي المتلقي،
نود أن نذكرك بأنه تم إيقاف دعم Python 2، لذا عليك اللعنة
… وما إلى ذلك وهلم جرا. دورة الحياة.
ولكن النقطة المهمة هي أن كل مطور لديه خيار. وإذا أجبرتهم على إعادة كتابة التعليمات البرمجية في كثير من الأحيان، فقد يفكرون في ذلك آخر خيارات. إنهم ليسوا رهائن لديك، بغض النظر عن مدى رغبتك في أن يكونوا. إنهم ضيوفك. لا تزال Python لغة برمجة شائعة جدًا، ولكن اللعنة، لقد خلقت Python 3(000) مثل هذه الفوضى في حد ذاتها وفي مجتمعاتها وبين مستخدمي مجتمعاتها بحيث لم يتم توضيح العواقب لمدة خمسة عشر عامًا.
كم عدد برامج بايثون التي تمت إعادة كتابتها بلغة Go (أو Ruby، أو أي بديل آخر) بسبب عدم التوافق مع الإصدارات السابقة؟ ما مقدار البرامج الجديدة التي تمت كتابتها بلغة أخرى غير لغة بايثون، على الرغم من ذلك ممكن ان يكون مكتوب بلغة بايثون، لو لم يحرق جويدو القرية بأكملها؟ من الصعب القول، ولكن من الواضح أن بايثون عانت. إنها فوضى كبيرة والجميع يخسر.
لنفترض أن شركة Apple تأخذ إشارة من Guido وتكسر التوافق. ماذا تعتقد سوف يحدث بعد ذلك؟ حسنًا، ربما يقوم 80-90% من المطورين بإعادة كتابة برامجهم إن أمكن. بمعنى آخر، 10-20% من قاعدة المستخدمين تنتقل تلقائيًا إلى بعض اللغات المنافسة، مثل Flutter.
قم بذلك عدة مرات وستفقد نصف قاعدة المستخدمين الخاصة بك. كما هو الحال في الرياضة، في عالم البرمجة، الشكل الحالي مهم أيضًا. كل. أي شخص يفقد نصف مستخدميه خلال خمس سنوات سيعتبر خاسرًا كبيرًا. يجب أن تكون عصريًا في عالم المنصات. ولكن هذا هو المكان الذي سيؤدي فيه عدم دعم الإصدارات الأقدم إلى تدميرك بمرور الوقت. لأنه في كل مرة تتخلص فيها من بعض المطورين، فإنك (أ) تخسرهم إلى الأبد لأنهم غاضبون منك بسبب خرق العقد، و(ب) تتنازل عنهم لمنافسيك.
ومن عجيب المفارقات أنني ساعدت Google أيضًا في أن تصبح رائدة تتجاهل التوافق العكسي عندما أنشأت Grok، وهو نظام لتحليل وفهم كود المصدر يجعل من السهل أتمتة التعليمات البرمجية نفسها واستخدامها - على غرار IDE، ولكن هنا تخزن الخدمة السحابية تمثيلات مادية لجميع مليارات الأسطر من كود مصدر Google في مستودع بيانات كبير.
زوّد Grok موظفي Google بإطار عمل قوي لإجراء عمليات إعادة البناء التلقائية عبر قاعدة التعليمات البرمجية الخاصة بهم بالكامل (حرفيًا عبر Google). لا يقوم النظام بحساب تبعياتك الأولية فقط (التي تعتمد عليها)، ولكن أيضًا تنازلي (الأمر متروك لك) لذلك عندما تقوم بتغيير واجهات برمجة التطبيقات (API)، فإنك تعرف كل شخص تقوم بكسره! بهذه الطريقة، عند إجراء تغييرات، يمكنك التحقق من أن كل مستهلك لواجهة برمجة التطبيقات (API) الخاصة بك قد قام بالتحديث إلى الإصدار الجديد، وفي الواقع، غالبًا باستخدام أداة Rosie التي كتبوها، يمكنك أتمتة العملية بالكامل.
يتيح ذلك لقاعدة بيانات Google أن تكون نظيفة داخليًا بشكل خارق للطبيعة تقريبًا، حيث أن لديهم هؤلاء الخدم الآليين يتجولون في جميع أنحاء المنزل وينظفون كل شيء تلقائيًا إذا أعادوا تسمية SomeDespicableLongFunctionName إلى SomeDespicouslyLongMethodName لأن شخصًا ما قرر أنه حفيد قبيح ويجب أن ينام.
وبصراحة، إنه يعمل بشكل جيد جدًا مع Google... داخليًا. أعني، نعم، مجتمع Go في Google يضحك كثيرًا مع مجتمع Java في Google بسبب عادتهم في إعادة البناء المستمر. إذا قمت بإعادة تشغيل شيء ما N مرات، فهذا يعني أنك لم تفسد الأمر N-1 مرات فقط، ولكن بعد فترة يصبح من الواضح تمامًا أنك ربما أفسدته في المحاولة N أيضًا. لكنهم إلى حد كبير يظلون فوق كل هذه الضجة ويحافظون على الكود "نظيفًا".
تبدأ المشكلة عندما يحاولون فرض هذا الموقف على عملائهم السحابيين ومستخدمي واجهات برمجة التطبيقات الأخرى.
لقد عرّفتك قليلاً على Emacs وAndroid وJava؛ دعونا نلقي نظرة على أحدث منصة ناجحة طويلة الأمد: الويب نفسه. هل يمكنك أن تتخيل عدد التكرارات التي مر بها HTTP منذ عام 1995 عندما استخدمنا العلامات الوامضة؟ وأيقونات "تحت الإنشاء" على صفحات الويب.
لكنها لا تزال تعمل! وما زالت هذه الصفحات تعمل! نعم يا شباب، المتصفحات هي أبطال العالم في التوافق مع الإصدارات السابقة. يعد Chrome مثالًا آخر على نظام Google الأساسي النادر الذي تم تثبيت رؤوسه بشكل صحيح، وكما كنت قد خمنت، يعمل Chrome بشكل فعال كشركة محمية منفصلة عن بقية Google.
أريد أيضًا أن أشكر أصدقائنا في مطوري أنظمة التشغيل: Windows، وLinux، وNOT APPLE FUCK YOU APPLE، وFreeBSD، وما إلى ذلك، لقيامهم بهذا العمل الرائع في التوافق مع الإصدارات السابقة على منصاتهم الناجحة (تحصل Apple على درجة C في أفضل الأحوال مع The الجانب السلبي هو أنهم يعطلون كل شيء طوال الوقت دون سبب وجيه، ولكن بطريقة ما يتغلب المجتمع على ذلك مع كل إصدار، ولا تزال حاويات OS X غير قديمة تمامًا... حتى الآن).
لكن انتظر، كما تقول. ألسنا نقارن التفاح بالبرتقال - أنظمة البرامج المستقلة على جهاز واحد مثل Emacs/JDK/Android/Chrome مقابل الأنظمة متعددة الخوادم وواجهات برمجة التطبيقات مثل الخدمات السحابية؟
حسنًا، لقد قمت بالتغريد عن هذا بالأمس، ولكن بأسلوب لاري وول (مبتكر لغة البرمجة بيرل - تقريبًا. لكل.) على مبدأ "تمتص/قواعد" بحثت عن الكلمة إهمال على مواقع المطورين جوجل وأمازون. وعلى الرغم من أن AWS لديها مئات عروض الخدمة أكثر من عروض Google Cloud Platform بمرتين، تشير وثائق مطوري Google إلى الإيقاف بمعدل سبع مرات تقريبًا.
إذا كان أي شخص في Google يقرأ هذا، فمن المحتمل أن يكون مستعدًا لسحب الرسوم البيانية على غرار دونالد ترامب التي توضح أنهم يفعلون كل شيء بشكل صحيح، وأنه لا ينبغي لي إجراء مقارنات غير عادلة مثل "عدد الإشارات إلى الكلمة الموقوفة مقابل" عدد الخدمات""
ولكن بعد كل هذه السنوات، لا تزال خدمة Google Cloud هي الخدمة رقم 3 (لم أكتب مطلقًا مقالًا عن المحاولة الفاشلة لتصبح الخدمة رقم 2)، ولكن إذا صدقنا المطلعين على بواطن الأمور، فهناك بعض المخاوف من احتمال تراجعها قريبًا إلى المرتبة الثانية. رقم 4.
ليس لدي أي حجج مقنعة "لإثبات" أطروحتي. كل ما لدي هو الأمثلة الملونة التي تراكمت لدي على مدار 30 عامًا كمطور. لقد ذكرت بالفعل الطبيعة الفلسفية العميقة لهذه المشكلة؛ في بعض النواحي يتم تسييسه في مجتمعات المطورين. يعتقد البعض ذلك المبدعين يجب أن تهتم المنصات بالتوافق، بينما يعتقد البعض الآخر أن هذا مصدر قلق المستخدمين (المطورين أنفسهم). واحد من اثنين. في الواقع، أليست المسألة سياسية عندما نقرر من الذي يجب أن يتحمل تكاليف المشاكل المشتركة؟
إذن هذه هي السياسة. ومن المحتمل أن تكون هناك ردود فعل غاضبة على خطابي.
كيف المستخدم Google Cloud Platform، وباعتباري مستخدمًا لـ AWS لمدة عامين (أثناء العمل في Grab)، أستطيع أن أقول إن هناك فرقًا كبيرًا بين فلسفتي Amazon وGoogle عندما يتعلق الأمر بالأولويات. لا أقوم بالتطوير بشكل نشط على AWS، لذلك لا أعرف جيدًا عدد المرات التي يقومون فيها بإزالة واجهات برمجة التطبيقات القديمة. ولكن هناك شك في أن هذا لا يحدث بنفس القدر الذي يحدث في جوجل. وأعتقد حقًا أن مصدر الجدل المستمر والإحباط في Google Cloud Platform هو أحد أكبر العوامل التي تعيق تطوير النظام الأساسي.
أعلم أنني لم أذكر أمثلة محددة لأنظمة Google Cloud Platform التي لم تعد مدعومة. أستطيع أن أقول إن كل ما استخدمته تقريبًا، بدءًا من الشبكات (من الأقدم إلى VPC) وحتى التخزين (Cloud SQL v1-v2)، وFirebase (الآن Firestore مع واجهة برمجة تطبيقات مختلفة تمامًا)، وApp Engine (دعونا لا نبدأ حتى) ، نقاط نهاية السحابة نقطة نهاية السحابة وما يصل إلى... لا أعرف - كل هذا على الاطلاق أجبروك على إعادة كتابة الكود بعد مدة أقصاها 2-3 سنوات، ولم يقوموا أبدًا بإجراء عملية الترحيل تلقائيًا لك، وفي كثير من الأحيان . كما لو كان من المفترض أن يكون الأمر كذلك.
وفي كل مرة ألقي نظرة على AWS، أسأل نفسي لماذا بحق الجحيم لا أزال أستخدم برنامج Google Cloud Platform. من الواضح أنهم لا يحتاجون إلى عملاء. إنهم بحاجة покупатели. هل تفهم الإختلاف؟ دعني أشرح.
جوجل السحابية لديها حيث يقترح الناس حلولهم البرمجية، ولتجنب تأثير المطعم الفارغ، كانوا بحاجة إلى ملئه ببعض المقترحات، فتعاقدوا مع شركة تدعى Bitnami لإنشاء مجموعة من الحلول التي يتم نشرها بـ "نقرة واحدة"، أو ينبغي أنا أكتبها بنفسي "حلولًا"، لأنها لا تحل شيئًا. إنها ببساطة موجودة كمربعات اختيار، وكمواد حشو للتسويق، ولم تهتم Google أبدًا بما إذا كانت أي من الأدوات تعمل بالفعل. أعرف مديري المنتجات الذين كانوا في مقعد السائق، ويمكنني أن أؤكد لكم أن هؤلاء الأشخاص لا يهتمون.
لنأخذ على سبيل المثال حل النشر المفترض "بنقرة واحدة". . لقد سئمت حتى الموت من خدع Google Cloud SQL، لذلك بدأت النظر في إنشاء مجموعة Percona الخاصة بي كبديل. وهذه المرة يبدو أن Google قامت بعمل جيد، وسوف توفر لي بعض الوقت والجهد بنقرة زر واحدة!
حسنا عظيم، دعونا نذهب. دعنا نتبع الرابط وانقر على هذا الزر. حدد "نعم" للموافقة على جميع الإعدادات الافتراضية ونشر المجموعة في مشروع Google السحابي الخاص بك. هاها، لا يعمل. لا شيء من هذا الهراء يعمل. لم يتم اختبار الأداة مطلقًا وبدأت في التعفن منذ الدقيقة الأولى، ولن أتفاجأ إذا كان أكثر من نصف "الحلول" عبارة عن عمليات نشر بنقرة واحدة (الآن نفهم سبب الاقتباسات) بشكل عام لا يعمل. هذا ظلام ميؤوس منه تماما، حيث من الأفضل عدم الدخول.
لكن جوجل على حق تحث لك استخدامها. يريدون منك ذلك اشترى. بالنسبة لهم إنها صفقة. إنهم لا يريدون أي شيء لدعم. إنه ليس جزءًا من الحمض النووي لـ Google. نعم، يدعم المهندسون بعضهم البعض، كما يتضح من قصتي مع Bigtable. ولكن في المنتجات والخدمات للأشخاص العاديين هم دائما كانوا لا يرحمون في ، والذي لا يفي بمعايير الربحية حتى لو كان لديه ملايين المستخدمين.
ويمثل هذا تحديًا حقيقيًا لـ Google Cloud Platform لأن هذا هو الحمض النووي وراء جميع العروض السحابية. إنهم لا يحاولون دعم أي شيء؛ ومن المعروف أنهم يرفضون استضافة (كخدمة مُدارة) أي برنامج تابع لجهة خارجية حتى، حتى تفعل AWS الشيء نفسه وتبني عملاً تجاريًا ناجحًا حولها، وعندما يطلب العملاء نفس الشيء حرفيًا. ومع ذلك، يتطلب الأمر بعض الجهد لجعل Google تدعم شيئًا ما.
يؤدي هذا النقص في ثقافة الدعم، إلى جانب عقلية "دعونا نكسرها لنجعلها أكثر جمالاً"، إلى تنفير المطورين.
وهذا ليس بالأمر الجيد إذا كنت ترغب في بناء منصة طويلة الأمد.
جوجل، استيقظ، اللعنة. إنه عام 2020 الآن. أنت لا تزال تخسر. لقد حان الوقت لإلقاء نظرة فاحصة على المرآة والإجابة عما إذا كنت تريد حقًا البقاء في الأعمال السحابية.
إذا كنت ترغب في البقاء ثم توقف عن كسر كل شيء. يا رفاق، أنتم غنيون. نحن المطورين لا نفعل ذلك. لذلك عندما يتعلق الأمر بمن سيتحمل عبء التوافق، عليك أن تأخذه على عاتقك. ليس لنا.
لأن هناك ما لا يقل عن ثلاث سحب جيدة حقًا. إنهم يومئون.
والآن سأنتقل لإصلاح جميع أنظمتي المعطلة. إيه.
حتى المرة القادمة!
تحديث PS بعد قراءة بعض المناقشات حول هذه المقالة (المناقشات رائعة، راجع للشغل). لم يتم إيقاف دعم Firebase ولا توجد خطط على علم بها. ومع ذلك، لديهم خطأ فادح في البث يتسبب في توقف عميل Java في App Engine. ساعدني أحد المهندسين في حل هذه المشكلة، عندما كنت أعمل في جوجل، لكنهم لم يقوموا بإصلاح الخلل فعليًا، لذلك لدي حل بديل سيئ يتمثل في الاضطرار إلى إعادة تشغيل تطبيق 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/XNUMX/XNUMX. شريط !
تحديث 3، 31.08.2020/2/2. لقد اتصل بي أحد مهندسي Google في Cloud Marketplace والذي تبين أنه صديق قديم لي. لقد أراد معرفة سبب عدم عمل CXNUMXD، واكتشفنا في النهاية أن السبب هو أنني قمت ببناء شبكتي منذ سنوات، وأن CXNUMXD لم يكن يعمل على الشبكات القديمة لأن معلمة الشبكة الفرعية كانت مفقودة في قوالبها. أعتقد أنه من الأفضل لمستخدمي Google Cloud Platform المحتملين التأكد من أنهم يعرفون عددًا كافيًا من المهندسين في Google...
المصدر: www.habr.com