14 نوفمبر 2025·6 دقيقة
Craig McLuckie والحوسبة السحابية الأصلية: فوز تفكير المنصة
نظرة عملية على دور Craig McLuckie في تبنّي السحابي-الأصلي وكيف أن تفكير المنصة حوّل الحاويات إلى بنية تحتية موثوقة للإنتاج.
نظرة عملية على دور Craig McLuckie في تبنّي السحابي-الأصلي وكيف أن تفكير المنصة حوّل الحاويات إلى بنية تحتية موثوقة للإنتاج.
الفرق لا تعاني لأنهم لا يستطيعون تشغيل حاوية واحدة. يعانون لأن عليهم تشغيل المئات منها بأمان، تحديثها بدون توقف، استعادتها عندما تتعطل، ومع ذلك تسليم الميزات في مواعيدها.
قصة "سحابي-أصلي" لدى Craig McLuckie مهمة لأنها ليست استعراضًا للعرض المبهر. إنها سجل لكيفية تحول الحاويات إلى شيء قابل للتشغيل في بيئات حقيقية—حيث تحدث الحوادث، توجد امتثال، وتحتاج الأعمال إلى تسليم متوقع.
"سحابي-أصلي" ليس مجرد "التشغيل في السحابة". إنه نهج لبناء وتشغيل البرمجيات بحيث يمكن نشرها بشكل متكرر، التوسع عندما يتغير الطلب، وإصلاحها بسرعة عند فشل أجزاء منها.
عمليًا، هذا عادة يعني:
كانت تبنّي الحاويات مبكرًا يبدو غالبًا كصندوق أدوات: فرق تستعمل Docker، تربط سكربتات معًا، وتأمل أن يواكب قسم العمليات. تفكير المنصة يقلب هذا النموذج. بدلاً من أن يخترع كل فريق طريقه إلى الإنتاج، تبني منصة مشتركة "طرق مرصوفة"—منصة تجعل الطريق الآمن والمتوافق والملاحظ هو أيضًا الأسهل.
هذا التحول هو الجسر من "نستطيع تشغيل الحاويات" إلى "نستطيع تشغيل أعمالنا عليها".
هذا موجه للأشخاص المسؤولين عن النتائج، وليس مجرد خرائط المعمارية:
إذا كان هدفك تسليم موثوق على نطاق، فهذه التاريخية تحتوي دروسًا عملية.
Craig McLuckie هو أحد الأسماء الأكثر ارتباطًا بحركة السحابي-الأصلي المبكرة. ستراه مرجعًا في محادثات عن Kubernetes، Cloud Native Computing Foundation (CNCF)، وفكرة معاملة البنية التحتية كمنتج—ليس كمجموعة تذاكر ومعرفة قبلية.
من المهم أن نكون دقيقين. لم يخترع McLuckie السحابي-الأصلي بمفرده، وKubernetes لم يكن مشروع شخص واحد. Kubernetes برز من فريق في Google، وكان McLuckie جزءًا من ذلك الجهد المبكر.
ما ينسبه الناس إليه غالبًا هو المساعدة في تحويل مفهوم هندسي إلى شيء يمكن للصناعة الأوسع تبنيه بالفعل: بناء مجتمع أقوى، تغليف أوضح، ودفع نحو ممارسات تشغيل قابلة للتكرار.
عبر Kubernetes وعصر CNCF، كانت رسالة McLuckie أقل عن العمارة الرائجة وأكثر عن جعل الإنتاج متوقعًا. وهذا يعني:
إذا سمعت مصطلحات مثل "طرق مرصوفة" أو "مسارات ذهبية" أو "المنصة كمنتج" فأنت تدور حول نفس الفكرة: تقليل الحمل المعرفي عن الفرق بجعل الشيء الصحيح هو الأسهل.
هذا المنشور ليس سيرة ذاتية. McLuckie مرجع مفيد لأن عمله يجلس عند تقاطع ثلاث قوى غيّرت تسليم البرمجيات: الحاويات، التنسيق، وبناء النظام البيئي. الدروس هنا ليست عن الشخصية—بل عن سبب نجاح تفكير المنصة في جعل الحاويات قابلة للتشغيل في الإنتاج الحقيقي.
كانت الحاويات فكرة مثيرة قبل أن يصبح مصطلح "سحابي-أصلي" شائعًا. ببساطة، الحاوية هي وسيلة لتعبئة التطبيق مع الملفات والمكتبات التي يحتاجها بحيث يعمل بنفس الشكل على آلات مختلفة—مثل شحن منتج في صندوق مختوم بكل القطع داخل.
في البداية، استخدمت الفرق الحاويات للمشروعات الجانبية، العروض التوضيحية، وتدفقات عمل المطوّرين. كانت ممتازة لتجربة خدمات جديدة بسرعة، إنشاء بيئات اختبار، وتجنّب مفاجآت "يعمل على جهاز المطوّر" أثناء التسليم.
لكن الانتقال من عدد قليل من الحاويات إلى نظام إنتاجي يعمل 24/7 مختلفة تمامًا. الأدوات كانت موجودة، لكن القصة التشغيلية كانت ناقصة.
ظهرت مشكلات شائعة بسرعة:
ساعدت الحاويات على جعل البرمجيات محمولة، لكن القابلية للنقل وحدها لم تضمن الاعتمادية. لا تزال الفرق بحاجة إلى ممارسات نشر متسقة، ملكية واضحة، وحواجز تشغيلية—لكي لا تعمل التطبيقات المحواة لمرة واحدة فقط، بل تعمل بثبات كل يوم.
تفكير المنصة هو اللحظة التي تتوقف فيها الشركة عن معاملة البنية التحتية كمشروع لمرة واحدة وتبدأ في معالجتها كمنتج داخلي. "العملاء" هم المطوّرون، فرق البيانات، وأي شخص يطلق برمجيات. هدف المنتج ليس المزيد من الخوادم أو المزيد من YAML—بل مسار أنعم من الفكرة إلى الإنتاج.
المنصة الحقيقية لها وعد واضح: "إذا بنيت ونشرت باستخدام هذه المسارات، ستحصل على الاعتمادية، الأمن، والتسليم المتوقع." هذا الوعد يتطلّب عادات منتج—توثيق، دعم، إصدارات، وحلقات تغذية راجعة. كما يتطلب تجربة مستخدم مقصودة: افتراضات معقولة، طرق مرصوفة، ومخرج للطوارئ عندما يحتاج الفرق فعلًا لخروج عن المسار.
التوحيد يزيل تعب اتخاذ القرار ويمنع التعقيد العرضي. عندما تشارك الفرق نفس أنماط النشر والسجلات وضوابط الوصول، تصبح المشاكل قابلة للتكرار—ومن ثَم قابلة للحل. تتحسن مناوبات الاستدعاء لأن الحوادث تبدو مألوفة. تسرّع مراجعات الأمان لأن المنصة تبني الحواجز بدل أن يختَرع كل فريق حلّه.
هذا ليس عن إجبار الجميع على صندوق واحد. إنه عن الاتفاق على الـ80% التي يجب أن تكون مملة، حتى تَصرف الفرق طاقتها على الـ20% التي تميّز العمل.
قبل صعود نهج المنصة، كانت البنية التحتية تعتمد غالبًا على معرفة خاصة: قلة من الناس يعرفون أي الخوادم محدثة، أي الإعدادات آمنة، وأي السكربتات هي "الجيدة". يفكك تفكير المنصة ذلك بأنماط قابلة للتكرار: قوالب، توفير آلي، وبيئات متسقة من التطوير إلى الإنتاج.
عندما تُنفّذ جيدًا، تخلق المنصات حوكمة أفضل مع أوراق عمل أقل. تصبح السياسات فحوصات آلية، وتصبح الموافقات مسارات عمل قابلة للتدقيق، وتنتج أدلة الامتثال تلقائيًا عند نشر الفرق—بحيث تحصل المؤسسة على السيطرة دون إبطاء الجميع.
جعلت الحاويات سهولة تعبئة وشحن التطبيق. الجزء الصعب كان ما يحدث بعد الشحن: أين يجب أن يعمل، كيفية بقائه صحيًا، والتكيّف عندما يتغير المرور أو تفشل البنية التحتية.
هذا هو الفجوة التي سدها Kubernetes. حوّل "كومة حاويات" إلى شيء يمكنك تشغيله يومًا بعد يوم، حتى عندما تفشل الخوادم، تحدث الإصدارات، ويتزايد الطلب.
غالبًا ما يُوصف Kubernetes بأنه "تنسيق الحاويات"، لكن المشاكل العملية أكثر تحديدًا:
بدون منظّم، تنتهي الفرق بكتابة سكربتات لهذه السلوكيات وإدارة الاستثناءات يدويًا—حتى لا تتطابق السكربتات مع الواقع.
شاع Kubernetes فكرة وجود لوحة تحكم مشتركة: مكان واحد تُصرّح فيه بما تريد ("شغّل 3 نسخ من هذه الخدمة") وتعمل المنصة باستمرار لجعل العالم الحقيقي يطابق تلك النية.
هذا تغيير كبير في المسؤوليات:
لم يظهر Kubernetes لمجرد أن الحاويات كانت رائجة. نما من الدروس المستفادة عند تشغيل أساطيل كبيرة: عالج البنية التحتية كنظام به حلقات تغذية راجعة، لا كمجموعة مهام خوادم لمرة واحدة. هذه الذهنية التشغيلية هي سبب كونه الجسر من "نستطيع تشغيل الحاويات" إلى "نستطيع تشغيلها بثقة في الإنتاج".
لم يقدّم السحابي-الأصلي أدوات جديدة فحسب—بل غيّر إيقاع النشر اليومي. انتقلت الفرق من "خوادم مصنوعة يدويًا وكتيبات تشغيل" إلى أنظمة مصممة لتُدار عبر واجهات برمجة تطبيقات، الأتمتة، والتكوين التصريحي.
يفترض إعداد سحابي-أصلي أن البنية التحتية قابلة للبرمجة. هل تحتاج قاعدة بيانات أو موازن تحمل أو بيئة جديدة؟ بدل الانتظار لإعداد يدوي، تصف الفرق ما تريد وتسمح للأتمتة بإنشائه.
التحوّل الرئيسي هو التكوين التصريحي: تحدد الحالة المرغوبة ("شغّل 3 نسخ من هذه الخدمة، افتحها على هذا المنفذ، حد الذاكرة إلى X") وتعمل المنصة باستمرار لمطابقة تلك الحالة. هذا يجعل التغييرات قابلة للمراجعة، قابلة للتكرار، وأسهل في التراجع.
غالبًا ما كان التسليم التقليدي يتضمن ترقيع الخوادم الحية. مع الوقت، كل آلة تصبح مختلفة قليلًا—انحراف التكوين الذي يظهر فقط أثناء الحوادث.
دفع التسليم السحابي-الأصلي الفرق نحو نشرات غير قابلة للتعديل: بناء آرتيفاكت مرة واحدة (غالبًا صورة حاوية)، نشرها، وإذا احتجت تغييرًا، تطرح إصدارًا جديدًا بدل تعديل الجاري. مجتمعة مع الطروحات الآلية وفحوصات الصحة، يقلل هذا النهج من "حوادث الغموض" الناتجة عن إصلاحات فردية.
سهّلت الحاويات حزم وتشغيل خدمات صغيرة عديدة بشكل متسق، مما شجّع هندسات الخدمات المصغرة. بدورها، زادت الخدمات المصغرة الحاجة إلى نشر متسق، التوسع، واكتشاف الخدمة—مجالات يتفوّق فيها تنسيق الحاويات.
المقايضة: مزيد من الخدمات يعني مزيدًا من العبء التشغيلي (المراقبة، الشبكات، إصدار النسخ، الاستجابة للحوادث). يساعد السحابي-الأصلي في إدارة تلك التعقيدات، لكنه لا يمحوها.
تحسّنت القابلية للنقل عندما اتفقت الفرق على بدائل نشر ومحددات مشتركة. مع ذلك، "التشغيل في أي مكان" عادة يتطلب عملًا—الاختلافات في الأمان، التخزين، الشبكات، والخدمات المُدارة مهمة. من الأفضل فهم السحابي-الأصلي كـ تقليل الاقفال والاحتكاك، لا كإلغائهما.
لم ينتشر Kubernetes فقط لأنه قوي. انتشر لأنه وجد موطنًا محايدًا، حوكمة واضحة، ومكانًا يمكن للشركات المتنافسة التعاون فيه دون أن يملك بائع واحد "القواعد".
أنشأت Cloud Native Computing Foundation (CNCF) حوكمة مشتركة: صنع قرارات مفتوحة، عمليات مشاريع متوقعة، وخرائط طريق علنية. هذا مهم للفرق التي تراهن على بنية تحتية أساسية. عندما تكون القواعد شفافة وغير مرتبطة بنموذج أعمال شركة واحدة، يصبح التبنّي أقل مخاطرة—وتصبح المساهمات أكثر جاذبية.
باحتضان Kubernetes ومشاريع ذات صلة، ساعدت CNCF في تحويل "أداة مفتوحة المصدر شعبية" إلى منصة طويلة الأمد بدعم مؤسسي. وفرت:
مع مساهمين كثيرين (مزودو سحابة، شركات ناشئة، مؤسسات، ومهندسون مستقلون)، تطور Kubernetes أسرع وفي اتجاهات واقعية أكثر: الشبكات، التخزين، الأمان، وعمليات الـ day-2. جعلت الواجهات المفتوحة والمعايير التكامل أسهل، مما قلّل القفل وزاد الثقة للاستخدام في الإنتاج.
سارعت CNCF أيضًا إلى انفجار في النظام البيئي: service meshes، ingress controllers، أدوات CI/CD، محركات سياسات، حزم مراقبة، والمزيد. هذه الوفرة قوة—لكنها تخلق تراكبًا.
لأغلب الفرق، النجاح يأتي من اختيار مجموعة صغيرة من المكونات المدعومة جيدًا، تفضيل التوافق، والوضوح حول الملكية. نهج "الأفضل في كل شيء" غالبًا ما يؤدي إلى عبء صيانة بدل تحسين التسليم.
حلّت الحاويات وKubernetes جزءًا كبيرًا من سؤال "كيف نشغّل البرمجيات؟". لم تحل تلقائيًا السؤال الأصعب: "كيف نبقيها تعمل عندما يظهر المستخدمون الحقيقيون؟" الطبقة المفقودة هي الاعتمادية التشغيلية—توقعات واضحة، ممارسات مشتركة، ونظام يجعل السلوكيات الصحيحة هي الافتراضية.
يمكن للفريق أن ينشر بسرعة ويظل على بعد نشر سيئ واحد من الفوضى إن لم يُعرّف الحد الأدنى للإنتاج. على الأقل تحتاج إلى:
بدون هذا الأساس، تختلق كل خدمة قواعدها وتصبح الاعتمادية مسألة حظ.
قدمت DevOps وSRE عادات مهمة: الملكية، الأتمتة، قياس الاعتمادية، والتعلم من الحوادث. لكن العادات وحدها لا تتوسع عبر عشرات الفرق ومئات الخدمات.
المنصات تجعل هذه الممارسات قابلة للتكرار. يضع SRE أهدافًا (مثل SLOs) وحلقات تغذية، وتوفر المنصة طرقًا مرصوفة للالتقاء بتلك الأهداف.
التسليم الموثوق عادة يتطلب مجموعة متسقة من القدرات:
المنصة الجيدة تبني هذه الافتراضات في القوالب، خطوط الأنابيب، وسياسات وقت التشغيل: لوحات قياس معيارية، قواعد تنبيه شائعة، حواجز نشر، وآليات تراجع. هكذا تتوقف الاعتمادية عن كونها اختيارًا—وتصبح نتيجة متوقعة للشحن.
أدوات السحابي-الأصلي يمكن أن تكون قوية وفي نفس الوقت "زائدة" لمعظم فرق المنتج. هندسة المنصات موجودة لسد تلك الفجوة. المهمة بسيطة: تقليل العبء المعرفي لفرق التطبيقات حتى تتمكن من شحن الميزات دون أن تصبح خبراء بنية تحتية جزئيين.
يتعامل فريق المنصة الجيد مع البنية التحتية الداخلية كمنتج داخلي. هذا يعني مستخدمين واضحين (المطورون)، نتائج واضحة (تسليم آمن وقابل للتكرار)، وحلقة تغذية راجعة. بدلًا من تسليم كومة من بدائل Kubernetes، تقدم المنصة طرقًا موجهة لبناء، نشر، وتشغيل الخدمات.
عدسة عملية مفيدة: "هل يستطيع المطور الانتقال من فكرة إلى خدمة تعمل دون فتح عشرات التذاكر؟" الأدوات التي تضغط هذا سير العمل—مع الحفاظ على الحواجز—متوافقة مع هدف منصة السحابي-الأصلي.
معظم المنصات هي مجموعة "طرق مرصوفة" قابلة لإعادة الاستخدام يختارها الفرق افتراضيًا:
الهدف ليس إخفاء Kubernetes—بل تغليفه في افتراضات منطقية تمنع التعقيد العرضي.
في هذا السياق، يمكن استخدام Koder.ai كطبقة "تسريع تجربة المطوّر" للفرق التي تريد إنشاء أدوات داخلية أو ميزات منتج بسرعة عبر الدردشة، ثم تصدير الكود المصدري عند الحاجة للتكامل مع منصة أكثر رسمية. بالنسبة لفرق المنصات، يمكن أن يعكس وضع التخطيط واللقطات/التراجع المضمّن نفس النهج المعتمد على الاعتمادية الذي تريده في سير عمل الإنتاج.
كل طريق مرصوف هو مقايضة: مزيد من التناسق وعمليات أكثر أمانًا، لكن خيارات أقل خارج المألوف. تنجح فرق المنصة عندما تقدم:
يمكن رؤية نجاح المنصة بطرق قابلة للقياس: تسريع اندماج المهندسين الجدد، قلة سكربتات النشر المخصصة، قلة مجموعات "الثلج" الفريدة، ووضوح الملكية عند حدوث الحوادث. إذا استطاعت الفرق الإجابة "من يملك هذه الخدمة وكيف ننشرها؟" بدون اجتماع، فالمنصة تعمل.
سحابي-أصلي هو نهج لبناء وتشغيل البرمجيات بحيث يمكنك النشر بشكل متكرر، التوسع عند تغير الطلب، والاستعادة بسرعة من الأعطال.
عمليًا عادة يتضمن حاويات، أتمتة، خدمات أصغر، وطرق معيارية للمراقبة، الأمن، والحكومة على ما يعمل.
الحاوية تساعدك في إرسال البرمجيات بشكل متسق، لكنها لا تحل بمفردها مشكلات الإنتاج المعقدة مثل التحديثات الآمنة، اكتشاف الخدمات، ضوابط الأمن، والمراقبة الدائمة.
الفجوة تظهر عندما تنتقل من عدد قليل من الحاويات إلى مئات تعمل 24/7.
“تفكير المنصة” يعني التعامل مع البنية التحتية الداخلية كـ منتج داخلي له مستخدمون واضحون (المطوّرون) ووعد واضح (تسليم آمن وقابل للتكرار).
بدلاً من أن يبني كل فريق مساره الخاص إلى الإنتاج، تبني المؤسسة طرقًا مشتركة “طُرُق مرصوفة” (paved roads) مع افتراضات معقولة ودعم.
Kubernetes يوفر الطبقة التشغيلية التي تحوّل “كومة حاويات” إلى نظام يمكنك تشغيله يوميًا:
كما يقدم لوحة تحكم مشتركة تُصرّح فيها بالوضع المرغوب والنظام يعمل لمطابقة الحالة الفعلية.
التكوين التصريحي يعني أن تصف ما تريد (الحالة المرغوبة) بدل كتابة خطوات تنفيذية.
الفوائد العملية:
النشرات غير القابلة للتعديل تعني أنك لا تعبث بالخوادم الحية. تبني آرتيفاكت مرة واحدة (غالبًا صورة حاوية) وتنشر هذا الآرتيفاكت بالضبط.
لتغيير شيء ما، تطرح إصدارًا جديدًا بدل تعديل النظام الجاري. هذا يقلل انحراف التكوين ويسهّل إعادة إنتاج الحوادث والتراجع.
CNCF أوفرت موطن حوكمي محايد لـ Kubernetes ومشاريع ذات صلة، ممّا خفّف المخاطر عند المراهنة على بنية تحتية جوهرية.
ساعدت في:
الحد الأدنى للإنتاج (production baseline) هو مجموعة القدرات والممارسات التي تجعل الاعتمادية متوقعة، مثل:
بدونه، يخترع كل خدمة قواعدها الخاصة وتصبح الاعتمادية مسألة حظ.
هندسة المنصات تركز على تقليل العبء المعرفي للمطوّرين بتغليف مبادئ cloud-native في افتراضات راقية:
الهدف ليس إخفاء Kubernetes، بل جعل المسار الآمن هو الأسهل.
أخطاء شائعة:
التقييدات التي تحافظ على الزخم: