إطار عمل IBM Well-Architected Framework
التهجين هو القدرة على تشغيل أعباء العمل داخل سحابة واحدة أو عبر عدة سحابات عامة، أو خاصة، أو محلية. توفِّر السحابة الهجينة التنسيق والإدارة وقابلية نقل التطبيقات عبر البنية التحتية العامة والخاصة والمحلية. النتيجة هي بيئة حوسبة موزعة موحَّدة ومرنة تمكِّن المؤسسة من تشغيل وتوسيع أعباء العمل التقليدية أو السحابية الأصلية على نموذج الحوسبة الأنسب.
القابلية للنقل هي القدرة على نقل أعباء العمل والبيانات بين بيئات الحوسبة السحابية، ما يمكِّن من الانتقال من سحابة عامة إلى أخرى أو حتى إلى سحابة خاصة دون الحاجة إلى إعادة تكوين كبيرة لأعباء العمل.
يسهِّل الجمع بين مبادئ التهجين والقابلية للنقل تحقيق التشغيل البيني. ويشمل ذلك المنصات والبيانات والتطبيقات. تمتلك التطبيقات المبنية وفق مبادئ التصميم درجة أعلى من التشغيل البيني.
تعتمد المؤسسات استراتيجية متعددة السحابة لتجنُّب التقيّد بمورِّد واحد أو بسبب متطلبات موقع البيانات. كما ترغب في القدرة على نقل أو ترحيل أعباء العمل من سحابة إلى أخرى أو تشغيل التطبيقات على عدة سحابات. تصميم التطبيقات السحابية مع مراعاة القابلية للنقل والتشغيل البيني هو مفتاح نجاح هذه المؤسسات.
يجب بناء أعباء العمل مرة واحدة ونشرها بشكل متسق في كل مكان. لا تحتاج أعباء العمل إلى تعديل أو تكوين لتناسب الخدمات أو القيود الخاصة بالمنصة التي تتم استضافتها عليها. هذا هو في الواقع شعار IBM Red Hat OpenShift، منصة حاويات السحابة الهجينة المتاحة تقريبًا على كل السحابات العامة. تستند بقية المبادئ في هذه الركيزة إلى تحقيق هذا المثال المثالي.
تفصل الحاويات أعباء العمل عن البنية التحتية التي تستضيفها. وهذا يجعل أعباء العمل المعبأة في حاويات قابلة للنقل إلى أي منصة تستضيف بيئة تشغيل حاويات متوافقة، وبالتالي تُعَد الحاويات التقنية المفضلة لتغليف ونشر التطبيقات.
يُعَد Kubernetes منصة مفتوحة المصدر لنشر وإدارة أعباء العمل المعبأة في حاويات على أي محرك حاويات يدعم واجهة تشغيل حاويات Kubernetes (CRI). يمكن استخدام Kubernetes ومنصات الإدارة المستندة إليه لإدارة أعباء العمل المعبأة في حاويات على السحابات العامة والخاصة، وكذلك على البنية التحتية المحلية.
أعباء العمل التي تعتمد على تمثيل أو نوع محدد من البنية التحتية تكون قابلة للنقل فقط إلى البيئات التي تحتوي على البنية التحتية نفسها. استخدام أداة برمجة لا تعتمد على نوع السحابة لتحديد البيئة أو كيفية تكوين التطبيقات. ثم استخدام أداة الأتمتة للنشر بشكل متسق عبر أي سحابة وحتى على البنية التحتية المحلية. استخدام البنية التحتية ككود (IaC) لنشر التطبيقات يسهِّل النشر على أي سحابة أو الانتقال من سحابة إلى أخرى. من مزايا IaC الأخرى أنها تساعد على التوسع ومنع الانحراف في التكوين. كما تجعل عملية النشر أكثر قابلية للنقل.
إن أعباء العمل التي تعتمد على خدمات أصلية للمنصة تصبح "مقيدة" بالمنصة. يجب على الحلول اعتماد واجهات برمجة التطبيقات (APIs) والخدمات القياسية في الصناعة، المستقلة عن المنصة التي يتم نشر الخدمة عليها.
لتحقيق القابلية للنقل بشكل كامل، قد تفكر الفِرق في اعتماد حلول مفتوحة المصدر كجزء من البنية لتقليل التقيّد بالمنصة الذي قد يعقد الأمر.
قد يتم اختيار البرمجيات مفتوحة المصدر بسبب تكلفتها المنخفضة أو عدم وجود تكلفة، أو المرونة في تخصيص الكود المصدر، أو وجود مجتمع دعم كبير للتطبيق. ومع ذلك، قد تتحمل الفِرق تكاليف أخرى عادةً ما تشمل تكامل الشبكات، ودعم المستخدم النهائي وفِرق تكنولوجيا المعلومات، وخدمات أخرى غالبًا ما تكون مدمجة مع البرمجيات الخاصة. بشكل عام، تجب موازنة هذا القرار مع دراسة الجدوى والأولوية في إمكانية نقل أعباء العمل.
يُعَد اختيار منصة نشر مثل Red Hat OpenShift المشتركة عبر جميع البيئات أمرًا أساسيًا لتحقيق القابلية للنقل والتشغيل البيني عبر السحابات المتعددة والبيئات المحلية. تستخدم الحلول المصممة بشكل جيد الحاويات كوحدة نشر مشتركة نظرًا لصغر حجمها والدعم الواسع عبر معظم أنظمة التشغيل ومزوِّدي الخدمات السحابية ومنصات البنية التحتية.
الحاويات، مثل Docker، تفصل أعباء العمل عن البنية التحتية التي تستضيفها. وهذا يجعل أعباء العمل المعبأة في حاويات قابلة للنقل إلى أي منصة تستضيف بيئة تشغيل حاويات متوافقة.
تعمل منصة تنسيق الحاويات مثل Kubernetes على أتمتة نشر التطبيقات عبر البيئات السحابية. كما يمكنها إدارة أعباء العمل المعبأة في حاويات. يُعَد Kubernetes منصة مفتوحة المصدر لنشر وإدارة أعباء العمل المعبأة في حاويات على أي محرك حاويات يدعم واجهة تشغيل حاويات Kubernetes (CRI). يتم استخدام Kubernetes ومنصات الإدارة المستندة إليها لإدارة أعباء العمل المعبأة في حاويات على السحابات العامة والخاصة، وكذلك على البنية التحتية المحلية.
قد يكون تكوين ونشر التطبيقات على سحابات متعددة أمرًا معقدًا، وقد تكون عمليات اليوم الثاني (Day 2 Operations) مرهقة. تُعَد الأدوات المستقلة عن نوع السحابة، مثل Ansible وTerraform وChef وPuppet ضرورية. تُعَد Ansible أداة مفتوحة المصدر لأتمتة تكنولوجيا المعلومات، تعمل على أتمتة التزويد وإدارة التكوين ونشر التطبيقات والتنسيق سواء في السحابة أم على البنية التحتية المحلية. يمكن استخدامها لأتمتة تثبيت البرمجيات، وتجهيز البنية التحتية، وحتى تحسين الأمن والامتثال من خلال تطبيق التحديثات بشكل دوري.
تزويد مئات أو آلاف الخوادم يدويًا غير عملي، ولهذا تفضِّل المؤسسات استخدام أدلة Ansible لتحقيق توسُّع سريع وموثوق به في تكنولوجيا المعلومات. باستخدام دليل Ansible، يمكن بناء نسخة واحدة، ثم استخدامها فورًا على النسخة نفسها أو أي عدد من الخوادم الإضافية مع معايير البنية التحتية نفسها.
تكوين السحابة الموزعة يُتيح استهلاك الخدمات السحابية في أي مكان تحتاجه، ونشر وإدارة والتحكم في أعباء العمل عبر البيئات المحلية، وبيئات حوسبة الحافة، والسحابات العامة من أي مورِّد خدمات سحابية. يقدِّم IBM Cloud Satellite الخدمات السحابية، وواجهات برمجة التطبيقات، وسياسات الوصول، والتسجيل، والمراقبة عبر جميع المواقع. وهذا يوفر جميع مزايا السحابة للبنية التحتية المحلية ويُتيح المرونة لنقل أعباء العمل إلى سحابات مزوِّدين آخرين وفق السياسات. مع الانتشار الواسع لأجهزة الحافة وزيادة حجم البيانات، تصبح قابلية نقل الحوسبة أقرب إلى "جاذبية البيانات" أكثر فاعلية من حيث التكلفة. كما تعزز الأمن وتبسِّط عمليات اليوم الثاني (Day 2 Operations).
على الرغم من أن الأمن يشكِّل ركيزة منفصلة، إلا إنه يغطي جميع جوانب الحوسبة السحابية، سواء أكانت سحابة خاصة، أم عامة، أم بنية تحتية محلية. تضيف المرونة في نقل أعباء العمل إلى بيئات مختلفة مزيدًا من التحديات الأمنية. لا يمكن التضحية بالأمن مقابل قابلية النقل. ويجب اعتماد استراتيجية أمنية متعددة الطبقات عبر البنية التحتية، ومكدس التطبيقات، ودورة حياة التطبيقات بأكملها.