كانت خوادمنا نائمة وتكلفتها مستيقظة: كيف أنقذتنا معمارية Serverless من فواتير الموارد الخاملة؟

يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.

اسمحوا لي أبدأ معكم بقصة صارت معي قبل كم سنة، قصة علّمتني درس قاسي عن الحوسبة السحابية. وقتها كنت شغال مع فريق صغير على مشروع تطوعي، تطبيق بسيط لتسجيل الحضور في الفعاليات والورشات الثقافية في مجتمعنا. الشغل كان على قده، والتطبيق بسيط: واجهة تسجيل، وقاعدة بيانات، وشوية منطق برمجي يربط بينهم. رفعنا التطبيق على خادم سحابي صغير من نوع EC2 على AWS، وكنا مبسوطين والأمور تمام.

خلصت الفعالية الرئيسية اللي سوينا التطبيق عشانها، والكل انشغل بحياته. بعد شهرين ثلاثة، بتفقد إيميلي ولا بلاقي فاتورة من أمازون بمبلغ مش بسيط بالمرة. مسكت راسي وقلت “يا زلمة، شو هاد؟! من وين طلع هالمبلغ؟”. التطبيق ما حدا استخدمه من شهرين، فعلياً الخادم كان “نايم” وما عليه أي ضغط. لكن الفاتورة كانت صاحية ومصحصحة وعم تسحب من الفيزا كل شهر!

هنا كانت الصدمة. كنا ندفع ثمن خادم شغال 24 ساعة في اليوم، 7 أيام في الأسبوع، فقط “تحسباً” لو قرر شخص ما يفتح التطبيق. كنا ندفع ثمن الهواء تقريباً. هذه الحادثة كانت الشرارة اللي خلتني أغوص في عالم الـ Serverless، وصدقوني، كانت نقلة نوعية في تفكيري كمهندس برمجيات.

ما هي المشكلة بالضبط؟ جحيم الموارد الخاملة

قبل ما نحكي عن الحل، خلينا نفصّل المشكلة اللي أغلبنا وقع فيها. النموذج التقليدي للحوسبة السحابية (اللي يُعرف بـ IaaS – Infrastructure as a Service) بيعتمد على فكرة “حجز الموارد”.

تخيل أنك استأجرت مكتب كامل بمكاتبه وكراسيه وكهربته، لكنك ما بتستخدمه إلا ساعة واحدة في اليوم. هل صاحب المبنى رح يحاسبك على هاي الساعة بس؟ طبعاً لأ، رح تدفع إيجار المكتب كامل للشهر، سواء استخدمته أو لأ. هذا بالضبط ما يحدث مع الخوادم الافتراضية (Virtual Machines) مثل EC2 في AWS أو Droplets في DigitalOcean.

أنت تقوم بـ “حجز” (Provisioning) خادم بمواصفات معينة (مثلاً، 2 vCPU و 4GB RAM)، وتدفع مقابل كل ثانية يعمل فيها هذا الخادم، بغض النظر عما إذا كان ينفذ عمليات حسابية معقدة أو كان خاملاً لا يفعل شيئًا. وهذا يؤدي لمشكلتين رئيسيتين:

• الدفع مقابل الخمول (Paying for Idle): كما في قصتي، إذا كان تطبيقك يشهد حركة مرور متقطعة أو منخفضة، فأنت تهدر معظم أموالك على موارد غير مستخدمة.
• الإفراط في التجهيز (Over-provisioning): خوفًا من تعطل الخدمة أثناء ذروة الاستخدام، نميل إلى حجز خوادم أقوى مما نحتاج إليه في الوضع الطبيعي “للأمان”. وهذا يعني المزيد من الهدر المالي.

الحل السحري: معمارية “بلا خوادم” (Serverless)

وهنا يأتي دور الـ Serverless لتغيير قواعد اللعبة. أولاً، دعونا نصحح المفهوم الخاطئ: معمارية “بلا خوادم” لا تعني عدم وجود خوادم على الإطلاق. الخوادم موجودة بالتأكيد، ولكن الفرق الجوهري هو: أنت لم تعد مسؤولاً عن إدارتها أو الدفع لها وهي خاملة.

الفكرة بسيطة وعبقرية: أنت تكتب الكود الخاص بك على شكل “دوال” (Functions)، وتقوم برفعها إلى منصة سحابية مثل AWS Lambda أو Azure Functions. هذه المنصة هي التي تتكفل بتشغيل الكود فقط عند الحاجة إليه، وتتوقف عن تشغيله فوراً عند انتهاء المهمة.

فكر في الأمر كعامل “مياومة” حر. أنت لا توظفه بدوام كامل وتدفع له راتباً شهرياً. بل تتصل به فقط عندما يكون لديك عمل معين، وتدفع له أجرة هذا العمل فقط. هذا هو تماماً ما تفعله Lambda مع الكود الخاص بك.

كيف تعمل؟

تعمل معمارية Serverless بناءً على نموذج “مدفوع بالأحداث” (Event-Driven). الكود الخاص بك لا يعمل إلا استجابةً لـ “حدث” (Event) معين. قد يكون هذا الحدث:

• طلب HTTP من واجهة برمجية (API Gateway).
• إضافة ملف جديد إلى سلة تخزين (مثل Amazon S3).
• إضافة سجل جديد في قاعدة بيانات (مثل DynamoDB).
• رسالة جديدة في طابور رسائل (مثل SQS).
• مهمة مجدولة تعمل كل ساعة (مثل CloudWatch Events).

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

تجربتنا العملية: من الخادم التقليدي إلى Lambda

دعونا نعود لمثال تطبيق تسجيل الحضور. كان التطبيق مكتوبًا باستخدام Node.js وإطار العمل Express.js. إليك كيف كان يبدو الكود (بشكل مبسط) وكيف حولناه.

المشهد قبل Serverless: خادم Express.js على EC2

كان لدينا تطبيق بسيط يستمع على منفذ (port) معين، مع نقطة وصول (endpoint) واحدة `/register`.

// index.js on EC2 Server
const express = require('express');
const app = express();
const port = 3000;

app.use(express.json());

// Endpoint for event registration
app.post('/register', (req, res) => {
  const { name, email } = req.body;
  
  if (!name || !email) {
    return res.status(400).send({ message: 'Name and email are required.' });
  }

  // Logic to save user to the database...
  console.log(`Registering user: ${name} (${email})`);
  
  res.status(201).send({ message: `Welcome, ${name}!` });
});

app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

هذا الكود كان يعمل على خادم EC2 من نوع `t2.micro` بشكل متواصل 24/7. التكلفة الشهرية كانت تقارب 20-25 دولارًا (شاملة الخادم، مساحة التخزين، وغيرها) حتى لو لم يقم أي شخص بالتسجيل.

الانتقال إلى Serverless: استخدام AWS Lambda و API Gateway

الآن، قمنا بإعادة هيكلة هذا الكود ليعمل كدالة Lambda. الفكرة هي أن نتخلص من كل ما يتعلق بإدارة الخادم (مثل `app.listen`) ونجعل الكود يركز فقط على معالجة الطلب.

استخدمنا بوابة الواجهات البرمجية (API Gateway) في AWS لتكون هي الواجهة التي تستقبل طلبات HTTP، ثم تقوم باستدعاء دالة Lambda الخاصة بنا وتمرير معلومات الطلب لها.

هذا هو شكل الكود بعد تحويله إلى دالة Lambda:

// handler.js for AWS Lambda
module.exports.register = async (event) => {
  // The request body is passed in event.body as a JSON string
  const body = JSON.parse(event.body || '{}');
  const { name, email } = body;

  if (!name || !email) {
    return {
      statusCode: 400,
      body: JSON.stringify({ message: 'Name and email are required.' }),
    };
  }

  // Logic to save user to the database...
  console.log(`Registering user: ${name} (${email})`);

  return {
    statusCode: 201,
    body: JSON.stringify({ message: `Welcome, ${name}!` }),
  };
};

لاحظ الفرق: الكود أصبح أبسط وأكثر تركيزًا. لا يوجد خادم، لا يوجد منفذ. مجرد دالة تستقبل `event` (يحتوي على معلومات الطلب) وتعيد `response` (كائن JSON يمثل الرد).

النتائج المذهلة: توفير في التكاليف وراحة بال

النتائج كانت مذهلة بكل المقاييس. دعونا نقارن التكلفة بشكل مباشر.

تحليل التكلفة: قبل وبعد

• قبل (EC2): ~25 دولارًا شهريًا، بغض النظر عن الاستخدام.
• بعد (Lambda + API Gateway):
  • AWS Lambda: توفر AWS طبقة مجانية دائمة (Free Tier) تشمل مليون طلب مجاني و 400,000 جيجابايت-ثانية من وقت الحوسبة شهريًا. لمشروعنا الصغير، هذا يعني أن تكلفة Lambda كانت صفر دولار.
  • API Gateway: أيضًا، توفر طبقة مجانية تشمل مليون طلب API مجاني شهريًا. مرة أخرى، التكلفة كانت صفر دولار.

من الآخر، انتقلت فاتورتنا الشهرية من 25 دولارًا إلى 0 دولار. لم نعد ندفع قرشًا واحدًا إلا إذا استخدم شخص ما التطبيق بالفعل. هذا هو معنى “الدفع مقابل القيمة” (Pay-for-Value) الحقيقي.

فوائد أخرى لم نكن نتوقعها

لم يكن التوفير المالي هو الفائدة الوحيدة:

• التوسع التلقائي (Automatic Scaling): لو جاء 1000 شخص ليسجلوا في نفس الدقيقة، ستقوم AWS تلقائيًا بتشغيل 1000 نسخة متوازية من دالتنا للتعامل مع الحمل. لا داعي للقلق بشأن إدارة موازنات التحميل (Load Balancers) أو إضافة خوادم جديدة.
• تقليل الصيانة (Reduced Maintenance): خلص، ريحنا راسنا من وجعة راس تحديثات نظام التشغيل، الثغرات الأمنية، وإدارة الخوادم. كل هذا أصبح مسؤولية AWS.
• التركيز على المنتج: أصبحنا قادرين على قضاء وقتنا في كتابة ميزات جديدة وتحسين منطق العمل، بدلاً من إضاعة الوقت في إدارة البنية التحتية.

نصائح من خبرة أبو عمر

بعد سنوات من العمل مع Serverless، هذه بعض النصائح العملية التي أود مشاركتها معكم:

1. ابدأ صغيرًا: لست بحاجة إلى تحويل كل نظامك إلى Serverless دفعة واحدة. ابدأ بميزة صغيرة ومنعزلة، مثل معالجة رفع الصور، أو إرسال إشعارات، أو واجهة برمجية بسيطة.
2. احذر من “البداية الباردة” (Cold Starts): عندما لا يتم استدعاء دالتك لفترة، قد تحتاج المنصة السحابية بضع مئات من الملي ثانية (أو أكثر) لتجهيز البيئة وتشغيلها لأول مرة. هذا يسمى “Cold Start”. للمستخدم العادي قد لا تكون ملحوظة، ولكن للتطبيقات الحساسة للكمون (latency)، يمكنك استخدام ميزات مثل “Provisioned Concurrency” في AWS Lambda لإبقاء عدد معين من الدوال “جاهزة” دائمًا (ولكن هذا له تكلفة).
3. المراقبة ثم المراقبة: بما أنك لا تملك وصولاً للخادم، فإن السجلات (Logs) والمقاييس (Metrics) هي عيونك. تعلم استخدام أدوات مثل AWS CloudWatch و AWS X-Ray لفهم أداء دوالك وتصحيح الأخطاء.
4. استخدم إطار عمل: إدارة العشرات أو المئات من الدوال يدويًا عبر واجهة AWS أمر مرهق. استخدم أطر عمل مثل Serverless Framework أو AWS SAM. هذه الأدوات تسمح لك بتعريف كامل بنيتك التحتية (الدوال، بوابات API، قواعد البيانات) في ملف واحد (عادة `serverless.yml`) ونشرها بأمر واحد.

الخلاصة النهائية ونصيحة من القلب

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

نصيحتي لك: لا تخف من التجربة. في المرة القادمة التي تفكر فيها في بناء مشروع جانبي أو واجهة برمجية جديدة، امنح Serverless فرصة. ابدأ بدالة Lambda بسيطة. قد تتفاجأ من مقدار المال وراحة البال التي ستوفرها. ✅

بالتوفيق يا جماعة، وإذا عندكم أي سؤال، أنا حاضر.