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

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

بتذكر قبل كم سنة، كنا شغالين على مشروع لعميل، وكان فيه جزء من النظام مسؤول عن إنشاء تقارير يومية. الشغلانة كلها ما بتاخد أكتر من 15 دقيقة كل ليلة. عشان نشغّلها، حجزنا خادم (Server) صغير على وحدة من المنصات السحابية المعروفة. وكل آخر شهر، تيجي الفاتورة.. والخادم المسكين، اللي شغال 24 ساعة باليوم، 7 أيام في الأسبوع، فعلياً كان يشتغل ربع ساعة ويقضي باقي الـ 23 ساعة و 45 دقيقة “صافن في السقف”، بس طبعاً العدّاد شغال والفلوس بتنخصم.

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

خلوني آخذكم في هالرحلة، وأفرجيكم كيف ممكن هالتقنية تغير طريقة تفكيركم وعملكم تماماً.

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

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

خليني أبسّطها بمثال من حياتنا اليومية:

تخيل إنك بدك تشرب فنجان قهوة. عندك خيارين:

1. الطريقة التقليدية (مثل الخوادم التقليدية): تشتري ماكينة قهوة، وتشتري حبوب البن، وتطحنها، وتعاير المي، وتشغّل الماكينة، وبعدين تنظفها. أنت مسؤول عن كل خطوة، من الصيانة للشراء للتشغيل.

2. طريقة الـ Serverless: تروح على أقرب مقهى، تطلب فنجان قهوة، تدفع حقه، وتشربه. أنت ما بتعرف شو نوع الماكينة، ومين اللي عملها، وكيف بتشتغل. كل اللي بيهمك هو النتيجة النهائية: فنجان القهوة. أنت تدفع فقط مقابل الخدمة اللي حصلت عليها في هذيك اللحظة.

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

من “الخادم النائم” إلى “الدفع عند الاستدعاء”: رحلتنا مع التكاليف

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

المشكلة: نموذج التكلفة التقليدي (الخادم المخصص)

لنفترض أننا كنا نستخدم خادمًا افتراضيًا (VM) من نوع t3.small على AWS. تكلفة هذا الخادم تقارب 15 دولارًا شهريًا (حسب المنطقة والأسعار الحالية). هذا المبلغ يُدفع سواء كان الخادم يعمل بنسبة 100% من طاقته أو 0.1%.

• وقت التشغيل: 730 ساعة في الشهر.
• وقت العمل الفعلي: حوالي 7.5 ساعات في الشهر (15 دقيقة × 30 يوم).
• وقت الخمول (Idle Time): أكثر من 722 ساعة في الشهر!
• التكلفة: ثابتة، حوالي 15 دولارًا شهريًا، مقابل استخدام فعلي لا يتجاوز 1% من قدرة الخادم.

هذا هو الهدر بعينه. كنا ندفع ثمن الكهرباء والإيجار لمكتب نستخدمه دقائق معدودة كل يوم.

الحل: نموذج “الدفع حسب الاستخدام” في Serverless

عندما نقلنا هذه المهمة إلى AWS Lambda (وهي خدمة الحوسبة اللاخادمية من أمازون)، تغيرت المعادلة تمامًا. في Lambda، يتم حساب التكلفة بناءً على شيئين رئيسيين:

1. عدد الطلبات (Requests): تدفع مبلغًا ضئيلًا جدًا عن كل مرة يتم فيها استدعاء الدالة.
2. مدة التنفيذ (Duration): تدفع مقابل كل مللي ثانية يستغرقها الكود للتنفيذ، مضروبًا في حجم الذاكرة التي حجزتها للدالة.

لنفترض أن دالة التقرير تحتاج 10 دقائق (600,000 مللي ثانية) وذاكرة 512 ميجابايت. لنحسب التكلفة الشهرية التقريبية:

• عدد الطلبات: 30 طلبًا في الشهر.
• مدة التنفيذ الإجمالية: 30 طلب × 600 ثانية = 18,000 ثانية.

باستخدام حاسبة أسعار AWS Lambda، ستجد أن التكلفة الشهرية لمثل هذا الاستخدام ستكون… أقل من دولار واحد! في كثير من الأحيان، ستكون ضمن الطبقة المجانية (Free Tier) التي توفرها AWS، مما يعني أن التكلفة ستكون صفرًا. نعم، صفر.

انتقلنا من 15 دولارًا شهريًا إلى لا شيء تقريبًا. هذا هو سحر نموذج الدفع عند الاستدعاء.

كيف بدأنا رحلتنا العملية مع Serverless؟ (مثال مع AWS Lambda)

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

السيناريو: تصغير الصور تلقائيًا عند رفعها

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

الفكرة: سنستخدم خدمة التخزين AWS S3 مع AWS Lambda. عندما يرفع المستخدم صورة إلى “مجلّد” (Bucket) معين في S3، سيقوم S3 تلقائيًا باستدعاء دالة Lambda الخاصة بنا، ويمرر لها معلومات عن الصورة الجديدة. تقوم الدالة بقراءة الصورة، تصغيرها، وحفظ النسخ الجديدة في “مجلّد” آخر.

خطوات بسيطة للبدء (مع مثال كود Python)

لنفترض أن لدينا 2 Buckets على S3:

• my-app-uploads: لاستقبال الصور الأصلية من المستخدمين.
• my-app-processed-images: لحفظ الصور المعالجة (المصغرة).

1. كتابة كود الدالة (Function Code)

سنستخدم لغة Python مع مكتبة معالجة الصور الشهيرة Pillow ومكتبة AWS SDK المسماة boto3. هذا الكود سيقوم بالآتي:

1. يستقبل معلومات الحدث (Event) من S3.
2. يستخرج اسم الـ Bucket واسم ملف الصورة.
3. يقوم بتحميل الصورة من S3 إلى ذاكرة الدالة.
4. يستخدم Pillow لتصغير حجم الصورة.
5. يقوم برفع الصورة المصغرة إلى الـ Bucket الثاني.

import boto3
from PIL import Image
import io # للتعامل مع الملفات في الذاكرة
import os

# تهيئة عملاء AWS
s3_client = boto3.client('s3')
DESTINATION_BUCKET = os.environ['DEST_BUCKET'] # قراءة اسم الـ bucket الهدف من متغيرات البيئة

def lambda_handler(event, context):
    """
    الدالة الرئيسية التي تستدعيها AWS Lambda.
    """
    # 1. استخراج معلومات الملف من الحدث القادم من S3
    record = event['Records'][0]
    source_bucket = record['s3']['bucket']['name']
    source_key = record['s3']['object']['key'] # هذا هو مسار واسم الملف

    print(f"تم رفع ملف جديد: {source_key} في الـ bucket: {source_bucket}")

    try:
        # 2. تحميل الصورة من الـ Bucket المصدر
        response = s3_client.get_object(Bucket=source_bucket, Key=source_key)
        image_data = response['Body'].read()
        
        # 3. استخدام Pillow لمعالجة الصورة
        with Image.open(io.BytesIO(image_data)) as img:
            # لنقم بإنشاء نسخة مصغرة بحجم 200x200
            img.thumbnail((200, 200))
            
            # 4. حفظ الصورة المصغرة في الذاكرة
            buffer = io.BytesIO()
            img.save(buffer, format="JPEG")
            buffer.seek(0)
            
            # 5. رفع الصورة المصغرة إلى الـ Bucket الهدف
            new_key = f"thumbnails/{source_key}"
            s3_client.put_object(
                Bucket=DESTINATION_BUCKET,
                Key=new_key,
                Body=buffer,
                ContentType='image/jpeg'
            )
            
            print(f"تم إنشاء نسخة مصغرة وحفظها في: {new_key}")
            
            return {
                'statusCode': 200,
                'body': f"Image {source_key} processed successfully."
            }

    except Exception as e:
        print(f"حدث خطأ: {str(e)}")
        # يجب معالجة الأخطاء بشكل أفضل في تطبيق حقيقي
        raise e

نصيحة من أبو عمر: لاحظ أنني قرأت اسم الـ Bucket الهدف من متغيرات البيئة (Environment Variables). هذه أفضل ممارسة لجعل الكود قابلاً لإعادة الاستخدام والفصل بين الكود والإعدادات.

2. إعداد المُحفّز (Trigger) والصلاحيات (Permissions)

بعد رفع هذا الكود إلى AWS Lambda، كل ما عليك فعله هو:

• إضافة Trigger: في إعدادات دالة Lambda، أضف Trigger من نوع S3. اختر الـ Bucket المصدر (my-app-uploads) وحدد نوع الحدث ليكون s3:ObjectCreated:*.
• منح الصلاحيات: تحتاج دالة Lambda إلى صلاحيات للوصول إلى S3. تقوم AWS بإنشاء دور (IAM Role) تلقائيًا للدالة. يجب أن تعدّل هذا الدور لإعطائه صلاحية القراءة (s3:GetObject) من الـ Bucket المصدر، وصلاحية الكتابة (s3:PutObject) في الـ Bucket الهدف.

وهيك بكون كل شي جاهز. الآن، كلما تم رفع صورة جديدة إلى my-app-uploads، ستعمل هذه المنظومة تلقائيًا بكفاءة وتكلفة شبه معدومة.

ليست مجرد توفير للمال: فوائد أخرى غيّرت طريقة عملنا

صحيح أن توفير التكاليف كان الدافع الأول، لكن مع الوقت اكتشفنا أن فوائد الـ Serverless أعمق بكثير.

التركيز على الكود، لا على البنية التحتية

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

التوسع التلقائي الفوري (Automatic Scaling)

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

سرعة التطوير والنشر (Faster Time-to-Market)

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

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

لكي أكون منصفًا، الـ Serverless ليست الحل السحري لكل المشاكل. هناك سيناريوهات قد لا تكون فيها الخيار الأفضل. من خبرتي، هذه أبرز التحديات:

• مشكلة البداية الباردة (Cold Starts): إذا لم يتم استدعاء دالتك لفترة (مثلاً 15 دقيقة)، فإن المنصة السحابية “تجمّدها” لتوفير الموارد. عند استدعائها مرة أخرى، تحتاج إلى بضع مئات من الميلي ثانية إلى ثانية أو ثانيتين “لتستيقظ”. هذا التأخير قد يكون غير مقبول في التطبيقات الحساسة للزمن (مثل واجهات برمجة التطبيقات APIs التي تتطلب استجابة فورية). (ملاحظة: هناك حلول لهذه المشكلة مثل Provisioned Concurrency في AWS).
• العمليات طويلة الأمد (Long-Running Processes): دوال الـ Serverless لها حد أقصى لزمن التنفيذ (مثلاً، 15 دقيقة في AWS Lambda). إذا كانت لديك مهمة تحتاج ساعات لتنفيذها (مثل تدريب نماذج الذكاء الاصطناعي الكبيرة)، فإن الـ Serverless ليست مناسبة. في هذه الحالة، خادم مخصص أو خدمات مثل AWS Fargate تكون خيارًا أفضل.
• تعقيد المراقبة وتصحيح الأخطاء: عندما يكون لديك عشرات أو مئات الدوال الصغيرة التي تتحدث مع بعضها، فإن تتبع طلب معين عبر هذه الدوال وتصحيح الأخطاء يمكن أن يكون أكثر تعقيدًا من تطبيق متكامل (Monolith). ستحتاج إلى استخدام أدوات متخصصة مثل AWS X-Ray أو Datadog.

خلاصة تجربتي ونصيحتي لك 💡

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

إنها تمثل القوة والكفاءة: لا تدفع إلا مقابل ما تستخدمه، وتحصل على توسع لا نهائي عند الحاجة، كل ذلك دون الحاجة لمدير أنظمة متخصص.

نصيحتي العملية لك: لا تخف من التجربة. ابدأ بخطوة صغيرة. انظر إلى مشروعك الحالي، وابحث عن مهمة صغيرة وغير حرجة تعمل بشكل متقطع. يمكن أن تكون:

• مهمة تنظيف دورية لقاعدة البيانات.
• إرسال بريد إلكتروني ترحيبي عند تسجيل مستخدم جديد.
• معالجة ملف CSV يتم رفعه من وقت لآخر.

حوّل هذه المهمة الصغيرة إلى دالة Serverless. راقب التكلفة، ولاحظ السهولة في الإدارة. أضمن لك أن هذه التجربة الصغيرة ستفتح شهيتك لاستكشاف هذا العالم المدهش أكثر.

يلا يا جماعة، الكود بانتظاركم، والخوادم خلّوها على أهلها. بالتوفيق! 😉