الحوسبة بدون خادم

6 دقائق

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

ينقل النظام الأساسي كخدمة (PaaS) جزءًا من هذه المسؤولية إلى موفر خدمة السحابة وأدى إلى زيادة الاستثمارات في السحابة. مع خدمات مثل AWS Elastic Beanstalk وAzure App Service، يستطيع العملاء تزويد خوادم الويب الظاهرية المناسبة لأوقات التشغيل الشهيرة، مثل Java، وNode.js، وMicrosofy.NET، كما يمكنهم تشغيل البرامج عليها في غضون دقائق. بينما تتحمل الأجهزة الظاهرية القدر الأثقل من المسؤولية خلف الستار، فإنه يتم تجاهل وجود الأجهزة الظاهرية هذه بشكل كبير. يسمح النظام الأساسي كخدمة (PaaS) للعملاء بالتركيز على التطبيقات التي سيجرون الكتابة عليها لحل مشكلات النشاط التجاري بدلاً من استخدام الدورات في إدارة الأجهزة الظاهرية والحفاظ على سلامة الأنظمة الأساسية وتحديثها.

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

يمكنك اتباع نهج IaaS عن طريق إنشاء جهاز ظاهري واحد أو أكثر لتشغيل التعليمات البرمجية وتثبيت الأنظمة الأساسية والمكتبات المطلوبة. يمكنك تزويد مثيل Elastic Beanstalk أو App Service واستضافة التعليمة البرمجية هناك. أو يمكنك استخدام وقت التشغيل للوظيفة، مثل AWS Lambda أو Azure Functions لتنفيذ تعليمتك البرمجية وقتما تشاء بصرف النظر عن مكان أو كيفية استضافتها. AWS Lambda وAzure Functions هما مثالان على الحوسبة بلا خادم (على وجه التحديد، للوظائف بلا خادم)، وكذلك Google Cloud Functions. والأمثلة الثلاثة تُشكل الخطوة التالية في التطور الطبيعي لحوسبة السحابة بدايةً من خدمة تأجير البنية التحتية (laaS)، حيث تتحمل مسؤولية كل شيء، وصولاً إلى الوظائف بلا خادم، حيث تركز على الإجراءات التي ترغب في تنفيذها (المعلمة البرمجية التي ترغب في تنفيذها) في السحابة، والسماح لموفر خدمة السحاب بإدارة كل شيء آخر.

تُعد الوظائف بلا خادم التي يتم تنفيذها حسب أوقات تشغيل الوظائف في السحابة هي الشكل الأكثر شيوعًا من الحوسبة بلا خادم، ولكنها ليست الشكل الوحيد لها. توفر Amazon وMicrosoft وGoogle إصدارات بلا خادم لبعض خدمات النظام الأساسي كخدمة (PaaS) لديها، بما في ذلك قواعد البيانات بلا خادم. يقدم بعض الموفرين الدعم لسير العمل بلا خادم، ما يتيح لك تحديد مهام سير العمل في السحابة وتنفيذها استجابة لأحداث خارجية مثل الفواتير التي يتم تحميلها إلى التخزين السحابي، أو المؤقتات التي يتم تشغيلها على فترات زمنية محددة، أو رسائل البريد الإلكتروني التي تصل إلى علبة وارد -- غالبا دون كتابة سطر واحد من التعليمات البرمجية. وأخيرًا، فإن العديد من خدمات الحاويات التي يقدمها موفرو خدمات السحابة، بما في ذلك مثيلات Azure Container Instances وخدمة AWS Elastic Container Service، تعتبر أمثلة على الحوسبة بلا خادم لأنها تتيح لك تشغيل الحاويات في السحابة بينما يتم تجاهل البنية الأساسية.

فوائد الحوسبة بلا خادم

توفر الحوسبة بلا خادم ثلاث فوائد أساسية للمؤسسات التي تستفيد من حوسبة السحابة:

انخفاض تكاليف الحوسبة: يدفع العملاء عادة رسوما شهرية لأجهزة IaaS الظاهرية وخدمات PaaS مثل Elastic Beanstalk وAzure App Service. ويستمر إعداد الفواتير حتى إذا كانت الخدمات معطلة. ومع ذلك، تدعم معظم خدمات الحوسبة بلا خادم تسعير الاستهلاك، حيث تتم محاسبتك فقط على الوقت الذي يتم فيه تنفيذ التعليمات البرمجية الخاصة بك. تخيّل أنك تقوم بتخصيص جهاز ظاهري تبلغ تكلفته 100 دولار أمريكي كل شهر من أجل تشغيل تعليمة برمجية تجري النسخ الاحتياطي ليلاً على البيانات الحساسة للمهام، وأن هذه التعليمة البرمجية تعمل لمدة 30 دقيقة كل ليلة. أنت تدفع 100 دولار أمريكي في الشهر لتنفيذ تعليمة برمجية 1/48^th^ في الشهر، أو أقل من يوم واحد. إن توزيع نفس التعليمة البرمجية التي يتم استخدامها مع الوظيفة بلا خادم يمكن أن يكلفك بضعة دولارات كل شهر. فمع أسعار الاستهلاك، أنت لا تدفع مقابل وقت عدم النشاط.

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

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

ولكن توجد سلبيات للحوسبة بلا خادم أيضًا. وتشتمل بعض القيود التي يلزم اعتبارها على ما يلي:

تفرض بعض أوقات تشغيل الوظائف قيودًا على الفترة الزمنية التي يُسمح فيها بتنفيذ الوظيفة.
وبعض أوقات تشغيل الوظائف لا تضمن تنفيذ الوظيفة على الفور إذا كنت لا ترغب في تحمل المزيد من التكلفة من أجل إجراء ذلك. مع وظائف Azure Function التي تم تكوينها لاستخدام نموذج الأسعار المستند إلى الاستهلاك، على سبيل المثال، قد لا يتم تنفيذ وظيفة لمدة تصل إلى 10 دقائق بعد تشغيلها. قد لا تكون هذه مشكلة بالنسبة للنسخ الاحتياطي ليلاً؛ ربما لا تهتم بما إذا كان يتم تشغيل النسخ الاحتياطي في الساعة 1:00 صباحاً أو 1:10 صباحاً، ولكن يمكن أن يؤدي ذلك إلى تعطل قاطع دوائر الوظائف ذات الأهمية الزمنية - وهي الوظائف التي يجب تنفيذها في الوقت الفعلي (أو قريب من الوقت الحقيقي).
وعادةً ما تكون الوظائف بلا خادم عديمة الحالة أيضًا، أي أنه لا يمكنها تخزين البيانات داخليًا وتوقع استمرارها من استدعاء وظيفة إلى أخرى. يمكنهم استخدام خدمات التخزين السحابي الخارجية مثل Amazon S3 وAzure Storage لاستمرار البيانات بين المكالمات، ولكن هذا يجعل التعليمات البرمجية للوظيفة أكثر تعقيدا.

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

الوظائف بلا خادم

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

يسرد الشكل 11 لغات الكمبيوتر المدعومة من قِبل الوظائف بلا خادم في Azure وAWS وGCP وقت كتابة هذا المحتوى:

اللغة	دالات Azure	AWS لامدا	وظائف Google Cloud
C#‎	×	×
F#‎	×
انتقال		×	×
Java	×	×
جافا سكريبت (Node.js)	×	×	×
PowerShell	×	×
Python	×	×	×
Ruby		×
TypeScript	×

الشكل 11: لغات البرمجة المدعومة من قبل أوقات تشغيل الوظائف بلا خادم الشائعة.

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

عادةً ما تُستخدم الوظائف بلا خادم لإجراء المهام المنفصلة بذاتها، مثل عمليات النسخة الاحتياطية الفوترة التي تتم ليلاً. كما أنها تُستخدم لتوصيل خدمات السحابة الأخرى وإنشاء حلول غنية باستخدام خدمات السحابة ككتل لإنشاء البنية. يقدم الشكل 12 أحد الحلول المُستخدمة في الجمع بين العديد من خدمات Azure لمراقبة نشاط الدب القطبي في القطب الشمالي. تؤدي وظيفة Azure Function دورًا رئيسيًا في الهندسة من خلال أخذ الإخراج من Azure Stream Analytics (الناتج عن مكالمة HTTP)، واسترجاع صورة من Azure Blob Storage، وتقديم الصورة إلى نموذج تم تدريبه باستخدام Azure Custom Vision Service، والتي تستخدم الذكاء الاصطناعي (AI) لتحديد ما إذا كانت الصورة تحتوي على دب قطبي أم لا. تتصرف الوظيفة بوصفها «حلقة الوصل» التي تربط بين Stream Analytics وBlob Storage وCustom Vision Service معًا.

الشكل 12: استخدام وظيفة Azure Function للاتصال بخدمات Azure أخرى.

الشكل 12: استخدام وظيفة Azure لتوصيل خدمات Azure الأخرى.

سير العمل بلا خادم

تسمح بعض خدمات الحوسبة بلا خادم للعملاء بتشغيل سير العمل تلقائيًا دون كتابة التعليمات البرمجية للقيام بذلك. على سبيل المثال، توفر Azure Logic Apps أكثر من 100 موصل مضمن للتداخل مع مصادر البيانات التي تتراوح بين قواعد بيانات Oracle وخدمات الوسائط الاجتماعية مثل X. وهي توفر مشغلات لتحديد متى يجب تنفيذ مهام سير العمل - على سبيل المثال، عند تحميل ملف إلى Box.com أو تغريد شيء ما باستخدام علامة تجزئة محددة. كما أنها توفر مئات الإجراءات المحددة مسبقا التي تحدد ما يحدث عند تشغيل المشغل والتي يمكن ربطها معا لتشكيل مهام سير عمل معقدة، والشروط التي تسمح بتنفيذ الإجراءات بشكل مشروط. وهي قابلة للتوسيع بلا حدود، لأن أحد الإجراءات التي تدعمها تطبيقات Azure Logic هي الإجراءات التي تستدعي وظيفة Azure Function. إذا كان سير العمل يتضمن منطقًا مُخصصًا غير مغلف في إجراء ما، فإنه يمكنك تزويد التعليمات البرمجية التي تنفذ هذا المنطق وتضمينها في سير العمل كما لو كان إجراءً تم تعريفه مسبقًا.

يوضح الشكل 13 سير عمل واحد من هذا القبيل في مصمم^{Azure Logic Apps 1}. عند وصول رسالة بريد إلكتروني، يقوم Logic App بتطبيق الإجراء ويتحقق من وجود عبارة رئيسية في سطر موضوع البريد الإلكتروني ووجود مرفق. إذا تم استيفاء كلا الشرطين، فإن Logic App يستدعي Azure Function لتجريد أي HTML من نص البريد الإلكتروني. ثم يقوم بعد ذلك بإيداع البريد الإلكتروني المصحح وأي مرفقات ملحقة به في Azure Blob Storage، ويرسل بريدًا إلكترونيًا يحتوي على روابط إلى المستندات ذات الصلة في Blob Storage لإعلام الأطراف المهتمة بأن المعلومات متوفرة وتنتظر المراجعة. يجمع هذا المثال بين نموذجين بلا خادم -- Logic App الذي ينفذ الإجراءات دون أي تعليمات برمجية (على الأقل ليس تعليمات برمجية كتبتها أنت أو أي شخص في مؤسستك)، وAzure Function يحتوي على تعليمات برمجية قمت بتزويدها لتخصيص سير العمل -- ويمثل ذلك التحول الذي يحدث في حوسبة السحابة من الأجهزة الظاهرية القائمة على المجهود الذاتي إلى تجريدات ذات مستوى أعلى تسمح للمؤسسات بتركيز طاقاتها على حل مشاكل نشاطات الأعمال بدلاً من إدارة الأجهزة الظاهرية وتثبيتها والحفاظ على أوقات التشغيل.

الشكل 13: تعريف سير العمل في Azure Logic Apps.

الشكل 13: تحديد سير عمل في Azure Logic Apps.

تقدم Amazon خدمة مماثلة في شكل AWS Step Functions. باستخدام Step Functions، يمكنك إنشاء سير عمل مرئية تجمع بين خدمات أخرى مثل AWS Lambda وAWS ECS. يتضمن سير العمل سلسلة من الخطوات، حيث يكون الناتج من خطوة واحدة بمثابة مدخل إلى الخطوة التالية. حالها كحال Azure Logic Apps، توفر AWS Step Functions أوليات للتنفيذ المتفرع والمتوازي، ما يمنعك من كتابة التعليمات البرمجية للقيام بنفس الشيء. في الواقع، إن سير عمل نشاط الأعمال يصبح الرسم التخطيطي لجهاز الحالة، والذي يكون من السهل فهمه، وشرحه للآخرين وتعديله.

قواعد بيانات بلا خادم

في الأيام الأولى من حوسبة السحابة، كانت تؤدي استضافة قاعدة بيانات في سحابة إلى تزويد جهاز ظاهري وتثبيت منتج قاعدة بيانات مثل MySQL أو PostgreSQL أو SQL Server. تغير النظام الأساسي كخدمة (PaaS) هذا من خلال تقديم قواعد البيانات كخدمة. مع قاعدة بيانات Azure SQL Database أو خدمة Amazon Relational Database Service (RDS)، على سبيل المثال، ما عليك سوى تزويد مثيل وسيتوفر لديك في دقائق قاعدة بيانات مستضافة على السحابة جاهزة لخدمة العملاء. وعلاوة على ذلك، يحافظ موفر خدمة السحابة على تحديث النظام الأساسي لقاعدة البيانات من خلال تطبيق تحديثات البرامج وتصحيحاتها.

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

إن الإصدار بلا خادم من Azure SQL Database يخفف من حدة ذلك عن طريق تحجيم قاعدة البيانات حسب الحاجة، لمعالجة الأحمال التي تواجهها، مع التكاليف المستندة إلى مجموع تكاليف الحوسبة وتكاليف التخزين. كما هو الحال مع الوظائف بلا خادم التي تستخدم نموذج استهلاك، أنت لا تدفع إلا مقابل ما تستخدمه. تقدم Amazon خدمة مماثلة في شكل AWS Aurora Serverless، وهو إصدار بلا خادم من خدمة قاعدة بيانات Amazon's Aurora، في حين تقدم Google لعملائها خدمة قاعدة بيانات NoSQL بلا خادم تُعرف باسم Google Cloud Firestore.

المراجع

مايكروسوفت (2019). التشغيل التلقائي لمعالجة رسائل البريد الإلكتروني والمرفقات باستخدام Azure Logic Apps. https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow.

الملاحظات

هل كانت هذه الصفحة مفيدة؟

الحوسبة بدون خادم

‏‫اختبر معلوماتك

الملاحظات