“يا زلمة، بندفع ع الهوا”: قصة فاتورة الـ 300 دولار
قبل كم سنة، كنت شغال مع شباب صحابي على مشروع جانبي، تطبيق بسيط لمعالجة وتحليل بيانات من مصادر مختلفة. كانت الفكرة إنه التطبيق يشتغل بشكل متقطع، يعني لما المستخدم يرفع ملف، أو كل كم ساعة يسحب بيانات جديدة. بحكم العادة، وكما تعلمنا في “الكتاب”، أول إشي عملناه هو إنه حجزنا خادم افتراضي (Virtual Server) على AWS، من نوع EC2. اخترنا واحد مواصفاته “منيحة” عشان “ما نتغلبش” لقدام. ورفعنا الكود تبعنا عليه، وشبكناه، وكله تمام.
مرّ أول شهر، والتطبيق شغال، بس بشكل متقطع زي ما حكينا. إجت الفاتورة: حوالي 300 دولار. طلعنا على بعض، واحد من الشباب حكى جملته الشهيرة: “يا زلمة، 300 دولار؟ إحنا بندفع ع الهوا!”. كان معه حق. لما دخلت على لوحة المراقبة (Monitoring Dashboard)، شفت منظر صدمني: رسمة استهلاك المعالج (CPU Utilization) كانت تحت الـ 5% معظم الوقت، وبس بتقفز لفوق لمدة كم دقيقة كل كم ساعة لما يشتغل الكود تبعنا، وبعدين بترجع تنام. حرفيًا، كان خادمنا خامل أكثر من 90% من الوقت، بس إحنا كنا بندفع ثمنه كامل، 24 ساعة في اليوم، 7 أيام في الأسبوع. شعور بالظلم، كإنك مستأجر سيارة فخمة بس عشان توقفها قدام البيت.
هنا بلشت رحلة البحث عن حل، عن طريقة ندفع فيها بس على قد شغلنا. وهون تعرفت على عالم غيّر طريقة تفكيري في بناء التطبيقات: عالم الـ Serverless.
ما هو “جحيم التكاليف المهدرة” في عالم الخوادم؟
القصة اللي حكيتها هي مثال صارخ على مشكلة شائعة جداً اسمها “Over-provisioning” أو “توفير الموارد الزائدة”. في النموذج التقليدي، أنت تقوم بتقدير حجم الضغط المتوقع على تطبيقك، وبناءً عليه، تقوم بحجز خادم (أو مجموعة خوادم) بالمواصفات اللي بتظن إنها كافية. المشكلة وين؟
- الضغط المتقطع (Spiky Workloads): معظم التطبيقات لا تشهد ضغطًا ثابتًا. هناك أوقات ذروة وأوقات خمول. أنت تضطر للدفع مقابل الخادم الذي يستطيع تحمل وقت الذروة، حتى لو كان هذا الوقت يمثل 10% فقط من اليوم.
- صعوبة التنبؤ: خصوصًا في المشاريع الجديدة، من شبه المستحيل أن تتنبأ بحجم الاستخدام. فإما أن تحجز خادمًا صغيرًا وتخاطر بتعطل الخدمة، أو تحجز خادمًا كبيرًا وتهدر المال.
- التكلفة الثابتة: الخادم شغال؟ العداد شغال. سواء كان يخدم ألف مستخدم أو مستخدم واحد أو حتى صفر، أنت تدفع نفس الإيجار الشهري.
ببساطة، النموذج التقليدي يشبه اشتراك نادي رياضي سنوي تدفعه بالكامل، حتى لو كنت تذهب مرة واحدة في الشهر. أنت تدفع مقابل “الإتاحة” وليس مقابل “الاستخدام”.
بصيص الأمل: تعرفنا على “الحوسبة بدون خوادم” (Serverless)
لما تسمع كلمة “Serverless” أو “بدون خوادم”، أول إشي بيخطر في بالك إنه ما في سيرفرات في الموضوع. وهذا الكلام مش دقيق. السيرفرات موجودة ومين ما كان، بس الفكرة إنه أنت كمطور بطلت شايل همها. شركة الحوسبة السحابية (مثل AWS, Google Cloud, Azure) هي اللي بتديرها، بتصونها، وبتشغلها.
المفهوم الجوهري للـ Serverless هو الانتقال من الدفع مقابل “وقت تشغيل الخادم” إلى الدفع مقابل “التنفيذ الفعلي للكود”. تخيل معي:
- النموذج التقليدي (الخادم): أنت تستأجر مطبخًا كاملاً لمدة 24 ساعة، سواء طبخت فيه وجبة واحدة أو مئة وجبة.
- نموذج الـ Serverless: أنت لا تستأجر أي شيء. عندما تريد أن تطبخ، يظهر مطبخ مجهز فجأة، تطبخ فيه وجبتك، وتدفع فقط ثمن الغاز والكهرباء اللي استهلكتها خلال دقائق الطبخ، ثم يختفي المطبخ.
هذا النموذج غيّر قواعد اللعبة تمامًا. بطلنا ندفع على “الهوا”. صرنا ندفع فقط مقابل كل مرة يتم فيها تنفيذ الكود تبعنا، بالمللي ثانية!
كيف تعمل هذه التقنية السحرية؟ نظرة على AWS Lambda
أشهر تطبيق لمفهوم الـ Serverless هو ما يسمى “Function-as-a-Service” أو “FaaS”، والمثال الأبرز عليه هو خدمة AWS Lambda من أمازون.
ما هي AWS Lambda؟
ببساطة، هي خدمة تسمح لك برفع قطعة من الكود (تسمى “دالة” أو Function) إلى السحابة. هذه الدالة تظل نائمة ولا تكلفك شيئًا. عندما يحدث “حدث” معين أنت تحدده، تقوم AWS تلقائيًا بتشغيل الكود الخاص بك في بيئة معزولة، تنفذ المطلوب، ثم تتوقف. أنت تدفع فقط مقابل مدة تنفيذ هذه الدالة.
ما هي “الأحداث” (Events) التي تشغل الكود؟
الجميل في Lambda هو أنها تتكامل مع كل خدمات AWS تقريبًا. يمكن تشغيل دالتك عبر:
- طلب HTTP: من خلال خدمة اسمها API Gateway، يمكنك تحويل دالتك إلى API endpoint يستجيب لطلبات الويب.
- رفع ملف: عند رفع صورة أو ملف جديد إلى مخزن الملفات S3. (مثالي لمعالجة الصور التلقائية).
- جدول زمني (Cron Job): تشغيل الكود كل ساعة، أو كل يوم في منتصف الليل. (هذا بالضبط ما كنا نحتاجه لمشروعنا!).
- رسالة في طابور (Queue): عند وصول رسالة جديدة إلى خدمة SQS أو Kinesis.
- تغيير في قاعدة البيانات: عند إضافة سجل جديد في قاعدة بيانات مثل DynamoDB.
مثال عملي: من الخادم التقليدي إلى Lambda
لنفترض أن لدينا كود بسيط بلغة Node.js يستقبل طلب HTTP، يقوم بعملية ما، ثم يرجع استجابة. هكذا سيبدو على خادم تقليدي باستخدام إطار Express.js:
// server.js - يعمل 24/7 على خادم EC2
const express = require('express');
const app = express();
const port = 3000;
// هذا الخادم يجب أن يبقى يعمل طوال الوقت لاستقبال الطلبات
app.get('/api/hello', (req, res) => {
const name = req.query.name || 'Guest';
res.send({ message: `مرحباً يا ${name}!` });
});
app.listen(port, () => {
console.log(`الخادم يعمل باستمرار على المنفذ ${port}`);
});
الآن، لنرى كيف سيبدو نفس المنطق باستخدام AWS Lambda و API Gateway:
// handler.js - يتم رفعه إلى Lambda
// هذا الكود لا يعمل إلا عند وصول طلب فعلي
exports.handler = async (event) => {
// المعلومات من الطلب تكون موجودة في الـ event object
const name = event.queryStringParameters?.name || 'Guest';
const response = {
statusCode: 200,
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({ message: `مرحباً يا ${name}!` }),
};
return response;
};
لاحظ الفرق الجوهري: في المثال الأول، نحن مسؤولون عن تشغيل الخادم وإدارته وصيانته على مدار الساعة. في المثال الثاني، كل ما فعلناه هو كتابة المنطق الأساسي (الـ business logic)، وتركنا مهمة التشغيل والتوسع وإدارة البنية التحتية بالكامل لـ AWS.
النتائج على أرض الواقع: الأرقام لا تكذب
بعد أن قمنا بنقل منطق تطبيقنا من خادم EC2 إلى دوال Lambda، كانت النتائج مذهلة:
- التكلفة: فاتورتنا الشهرية المتعلقة بهذه الجزئية من التطبيق انخفضت من حوالي 300 دولار إلى أقل من 5 دولارات! نعم، أقل من 5 دولارات. لأننا كنا ندفع فقط مقابل الثواني القليلة التي يعمل فيها الكود كل يوم. الطبقة المجانية (Free Tier) في Lambda سخية جدًا وتغطي أول مليون طلب كل شهر، وهذا كان أكثر من كافٍ لمشروعنا في بداياته.
- التوسع التلقائي (Auto Scaling): في أحد الأيام، قام أحد المؤثرين بمشاركة تطبيقنا، وحصلنا على آلاف الطلبات في دقائق. لو كنا على خادمنا القديم، لانهار فورًا. مع Lambda، لم نشعر بشيء. قامت AWS تلقائيًا بتشغيل آلاف النسخ المتوازية من دالتنا للتعامل مع الضغط، ثم اختفت عندما انتهى. “ما وكلنا هم الضغط بالمرة”.
- التركيز على المهم: بدلًا من قضاء الوقت في تحديث نظام التشغيل، ومراقبة أداء الخادم، والقلق بشأن الأمن، أصبحنا نركز 100% من وقتنا على كتابة الكود الذي يخدم المستخدم ويطور المنتج.
نصائح أبو عمر الذهبية للانتقال إلى عالم الـ Serverless
من خلال تجربتي، هذه بعض النصائح العملية لمن يفكر في تبني هذه المعمارية:
- ابدأ صغيرًا: لا تحاول تحويل تطبيقك بالكامل مرة واحدة. اختر جزءًا صغيرًا ومناسبًا، مثل مهمة مجدولة (cron job)، أو وظيفة معالجة صور، أو API endpoint بسيط. جرب وشاهد النتائج بنفسك.
- استخدم إطار عمل (Framework): كتابة وإدارة دوال Lambda يدويًا يمكن أن يصبح معقدًا. استخدم أطر عمل مثل Serverless Framework أو AWS SAM. هذه الأدوات تسهل عليك عملية التطوير، الاختبار، والنشر بشكل كبير.
- فكر بطريقة “غير متزامنة” (Asynchronous): الـ Serverless يلمع في المهام التي يمكن تنفيذها في الخلفية. بدلًا من جعل المستخدم ينتظر اكتمال عملية طويلة، يمكنك تشغيل دالة Lambda في الخلفية وإعلام المستخدم عند الانتهاء.
- راقب التكاليف والأداء: استخدم أدوات مثل AWS CloudWatch لمراقبة عدد مرات التنفيذ، مدة التنفيذ، والأخطاء. هذا يساعدك على تحسين الكود وتجنب أي تكاليف غير متوقعة.
- ليست حلًا لكل شيء: الـ Serverless ليست الحل السحري لكل المشاكل. للتطبيقات ذات الحمل الثابت والعالي جدًا على مدار الساعة، قد يكون الخادم المخصص أرخص. للتطبيقات التي تحتاج لاتصال دائم (like WebSockets)، قد تكون هناك حلول أفضل. افهم متى تستخدمها ومتى لا.
الخلاصة: هل تستحق التجربة؟
بالتأكيد. الحوسبة بدون خوادم ليست مجرد تقنية جديدة، بل هي نقلة نوعية في طريقة تفكيرنا ببناء وتشغيل التطبيقات. إنها تمنح المطورين والشركات الصغيرة قوة كانت حكرًا على الشركات الكبيرة: القدرة على بناء تطبيقات قابلة للتوسع بشكل لانهائي وبتكلفة مرتبطة بالاستخدام الفعلي فقط.
بالنسبة لنا، كانت Serverless هي المنقذ الذي حررنا من “جحيم التكاليف المهدرة” وسمح لنا بالتركيز على الابتكار بدلًا من الإدارة. أنصح كل مطور، سواء كنت مبتدئًا أو خبيرًا، أن يعطيها فرصة.
جربوها يا جماعة. في أسوأ الأحوال، بتتعلموا إشي جديد ومطلوب في السوق. وفي أحسن الأحوال، بتوفروا مصاري ووقت وجهد، وهذا هو المهم في النهاية. 😉
