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

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

قبل كم سنة، كنت أشتغل مع فريق ناشئ عنده فكرة تطبيق رائعة. الحماس كان في السماء، وكلنا كنا مؤمنين بالمنتج. بعد شهور من التعب والبرمجة ليلاً ونهاراً، أطلقنا التطبيق. وكأي فريق تقني، كان لازم نجهز البنية التحتية (Infrastructure). وقتها، الخيار الطبيعي كان إننا “نستأجر” خادم افتراضي (Virtual Server) من أحد مزودي الخدمات السحابية الكبار.

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

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

الحوسبة التقليدية: الوحش الذي لا ينام

قبل ما نحكي عن الحل، خلينا نوضح المشكلة بشكل أعمق. في النموذج التقليدي (سواء كان خادماً فيزيائياً عندك في المكتب أو خادماً افتراضياً على السحابة مثل AWS EC2 أو Azure VM)، أنت تقوم بالتالي:

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

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

الحوسبة بلا خوادم (Serverless): المنقذ الذي لا يطلب أجراً وهو نائم

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

على بلاطة، الفكرة بسيطة جداً:

1. أنت تكتب الكود الخاص بك على شكل “دوال” (Functions) صغيرة ومستقلة.
2. ترفع هذه الدوال على منصة سحابية (مثل AWS Lambda, Google Cloud Functions, Azure Functions).
3. تحدد “حدثاً” (Event) معيناً لتشغيل هذه الدالة. هذا الحدث ممكن يكون:
   • طلب HTTP API جديد.
   • رفع ملف جديد على خدمة تخزين (مثل Amazon S3).
   • رسالة جديدة في طابور رسائل (like SQS).
   • مهمة مجدولة تعمل كل ساعة.

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

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

مثال عملي: معالجة الصور عند رفعها

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

باستخدام Serverless (وتحديداً AWS Lambda كمثال)، يصبح الأمر “شغل مرتب” ومختلف تماماً:

1. الحدث (Trigger): نُخبر AWS Lambda أن “تستمع” لخدمة التخزين S3. الحدث هو: “عند رفع أي ملف جديد إلى مجلد ‘uploads'”.
2. الدالة (Function): نكتب دالة بسيطة بلغة Python (أو أي لغة أخرى) تقوم بالتالي:
   • تستقبل معلومات الملف الذي تم رفعه (اسمه ومكانه).
   • تقرأ الصورة.
   • تغير حجمها إلى حجم أصغر (مثلاً 150×150 بكسل).
   • تحفظ النسخة المصغرة في مجلد آخر على S3 اسمه ‘thumbnails’.

هذا كل شيء! الآن، كلما رفع مستخدم صورة، تعمل هذه الدالة لجزء من الثانية، تنفذ مهمتها، وتتوقف. التكلفة؟ قد تكون أقل من 0.00001 دولار لكل صورة. ولو لم يرفع أحد أي صورة طوال الشهر، التكلفة ستكون صفر.

مثال كود (Python على AWS Lambda)

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

import boto3
from PIL import Image
import io

# تهيئة عميل خدمة S3
s3_client = boto3.client('s3')

def resize_image_handler(event, context):
    # 1. استخراج اسم المجلد (bucket) واسم الملف (key) من الحدث القادم من S3
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    file_key = event['Records'][0]['s3']['object']['key']
    
    # تجنب حلقة لا نهائية (حتى لا تعمل الدالة على الصورة المصغرة التي تنتجها)
    if 'thumbnails/' in file_key:
        return

    # 2. تحميل الصورة من S3 إلى الذاكرة
    response = s3_client.get_object(Bucket=bucket_name, Key=file_key)
    image_content = response['Body'].read()
    
    image = Image.open(io.BytesIO(image_content))
    
    # 3. تغيير حجم الصورة
    thumbnail_size = (150, 150)
    image.thumbnail(thumbnail_size)
    
    # 4. حفظ الصورة المصغرة في الذاكرة المؤقتة
    buffer = io.BytesIO()
    image.save(buffer, format="JPEG")
    buffer.seek(0)
    
    # 5. رفع الصورة المصغرة إلى مجلد 'thumbnails' في S3
    new_key = f"thumbnails/thumb_{file_key.split('/')[-1]}"
    s3_client.put_object(
        Bucket=bucket_name,
        Key=new_key,
        Body=buffer,
        ContentType='image/jpeg'
    )
    
    print(f"تم إنشاء صورة مصغرة بنجاح: {new_key}")
    
    return {'status': 'success'}

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

متى نستخدم Serverless؟ وهل هي الحل السحري لكل شيء؟

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

• واجهات برمجة التطبيقات (APIs): خصوصاً للخدمات الصغيرة (Microservices) التي لا تحتاج لاتصال دائم.
• معالجة البيانات غير المتزامنة: مثل مثال معالجة الصور، أو تحويل ملفات الفيديو، أو تحليل سجلات (logs).
• المهام المجدولة (Cron Jobs): بدلاً من تشغيل خادم كامل فقط لتنفيذ سكربت كل ليلة، يمكنك استخدام دالة Serverless تعمل مرة واحدة وتتوقف.
• الواجهات الخلفية لتطبيقات الويب والموبايل: التي تشهد حركة مرور متقلبة.
• تطبيقات إنترنت الأشياء (IoT): حيث ترسل آلاف الأجهزة بيانات صغيرة بشكل متقطع.

لكن، على بلاطة، هناك حالات قد لا تكون Serverless الخيار الأفضل فيها:

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

الخلاصة: فكّر بالأحداث، وليس بالخوادم 💡

بالنسبة لنا في تلك الشركة الناشئة، كان التحول إلى Serverless بمثابة طوق نجاة. فاتورتنا الشهرية للبنية التحتية انخفضت بنسبة تقارب 80-90%. الأهم من ذلك، تخلصنا من “وجعة الراس” المتعلقة بإدارة الخوادم وتحديثها ومراقبتها، وتفرغنا لما هو أهم: كتابة كود يخدم مستخدمينا ويحل مشاكلهم.

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

إذا كانت الإجابة “نعم”، فربما تكون قد وجدت للتو طريقة لتوفير الكثير من المال والجهد، وبناء نظام أكثر مرونة وقابلية للتوسع. ابدأ صغيراً، جرب بناء API بسيط أو مهمة معالجة بيانات، وسترى بنفسك القوة الهائلة لهذه التقنية.

ودمتم سالمين ومبدعين.