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

يا صباح الخير يا جماعة، بتذكر هذاك اليوم زي كأنه مبارح. صحيت الصبح، عملت فنجان القهوة اللي على أصوله، وقعدت على مكتبي متحمس أبدأ يوم جديد من البرمجة. كعادتي، أول شي بعمله هو تفقد الإيميلات. وبينما كنت أتصفح، لمحت إيميل من مزود الخدمة السحابية تبعي… العنوان كان “Your monthly bill is ready”.

فتحت الإيميل ببرود أعصاب، متوقع أشوف الرقم المعتاد اللي تعودت عليه. لكن الصدمة كانت لما شفت رقم أكبر بعشر أضعاف! للحظة فكرت حسابي تهكر. عرقت وشعرت إن القهوة فقدت طعمها. شو القصة؟ بعد تدقيق وتحليل استمر لساعات، اكتشفت الحقيقة المُرّة: أنا كنت بدفع مقابل “الهواء”.

كان عندي خادم افتراضي (Virtual Machine) شغال 24 ساعة في اليوم، 7 أيام في الأسبوع، لينفذ مهمة بسيطة ما بتاخذ أكثر من 5 دقائق يومياً. الخادم كان “فاضي” 99% من الوقت، لكن الفاتورة كانت ماشية. هنا كانت بداية رحلتي مع عالم الـ Serverless اللي أنقذ مشروعي، وجيبتي كمان.

ما هي المشكلة الحقيقية في الخوادم التقليدية؟

قبل ما نغوص في الحل، خلينا نفهم أصل المشكلة. في عالم الحوسبة السحابية التقليدي (مثل استخدام سيرفرات EC2 في AWS أو VMs في Azure)، أنت تقوم بحجز “موارد” مسبقاً.

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

هذه الطريقة، التي تسمى “Provisioned Infrastructure”، لها مشاكلها:

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

الحل السحري: الحوسبة بلا خوادم (Serverless)

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

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

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

رحلتي العملية: من خادم EC2 إلى دالة AWS Lambda

خليني أفرجيكم كيف حولت المهمة اللي كانت تكلفني الكثير من المال إلى دالة Serverless تكلفتها شبه صفرية.

المهمة كانت بسيطة: كلما قام مستخدم برفع صورة على خدمتنا، يقوم الخادم بإنشاء نسخة مصغرة (Thumbnail) من هذه الصورة. سابقاً، كان عندي سيرفر EC2 صغير عليه سكربت Python يعمل باستمرار ويتفقد وجود صور جديدة.

الخطوة الأولى: فهم الكود وتفكيكه

الكود الأساسي كان موجوداً بالفعل. كل ما احتجت إليه هو إعادة هيكلته ليعمل كـ “دالة” تستقبل “حدثاً” (Event). في هذه الحالة، الحدث هو “تم رفع صورة جديدة إلى مخزن S3”.

الخطوة الثانية: كتابة دالة Lambda

باستخدام Python، قمت بكتابة دالة بسيطة. AWS Lambda توفر للدالة “handler” يستقبل متغيرين: event و context.

• event: يحتوي على كل المعلومات المتعلقة بالحدث الذي أدى لتشغيل الدالة (مثل اسم الملف الذي تم رفعه واسم الـ bucket).
• context: يحتوي على معلومات عن بيئة التنفيذ.

هذا مثال مبسط جداً للكود بلغة Python باستخدام مكتبة boto3 و Pillow:

import boto3
from PIL import Image
import io

s3_client = boto3.client('s3')

def resize_image_handler(event, context):
    # 1. استخراج معلومات الملف من الحدث (Event)
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # تجنب الدخول في حلقة لا نهائية إذا كانت الدالة تحفظ الصورة في نفس الـ bucket
    if "thumbnail" in key:
        print("This is already a thumbnail. Exiting.")
        return

    # 2. تحميل الصورة من S3
    response = s3_client.get_object(Bucket=bucket_name, Key=key)
    image_content = response['Body'].read()
    
    # 3. تغيير حجم الصورة باستخدام مكتبة Pillow
    image = Image.open(io.BytesIO(image_content))
    image.thumbnail((128, 128)) # تصغير الصورة إلى 128x128 بكسل
    
    buffer = io.BytesIO()
    image.save(buffer, format="JPEG")
    buffer.seek(0)
    
    # 4. رفع الصورة المصغرة إلى S3
    thumbnail_key = f"thumbnails/{key.split('/')[-1]}"
    s3_client.put_object(
        Bucket=bucket_name,
        Key=thumbnail_key,
        Body=buffer,
        ContentType='image/jpeg'
    )
    
    print(f"Successfully created thumbnail: {thumbnail_key}")
    return {'status': 'success'}

الخطوة الثالثة: الربط مع الخدمات الأخرى (The Trigger)

بعد رفع الكود إلى AWS Lambda، كل ما تبقى هو إخبار Lambda “متى” يجب أن تعمل. في واجهة AWS، قمت ببساطة بإضافة “Trigger” (محفز) من نوع S3. وحددت اسم الـ bucket، وأخبرته أن يقوم بتشغيل دالتي كلما تم إنشاء كائن جديد (s3:ObjectCreated:*).

وهيك، صارت المنظومة تعمل بشكل آلي تماماً. لا يوجد خادم يعمل باستمرار. لا يوجد سكربت يحتاج للمراقبة. فقط كود نائم ينتظر بهدوء ليتم استدعاؤه.

النتائج المذهلة: الفاتورة تتحدث عن نفسها

بعد شهر من تطبيق هذا التغيير البسيط، جاء وقت الحقيقة: فاتورة السحابة الشهرية. فتحت الإيميل هذه المرة وقلبي يدق، لكن لسبب مختلف. الرقم كان… أقل من دولار واحد!

من حوالي 50$ شهرياً (تكلفة أصغر خادم EC2) إلى أقل من 1$ شهرياً.

لماذا هذا الانخفاض الهائل؟ لأن AWS Lambda لديها باقة مجانية (Free Tier) سخية جداً تمنحك مليون طلب و 400,000 جيجابايت-ثانية من وقت الحوسبة مجاناً كل شهر. لمعظم المشاريع الصغيرة والمتوسطة، هذا يعني أن تكلفتك ستكون صفراً أو قريبة جداً من الصفر.

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

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

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

1. ابدأ صغيراً (Start Small): لا تحاول تحويل تطبيقك الضخم كله إلى Serverless دفعة واحدة. اختر مهمة صغيرة ومعزولة، مثل معالجة الصور، إرسال إيميلات، أو وظيفة مجدولة (Cron Job)، وقم بتحويلها أولاً.
2. فكّر بالأحداث (Think in Events): التحول إلى Serverless هو أيضاً تحول في طريقة التفكير. بدلاً من التفكير في “عمليات مستمرة”، ابدأ بالتفكير في “أحداث” (Events) و “ردود أفعال” (Functions). ما هو الحدث الذي سيشغل الكود الخاص بي؟
3. راقب ثم راقب (Monitor, then Monitor): استخدم أدوات مثل Amazon CloudWatch لمراقبة أداء الدوال وتكلفتها. هذا سيساعدك على فهم سلوك تطبيقك وتحسينه باستمرار.
4. لا تخف من التجربة: جمال الـ Serverless هو أن تكلفة التجربة شبه معدومة. أنشئ دالة، جربها، وإذا لم تعمل كما تريد، احذفها. لن يكلفك الأمر شيئاً.

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

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

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

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

جربوها يا جماعة، حللوا تطبيقاتكم، وابحثوا عن تلك الأجزاء التي “تدفعون فيها مقابل الهواء”. قد تتفاجأون بحجم التوفير الذي يمكنكم تحقيقه. 🙏