توضح هذه المقالة كيفية عقد فريق هندسة البرامج التجارية من Microsoft (CSE) شراكة مع بائع تجزئة عالمي لنشر حل بلا خادم متوفر بشكل كبير عبر كل من الأنظمة الأساسية السحابية ل Azure وAmazon Web Services (AWS)، باستخدام إطار عمل بلا خادم.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
تدفق البيانات
- يمكن أن يأتي تطبيق المستخدم من أي مصدر قادر على تسجيل الدخول إلى السحابة. في هذا التنفيذ، يسجل المستخدم الدخول إلى تطبيق بوابة يوازن تحميل الطلبات من 50 إلى 50 بين سحابتي Azure وAWS.
- توجه أي استجابة أيضًا عبر بوابة API Manager، والتي ترسلها بعد ذلك إلى تطبيق مقدم الطلب.
المكونات
إطار عمل بلا خادم
يستخدم هذا الحل إطار عمل بلا خادم، متوفر من Serverless، Inc. يتضمن الإصدار المجاني من Serverless Framework CLI والمزيد من المكونات الإضافية وخدمات المراقبة المحدودة. يتميز الإصدار Pro بقدرات تشغيلية عبر السحب، مثل المراقبة والتنبيهات المحسنة. يدعم إطار العمل لغات Node.js وPython، وكل من مضيفي سحابة AWS وAzure.
لاستخدام Azure مع إطار عمل بلا خادم، يلزم توفر:
- Node.js، لحزم الخدمات المصغرة
- Azure Functions، لتوفير وظائف يمكن مقارنتها مع الأنظمة الأساسية السحابية الأخرى
- إطار عمل بلا خادم، لدعم التوزيع والمراقبة متعددة السحابة
- مكتبة متعددة السحابة بلا خادم، لتوفير واجهات برمجة تطبيقات وقت التشغيل العادية للمطورين
- المكون الإضافي Azure Functions Serverless، لدعم التوزيع متعدد السحابة. لم يصل هذا المكون الإضافي في البداية إلى التماثل مع المكون الإضافي AWS Lambda القابل للمقارنة، وتم تمديده لهذا المشروع.
يوضح الشكل التالي معالجة البنية الأساسية لبرنامج ربط العمليات التجارية. تمثل طبقات البرامج الوسيطة أي وظائف وسيطة مطلوبة قبل الوصول إلى المعالج.
واجهات برمجة التطبيقات غير المتصلة بالسحابة
يدعم التنفيذ بلا خادم على كل نظام أساسي الوظائف الفردية كخدمات مُصغرة، خدمة واحدة لكل عقدة وظيفية للجهاز الظاهري، وينفذ المعالجة حسب الحاجة. تحتوي كل دالة AWS Lambda على دالة Azure Functions مقابلة. تنشئ مكتبة متعددة السحابة بلا خادم خدمات مُصغرة مماثلة من أي سحابة إلى واجهة برمجة تطبيقات REST غير المتصلة بالسحابة يمكن لتطبيقات العميل استخدامها للواجهة مع أي من النظامين الأساسيين. نظرًا لأن طبقة واجهة برمجة التطبيقات المجردة توفر تعليمة برمجية لمعالجة الخدمات المُصغرة المقابلة لكل نظام أساسي، لا تحتاج المعاملات إلى ترجمة. تتيح الواجهة غير المتصلة بالسحابة لتطبيقات المستخدم التفاعل مع السحابة دون معرفة النظام الأساسي للسحابة الذي يمكنهم الوصول إليه أو الاهتمام به.
يوضح الرسم التخطيطي التالي هذا المفهوم:
CI/CD مع GitOps
الوظيفة الأساسية لإطار العمل بلا خادم هي تجريد جميع مخاوف البنية الأساسية لتوزيع تطبيق على السحابة. باستخدام نهج قائم على البيان، يمكن ل Serverless Framework التعامل مع جميع مشكلات النشر، ما يسمح بالنشر تلقائيا حسب الحاجة لدعم GitOps.
على الرغم من أن هذا المشروع الأولي استخدم عمليات التوزيع اليدوية، إلا أنه في الواقع يتم تنفيذ البنيات والاختبارات والنشرات بلا خادم المستندة إلى البيان داخل السُحب أو عبرها. يمكن لهذه العملية استخدام سير عمل مطور GitOps: البناء من Git، واستخدام بوابات الجودة للاختبار والتقييم، ودفع الحلول بلا خادم على كل من موفري خدمة السحابة. يعد تنفيذ جميع عمليات التوزيع باستخدام إطار عمل بلا خادم من بداية المشروع هو أكثر الطرق كفاءة للمتابعة.
مدير واجهة برمجة التطبيقات
يمكن أن يكون مدير واجهة برمجة التطبيقات تطبيقًا موجودًا أو مخصصًا. كان Apigee™ API Manager في هذا التنفيذ يعمل فقط بمثابة موجه لتوفير معاملة موازنة التحميل 50-50 إلى النظامين الأساسيين السحابيين، ولم يتم استخدامه بشكل جيد بفضل إمكانياته.
يجب أن يكون مدير واجهة برمجة التطبيقات قادرًا على:
- يتم توزيعه داخل أو خارج نظام أساسي سحابي حسبما يقتضي الأمر
- توجيه الرسائل من كلا النظامين الأساسيين السحابيين وإليهما
- تسجيل طلبات نسبة استخدام الشبكة لتنسيق نسبة استخدام الشبكة للرسائل غير المتزامنة
- ترحيل الطلبات والاستجابات باستخدام واجهة برمجة تطبيقات REST الشائعة من تطبيق المستخدم وإليه
- مراقبة صحة كل من عمليات توزيع إطار العمل بلا خادم على السحابة للتحقق من قدرتها على تلقي الطلبات
- إجراء فحوصات السلامة ومدى التوفر التلقائية على كل نظام أساسي سحابي، لدعم التوجيه وقابلية الوصول العالية
البدائل
يمكن للغات الأخرى مثل Python تنفيذ الحل، طالما أنها مدعومة بواسطة التطبيقات بلا خادم للأنظمة الأساسية السحابية وAWS Lambda وAzure Functions في هذه الحالة. استخدم هذا المشروع Node.js لحزم الخدمات المُصغرة، لأن العميل كان مرتاحا في استخدام Node.js، وتدعمه كل من أنظمة AWS وAzure الأساسية.
يمكن للحل استخدام أي نظام أساسي سحابي يدعم إطار عمل بلا خادم، ولا يقتصر الأمر على Azure وAWS. حاليًا، يُبلغ Serverless Framework عن التوافق مع ثمانية موفري خدمة سحابة مختلفين. أحد المحاذير الواجب معرفتها هي التأكد من أن العناصر التي تدعم البنية متعددة السحابة أو ما يعادلها متاحة على الأنظمة الأساسية السحابية المستهدفة.
يعمل مدير واجهة برمجة التطبيقات في هذا التنفيذ فقط بمثابة موجه لتوفير معاملة موازنة التحميل 50-50 إلى النظامين الأساسيين السحابيين. يمكن أن يتضمن مدير واجهة برمجة التطبيقات منطق آخر لتسلسل العمل لسيناريوهات محددة.
تفاصيل السيناريو
في الحوسبة بلا خادم، يخصص موفر خدمة السحابة موارد الخدمات المصغرة ديناميكيًا لتشغيل التعليمات البرمجية، ويخصم فقط تكاليف الموارد المستخدمة. تعمل الحوسبة بلا خادم على تجريد التعليمات البرمجية للتطبيق من تنفيذ البنية الأساسية وتوزيع التعليمات البرمجية والجوانب التشغيلية مثل التخطيط والصيانة.
كما هو الحال مع الخدمات الأخرى، يتمتع كل موفر خدمة السحابة بعملية التنفيذ بلا خادم، ومن الصعب على العملاء استخدام موفر مختلف دون أن يخلف أثرًا كبيرًا على صعيد العمليات والتكاليف على حد سواء. قد ينظر العملاء المحتملون إلى هذا الوضع على أنه يضعف موقفهم التفاوضي وسرعته. يعد تأمين المورد واحدا من أكبر العقبات التي تحول دون اعتماد سحابة المؤسسة.
Serverless Framework مفتوح المصدر هو واجهة سحابية عالمية لتطوير حلول الحوسبة بلا خادم وتوزيعها عبر موفري خدمة السحابة. تساعد المصادر المفتوحة وواجهات برمجة التطبيقات الشائعة للوظائف بلا خادم موفري الخدمة والعملاء والشركاء على إنشاء حلول عبر السحابة للحصول على أفضل الخدمات. يقلل إطار عمل بلا خادم من الحواجز التي تحول دون اعتماد السحابة من خلال معالجة مشكلات تأمين المورد وتكرار موفر خدمة السحابة. يمكن للعملاء تحسين حلولهم بناء على التكلفة والسرعة واعتبارات أخرى.
يقوم CSE وفريق منتج Azure بإعادة كتابة Serverless CLI بشكل جماعي لدعم ميزات Azure Functions الجديدة مثل Premium Functions وAPIM وKeyVault. يوفر CLI بلا خادم الآن واجهة قياسية لتوزيع GitOps إلى كل من Azure وAWS. طور الفريق أيضًا مكتبة متعددة السحابة بلا خادم، والتي توفر واجهة برمجة تطبيقات وقت تشغيل عادية لتوزيع التطبيقات بلا خادم على كل من AWS وAzure.
يوفر هذا التصميم توفرًا عاليًا مع تجاوز الفشل النشط-النشط بين الأنظمة الأساسية السحابية المتعددة، بدلا من تجاوز الفشل النشط-السلبي . إذا أصبحت خدمة موفر خدمة السحابة واحد غير صحية أو غير متوفرة، يمكن لهذا الحل إعادة توجيه الطلبات إلى نظام أساسي سحابي آخر.
وقد استوفى هذا المشروع الأهداف التقنية التالية:
- إنشاء حل عبر الصناعة.
- استخدم مكتبة Multicloud Serverless لدعم واجهة برمجة تطبيقات غير المتصلة بالسحابة التي تتفاعل مع الخدمات المصغرة أينما تم توزيعها.
- دعم سير عمل عملية GitOps CI/CD للتطوير والاختبار والتوزيع على جميع الأنظمة الأساسية السحابية المدعومة.
- استخدم الوصول المستند إلى واجهة برمجة التطبيقات عبر بوابة سحابية مصادق عليها، وموازنة التحميل بين الأنظمة الأساسية السحابية باستخدام البوابة بمثابة موجه.
تشمل الفوائد المحتملة الأخرى لاستخدام إطار عمل بلا خادم ما يلي:
- منع تأمين المورد أو تقليله
- تقليل التعليمات البرمجية بنسبة 40-60+% أثناء التطوير باستخدام مكتبة Multicloud Serverless Library
- وضع أفضل الحلول التي تجمع بين خدمات موفري الخدمات السحابية المختلفة
- القضاء على معظم متطلبات تعقيد الأنظمة الأساسية والبنية الأساسية وصيانتها
- مشاركة البيانات بسهولة، والمقارنات بين الأداء والتكلفة، والقدرة على الاستفادة من العروض الخاصة
- قابلية وصول عالية نشطة-نشطة
حالات الاستخدام المحتملة
- دوّن التطبيقات من جانب العميل لمنصات متعددة باستخدام واجهة برمجة تطبيقات غير متصلة بالسحابة من مكتبة متعددة السحابة بلا خادم.
- توزيع مجموعة من الخدمات المصغرة الوظيفية في إطار عمل بلا خادم إلى أنظمة أساسية سحابية متعددة.
- استخدم تطبيقا غير متصل بالسحابة عبر الأنظمة الأساسية السحابية دون معرفة النظام الأساسي الذي يستضيفه أو الاهتمام به.
الاعتبارات
لا تصف هذه المقالة حلول الأمان، على الرغم من أن التوزيع الأولي تضمنها. توجد العديد من الحلول الأمنية المحتملة، وبعضها يعتمد على النظام الأساسي، ويجب أن يستوعب إطار العمل هذا أي حل معقول. مصادقة المستخدم هي الحد الأدنى من الأمان المفترض.
نظرًا لأنه من الصعب توضيح أوجه الاختلاف بين عروض AWS وAzure الوظيفية بلا خادم، يجب أن يركز بذل الجهد المبكر على تعيين الوظائف المتاحة على كل نظام أساسي سحابي وتحديد متطلبات التحويل الضرورية. يمكنك تطوير واجهة برمجة تطبيقات غير متصلة بالنظام الأساسي من هذه المعلومات.
قد يؤدي استخدام حل مفتوح المصدر إلى التعرض لمخاطر الناتجة عن الصعوبات المتعلقة بالصيانة والدعم طويلة الأجل مع أي برامج مفتوحة المصدر.
في إطار العمل بلا خادم المجاني، تقتصر المراقبة بشكل أساسي على لوحة المعلومات الإدارية. المراقبة متاحة في عرض المؤسسة المدفوعة. حاليا، لا يتضمن المكون الإضافي Azure Functions Serverless بنودًا لقابلية الملاحظة أو المراقبة، وسيلزم إدخال تعديل لإعمال هذه القدرات.
يمكن لهذا الحل استخدام المقاييس لمقارنة الأداء والتكاليف بين الأنظمة الأساسية السحابية، ما يمّكن العملاء من الاستخدام على النحو الأمثل عبر الأنظمة الأساسية السحابية بسلاسة.
نشر هذا السيناريو
يقوم التوزيع الأزرق والأخضر التقليدي بإنشاء تطبيق وتوزيعه في بيئتين منفصلتين ولكن متماثلتين، الأزرق والأخضر، مما يؤدي إلى زيادة التوافر ويقلل من المخاطر. غالبًا ما تكون البيئة الزرقاء هي بيئة التشغيل التي تتعامل دائمًا مع نسبة استخدام الشبكة المباشرة، والبيئة الخضراء هي توزيع تجاوز الفشل حسب الضرورة. تقوم البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD تلقائيًا بتوزيع كل من البيئات الزرقاء والخضراء غالبًا داخل نفس النظام الأساسي السحابي. يعتبر هذا التكوين تكوينا نشطا-سلبيًا .
في الحل متعدد السحابة، يتم تنفيذ التوزيع الأزرق والأخضر في كلا النظامين الأساسيين السحابيين. في حالة بلا خادم، يتم توزيع مجموعتين مكررة من الخدمات المُصغرة لكل نظام أساسي سحابي، واحدة بمثابة بيئة التشغيل والأخرى بمثابة بيئة تجاوز الفشل. يقلل هذا الإعداد النشط-السلبي داخل كل نظام أساسي سحابي من خطر انخفاض هذا النظام الأساسي، وزيادة توافره، وتمكين قابلية الوصول العالية النشطة-النشطة متعددة السحابة.
تتمثل الميزة الثانوية للتوزيع الأزرق والأخضر في القدرة على استخدام توزيع تجاوز الفشل على كل نظام أساسي سحابي بمثابة بيئة اختبار لتحديثات الخدمات المُصغرة، قبل إصدارها إلى توزيع الإنتاج.