كنا ندفع ثمن الخوادم حتى وهي نائمة: كيف حررتنا الحوسبة بدون خوادم (Serverless) من جحيم التكاليف الخاملة؟

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

لما صار وقت إطلاق المشروع، عملنا زي ما كل الناس بتعمل: حجزنا سيرفر (خادم) على إحدى الخدمات السحابية المعروفة، نزلنا عليه كل شي، وشغلنا التطبيق. في الأيام الأولى، كان الوضع ممتاز، المستخدمين بدوا يجوا، والتطبيق شغال زي الساعة. لكن بعد فترة الحماس الأولية، لاحظنا إنه استخدام التطبيق موسمي جدًا. بيجي عليه ضغط كبير في أوقات معينة من اليوم أو الأسبوع، وباقي الوقت… “نايم في العسل”، ما في حدا تقريبًا.

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

ما هي مشكلة “الخوادم النائمة”؟

القصة اللي حكيتها هي مثال بسيط على مشكلة ضخمة في عالم تطوير البرمجيات التقليدي، وهي مشكلة “التكاليف الخاملة” أو الـ Idle Costs. عشان نفهمها أكثر، خلينا نفصّلها:

في النموذج التقليدي، لما بدك تشغل تطبيق على الإنترنت، أنت بتقوم بالخطوات التالية:

1. حجز الموارد (Provisioning): بتروح على مزود خدمة سحابية (زي AWS, Azure, Google Cloud) وبتحجز جهاز افتراضي (Virtual Machine) أو سيرفر بمواصفات معينة (مثلاً 2 CPU, 4GB RAM).
2. الدفع المستمر: من لحظة ما تحجز هذا السيرفر، بيبدأ العداد يحسب عليك. أنت بتدفع مقابل “الوقت” اللي هاد السيرفر محجوز إلك، مش مقابل “الاستخدام” الفعلي. يعني سواء تطبيقك استقبل مليون طلب أو صفر طلب، الفاتورة تقريبًا نفسها.
3. الإدارة والصيانة: أنت مسؤول عن كل شي: تحديث نظام التشغيل، تطبيق التحديثات الأمنية، تنصيب الـ Web Server، مراقبة أداء السيرفر، ولو زاد الضغط، أنت المسؤول عن عملية التوسع (Scaling) المعقدة.

ببساطة، أنت تدفع ثمن “جاهزية” السيرفر، وليس ثمن “عمله” الفعلي. وهذا هو بالضبط تعريف الهدر في الموارد.

ودخلت علينا “السيرفرلس”… ثورة هادئة في عالم السحابة

وسط هذا الجحيم من التكاليف الخاملة والتعقيدات الإدارية، ظهر مفهوم ثوري اسمه “الحوسبة بدون خوادم” أو Serverless. وأول شي لازم أوضحه، الاسم خدّاع شوي. الخوادم بعدها موجودة، ما تبخرت! لكن الفكرة إنك أنت كمبرمج بطلت تشوفها أو تتعامل معها أو تديرها. مزود الخدمة السحابية هو اللي تكفّل بكل هاي القصة.

الفكرة الجوهرية في الـ Serverless، وتحديدًا في نموذج “الوظائف كخدمة” (Function as a Service – FaaS) مثل AWS Lambda، هي كالتالي:

• أنت تكتب الكود الخاص بك على شكل “وظيفة” (Function) صغيرة ومستقلة تؤدي مهمة محددة.
• ترفع هذه الوظيفة على المنصة السحابية.
• المنصة لا تقوم بتشغيل الكود إلا عند الحاجة فقط! يعني عند وقوع “حدث” (Event) معين. هذا الحدث ممكن يكون طلب HTTP من مستخدم، أو رفع ملف جديد، أو إضافة سجل جديد في قاعدة البيانات.
• بعد انتهاء تنفيذ الوظيفة، “تختفي” مرة أخرى ولا تستهلك أي موارد.

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

كيف حررتنا الحوسبة بدون خوادم؟

بالعودة لمشروعنا، كان التحول إلى Serverless بمثابة طوق نجاة حقيقي. هذه هي الفوائد الملموسة التي لمسناها على أرض الواقع:

وداعاً للتكاليف الخاملة

هذه هي الفائدة الأوضح والأهم. فاتورتنا الشهرية انخفضت بشكل دراماتيكي. بدلًا من دفع 50-100 دولار شهريًا لسيرفر معظم وقته خامل، صرنا ندفع سنتات أو دولارات قليلة جدًا. النموذج صار عادلًا: ندفع فقط عندما يستخدم الناس تطبيقنا ويحقق لنا قيمة فعلية.

التوسع التلقائي… “على قد الحمل بتمد رجليك”

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

التركيز على الكود، مش على البنية التحتية

كمبرمجين، شغفنا هو في كتابة الكود وحل المشاكل البرمجية. ما حدا فينا بحب يقضي وقته في تحديث أنظمة التشغيل أو تعديل ملفات إعدادات السيرفرات. مع الـ Serverless، صرنا نركز 100% من طاقتنا على كتابة “المنطق البرمجي” (Business Logic) اللي بيخدم المستخدم وبجيب قيمة للمشروع. زادت إنتاجيتنا بشكل ملحوظ، وصرنا نطلق الميزات الجديدة بسرعة أكبر.

مثال عملي: من سيرفر تقليدي إلى Lambda

حتى تكون الصورة أوضح، خلينا نأخذ مثال عملي شائع جدًا: خدمة مصغرة لمعالجة الصور. السيناريو هو أن المستخدم يرفع صورة، ونريد أن ننشئ نسخة مصغرة (Thumbnail) منها تلقائيًا.

الطريقة التقليدية (سيرفر Express.js)

كنا سنبني سيرفر صغير باستخدام Node.js و Express، ونتركه يعمل 24/7. الكود قد يبدو هكذا:

// Server running 24/7 on a VM/EC2 instance
const express = require('express');
const multer = require('multer'); // For file uploads
const sharp = require('sharp');   // For image processing

const app = express();
const upload = multer({ dest: 'uploads/' });

app.post('/upload', upload.single('avatar'), async (req, res) => {
  try {
    const imagePath = req.file.path;
    const thumbnailPath = `thumbnails/thumb-${req.file.filename}.jpg`;

    // Resize image
    await sharp(imagePath)
      .resize(150, 150)
      .toFile(thumbnailPath);

    res.status(201).send({ message: 'Thumbnail created!', path: thumbnailPath });
  } catch (error) {
    res.status(500).send({ error: 'Image processing failed.' });
  }
});

app.listen(3000, () => {
  console.log('Server is always running, waiting for uploads...');
});

هذا السيرفر يجب أن يبقى يعمل طوال الوقت، مما يستهلك الموارد والتكاليف.

طريقة الحوسبة بدون خوادم (AWS Lambda + S3)

الآن، لنفكر بطريقة “الأحداث”. الحدث هو “رفع صورة جديدة”.

1. نضبط خدمة تخزين الملفات (مثل AWS S3) بحيث تقوم بإرسال “إشعار” كلما تم رفع ملف جديد إلى مجلد معين.
2. هذا الإشعار يقوم بتشغيل وظيفة Lambda الخاصة بنا.

كود وظيفة Lambda باستخدام Node.js قد يبدو هكذا:

// A Lambda function, runs only when a file is uploaded to S3
const AWS = require('aws-sdk');
const sharp = require('sharp');

const s3 = new AWS.S3();

exports.handler = async (event) => {
  // Get the bucket and key (filename) from the event
  const bucket = event.Records[0].s3.bucket.name;
  const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/+/g, ' '));
  const newKey = `thumbnails/thumb-${key.split('/').pop()}`;

  try {
    // 1. Get image from S3
    const response = await s3.getObject({ Bucket: bucket, Key: key }).promise();

    // 2. Resize image
    const thumbnailBuffer = await sharp(response.Body)
      .resize(150, 150)
      .toFormat('jpeg')
      .toBuffer();
    
    // 3. Upload thumbnail back to S3
    await s3.putObject({
        Bucket: bucket,
        Key: newKey,
        Body: thumbnailBuffer,
        ContentType: 'image/jpeg'
    }).promise();

    console.log(`Thumbnail created successfully: ${newKey}`);
    return { status: 'success' };

  } catch (err) {
    console.error('Error processing image:', err);
    throw err;
  }
};

لاحظ الفرق في التفكير: الكود الثاني لا يحتوي على سيرفر أو “listener”. هو مجرد وظيفة تتوقع “حدثًا” لتستيقظ، تعمل لثوانٍ معدودة، ثم تعود للنوم. التكلفة؟ ربما جزء من الألف من السنت لكل صورة تتم معالجتها. والجمال في الأمر أنه لو قام 1000 شخص برفع صور في نفس اللحظة، ستقوم AWS بتشغيل 1000 نسخة من هذه الوظيفة بالتوازي بدون أي مشكلة.

نصائح من “أبو عمر” لدخول عالم الـ Serverless

من خبرتي المتواضعة، إذا كنت تفكر في البدء بهذا العالم، اسمح لي أن أقدم لك بعض النصائح العملية:

• ابدأ صغيرًا: لا تحاول تحويل مشروعك الضخم بالكامل دفعة واحدة. ابدأ بمهمة صغيرة ومنفصلة. مثلاً، وظيفة لإرسال إيميل ترحيبي عند تسجيل مستخدم جديد، أو مهمة مجدولة (Cron Job) لتنظيف قاعدة البيانات كل ليلة.
• تعلم الأدوات: إدارة عشرات الوظائف يدويًا أمر صعب. تعلم استخدام أطر العمل مثل Serverless Framework أو AWS SAM. هذه الأدوات تجعل عملية بناء واختبار ونشر التطبيقات بدون خوادم أسهل بكثير.
• فكر بطريقة “الحدث”: هذا هو التحول الذهني الأهم. بدلًا من التفكير في “سيرفر ينتظر طلبات”، فكر في “أحداث تقع” و “وظائف تستجيب”. ما هي الأحداث في تطبيقك؟ تسجيل مستخدم، رفع ملف، ضغطة زر، وصول رسالة… كل هذه مرشحة ممتازة لتكون وظيفة Serverless.
• راقب تكاليفك وفواتيرك: صحيح أنها موفرة، لكن الخطأ وارد. وظيفة بها حلقة لا نهائية (infinite loop) يمكن أن تتسبب في فاتورة غير متوقعة. كل المنصات السحابية توفر أدوات لمراقبة التكاليف ووضع تنبيهات (Billing Alerts). استخدمها دائمًا، “القرش الأبيض بينفع في اليوم الأسود”.
• افهم “البداية الباردة” (Cold Start): عندما لا يتم استدعاء وظيفتك لفترة، تقوم المنصة بإيقافها تمامًا. عند أول طلب بعد فترة الخمول، تحتاج المنصة بضعة أجزاء من الثانية (أو ثوانٍ قليلة) لتهيئتها مرة أخرى. هذا التأخير يسمى “البداية الباردة”. لمعظم التطبيقات، هذا التأخير لا يذكر، لكن لو كان تطبيقك حساسًا جدًا للسرعة، هناك تقنيات للتعامل معها مثل “Provisioned Concurrency”.

الخلاصة: هل الـ Serverless هي الحل السحري لكل شيء؟

بكل صراحة، لا. لا يوجد حل سحري واحد يناسب كل المشاكل في عالمنا التقني. الحوسبة بدون خوادم قد لا تكون الخيار الأمثل للتطبيقات التي تتطلب اتصالات مستمرة ومفتوحة لفترات طويلة (مثل غرف الدردشة القديمة التي تستخدم WebSockets أو سيرفرات الألعاب) أو المهام التي تحتاج وقت تنفيذ طويل جدًا (أكثر من 15 دقيقة).

ولكن، بالنسبة لغالبية ساحقة من حالات الاستخدام على الويب اليوم – من واجهات برمجة التطبيقات (APIs)، والخدمات المصغرة (Microservices)، ومهام معالجة البيانات، والأتمتة، وتطبيقات الويب – فإن الـ Serverless ليست مجرد خيار، بل هي غالبًا الخيار الأذكى والأكثر كفاءة وفعالية من حيث التكلفة.

لقد حررتنا من قيود إدارة الخوادم، وسمحت لنا بالتركيز على ما يهم حقًا: بناء برمجيات رائعة. جربوها، ومش رح تندموا. والله الموفق! 😉