الحوسبة عديمة الخوادم

الحوسبة عديمة الخوادم هي "فئة من خدمات الحوسبة السحابية حيث يمكن للعميل استخدام أنواع مختلفة من إمكانيات الحوسبة السحابية دون الحاجة إلى توفير أو نشر أو إدارة موارد الأجهزة أو البرامج، باستثناء توفير رمز تطبيق العميل أو بياناته. وتمثل الحوسبة بلا خوادم شكلاً من أشكال الحوسبة الافتراضية"، وفقًا لمعيار ISO /IEC 22123-2. وتُعدّ الحوسبة بلا خوادم نظامًا بيئيًا واسعًا يشمل مزود الخدمة السحابية، ووظائف الخدمة (FaaS)، والخدمات المُدارة، والأدوات، والأطر، والمهندسين، وأصحاب المصلحة، وعناصر أخرى مترابطة.

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

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

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

 التحديات 
تُعدّ التطبيقات التي لا تعتمد على الخوادم عرضةً لمغالطات الحوسبة الموزعة. إضافةً إلى ذلك، فهي عُرضة للمغالطات التالية:

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

 المراقبة وتصحيح الأخطاء 
قد يُمثل رصد وتصحيح تطبيقات الحوسبة بلا خوادم تحديات فريدة نظرًا لطبيعتها الموزعة والقائمة على الأحداث وبيئاتها الخاصة. قد تعجز الأدوات التقليدية عن ذلك، مما يُصعّب تتبع مسارات التنفيذ عبر الخدمات. مع ذلك، تُخفف الحلول الحديثة، مثل أدوات التتبع الموزعة (مثل AWS X-Ray وDatadog)، والتسجيل المركزي، ومنصات المراقبة المستقلة عن السحابة، من هذه التحديات. كما تُساهم التقنيات الناشئة، مثل OpenTelemetry، واكتشاف الشذوذ المدعوم بالذكاء الاصطناعي، وأطر العمل الخاصة بالحوسبة بلا خوادم، في تحسين الرؤية وتحليل الأسباب الجذرية. ورغم استمرار التحديات، فإن التطورات في أدوات الرصد والتصحيح تُعالج هذه القيود باستمرار.

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

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

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

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

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

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

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

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

 مبادئ 
يمكن أن يساعد تبني ممارسات DevSecOps في تحسين استخدام وأمان التقنيات التي لا تعتمد على الخوادم.

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

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

 انظر أيضاً 

 كخدمة
 الواجهة الخلفية كخدمة
 الحوسبة السحابية
 الوظيفة كخدمة

 مراجع 

 للمزيد من القراءة 




 14 authors from UC Berkeley (9 February 2019). "Cloud Programming Simplified: A Berkeley View on Serverless Computing".

تصنيف:حوسبة سحابية