السحابة الهجينة ومتعددة المزودين

من يملك ماذا: مشكلتان مختلفتان

يحتفظ بنك إقليمي بسجل معاملاته الأساسي، المبني قبل 40 سنة، على حاسوب مركزي (mainframe) داخل مركز بياناته الخاص. نقل هذا التاريخ الطويل من البيانات، مع سجل تدقيق يخضع لمراقبة جهة تنظيمية صارمة، ليس قراراً يُتخذ بسهولة. لكن البنك يريد أيضاً أن يعمل تطبيقه الجديد للهاتف المحمول على بنية تحتية تمتص ذروة حركة موسم التسوق دون شراء خوادم يستخدمها 3 أيام في السنة فقط. هذه مشكلة واحدة: كيف تربط بنية تحتية لا يمكنك التخلي عنها ببنية تحتية تريد إضافتها.

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

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

السحابة الهجينة: بنيتان مرتبطتان بتقنية واحدة

يعرّف NIST السحابة الهجينة بأنها "تركيبة من بنيتين متمايزتين أو أكثر من البنى السحابية (خاصة أو مجتمعية أو عامة) تبقى كيانات فريدة، لكن تُربَط معاً بتقنية موحدة أو خاصة تتيح نقل البيانات والتطبيقات (كالتدفق السحابي لتوزيع الحمل بين السحب)." اقرأ هذا التعريف بعناية: تبقى الأجزاء منفصلة. حاسوب البنك المركزي لا يصبح جزءاً من AWS، و AWS لا يصبح جزءاً من مركز بيانات البنك. ما يربط بينهما طبقة، بُنيت خصيصاً لنقل البيانات وأعباء العمل بين الاثنين، تجعل الحد الفاصل بينهما غير محسوس قدر الإمكان لمن يستخدمهما.

هذه الطبقة الرابطة فئة منتجات حقيقية، وتبيعها عدة جهات بالضبط لهذا الغرض. AWS Outposts يمدّ عتاد AWS وواجهاته البرمجية وخدماته إلى مركز بيانات الشركة نفسه، فيستطيع الفريق تشغيل الأدوات نفسها داخلياً وفي السحابة العامة دون تعلّم منصتين مختلفتين. Azure Arc من Microsoft يؤدي المهمة نفسها لـ Azure: يدير الخوادم الداخلية وعناقيد Kubernetes وقواعد البيانات كأنها موارد Azure، أينما وُجدت فعلياً. الهدف في الحالتين واحد: قابلية النقل، أي تحريك تطبيق أو مجموعة بيانات عبر الحد الفاصل دون إعادة بنائها.

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

السحابة متعددة المزودين: أكثر من مزوّد سحابة عام واحد

تعني السحابة متعددة المزودين (Multi-Cloud) شيئاً أضيق مما يوحي به الاسم: استخدام خدمات سحابة عامة من مزوّدين منفصلين أو أكثر، AWS و Google Cloud مثلاً، بدل الالتزام الكامل بمزوّد واحد.

نمط التطبيق الاجتماعي في المقدمة نمط واقعي، لا افتراضي. التزمت Snap Inc، الشركة المالكة لـ Snapchat، بإنفاق 2 مليار دولار على الأقل مع Google Cloud خلال 5 سنوات ابتداءً من 2017، عقد بلغ من الضخامة أن نشرة اكتتابها العام (IPO) نفسها أدرجته كمخاطرة مالية كبرى. رد فعل Snap كان إضافة التزام ثانٍ ومنفصل: مليار دولار على الأقل مع AWS بحلول نهاية 2021، لما وصفته نشرتها بـ"دعم بنية تحتية احتياطية". تعمل بنية Snap اليوم كخدمات مصغّرة (microservices) موزّعة بين المزوّدين معاً، فلا يستطيع تسعير مزوّد واحد أو انقطاعه أو تجديد عقده أن يفرض شروطه على كل شيء.

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

الحد الفاصل بين النموذجين، ولماذا "كلاهما" شائع

تجيب السحابة الهجينة ومتعددة المزودين عن سؤالين مختلفين، والسيناريو عادة يختبر واحداً منهما فقط.

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

فخ يستحق التسمية المباشرة: تشغيل أعباء العمل في منطقتين مختلفتين للمزوّد نفسه، منطقتي AWS مثلاً، ليس تعدد مزودين. يعني تعدد المزودين تحديداً مزودين منفصلين. تشغيل أعباء العمل في مناطق متعددة لمزوّد واحد أسلوب لتحسين الموثوقية داخل سحابة واحدة، مفهوم مختلف يغطيه هذا المقرر لاحقاً.

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

ما تحمله معك

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