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

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

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

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

قعدت مع الفريق، بنحلل الوضع. اكتشفنا الكارثة: تطبيقنا كان يشهد ذروة استخدام في ساعات المساء فقط، حوالي 3-4 ساعات. باقي اليوم، يعني حوالي 20 ساعة، السيرفر الضخم اللي بندفع عليه دم قلبنا كان قاعد “بشرب شاي وبستنى الفرج”. كان خامل تمامًا، لكن العداد شغال! وقتها واحد من الشباب حكى جملة ما بنساها: “يا زلمة، إحنا بندفع إيجار لسيرفر نايم!”.

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

ما هي الحوسبة بلا خوادم (Serverless)؟ ولماذا “بلا خوادم” تسمية خادعة؟

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

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

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

كيف كنا نعمل “زمان”؟ (نموذج الخادم التقليدي)

عشان نفهم عظمة Serverless، خلينا نتذكر “أيام العز” مع الخوادم التقليدية (سواء كانت في شركة أو على السحابة كـ IaaS):

• التجهيز (Provisioning): لازم تختار حجم السيرفر، كم CPU، كم RAM، مساحة التخزين، ونظام التشغيل. لو اخترت أقل من اللازم، بيوقع الموقع. ولو اخترت أكثر من اللازم، بتدفع زيادة على الفاضي.
• الإعداد (Configuration): تنزيل وتحديث نظام التشغيل، تنصيب الـ Web Server (زي Apache أو Nginx)، تنصيب بيئة التشغيل (Node.js, Python, PHP)، وتجهيز كل المكتبات اللازمة.
• النشر (Deployment): رفع الكود على السيرفر، والتأكد إنه كل شيء بيشتغل مع بعضه صح.
• الصيانة (Maintenance): أنت المسؤول عن التحديثات الأمنية، ومراقبة أداء السيرفر، ولو صار أي عطل نص الليل، لازم تصحى وتحله.
• التوسع (Scaling): لو زاد الضغط على موقعك، لازم تجهز سيرفرات جديدة يدويًا أو عن طريق إعدادات معقدة (Auto Scaling Groups).

المشكلة الأساسية: أنت تدفع مقابل “الوقت” الذي يبقى فيه الخادم شغالًا (24/7)، وليس مقابل “العمل” الفعلي الذي يقوم به.

كيف غيرت Serverless اللعبة؟ (النموذج الجديد)

النموذج الجديد قلب الطاولة. بطلنا نفكر بـ “الخوادم”، وصرنا نفكر بـ “الأحداث” (Events). الكود تبعك صار عبارة عن دالة صغيرة بتستجيب لحدث معين. بس يقع الحدث، الدالة بتشتغل. بس تخلص، بترجع تنام.

أشهر المحفزات (Triggers) للدوال بلا خوادم:

• طلب HTTP: أشهر مثال هو بناء واجهات برمجية (APIs). كل طلب API يستدعي دالة معينة (عبر خدمة مثل Amazon API Gateway).
• رفع ملف جديد: عند رفع صورة أو ملف على خدمة تخزين (مثل Amazon S3)، يمكن تشغيل دالة لمعالجتها (مثلاً، ضغط الصورة أو تحليل محتواها).
• رسالة في طابور (Queue): عند وصول رسالة جديدة إلى طابور (مثل Amazon SQS)، يتم تشغيل دالة لمعالجتها.
• تغيير في قاعدة البيانات: عند إضافة سجل جديد في قاعدة بيانات NoSQL (مثل DynamoDB)، يمكن تشغيل دالة لعمل شيء ما بناءً على هذا التغيير.
• مهمة مجدولة (Cron Job): تشغيل دالة في أوقات محددة (مثلاً، كل يوم الساعة 3 الفجر لإرسال تقرير).

مثال عملي: من سيرفر EC2 إلى دالة Lambda

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

الطريقة التقليدية (على سيرفر EC2)

كنا بنعملها عن طريق سيرفر Node.js/Express شغال 24 ساعة. السيرفر فيه نقطة نهاية (Endpoint) اسمها /upload. لما يوصلها طلب فيه صورة، السيرفر بيستخدم مكتبة مثل sharp عشان يصغرها ويخزنها. المشكلة؟ السيرفر هذا لازم يظل شغال ومستني تيجي صورة، وممكن ما تيجي ولا صورة لساعات طويلة.

طريقة Serverless (باستخدام AWS Lambda و S3)

هون بيجي الإبداع. غيرنا المعمارية بالكامل لتصبح كالتالي:

1. المستخدم يرفع الصورة مباشرة إلى مخزن S3 في مجلد اسمه /uploads.
2. مخزن S3 نفسه، عند استقباله لملف جديد في هذا المجلد، يقوم “بتحفيز” أو استدعاء دالة Lambda التي كتبناها.
3. دالة Lambda تأخذ الصورة الجديدة، تستخدم نفس مكتبة sharp لتصغيرها، ثم تحفظ النسخة المصغرة في نفس مخزن S3 ولكن في مجلد آخر اسمه /thumbnails.

النتيجة؟ لا يوجد سيرفر شغال 24/7. الكود لا يعمل إلا عند رفع صورة، ولمدة ثوانٍ قليلة فقط. التكلفة انخفضت من عشرات الدولارات شهريًا لهذه المهمة تحديدًا إلى بضعة سنتات!

مثال كود لدالة Lambda (Node.js)

هذا مثال حقيقي ومبسط للكود اللي ممكن يكون داخل دالة Lambda لعمل هذه المهمة:

const AWS = require('aws-sdk');
const sharp = require('sharp'); // يجب رفع هذه المكتبة مع الدالة كـ Layer أو في نفس الحزمة

const s3 = new AWS.S3();

exports.handler = async (event) => {
    // 1. استخلاص اسم المخزن (Bucket) واسم الملف (Key) من الحدث
    const bucket = event.Records[0].s3.bucket.name;
    const key = decodeURIComponent(event.Records[0].s3.object.key.replace(/+/g, ' '));
    
    // منع حدوث حلقة لا نهائية (الدالة تستدعي نفسها)
    if (key.startsWith('thumbnails/')) {
        return;
    }

    try {
        // 2. قراءة الصورة الأصلية من S3
        const imageObject = await s3.getObject({ Bucket: bucket, Key: key }).promise();

        // 3. تصغير الصورة باستخدام مكتبة sharp
        const thumbnailBuffer = await sharp(imageObject.Body)
            .resize({ width: 200, height: 200, fit: 'inside' })
            .toBuffer();

        // 4. رفع الصورة المصغرة إلى مجلد thumbnails
        const thumbnailKey = `thumbnails/thumb-${key.split('/').pop()}`;
        await s3.putObject({
            Bucket: bucket,
            Key: thumbnailKey,
            Body: thumbnailBuffer,
            ContentType: 'image/jpeg' // أو حسب نوع الصورة
        }).promise();

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

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

مزايا وعيوب الحوسبة بلا خوادم (من أرض الواقع)

زي أي تقنية، Serverless مش حل سحري لكل المشاكل. إلها إيجابياتها وسلبياتها.

المزايا (الإيجابيات)

• توفير هائل في التكاليف: هذه أكبر ميزة. “الفلوس اللي بتدفعها على قد الشغل وبس”. مثالية للمشاريع الجديدة والتطبيقات ذات الاستخدام المتقطع.
• التوسع التلقائي (Automatic Scaling): لو دالتك استقبلت 10 طلبات في الثانية، AWS بيشغلك 10 نسخ منها. لو استقبلت 1000، بيشغلك 1000. كل هذا بشكل تلقائي وبدون أي تدخل منك.
• تقليل العبء الإداري: انسى هم تحديثات السيرفرات والمشاكل الأمنية للبنية التحتية. “ركّز على الكود واترك الباقي عليهم”.
• سرعة الوصول للسوق (Faster Time-to-Market): بما أنك لا تقلق بشأن البنية التحتية، يمكنك بناء ونشر الميزات الجديدة بسرعة أكبر.

العيوب (السلبيات والتحديات)

• البداية الباردة (Cold Start): إذا كانت دالتك خاملة لفترة، فإن أول طلب لها قد يستغرق وقتًا أطول قليلاً (من بضع مئات من الملي ثانية إلى ثوانٍ) لأن المنصة تحتاج إلى تهيئة بيئة التشغيل. يمكن التغلب على هذا بأساليب مثل “Provisioned Concurrency” لكنها تزيد التكلفة.
• التقييد بالمزوّد (Vendor Lock-in): كتابة الكود لـ AWS Lambda يجعله مرتبطًا بنظام AWS. نقله إلى Azure Functions أو Google Cloud Functions ليس سهلاً دائمًا.
• التعقيد في المراقبة وتصحيح الأخطاء: بدلًا من تطبيق واحد متكامل، يصبح لديك عشرات أو مئات الدوال المتناثرة. تتبع طلب واحد عبر عدة دوال يمكن أن يكون صعبًا بدون الأدوات المناسبة (مثل AWS X-Ray).
• قيود زمن التنفيذ والموارد: دوال Lambda لها حد أقصى لزمن التنفيذ (حالياً 15 دقيقة) وحدود على الذاكرة. هذا يجعلها غير مناسبة للمهام الطويلة جدًا (مثل تدريب نماذج الذكاء الاصطناعي الكبيرة).

نصائح “أبو عمر” الذهبية للبدء مع Serverless

1. ابدأ صغيرًا: لا تحاول تحويل تطبيقك بالكامل مرة واحدة. اختر مهمة صغيرة ومعزولة (مثل إرسال إيميل ترحيبي، أو معالجة الصور كما في مثالنا) وحولها إلى دالة Serverless. قس النتائج وقرر الخطوة التالية.
2. استخدم إطار عمل (Framework): لا تقم بإعداد كل شيء يدويًا. استخدم أدوات مثل Serverless Framework أو AWS SAM. هذه الأدوات “بتخلي حياتك أسهل بكتير” في تعريف الدوال، إدارة الصلاحيات، والنشر.
3. فكّر بالأحداث (Think in Events): يتطلب التحول إلى Serverless تغييرًا في طريقة التفكير. ابدأ في تحليل تطبيقك كـ “مجموعة من الأحداث” وليس كـ “عملية مستمرة”.
4. لا تخف من التجربة: معظم مزودي الخدمات السحابية يقدمون طبقة مجانية (Free Tier) سخية جدًا لخدمات Serverless. يمكنك تشغيل مليون طلب لدالة Lambda شهريًا مجانًا على AWS. استغل هذا وجرّب بنفسك.

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

بالتأكيد لا. لا يوجد حل سحري في هندسة البرمجيات. الحوسبة بلا خوادم هي أداة قوية جدًا في صندوق أدواتك كمطور، ولكن يجب أن تعرف متى تستخدمها.

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

نصيحتي الأخيرة لكم: لا تكن مثلنا وتنتظر الفاتورة الصادمة حتى تبدأ بالتعلم. ابدأ اليوم. اقرأ، جرب، وافشل، ثم جرب مرة أخرى. عالم Serverless يفتح آفاقًا جديدة للإبداع بتكلفة شبه معدومة، وسيكون جزءًا أساسيًا من مستقبل تطوير البرمجيات. ✨