«لقد قمنا ببناء مجموعة Mesos المكونة من 70,000 عقدة لمطورينا، لكنهم لن يستخدموها. هل يمكنك المساعدة؟» كانت هذه بداية محادثة مع نائب رئيس عمليات البنية التحتية في شركة كبيرة جدًا ومشهورة. على الرغم من أنه إنجاز مثير للإعجاب، إلا أنه كان أيضًا إلى حد بعيد أكبر إعداد للبنية التحتية في حاويات رأيته دون استخدام - ولم يكن، للأسف، حادثًا منفردًا
.لقد تحدثت عن هذا اللقاء مع عدد كبير من العملاء والمحللين والأصدقاء والزملاء والشركاء وأصحاب رؤوس الأموال والمنافسين. لقد عبرنا جميعًا عن تجارب مماثلة، وأردنا جميعًا معرفة سبب ذلك. بعد كل شيء، إذا تم إهدار الكثير من الموارد في صناعتنا، فإننا جميعًا نخاطر كثيرًا من خلال عدم فهم المشكلة وحلها. بخلاف ذلك، قد تبدأ الموجة التالية من المستخدمين في الشك في أن الحاويات يمكن أن تساعد أعمالهم، وسنحتاج جميعًا إلى البدء في تلميع سيرنا الذاتية
.يجب أن أكون صادقًا هنا: أنا مطور ومهندس وتقني يحب بناء المنتجات واستخدام أحدث التقنيات. لذا، كان المكان الأول الذي بحثت فيه، في سعيي للعثور على إجابة لهذا السؤال المكون من 70 ألف عقدة، هو التقنيات المستخدمة. هل كانت Mesos هي التكنولوجيا الخاطئة؟ هل تم تنفيذه بطريقة خاطئة؟ هل استخدموا المصدر المفتوح أو المصدر المغلق؟ هل كان هناك تنظيم الدولة الإسلامية متورط؟ أسئلة مثل هذه تتبادر إلى الذهن أولاً. بعد فوات الأوان، أعتقد أن هذه ربما كانت الأسئلة الخاطئة
.جاءتني الإجابة عندما تذكرت يومًا في مسيرتي المهنية قبل 15 عامًا: كنت جالسًا على مكتبي كمطور في بنك كبير، أتذكر مندوبي مبيعات يرتدون ملابس لا تشوبها شائبة يأتون ويذهبون إلى غرف اجتماعاتنا، ويغازلون نائب رئيس البنية التحتية وفريقه. كانوا من VMware، التي كانت في ذلك الوقت شركة البنية التحتية الافتراضية. كنت مجرد مطور في البنك، ولكن لم تتم دعوة حتى رئيسي أو رئيسه أو حتى رئيس رئيسه إلى أي من حفلات عشاء شرائح اللحم التي يستضيفها موظفو VMware كل أسبوع تقريبًا. كان مندوبو مبيعات VMware مهتمين فقط بصناع قرارات العمليات والبنية التحتية. بعد شهرين أو ثلاثة، تم إخبار فريقنا أنه تم توقيع صفقة مع VMware وسنقوم بنقل خدماتنا إلى الأجهزة الافتراضية قريبًا، وبعد فترة وجيزة من حدوث هذه الخطوة على مدار أسبوعين
.ثم في صباح أحد أيام الاثنين، كانت الخدمات التي كان فريقي مسؤولاً عنها تعمل على أجهزة افتراضية بدلاً من الخوادم المعدنية القديمة ذات الأضواء الزرقاء الساطعة والمراوح الصاخبة. كان هذا كل شيء. تم إضفاء الطابع الافتراضي على بنيتنا التحتية بالكامل في غضون أشهر دون قول الكثير من المطورين، وبينما كنا نمارس بعض المقاومة الزائفة لهذا التغيير (ومن يحب التغيير بعد كل شيء؟) وموافقتنا على مضض على أن نكون على أهبة الاستعداد خلال بضعة عطلات نهاية أسبوع، لم نتمكن حقًا من التمييز بين الإعداد القديم والجديد: كل شيء كان على حاله. تصرفت خوادم VM الخاصة بنا وشعرت وكأنها خوادم «حقيقية». أنا متأكد من أننا لم نكن لنتمكن من معرفة الفرق في اختبار التعمية المزدوجة إذا أجرى أي شخص واحدًا
. إنتذكر تلك الأيام جعلني أتساءل لماذا لا تعمل الموجة الجديدة من تغيير البنية التحتية في الحاويات بنفس الطريقة. لماذا لا يمكننا بناء مجموعة Mesos أو Kubernetes خلال عطلة نهاية أسبوع أو اثنتين وإرسال مذكرة إلى المطورين بعنوان: «مرحبًا بك في مستقبل البنية التحتية. مرحبًا بك!»؟
الإجابة كما نعلم جميعًا هي أن النقل بالحاويات لن يعمل بدون مشاركة المطورين والشراء. يحتاج المطورون إلى إنشاء تطبيقات للإعداد في حاويات، ولكن المتأصلة في الحاويات، مع تعرض واجهات برمجة التطبيقات مثل Kubernetes عبر دورة حياة البرنامج، أمر حتمي للمطورين والمشغلين لتغيير طريقة عملهم والتواصل مع بعضهم البعض. السبب وراء وجود مجموعة لامعة مكونة من 70 ألف عقدة تعمل على تشغيل tumbleweed بدلاً من تطبيقات الأعمال هو أن الأدوات التي قمنا ببنائها لهذا الانتقال الجديد لا تعالج هذا التغيير التنظيمي الأساسي والأساسي، وهو المزج بين المطورين والعمليات. الواقع المثير هو أن إعداد البنية التحتية للحاويات أصبح أسهل، حيث توجد وفرة من الحلول مفتوحة المصدر التي تجعلك تعمل مع مجموعة Kubernetes. إذا كنت تعمل بالفعل على مزود سحابة رئيسي، فأنت ببساطة على بعد بضع نقرات من امتلاك مجموعة الحاويات الخاصة بك، والتي تتم إدارتها وخدمتها وإصدار الفواتير بها كل دقيقة. تظهر فوائد تشغيل البنية التحتية الحاوية لفرق العمليات: خوادم أحادية التكوين (لا مزيد من «رقاقات الثلج»)، والتوافر والمرونة المدمجين، وتحسين استخدام الموارد، على سبيل المثال لا الحصر. يرى المطورون أيضًا قيمة التشغيل في إعداد الحاويات: المزيد من التأثير على بيئة التشغيل، والتحكم المحسن في المكتبات والتبعيات، وتضييق الفجوة بين بيئات الإنتاج والتطوير هي بعض من هذه العوامل. يحتوي كل جانب من جوانب هذه المعادلة (devs and ops) على مورديه وأدواته ومشاريعه مفتوحة المصدر لمساعدتهم في ما يلزم للانتقال إلى عالم الحاويات - ولكن هذا ليس كافيًا. ما زلنا نفتقد إطار عمل المطورين والعمليات للعمل معًا لإنجاح ذلك. هناك ببساطة عدد قليل جدًا من الأدوات والتقنيات المتاحة، إن وجدت، لتسهيل هذا الاتصال.
نحن جميعًا نركز على مجالات الابتكار الفردية لدينا - من الشبكة إلى التخزين والتنظيم - بحيث يمكننا أن نفقد التركيز على تحقيق عملائنا لأهداف أعمالهم. في مثل هذه البيئة، تحقق شركات تكامل الأنظمة والاستشارات والخدمات المهنية أداءً جيدًا، حيث إنها الوحيدة التي تركز على النتيجة وعلى التسليم عبر سلسلة توريد البرامج؛ لكن هذا ليس مستدامًا. التقنيات التي تتطلب من العملاء دفع الكثير للاستشارات لجعلها تعمل لن تكون تقنيات متطورة. دعونا نواجه الأمر: إذا كانت المحاكاة الافتراضية بحاجة إلى أن تكون McKinsey حاضرة دائمًا على جدول الرواتب حتى تعمل، فلن تكون هناك سحابة اليوم
.لكي نستفيد جميعًا من التكنولوجيا المتطورة مثل نقل البنية التحتية بالحاويات، نحتاج إلى التفكير على نطاق أوسع من أدواتنا ذات الغرض الواحد أو مجالات التركيز الأساسية وإعادة التفكير في الطريقة التي نبني بها منتجات لهذه الصناعة. وهذا يختلف عن ثورة المحاكاة الافتراضية والسحابة، وكلما أسرعنا في إدراك ذلك، زادت الفوائد التي تعود على عملائنا.
Devops ليست مجرد مجموعة من الأدوات المجزأة أو مشروع «التحول الرقمي» الفاخر، إنها طريقة للعمل بشكل تعاوني بين الوظائف، التي تتيحها التكنولوجيا. لذلك، فإن أي تقنية تستهدف سوق devops، وتحديدًا حول النقل بالحاويات، تحتاج أيضًا إلى معالجة عقلية التعاون المستمر قبل أي شيء آخر. لذلك، دعونا جميعًا نبني منتجات مع وضع ذلك في الاعتبار لبدء محادثة بين المطورين والمشغلين والحفاظ عليها.
تم نشر هذا المنشور لأول مرة هنا