سيرفراتنا كانت تلتهم ميزانيتنا وهي خاملة: كيف أنقذتنا ‘الحوسبة بدون خوادم’ (Serverless) من جحيم الفواتير المنتفخة؟

قصة فاتورة كادت أن “تجلطنا”

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

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

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

المشكلة في النموذج التقليدي: أنت تدفع ثمن “الانتظار”

قبل ما نغوص في الحل، خلينا نفهم أصل المشكلة. في عالم الحوسبة السحابية التقليدي (IaaS – Infrastructure as a Service)، أنت تقوم بـ:

1. استئجار خادم افتراضي (Virtual Machine) مثل AWS EC2 أو Azure VM.
2. تحديد مواصفاته (CPU, RAM, Storage).
3. تثبيت نظام التشغيل والتحديثات الأمنية.
4. نشر الكود الخاص بك وتشغيله.

المشكلة الأساسية هنا أنك تدفع مقابل “وقت تشغيل” الخادم، وليس مقابل “وقت التنفيذ الفعلي” للكود. إذا كان خادمك يعمل لمدة 720 ساعة في الشهر، ستدفع مقابل 720 ساعة، حتى لو كان الكود الخاص بك قد عمل لمدة 5 ساعات فقط طوال الشهر. هذا هو “الدفع مقابل الخمول” (Paying for Idle)، وهو أكبر عدو للشركات الناشئة والمشاريع ذات الميزانيات المحدودة.

باختصار، أنت تبني مطعماً ضخماً وتدفع إيجاره وكهرباء ورواتب موظفيه بالكامل، حتى في الأيام التي لا يأتيك فيها أي زبون.

المنقذ: ما هي الحوسبة بدون خوادم (Serverless)؟

هنا يأتي دور الـ Serverless ليقلب الطاولة. الاسم قد يكون خادعاً بعض الشيء، فكلمة “بدون خوادم” لا تعني عدم وجود خوادم على الإطلاق. بالتأكيد هناك خوادم، لكن الفكرة هي: أنت كمطور لا تديرها ولا تفكر فيها.

الحوسبة بدون خوادم هي نموذج يقوم فيه مزود الخدمة السحابية (مثل AWS, Google Cloud, Azure) بإدارة البنية التحتية بالكامل نيابة عنك. أنت كل ما عليك فعله هو كتابة الكود الخاص بك على شكل “دوال” (Functions) ورفعها على المنصة. هذه المنصة تقوم تلقائياً بتشغيل الكود الخاص بك عند الحاجة فقط، وتتكفل بتوفير الموارد اللازمة له وتوسيعها (Scaling) حسب الضغط.

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

هذا المفهوم يُعرف بشكل أدق بـ FaaS (Functions as a Service) أو “الدوال كخدمة”، وأشهر مثال عليه هو خدمة AWS Lambda.

كيف طبقنا الحل باستخدام AWS Lambda؟

بالعودة لقصتنا، قررنا التخلص من سيرفر EC2 المكلف والانتقال إلى AWS Lambda. الخطوات كانت بسيطة ومباشرة بشكل مدهش:

1. كتابة الدالة (Function): أخذنا نفس كود الـ Node.js الذي كان يعالج الصور، وقمنا بتعديل بسيط عليه ليصبح متوافقاً مع صيغة دالة Lambda.
2. تحديد المُحفِّز (Trigger): بدل أن يظل الكود “ينتظر”، قمنا بربط دالة Lambda بحدث (Event). في حالتنا، كان الحدث هو “رفع ملف جديد” على مساحة تخزين S3.
3. النشر (Deployment): رفعنا الكود المضغوط مع المكتبات التي يستخدمها إلى Lambda.

والنتيجة؟ السيناريو الجديد أصبح كالتالي:

• المستخدم يرفع صورة إلى مجلد معين في S3.
• خدمة S3 ترسل إشعاراً تلقائياً إلى Lambda.
• تقوم Lambda “بإيقاظ” الكود الخاص بنا، وتمرير معلومات الصورة إليه.
• الكود يقوم بمعالجة الصورة وحفظ النسخة الجديدة في مجلد آخر على S3.
• تنتهي الدالة، وتتوقف عملية المحاسبة فوراً.

الفاتورة الشهرية لهذه العملية تحولت من حوالي 70 دولاراً (ثمن سيرفر EC2) إلى أقل من 3 دولارات! نعم، قرأتها بشكل صحيح. وفرنا أكثر من 95% من التكلفة لأننا أصبحنا ندفع فقط مقابل الثواني القليلة التي يتم فيها معالجة الصور فعلياً.

مثال كود: دالة Lambda لمعالجة الصور (Node.js)

لتقريب الصورة، هذا مثال مبسط لكيف يمكن أن تبدو دالة Lambda لمعالجة الصور باستخدام مكتبة sharp الشهيرة.

// index.js
const AWS = require('aws-sdk');
const sharp = require('sharp');

// تهيئة S3
const s3 = new AWS.S3();

// الدالة الرئيسية التي ستستدعيها Lambda
exports.handler = async (event, context) => {
    // استخراج اسم الحاوية (bucket) واسم الملف (key) من الحدث القادم من S3
    const bucket = event.Records[0].s3.bucket.name;
    const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/+/g, ' '));
    
    // اسم الحاوية الهدف للصور المعالجة
    const destBucket = bucket + '-processed';

    try {
        // 1. جلب الصورة الأصلية من S3
        const s3Object = await s3.getObject({ Bucket: bucket, Key: key }).promise();

        // 2. تغيير حجم الصورة باستخدام مكتبة sharp
        const resizedImageBuffer = await sharp(s3Object.Body)
            .resize({ width: 500 }) // تغيير العرض إلى 500 بكسل
            .toBuffer();

        // 3. رفع الصورة الجديدة إلى الحاوية الهدف
        await s3.putObject({
            Bucket: destBucket,
            Key: key,
            Body: resizedImageBuffer,
            ContentType: 'image/jpeg' // تحديد نوع الملف
        }).promise();

        console.log(`Success: Image ${key} processed and uploaded to ${destBucket}.`);
        return 'Success';

    } catch (error) {
        console.error('Error processing image:', error);
        throw error; // لإعلام Lambda بحدوث خطأ
    }
};

هذا الكود، عند رفعه إلى AWS Lambda وربطه بحاوية S3، سيقوم بكل العمل الشاق تلقائياً وبأقل تكلفة ممكنة.

نصائح من مطبخ أبو عمر: متى تستخدم Serverless؟

الـ Serverless أداة جبارة، لكنها ليست الحل السحري لكل المشاكل. من خبرتي، هذه أفضل الحالات لاستخدامها:

• واجهات برمجة التطبيقات (APIs): بناء REST APIs خفيفة وسريعة الاستجابة. بدلاً من سيرفر Express.js يعمل طوال الوقت، كل Endpoint يصبح دالة Lambda منفصلة.
• المهام الخلفية المتقطعة (Background Jobs): مثل حالتنا: معالجة الصور والفيديو، إرسال الإيميلات، إنشاء التقارير، مهام ETL (استخراج، تحويل، تحميل البيانات).
• تطبيقات الويب (Webhooks): استقبال ومعالجة البيانات من خدمات خارجية مثل Stripe, Slack, GitHub.
• إنترنت الأشياء (IoT): معالجة البيانات القادمة من آلاف الأجهزة والحساسات بشكل فوري.
• التطبيقات الموجهة بالأحداث (Event-Driven Apps): أي تطبيق يعتمد منطقه على وقوع أحداث معينة (مثل إضافة سجل جديد في قاعدة البيانات).

متى يجب أن تفكر مرتين؟

• المهام طويلة الأمد: معظم منصات FaaS لها حد أقصى لوقت التنفيذ (مثلاً 15 دقيقة في AWS Lambda). إذا كانت مهمتك تحتاج ساعات، فالـ Serverless ليس الخيار الأنسب.
• التطبيقات ذات الحمل الثابت والعالي جداً: إذا كان تطبيقك يتلقى ملايين الطلبات بشكل ثابت كل ثانية، قد يكون استئجار خادم مخصص أرخص على المدى الطويل.
• مشكلة “البداية الباردة” (Cold Start): عند استدعاء دالة لم تُستخدم منذ فترة، تحتاج المنصة بضعة أجزاء من الثانية (أو أكثر) لتهيئتها. هذا التأخير قد يكون غير مقبول في التطبيقات الحساسة جداً للزمن. (مع العلم أن هناك طرقاً لتقليل هذه المشكلة).

الخلاصة والزبدة 💡

الانتقال إلى الحوسبة بدون خوادم (Serverless) كان نقلة نوعية في طريقة تفكيرنا ببناء التطبيقات وإدارة التكاليف. هو ليس مجرد تقنية جديدة، بل هو عقلية مختلفة تماماً في التطوير.

الزبدة من كل هالحكي:

• ✅ توفير هائل في التكاليف: أنت تدفع فقط عند تنفيذ الكود، لا أكثر.
• 🚀 توسع تلقائي (Auto-Scaling): لا تقلق أبداً بشأن زيادة الضغط، المنصة تتكفل بذلك.
• 🛠️ تقليل العبء التشغيلي: انسَ تحديثات السيرفرات والمشاكل الأمنية لنظام التشغيل. ركز على كتابة كود يحل مشكلة حقيقية.
• 🧩 بنية مرنة: تشجعك على بناء تطبيقاتك على شكل وحدات صغيرة ومستقلة (Microservices).

نصيحتي الأخيرة لكل مطور أو صاحب مشروع: لا تخف من تجربة الـ Serverless. ابدأ بمشروع جانبي صغير أو بمهمة خلفية في تطبيقك الحالي. قم بتحويلها إلى دالة Lambda أو Azure Function وقارن التكلفة والأداء. أضمن لك أنك ستتفاجأ بالنتائج. يلا يا جماعة، شدّوا حيلكم وجربوها، فالمستقبل يبدو “بدون خوادم” إلى حد كبير. 👍