ما هو Serverless؟ الحوسبة بلا خوادم مشروحة ببساطة
Serverless طريقة لتشغيل الشيفرة دون أن تُعدّ أي خوادم أو تديرها بنفسك. تسلّم شيفرتك لمزود سحابي، فيشغّلها فقط حين يحدث شيء يطلقها، مثل طلب ويب أو رفع ملف أو إشعار دفع، ثم تتوقف. وعادةً تدفع مقابل الوقت الذي تعمل فيه الشيفرة فعلاً، لا مقابل جهاز خامل ينتظر.
لماذا يهم Serverless عند البناء بالذكاء الاصطناعي
حين تبني تطبيقاً بالذكاء الاصطناعي وتنظر في خيارات الاستضافة أو الشيفرة، ستصادف عبارات مثل "الدوال بلا خادم" (Serverless functions) أو "دوال الحافة" (Edge functions) أو "دوال السحابة" (Cloud functions). وكثير من منصات الاستضافة تقدمها، وبعض أدوات بناء الذكاء الاصطناعي تنشر الخلفيات بهذه الطريقة. ويساعدك فهم هذا النموذج في ثلاثة أسئلة عملية:
- التكلفة. هل سيكلّفك التطبيق مالاً بينما لا يستخدمه أحد؟
- السرعة. لماذا يكون الطلب الأول بعد فترة هدوء أبطأ؟
- الحدود. لماذا انتهت مهلة مهمة طويلة، كإنشاء تقرير ضخم أو معالجة فيديو؟
ومن المفيد أيضاً أن تعرف ما لا يعنيه Serverless: فهو لا يعني غياب الخلفية. لا تزال لديك شيفرة تعمل على الخادم، لكن شخصاً آخر هو من يشغّل الأجهزة. وللأساسيات، راجع ما هو الخادم.
تشبيه من الحياة اليومية
الخادم التقليدي يشبه امتلاك سيارة. فهي موجودة دائماً وجاهزة للانطلاق فوراً، لكنك تدفع ثمنها، من تأمين وإيجار موقف وصيانة، سواء قدتها أم لا.
أما Serverless فيشبه طلب سيارة أجرة. تدفع فقط مقابل الرحلات التي تقوم بها، وإذا احتاج مئة شخص إلى توصيلة في وقت واحد، تأتي مئة سيارة. لكن قد يكون هناك انتظار قصير حتى تصل السيارة (وهو البدء البارد)، ولكل رحلة حد أقصى للطول، والسائق لا يتذكرك من رحلتك السابقة (فالدوال عديمة الحالة Stateless).
كيف تعمل دوال Serverless
في شكلها الأكثر شيوعاً، المسمى الدوال كخدمة (Functions as a Service):
- تكتب دالة، أي قطعة صغيرة من الشيفرة تتعامل مع نوع واحد من الأحداث، مثل "عالج طلب POST إلى
/api/bookings". - تنشرها. يخزنها المزود ويربطها بمحفّز: عنوان URL، أو جدول زمني، أو ملف جديد في التخزين، أو رسالة في طابور.
- يصل حدث. يبدأ المزود نسخة من دالتك (أو يعيد استخدام نسخة دافئة)، ويشغّلها ويعيد النتيجة.
- تتوسع تلقائياً. إذا وصل ألف طلب في وقت واحد، يشغّل المزود نسخاً كثيرة بالتوازي، حتى حدود حسابك.
- تصبح خاملة. حين تتوقف الحركة، تُغلق النسخ. وبلا شيء يعمل، لا تدفع شيئاً مقابل الحوسبة.
دالة Serverless بسيطة بلغة JavaScript قد تبدو هكذا:
export default async function handler(request) {
const { name } = await request.json();
return Response.json({ message: `Hello, ${name}` });
}
لا توجد شيفرة لتشغيل خادم أو فتح منفذ أو إبقاء عملية حية. فالمنصة تتولى كل ذلك.
ويُستخدم مصطلح "Serverless" بشكل أوسع لخدمات مُدارة أخرى تتوسع تلقائياً وتُحاسب حسب الاستخدام، مثل قواعد البيانات بلا خادم، التي تتوقف حين تكون خاملة.
شرح المصطلحات
| المصطلح | المعنى |
|---|---|
| Function (FaaS) (الدالة) | وحدة صغيرة من الشيفرة يشغّلها المزود عند الطلب. |
| Trigger / event (المحفّز / الحدث) | ما يبدأ الدالة: طلب HTTP، أو رفع ملف، أو مؤقت، أو رسالة في طابور. |
| Cold start (البدء البارد) | التأخير الذي يحدث قبل أن تبدأ نسخة جديدة من الدالة في معالجة طلب. |
| Warm (دافئ) | نسخة تعمل بالفعل ويمكنها الرد فوراً. |
| Stateless (عديم الحالة) | الدالة لا تحتفظ بذاكرة بين التشغيلات. وأي شيء يجب أن يبقى يُحفظ في قاعدة بيانات أو تخزين. |
| Timeout (المهلة الزمنية) | أقصى وقت يُسمح به لتشغيل واحد. فالحد الأقصى لـ AWS Lambda مثلاً 15 دقيقة، وكثير من المنصات تضع حداً أقل بكثير افتراضياً. |
| Edge function (دالة الحافة) | دالة تعمل في مواقع كثيرة قريبة من المستخدمين، وغالباً بحدود أضيق. |
| Scale to zero (التوسع إلى الصفر) | عدم تشغيل أي شيء، وعدم دفع أي شيء مقابل الحوسبة، حين لا توجد حركة. |
مثال عملي: موقع حجوزات صغير
يشهد موقع حجوزات لاستوديو يوغا زيارات مكثفة كل مساء أحد عند نشر الجدول الجديد، وقليلة جداً بقية الأسبوع.
- على خادم يعمل دائماً، يدفع الاستوديو ثمن جهاز يعمل 24/7، ومُجهَّز لذروة مساء الأحد، وخامل غالب الوقت.
- مع دوال Serverless، تكون
GET /api/classesوPOST /api/bookingsدوالاً. فازدحام الأحد يشغّل نسخاً كثيرة تلقائياً، وفي صباح ثلاثاء هادئ يكاد لا يعمل شيء، وتكون الفاتورة قريبة من الصفر.
وتظهر المقايضات أيضاً. قد ينتظر أول شخص يفتح الموقع صباح الثلاثاء لحظة إضافية بسبب البدء البارد. وقاعدة البيانات يجب أن تتعامل مع اتصالات قصيرة كثيرة من نسخ دوال كثيرة، وقد تحتاج إلى مجمّع اتصالات (Connection Pooler). وإذا أراد الاستوديو لاحقاً مهمة "إنشاء ملف PDF بحضور الجميع السنوي"، فقد تتجاوز المهلة الزمنية للدالة، فتحتاج إلى تشغيلها في مكان آخر.
متى يناسب Serverless، ومتى لا يناسب
| مناسب جداً | أقل ملاءمة |
|---|---|
| حركة منخفضة أو متقطعة أو غير متوقعة | حركة ثقيلة ومستمرة، حيث قد يكون الخادم الدائم أرخص |
| مهام قصيرة للطلب والرد: واجهات API، ومعالجات النماذج، وWebhooks | مهام طويلة التشغيل: معالجة فيديو ضخم، واستيراد بيانات كبير |
| فرق صغيرة لا تريد إدارة الخوادم | تطبيقات تُبقي اتصالات حية مفتوحة (بعض ميزات الدردشة أو الألعاب الجماعية)، ما لم تدعم المنصة ذلك |
| معالجة الأحداث: "عند رفع ملف، أنشئ صورة مصغّرة" | تطبيقات تحتاج ذاكرة كبيرة تُحفظ بين الطلبات |
مفاهيم خاطئة شائعة
- "Serverless يعني لا توجد خلفية." يعني لا توجد خوادم تحتاج إلى إدارتك. لا تزال تكتب شيفرة الخلفية وتؤمّنها.
- "Serverless أرخص دائماً." أرخص عند الحجم المنخفض، لكن التسعير لكل طلب قد يتراكم عند حجم مرتفع ومستمر.
- "Serverless يتوسع بلا حدود." المنصات لها حدود للتزامن، وقاعدة بياناتك قد تصبح عنق الزجاجة قبل أن تصبح الدوال كذلك.
- "الملفات التي تحفظها الدالة ستبقى في المرة القادمة." التخزين المحلي مؤقت. استخدم قاعدة بيانات أو تخزين ملفات.
- "التوسع إلى الصفر هو نفسه Serverless." مرتبطان لكنهما ليسا متطابقين. فبعض المنصات تشغّل تطبيقك كخادم عادي ينام حين يكون خاملاً ويستيقظ عند الطلب التالي، وهذا يوفر تكلفة مشابهة ويعطي تأخيراً مشابهاً في الطلب الأول، لكن دون حدود زمنية لكل طلب على طريقة الدوال.
ماذا تطلب من أداة البناء بالذكاء الاصطناعي
- "هل ستعمل هذه الخلفية كدوال Serverless، أم كخادم يعمل دائماً أو ينام؟ ماذا يعني ذلك للتكلفة؟"
- "هل ستتجاوز أي مهمة الحد الزمني للمنصة على الأرجح؟ إن حدث ذلك، كيف نتعامل معها؟"
- "خزّن كل ما يجب أن يبقى في قاعدة البيانات أو تخزين الملفات، لا في الذاكرة أو الملفات المحلية."
- "كيف تُدار اتصالات قاعدة البيانات إذا عملت نسخ كثيرة في وقت واحد؟"
- "ما مقدار التأخير في الطلب الأول بعد أن يكون التطبيق خاملاً؟"
كيف تستضيف Mythex التطبيقات
لا يصف Mythex استضافته بأنها دوال Serverless. فحين تنشر، يعمل تطبيقك كتطبيق ويب عادي أو حاوية يديرها Mythex عنك، ولا يوجد شيء لتُعدّه. إنه التوسع إلى الصفر (Scale-to-zero): فالتطبيقات المنشورة وقواعد بياناتها تنام حين تكون خاملة وتستيقظ عند الزيارة التالية، والتطبيق النائم لا يكلّف شيئاً على الحوسبة، وتبدأ أجهزة إضافية فقط حين تكون الحركة كثيفة (تسمح خطة Pro بما يصل إلى 3 لكل خدمة). كما تنام قاعدة بيانات Postgres المرفقة بعد 5 دقائق من الخمول، ويُحاسب الوقت الذي كانت فيه مستيقظة. لذلك تحصل على كثير من فائدة "ادفع مقابل ما تستخدمه"، مع نوع التأخير نفسه في الطلب الأول بعد فترة هدوء. راجع حدود الاستضافة في الوثائق، وأدلتنا حول الاستضافة على الويب وتقليل تكاليف الاستضافة.
الأسئلة
ماذا يعني Serverless ببساطة؟
يعني أنك تعطي مزود السحابة شيفرتك فيشغّلها فقط عند الحاجة، مثلاً حين يصل طلب، دون أن تُعدّ أي خادم أو تعتني به. وغالباً تدفع مقابل الوقت الذي تعمل فيه الشيفرة فعلاً، لا مقابل جهاز يعمل طوال الوقت.
هل توجد خوادم فعلاً في Serverless؟
نعم توجد خوادم، لكنك لا تديرها. يشغّل المزود شيفرتك على أجهزته الخاصة، ويبدؤها حين تصل الطلبات، ويوسّعها عند الضغط، ويوقفها حين تكون خاملة.
ما البدء البارد (Cold Start)؟
البدء البارد هو التأخير الإضافي حين تعمل دالة Serverless بعد فترة خمول، لأن المزود يجب أن يشغّل نسخة جديدة منها أولاً. وقد يتراوح من تأخير بالكاد يُلاحظ إلى ثانية أو أكثر، حسب المنصة واللغة وحجم الشيفرة.
هل Serverless أرخص من الخادم العادي؟
في التطبيقات ذات الحركة القليلة أو غير المنتظمة، غالباً نعم، لأنك تدفع قريباً من لا شيء أثناء الخمول. أما التطبيقات ذات الحركة الثقيلة والمستمرة فقد يكون الخادم الذي يعمل طوال الوقت أرخص. الأمر يعتمد على نمط استخدامك وتسعير المزود.
ما أمثلة منصات Serverless؟
من الأمثلة المعروفة AWS Lambda، وGoogle Cloud Run functions، وAzure Functions، وCloudflare Workers، وميزات الدوال في منصات الاستضافة مثل Vercel وNetlify.