كيفية تصميم بنية سحابة هجينة

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

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

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

النقل بالحاويات كنموذج للتعبئة والتغليف لعزل العمليات في أي بيئة ليس مفهومًا جديدًا، ولكن ظهور Docker في عام 2013 كمحرك للحاويات أدى إلى إنشاء بنية تعبئة وتغليف عالمية. علاوة على ذلك، تعمل منصات تنسيق الحاويات مثل Kubernetes على أتمتة نشر Docker—أو أي حاوية أخرى تتوافق مع معايير مبادرة الحاويات المفتوحة (OCI)—عبر بيئات السحابة الهجينة.

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

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

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

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

وقد أدى كل هذا إلى بنية حديثة ومتاحة ومرنة للغاية توفر أداءً عاليًا وكفاءة في استخدام الموارد وتوفيرًا في التكاليف.

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

إستراتيجية التحديث

بالنسبة إلى معظم المؤسسات، تبدأ فكرة الحوسبة السحابية الهجينة بالتحديث أو نقل التطبيقات من البيئة المحلية إلى السحابة، وهناك عدة طرق لتنفيذ ذلك:

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

لوحة تحكم موحدة

تدير فرق العمليات المؤسسية المشهد السحابي عبر مستوى تحكم موحد يوفر تجربة عمليات سحابية متماسكة ومتسقة عبر البيئات. وهي تدعم قدرات إدارة المجموعة الأساسية مثل جدولة أحمال التشغيل وتنسيقها، ومسارات التكامل والنشر المستمرين (CI/CD)، والتسجيل، والقياس عن بُعد، والأمان الموحّد.

يتمثل الهدف في استخلاص التعقيدات الأساسية لمزودي الخدمة السحابية (CSPs) وأوقات التشغيل من فرق التطبيقات وتوفير واجهة مشتركة لفرق العمليات لإدارة أحمال التشغيل في المؤسسة. 

فيما يلي بعض مزايا مستوى التحكم الموحد:

• استخدام إستراتيجيات وضع أحمال التشغيل الديناميكية عبر الأجهزة الافتراضية أو الحاويات أو عمليات النشر بدون خادم.
• الاستمتاع بالقدرة على إعداد مزودين إضافيين أو مواقع الحافة بأقل جهد.
• بناء قدرات المنصة كخدمة (PaaS) مثل الوظيفة كخدمة (FaaS) المتوفرة بدرجة عالية والتي تعمل عبر تطبيقات السحابة المختلفة.
• مركزية إدارة الامتثال.

بوابة واجهة برمجة التطبيقات وشبكة الخدمة

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

تعمل بوابة واجهة برمجة التطبيقات كبوابة أمامية موحدة في جميع المناطق، وهي مسؤولة عن التعامل مع وظائف حركة المرور "شمال-جنوب"، بما في ذلك ما يلي:

• مصادقة المستخدم وتفويضه
• الاختناق وتقييد المعدل
• إدارة حركة المرور
• إدارة دورة حياة واجهة برمجة التطبيقات
• حواجز أمن السحابة
• تحليلات الحافة

من ناحية أخرى، تتعامل شبكة الخدمة مع حركة مرور "شرق - غرب" بين تبعيات الخدمة:

• تأمين الاتصالات بين الخدمات في المجموعة
• إدارة حركة المرور مع موازنة الأحمال، وقواعد التوجيه، وإعادة المحاولة، وعمليات تجاوز الفشل، والتعافي من الكوارث، وحقن الأعطال
• القياس عن بُعد باستخدام المقاييس والسجلات والتتبعات لحركة المرور بأكملها داخل المجموعة، بما في ذلك خروج المجموعة ودخولها
• إمكانية التتبع الموزعة لأداة تدفق الطلب عبر حدود الخدمة
• الاكتشاف الآلي للخدمات

على سبيل المثال، Istio هي طبقة شبكة خدمات مفتوحة المصدر تعمل على توجيه الاتصالات بين الخدمات وفقًا لتكوين محدد مسبقًا يوفره مسؤولو السحابة. وهي تعمل كطرف جانبي لطبقة تنسيق Kubernetes وتعمل مع الحاويات، وهي غير مرئية للمبرمجين والمسؤولين.

الأمان

يتطلب تعقيد بنية السحابة الهجينة نهجًا متعدد المستويات في طبقات مختلفة لضمان الأمان والحماية الشاملة. 

يتحمل مزودو الخدمات السحابية مثل IBM Cloud وAmazon Web Services (AWS) وMicrosoft Azure وGoogle Cloud مسؤولية—وفقًا لاتفاقيات مستوى الخدمة (SLAs)—المصادقة على أي مكالمات في الطبقة المحيطية وتفويضها، وبناء جدار حماية حول تطبيقات المؤسسات. يشمل ذلك حماية من هجوم لحجب الخدمة والامتثال للوائح المتعلقة بالخصوصية مثل اللائحة العامة لحماية البيانات (GDPR) وقانون إخضاع التأمين الصحي لقابلية النقل والمساءلة (HIPAA).

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

تحتوي بيئة الحوسبة السحابية على طبقة إضافية من الأمان في شكل سياسات تحكم محددة في شبكة الخدمة وواجهات برمجة التطبيقات التي تعرضها منصة التنسيق. تضمن هذه السياسات إعادة توجيه المكالمات الآمنة فقط إلى عقدة Kubernetes ومن ثَمَّ إلى الخدمات المصغرة.

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

اتصال الشبكة

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

في بنية السحابة الهجينة، هناك ثلاثة أنماط لتبادل البيانات بين المزودين الأساسيين:

• عناوين IP العامة عبر الإنترنت (ينتج عنه زمن انتقال طويل بسبب النطاق الترددي المشترك)
• الخدمات المُدارة مثل VPN (زمن انتقال أكثر قابلية للتنبؤ مع أمان أعلى)
• الاتصالات المخصصة من خلال نقاط التواجد المشتركة (POPs) (خيار مكلف يقدمه مزودو الخدمات السحابية ولكن بأقل زمن انتقال مع أقصى درجات الأمان)

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

التحيز للمصادر المفتوحة في منصات التطوير

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

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

حتى في مجال حساس مثل الأمن، يُنظر الآن إلى البرمجيات مفتوحة المصدر كخيار رائع، كما ورد في تقرير Red Hat Report on The State of Enterprise Open Source. إن الأمان والجودة ودعم البنية السحابية الأصلية هي أهم الأسباب التي تجعل الشركات تُظهر انحيازًا واعيًا للمصدر المفتوح.

للمزيد راجع مقالة JJ Asghar "تنمية المهن والمجتمعات والشركات باستخدام المصدر المفتوح ".

توفر حلول السحابة الهجينة IBM Cloud المرونة وقابلية النقل لكل من التطبيقات والبيانات. Linux وKubernetes والحاويات تدعم مجموعة السحابة الهجينة وتتحد مع Red Hat OpenShift لإنشاء منصة مشتركة تربط بين الموارد المحلية والموارد على السحابة.

تعرف على المزيد حول حلول السحابة الهجينة المبنية على IBM Cloud.

لبدء إنشاء حلول السحابة الهجينة الخاصة بك، سجل في IBMid  وأنشئ حسابك على IBM Cloud.