المخاطر مقابل المكافأة: دليل لفهم حاويات البرامج

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

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

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

الحيوانات الأليفة للماشية

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

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

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

المكافآت

تجعل الحاويات الكثير من الأشياء أسهل. لقد سمحوا للشركات بالتركيز أكثر على الصلصة الخاصة بهم. يمكن للفرق الفنية أن تقلق بدرجة أقل بشأن إدارة البنية التحتية والتهيئة وبدلاً من ذلك تقلق في الغالب بشأن كود التطبيق. يمكن للشركات أن تخطو خطوة إلى الأمام وتستخدم الخدمات المدارة لأشياء مثل MySQL أو Cassandra أو Kafka أو Redis حتى لا تضطر إلى التعامل مع طبقة البيانات على الإطلاق. هناك العديد من الشركات الناشئة التي تقدم خدمات التعلم الآلي "التوصيل والتشغيل" أيضًا للسماح للشركات بإجراء تحليلات متطورة دون القلق بشأن البنية التحتية. بلغت هذه الاتجاهات ذروتها في نموذج بدون خادم - نهج هندسة البرمجيات الذي يسمح للفرق بإصدار البرامج دون إدارة جهاز ظاهري واحد أو حاوية. تجعل خدمات AWS مثل S3 و Lambda و Kinesis و Dynamo هذا ممكنًا. لتوسيع هذا القياس ، انتقلنا من الحيوانات الأليفة إلى الماشية إلى نوع من خدمة الحيوانات عند الطلب.

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

المخاطر

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

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

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

يتم إحتوائه

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

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