يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة. كنا شغالين على مشروع ناشئ، تطبيق لمشاركة الفعاليات والمناسبات الاجتماعية. الفكرة كانت بسيطة وحلوة، والشباب متحمسين. جينا لمرحلة البنية التحتية، وعلى طول، زي ما تعلمنا، استأجرنا خادم افتراضي (Virtual Server) من أحد مزودي الخدمات السحابية الكبار.
اخترنا خادم بمواصفات “مرتبة”، قلنا عشان يستحمل الضغط لو التطبيق “ضرب” فجأة وصار عليه إقبال. الأيام الأولى كانت حماس، نراقب الأداء، وكل شي تمام. لكن بعد فترة، بلّشنا نلاحظ شغلة غريبة ومزعجة جداً. تطبيقنا كان موسمي، يعني أوقات الذروة تبعته بتكون بالعادة في نهاية الأسبوع أو لما يكون في مناسبات كبيرة. باقي الوقت؟ التطبيق شبه نائم، والخادم قاعد “بتفرج علينا” ومش بعمل إشي تقريباً.
المشكلة إنه الفاتورة الشهرية ما كانت تنام! كانت تجينا كاملة، سواء استخدمنا 100% من موارد الخادم أو 1% بس. كنت كل آخر شهر أمسك الفاتورة وأحكي لحالي: “يا زلمة، إحنا بندفع حق سيارة مرسيدس واقفة بالكراج 25 يوم بالشهر وبنستخدمها 5 أيام بس!”. شعور بالإحباط وهدر المصاري كان قاتل، خصوصاً لشركة ناشئة كل قرش بفرق معها. كنا في جحيم الموارد المهدرة، إلى أن سمعنا بمصطلح غيّر كل شيء: البنية غير الخادومية (Serverless).
ما هي البنية غير الخادومية (Serverless)؟ وهل هي حقاً “بلا خوادم”؟
أول ما تسمع كلمة “Serverless” أو “بلا خوادم”، ممكن تفكر إن الكود تبعك بطير في الفضاء وبشتغل بقدرة قادر! الحكي بينا، الاسم مضلل شوي. الخوادم لا تزال موجودة، لكن الفرق الجوهري هو: أنت لم تعد مسؤولاً عنها.
تخيل معي هذا المثال البسيط: بدك تاكل بيتزا.
- الطريقة التقليدية (مثل الخوادم العادية): أنت تبني مطبخ كامل في بيتك، تشتري فرن، عجّانة، ثلاجة، وتوّظف طباخ. سواء أكلت بيتزا كل يوم أو مرة بالشهر، أنت دافع تكاليف المطبخ والطباخ كاملة.
- طريقة الـ Serverless: أنت تطلب البيتزا من مطعم دليفري. تدفع فقط ثمن البيتزا التي أكلتها. لا تفكر في إيجار المطعم، ولا راتب الطباخ، ولا فاتورة الكهرباء تبعت الفرن.
هذا بالضبط هو مبدأ الـ Serverless. أنت كمطور، تكتب “دوال” (Functions) صغيرة تؤدي مهمة محددة، وترفعها على منصة سحابية مثل AWS Lambda أو Azure Functions أو Google Cloud Functions. هذه المنصة هي التي تتكفل بتشغيل الكود عند الحاجة فقط، وأنت تدفع بالمللي ثانية على قدر التشغيل الفعلي. لما ما يكون في طلبات (requests) على الكود تبعك، أنت لا تدفع أي شيء. صفر طلبات = صفر تكلفة. شغلة مرتبة من الآخر!
كيف أنقذتنا “السيرفرلس” من جحيم الفواتير؟
لما انتقلنا لتطبيقنا من الخادم التقليدي إلى بنية Serverless، التغيير كان جذرياً. خلوني ألخصلكم الفوائد اللي لمسناها بشكل مباشر:
1. الدفع مقابل الاستخدام الفعلي (Pay-per-use)
هذه كانت أكبر نقلة نوعية. فاتورتنا الشهرية انخفضت بنسبة تقارب 80-90%. صرنا ندفع فقط عندما يقوم مستخدم فعلياً بإنشاء مناسبة أو تصفح الفعاليات. في أوقات الخمول، مثل منتصف الليل في أيام الأسبوع، كانت التكلفة تقترب من الصفر. معظم المنصات السحابية تقدم أيضاً “طبقة مجانية” (Free Tier) سخية جداً، تسمح لك بتشغيل مليون طلب شهرياً مجاناً. هذا يعني أن الكثير من المشاريع الصغيرة أو الجانبية يمكن أن تعمل مجاناً تماماً.
2. التوسع التلقائي (Automatic Scaling)
هل تذكرون خوفنا من “الضغط” المفاجئ على الخادم؟ مع Serverless، هذا الخوف اختفى. المنصة تتكفل تلقائياً بتشغيل نسخ متعددة من الكود الخاص بك بشكل متوازي للتعامل مع أي عدد من الطلبات. لو أتاك 10 طلبات في نفس الثانية، المنصة تشغل 10 نسخ. لو أتاك 1000 طلب، تشغل 1000 نسخة. كل هذا يحدث تلقائياً بدون أي تدخل منك. لا داعي للقلق بشأن “انهيار الخادم” وقت الذروة.
3. التركيز على الكود، لا على البنية التحتية
“خلّينا نركز في الكود وبس!”
هذه الجملة أصبحت شعارنا في الفريق. قبل الـ Serverless، كنت أقضي ساعات في تحديث نظام التشغيل على الخادم، وتثبيت التحديثات الأمنية (Patches)، وضبط إعدادات الـ Firewall، ومراقبة استهلاك الذاكرة والمعالج. مع الـ Serverless، كل هذا العبء زال. مزود الخدمة السحابية هو المسؤول عن كل هذه الأمور. نحن كمطورين، أصبح كل همنا هو كتابة منطق العمل (Business Logic) الذي يخدم المستخدم ويضيف قيمة للمنتج.
مثال عملي: من خادم Express.js إلى دالة AWS Lambda
حتى تكون الصورة أوضح، دعونا نرى مثالاً بسيطاً جداً: واجهة برمجية (API) صغيرة تعيد رسالة ترحيب. سنرى كيف نكتبها بالطريقة التقليدية وباستخدام Serverless.
الطريقة التقليدية: خادم Express.js على سيرفر EC2
في هذه الطريقة، أنت بحاجة لكتابة خادم كامل وتشغيله على مدار الساعة.
// index.js
const express = require('express');
const app = express();
const port = 3000;
// Endpoint to say hello
app.get('/hello', (req, res) => {
res.json({ message: 'أهلاً وسهلاً من خادم Express!' });
});
app.listen(port, () => {
console.log(`الخادم يعمل على المنفذ ${port}`);
});
هذا الكود يجب أن يبقى يعمل 24/7 على خادم استأجرته، وتدفع ثمنه سواء كان هناك من يزور الرابط /hello أم لا.
طريقة Serverless: دالة AWS Lambda
هنا، أنت تكتب فقط الدالة التي ستنفذ عند استدعاء الـ Endpoint. لا يوجد app.listen ولا إدارة للمنافذ.
// handler.js
// The handler function
exports.sayHello = async (event) => {
// الكود هنا لا يعمل إلا عند الطلب
console.log("تم استدعاء الدالة!");
// The response we want to send back
const response = {
statusCode: 200,
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
message: 'أهلاً وسهلاً من دالة Lambda غير الخادومية!',
}),
};
return response;
};
لاحظ الفرق؟ الكود أبسط بكثير ومركز على المهمة فقط. أنت تقوم بربط هذه الدالة مع خدمة مثل Amazon API Gateway، والتي تعطيك رابطاً عاماً. عند زيارة هذا الرابط، تقوم API Gateway باستدعاء دالة Lambda، تنفيذ الكود، وإرجاع النتيجة. إذا لم يزر أحد الرابط لمدة ساعة، فإن الكود لا يعمل أبداً، وأنت لا تدفع شيئاً.
نصائح من “أبو عمر”: متى تستخدم Serverless ومتى تبتعد عنها؟
رغم كل حبي لهذه التقنية، هي ليست الحل السحري لكل المشاكل. من خبرتي، هذه بعض الحالات التي تتألق فيها الـ Serverless، وبعض الحالات التي يجب أن تفكر فيها مرتين.
حالات الاستخدام المثالية لـ Serverless:
- الواجهات البرمجية (APIs): خصوصاً تلك التي تعاني من تذبذب في حركة المرور مثل تطبيقنا.
- مهام المعالجة في الخلفية (Background Jobs): مثلاً، عندما يرفع مستخدم صورة، يمكن لدالة Lambda أن تعمل تلقائياً لتغيير حجمها وإضافة علامة مائية.
- أتمتة مهام البنية التحتية: تشغيل سكربتات دورية لعمل نسخ احتياطي أو تنظيف قواعد البيانات.
- الروبوتات (Chatbots) وتطبيقات إنترنت الأشياء (IoT): هذه التطبيقات غالباً ما تكون مدفوعة بالأحداث (event-driven)، وهو ما تتفوق فيه بنية Serverless.
متى يجب أن تفكر مرتين؟ (محاذير مهمة)
- مشكلة البدء البارد (Cold Start): إذا لم يتم استدعاء دالتك لفترة (مثلاً 15 دقيقة)، فإن المنصة “تجمّدها” لتوفير الموارد. أول طلب يأتي بعد هذه الفترة سيستغرق وقتاً أطول قليلاً (من بضع مئات من الميلي ثانية إلى ثوانٍ) لأن المنصة تحتاج “لإيقاظ” الدالة. هذا قد يكون مشكلة في التطبيقات شديدة الحساسية لزمن الاستجابة. (نصيحة: يمكن التخفيف من هذه المشكلة باستخدام ميزات مثل “Provisioned Concurrency” التي تبقي عدداً من الدوال “جاهزة” دائماً، ولكنها تكلف أكثر).
- المهام طويلة الأمد: دوال الـ Serverless لها حد أقصى لزمن التنفيذ (مثلاً 15 دقيقة في AWS Lambda). إذا كانت لديك مهمة تحتاج لساعات لتنفيذها (مثل تدريب نموذج تعلم آلة ضخم)، فـ Serverless ليست الخيار المناسب لها.
- التقيّد بالمزوّد (Vendor Lock-in): عندما تبني نظامك بالكامل على خدمات Serverless من مزوّد معين (مثل AWS)، يصبح من الصعب جداً الانتقال إلى مزوّد آخر لاحقاً. (نصيحة: استخدام أطر عمل مثل Serverless Framework يمكن أن يقلل من هذا التقييد إلى حد ما).
الخلاصة: هل السيرفرلس هي المستقبل؟ 🚀
البنية غير الخادومية (Serverless) ليست مجرد “موضة” تقنية عابرة، بل هي نقلة نوعية في طريقة تفكيرنا ببناء وتشغيل التطبيقات. لقد أنقذتنا من صداع إدارة الخوادم ومن نزيف فواتير الموارد المهدرة، وسمحت لنا بالعودة إلى شغفنا الأساسي: كتابة كود رائع يحل مشاكل حقيقية.
هل هي الحل لكل شيء؟ بالطبع لا. ولكنها أداة قوية جداً يجب أن تكون في جعبة كل مطور ومسؤول تقني اليوم.
نصيحتي الأخيرة لك: لا تخف من تجربتها. ابدأ بمشروع جانبي صغير أو بميزة واحدة داخل تطبيقك الحالي. قم ببناء واجهة برمجية بسيطة باستخدام AWS Lambda و API Gateway. جرّبها يا صاحبي، وقارن التكلفة والجهد بنفسك. أنا أضمن لك أنك ستنبهر بالنتائج، وربما ستنقذ نفسك أيضاً من جحيم كنت تظن أنه لا مفر منه.
