خوادمي كانت تعمل 24/7 لمهمة تستغرق ثوانٍ: كيف أنقذتني “الدوال عديمة الخادم” من جحيم التكاليف؟

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

قبل كم سنة، كنت شغال على مشروع شخصي، تطبيق بسيط لمشاركة الصور بين أفراد العائلة والأصدقاء. الفكرة كانت إنه أي حدا بحمّل صورة، النظام تلقائيًا يعمل منها نسخة مصغّرة (Thumbnail) عشان التحميل يكون أسرع على التطبيق. شغلة بسيطة، صح؟

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

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

كان الخادم مثل سيارة أجرة واقفة قدام بيتي وشغّال العداد ليل نهار، مع إني بستخدمها مشوار واحد باليوم مدته 5 دقايق. هذا هو “جحيم التكاليف الخاملة” (The Hell of Idle Costs). كنت أدفع ثمن 99.9% من الوقت اللي الخادم فيه ما بعمل إشي، بس قاعد بستنى! هنا كانت بداية رحلتي مع عالم غيّر طريقة تفكيري تمامًا: عالم الحوسبة عديمة الخادم أو الـ Serverless.

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

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

ببساطة، بدل ما تحجز خادم وتثبت عليه نظام تشغيل وتحدثه وتأمّنه وتراقب أداءه، أنت بتقوم بس بكتابة الكود تبعك (على شكل دالة أو Function) وبترفعه للمنصة السحابية (مثل AWS Lambda, Google Cloud Functions, Azure Functions). المنصة هي اللي بتتولى كل شي ثاني.

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

تخيلها مثل لمبة بحساس حركة. اللمبة مطفية طول الوقت (ما بتصرف كهرباء)، ولما حدا يمر من قدامها (هذا هو الحدث)، بتضوي لكم ثانية (بتنفذ المهمة وبتصرف كهرباء)، وبعدين بترجع بتطفي. هذا هو جوهر الـ Serverless.

العودة لقصتي: كيف حلّت AWS Lambda المشكلة؟

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

قررت أنقل الكود تبعي لـ AWS Lambda، وهي خدمة الدوال كخدمة (Function as a Service – FaaS) من أمازون ويب سيرفيسز.

الخطوات العملية للانتقال (مثال مبسط)

كان الموضوع أسهل بكثير مما توقعت. هذه هي الخطوات اللي عملتها:

1. كتابة الدالة (The Function): أخذت نفس كود البايثون اللي كان عندي، وعدّلت عليه تعديل بسيط عشان يتناسب مع صيغة Lambda. الدالة في لامدا تستقبل معاملين أساسيين: event (يحتوي على معلومات عن الحدث اللي استدعى الدالة) و context (يحتوي على معلومات عن بيئة التنفيذ).
2. تحديد المُحفِّز (The Trigger): ربطت الدالة تبعتي بخدمة تخزين الملفات AWS S3. حددت إنه كل ما يتم رفع ملف جديد (حدث s3:ObjectCreated:*) على “مجلّد” (Bucket) معين اسمه raw-images، يتم استدعاء دالة لامدا تلقائيًا.
3. النشر والإعداد: قمت بضغط الكود مع المكتبات اللي بيحتاجها (مثل Pillow) في ملف ZIP ورفعته على لامدا. أعطيت الدالة الصلاحيات اللازمة عشان تقدر تقرأ من مجلد الصور الخام وتكتب في مجلد الصور المصغّرة thumbnails-images.

بعدها، وبكل بساطة، حذفت الخادم الافتراضي القديم اللي كان بكلفني عشرات الدولارات شهريًا. والنتيجة؟ الفاتورة الشهرية لهذه المهمة تحديدًا نزلت من حوالي 40-50 دولار إلى أقل من دولار واحد! وفي معظم الشهور كانت صفر، لأني كنت ضمن الطبقة المجانية (Free Tier) اللي بتوفرها AWS Lambda واللي بتعطيك مليون طلب مجاني كل شهر.

مثال كود: دالة لامدا لتصغير الصور باستخدام Python

عشان أوضح الفكرة أكثر، هذا مثال مبسط جدًا لكود بايثون ممكن يشتغل على AWS Lambda لنفس المهمة اللي حكيت عنها. الكود بيستخدم مكتبة boto3 للتفاعل مع خدمات AWS ومكتبة Pillow لمعالجة الصور.

import boto3
from PIL import Image
import io
import os

# تهيئة عملاء AWS
s3_client = boto3.client('s3')

# تحديد حجم الصورة المصغرة
THUMBNAIL_SIZE = (128, 128)

def lambda_handler(event, context):
    # استخراج اسم المجلد (Bucket) واسم الملف (Key) من الحدث
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    object_key = event['Records'][0]['s3']['object']['key']
    
    print(f"تم رفع صورة جديدة: {object_key} في المجلد: {bucket_name}")

    try:
        # 1. تحميل الصورة من S3 إلى الذاكرة
        response = s3_client.get_object(Bucket=bucket_name, Key=object_key)
        image_content = response['Body'].read()
        
        # 2. فتح الصورة باستخدام Pillow
        image = Image.open(io.BytesIO(image_content))
        
        # 3. إنشاء نسخة مصغرة
        image.thumbnail(THUMBNAIL_SIZE)
        
        # 4. حفظ النسخة المصغرة في الذاكرة بصيغة JPEG
        buffer = io.BytesIO()
        image.save(buffer, format="JPEG")
        buffer.seek(0)
        
        # 5. تحديد اسم ومسار النسخة المصغرة
        # مثال: لو الصورة الأصلية 'images/my-photo.jpg'
        # الصورة المصغرة ستكون 'thumbnails/my-photo.jpg'
        thumbnail_key = object_key.replace('images/', 'thumbnails/')
        
        # 6. رفع النسخة المصغرة إلى مجلد آخر في S3
        s3_client.put_object(
            Bucket=bucket_name, # أو يمكن أن يكون مجلد آخر
            Key=thumbnail_key,
            Body=buffer,
            ContentType='image/jpeg'
        )
        
        print(f"تم إنشاء وحفظ النسخة المصغرة بنجاح في: {thumbnail_key}")
        
        return {
            'statusCode': 200,
            'body': f"Successfully created thumbnail for {object_key}"
        }

    except Exception as e:
        print(f"حدث خطأ: {e}")
        raise e

هذا الكود هو كل ما تحتاجه. لا خوادم، لا تحديثات، لا قلق. فقط منطق العمل (Business Logic) الصافي.

مزايا الحوسبة عديمة الخادم: أكثر من مجرد توفير المال

صحيح أن توفير التكاليف كان الدافع الأول بالنسبة لي، لكن مع الوقت اكتشفت مزايا أخرى لا تقل أهمية:

1. التكلفة (Pay-for-value)

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

2. قابلية التوسع التلقائية (Automatic Scaling)

وهذه ميزة جبارة. في قصتي، لو قام شخص واحد برفع صورة، لامدا ستشغل نسخة واحدة من دالتي. لو قام 1000 شخص برفع صور في نفس الثانية، AWS ستقوم تلقائيًا بتشغيل 1000 نسخة متوازية من الدالة لمعالجة الطلبات فورًا، بدون أي تدخل مني. قارن هذا بالسيناريو التقليدي حيث ستحتاج إلى إعداد موازنات تحميل (Load Balancers) ومجموعات توسع تلقائي (Auto-scaling groups) وإدارة كل هذا التعقيد.

3. تقليل العبء الإداري (Reduced Operational Overhead)

انسَ أمر تحديثات نظام التشغيل، الثغرات الأمنية، إدارة السيرفرات، أو القلق بشأن “هل الخادم يعمل أم لا؟”. كل هذا العبء ينتقل إلى مزود الخدمة السحابية. هذا يعني أنك كمطور (أو كفريق صغير) يمكنك التركيز 100% على كتابة الكود الذي يضيف قيمة للمستخدم النهائي. زي ما بنقول: “بريح راسك” وبخليك تركز على شغلك الصح.

4. سرعة الوصول للسوق (Faster Time-to-Market)

بما أنك لست بحاجة إلى قضاء أسابيع في إعداد البنية التحتية، يمكنك تحويل الأفكار إلى منتجات عاملة بسرعة فائقة. يمكنك بناء ونشر واجهة برمجية (API) كاملة في ساعات بدلاً من أيام أو أسابيع.

لكن مهلاً يا أبو عمر، هل هي الحل السحري لكل شيء؟ (متى لا نستخدم Serverless)

لكل تقنية مكانها المناسب، والـ Serverless ليست استثناء. من المهم أن نكون واقعيين ونعرف حدودها:

• المهام طويلة الأمد (Long-running tasks): معظم منصات FaaS تضع حداً أقصى لمدة تنفيذ الدالة (مثلاً 15 دقيقة في AWS Lambda). إذا كانت لديك مهمة تحتاج ساعات لتنفيذها (مثل تدريب نماذج تعلم الآلة الكبيرة أو معالجة فيديوهات طويلة)، فالخادم المخصص أو الخدمات المخصصة لهذه المهام (مثل AWS Batch) تكون خيارًا أفضل.
• مشكلة البداية الباردة (Cold Starts): عندما لا يتم استدعاء دالتك لفترة، تقوم المنصة “بتجميدها” لتوفير الموارد. أول طلب يصل بعد فترة الخمول هذه قد يستغرق وقتًا أطول قليلاً (من بضع مئات من الملي ثانية إلى بضع ثوانٍ) لأن المنصة تحتاج إلى تهيئة بيئة التنفيذ من جديد. هذا التأخير يسمى “البداية الباردة”. بالنسبة لمعظم التطبيقات هذا التأخير غير ملحوظ، لكن في التطبيقات شديدة الحساسية لزمن الاستجابة (مثل أنظمة التداول المالي)، قد يكون هذا الأمر مشكلة. (ملاحظة: هناك تقنيات للتخفيف من هذه المشكلة مثل Provisioned Concurrency).
• التعقيد في المراقبة والتصحيح (Debugging Complexity): عندما يتحول تطبيقك من كتلة واحدة (Monolith) على خادم واحد إلى مجموعة من الدوال الصغيرة الموزعة، قد يصبح تتبع الأخطاء وتصحيحها أكثر تعقيدًا. ستحتاج إلى استخدام أدوات متخصصة (مثل AWS X-Ray أو Datadog) لتتبع الطلب أثناء مروره عبر الدوال المختلفة.
• التقييد بالمنصة (Vendor Lock-in): الكود الذي تكتبه لـ AWS Lambda قد يحتوي على تفاصيل خاصة بـ AWS. نقله إلى منصة أخرى مثل Google Cloud Functions قد يتطلب بعض التعديلات. استخدام أطر عمل مثل Serverless Framework يمكن أن يقلل من هذا التقييد إلى حد ما، لكنه يظل اعتبارًا قائمًا.

الخلاصة والنصيحة الأخيرة 💡

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

نصيحتي لك: ما تخاف تجرب.

ليس عليك أن تعيد بناء كل تطبيقاتك من الصفر. ابدأ بشيء صغير. هل لديك مهمة مجدولة (Cron Job) تعمل كل ليلة؟ هل لديك Webhook بسيط؟ حاول تحويل إحدى هذه المهام إلى دالة Serverless. شاهد بنفسك كيف تعمل، انظر إلى لوحة التحكم، وراقب التكاليف (أو انعدامها). أنا متأكد أنك ستعجب بالنتائج وستفتح لك آفاقًا جديدة.

يلا، شدوا حيلكم! 💪