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

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

اسمحولي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس قاسي عن الفواتير وكيف المصاري ممكن تطير بدون ما نحس. وقتها كنت شغال مع فريق صغير على مشروع ناشئ، وكنا متحمسين زي أي فريق ببداياته. بنينا تطبيقنا، ورفعناه على السحابة (Cloud)، وكل شي كان تمام التمام.

كان عنا جزء من النظام وظيفته بسيطة: كل ما مستخدم يرفع صورة شخصية، النظام لازم يعمل نسخة مصغّرة منها (thumbnail) ويحفظها. الحل “المنطقي” وقتها كان إنه نخصّص خادم صغير (EC2 instance على AWS) يضل شغال 24 ساعة، يستنى الصور الجديدة ويعالجها أول بأول. الخادم كان صغير وتكلفته الشهرية حوالي 15 دولار. مبلغ بسيط، صح؟ “مش هالمبلغ اللي بخرب الميزانية”، هيك كنا نفكر.

مرّت الشهور، والمشروع كبر شوي، وصار عنا أكتر من خدمة زي هيك، كل وحدة على خادم منفصل. وفي يوم من الأيام، وأنا براجع الفاتورة الشهرية لـ AWS، انصدمت. المبلغ كان أكبر من المتوقع بكتير! قعدت أحلل الفاتورة، سطر سطر، واكتشفت إنه مجموع تكلفة هاي الخوادم “الصغيرة” صار مبلغ محترم. ولما فكرت فيها بعمق، صابني إحباط… يا زلمة، هاي الخوادم شغالة 24 ساعة في اليوم، 7 أيام في الأسبوع، يعني حوالي 720 ساعة في الشهر. بس الشغل الفعلي اللي بتعمله؟ يمكن ما يجيش 10 دقائق باليوم! يعني إحنا بندفع ثمن 720 ساعة عشان نستفيد من أقل من 5 ساعات شهرياً! كانت الموارد خاملة 99% من الوقت، بس عدّاد الفلوس شغال وما برحم.

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

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

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

خليني أبسطها بمثال من حياتنا اليومية. تخيل أنك تريد أن تأكل بيتزا:

• الطريقة التقليدية (خادم خاص): أن تشتري مطعم بيتزا كامل! تدفع إيجار المحل، فواتير كهرباء ومياه، رواتب الطباخين والموظفين، وتكاليف الصيانة… كل هذا سواء بعت بيتزا واحدة في اليوم أو ألف بيتزا. المطعم ملكك، ومسؤوليتك الكاملة.

–

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

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

من الخادم “الكسول” إلى الدالة “النشيطة”: رحلتنا العملية

نرجع لقصتنا مع معالجة الصور. كيف حولنا الخادم “الكسول” اللي بيكلفنا 15 دولار شهريًا إلى دالة “نشيطة” تكلفتها تقترب من الصفر؟

المشكلة: خادم EC2 يعمل 24/7 لمهمة لا تتجاوز 5 دقائق يومياً

كان الوضع كالتالي:

1. مستخدم يرفع صورة إلى مخزن الملفات (AWS S3 Bucket).
2. الخادم (EC2) عليه برنامج صغير (script) يراقب هذا المخزن كل بضع ثوانٍ.
3. عند اكتشاف صورة جديدة، يقوم الخادم بسحبها، معالجتها لإنشاء نسخة مصغرة، ثم إعادة رفع النسخة المصغرة إلى مخزن آخر.
4. الخادم يظل يعمل وينتظر، يستهلك موارد (CPU, RAM) ويسجل تكاليف على مدار الساعة.

كانت هذه الطريقة تقتل الميزانية ببطء، خصوصًا مع نمو عدد الخدمات الصغيرة لدينا.

الحل: الانتقال إلى AWS Lambda (مثال عملي)

الحل كان في إعادة التفكير بالكامل في كيفية تنفيذ المهمة. بدلًا من وجود “كيان” دائم ينتظر العمل، قررنا أن نجعل “العمل” نفسه هو من يخلق “الكيان” المؤقت لتنفيذه. هنا يأتي دور AWS Lambda، وهي خدمة FaaS (Function as a Service) الأشهر.

الخطوات الجديدة أصبحت كالتالي:

1. مستخدم يرفع صورة إلى مخزن الملفات (AWS S3 Bucket). (لا تغيير هنا)
2. مخزن S3 نفسه، عند استقبال ملف جديد، يقوم تلقائيًا بإرسال “حدث” (Event) يستدعي دالة Lambda الخاصة بنا.
3. دالة Lambda تبدأ بالعمل، تستقبل معلومات عن الصورة التي تم رفعها من الحدث.
4. الدالة تقوم بسحب الصورة، معالجتها، ورفع النسخة المصغرة.
5. بمجرد انتهاء التنفيذ، تتوقف الدالة تمامًا، ويتوقف معها عداد التكلفة.

لاحظ الفرق: لا يوجد خادم يعمل في وضع الخمول. لا يوجد انتظار. العملية كلها تتم بناءً على حدث (Event-driven)، وهي فعالة بشكل لا يصدق.

مثال كود (Python) لدالة Lambda لمعالجة الصور:

هذا مثال مبسط جدًا يوضح الفكرة. ستحتاج إلى تثبيت مكتبة `Pillow` كـ Lambda Layer أو ضمن حزمة النشر.

import boto3
from PIL import Image
import io

s3_client = boto3.client('s3')

def lambda_handler(event, context):
    # 1. استخراج معلومات الملف من الحدث القادم من S3
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    object_key = event['Records'][0]['s3']['object']['key']
    
    print(f"New image detected: {object_key} in bucket {bucket_name}")
    
    # 2. تحميل الصورة من S3
    response = s3_client.get_object(Bucket=bucket_name, Key=object_key)
    image_content = response['Body'].read()
    
    # 3. معالجة الصورة باستخدام Pillow
    with Image.open(io.BytesIO(image_content)) as image:
        image.thumbnail((128, 128)) # إنشاء نسخة مصغرة بحجم 128x128
        
        # حفظ الصورة المصغرة في buffer
        buffer = io.BytesIO()
        image.save(buffer, format="JPEG")
        buffer.seek(0)
        
        # 4. رفع الصورة المصغرة إلى S3 bucket آخر أو نفس الـ bucket باسم مختلف
        thumbnail_key = f"thumbnails/thumb-{object_key.split('/')[-1]}"
        target_bucket = "your-thumbnails-bucket-name" # غيّر هذا الاسم
        
        s3_client.put_object(
            Bucket=target_bucket,
            Key=thumbnail_key,
            Body=buffer,
            ContentType='image/jpeg'
        )
        
    print(f"Thumbnail created successfully: {thumbnail_key}")
    
    return {
        'statusCode': 200,
        'body': 'Thumbnail created successfully!'
    }

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

متى تختار Serverless؟ ومتى تهرب منها؟ (نصائح من قلب الميدان)

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

أفضل حالات الاستخدام (وين بتزبط مية بالمية):

• المهام المعتمدة على الأحداث (Event-driven): مثل مثالنا السابق (معالجة الصور والفيديو عند رفعها)، أو معالجة بيانات تصل من أجهزة IoT، أو تشغيل أكواد عند حدوث تغيير في قاعدة البيانات.
• واجهات برمجة التطبيقات (APIs) والخدمات المصغرة (Microservices): خصوصًا للخدمات التي تعاني من تذبذب في حركة المرور (traffic). بدلاً من حجز خوادم كبيرة للتعامل مع الذروة، الـ Serverless تتوسع (scale) تلقائيًا لتلبية الطلب وتعود لتنكمش، فتدفع فقط مقابل الاستخدام الفعلي.
• المهام المجدولة (Cron Jobs): بدلاً من وجود خادم كامل فقط لتشغيل تقرير يومي أو تنظيف قاعدة البيانات مرة في الأسبوع، يمكنك استخدام دالة Serverless يتم تشغيلها بواسطة خدمة جدولة (مثل Amazon EventBridge).
• الواجهات الخلفية لتطبيقات الويب والجوّال: لعمليات المصادقة، وحفظ بيانات المستخدمين، وغيرها.

متى تفكر مرتين (وين لازم تدير بالك):

• العمليات طويلة الأمد: دوال الـ Serverless لها حد أقصى لوقت التنفيذ (عادة 15 دقيقة في AWS Lambda). إذا كانت لديك مهمة تحتاج لساعات لتكتمل (مثل تدريب نموذج تعلم آلة معقد)، فهذا النموذج غير مناسب.
• التطبيقات التي تتطلب حالة مستمرة (Stateful Applications): الـ Serverless بطبيعتها “عديمة الحالة” (Stateless). كل استدعاء للدالة هو كيان منفصل لا يتذكر الاستدعاءات السابقة. إذا كان تطبيقك يعتمد بشدة على الحفاظ على حالة في الذاكرة بين الطلبات، فستحتاج إلى حلول بديلة (مثل استخدام قواعد بيانات أو ذاكرة تخزين مؤقت خارجية)، مما قد يزيد من التعقيد.
• مشكلة “البداية الباردة” (Cold Start): عندما لا يتم استدعاء دالتك لفترة، يقوم مزود الخدمة بإيقافها تمامًا لتوفير الموارد. عند أول طلب جديد، تحتاج الدالة إلى بضع ثوانٍ (أو أجزاء من الثانية) لتبدأ من جديد. هذا التأخير، المسمى بـ Cold Start، قد يكون غير مقبول في التطبيقات شديدة الحساسية لزمن الاستجابة. (هناك طرق للتخفيف من هذه المشكلة، لكنها اعتبار مهم).
• التقييد بمزود خدمة معين (Vendor Lock-in): عندما تبني نظامك بالكامل حول خدمات Serverless لمزود معين (مثل AWS Lambda و S3 و DynamoDB)، يصبح من الصعب جدًا الانتقال إلى مزود آخر في المستقبل.

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

إذا تحمست للفكرة وتريد أن تبدأ، اسمح لي أن أقدم لك بعض النصائح العملية من تجربتي:

1. ابدأ صغيرًا: لا تحاول تحويل تطبيقك الضخم (Monolith) بالكامل دفعة واحدة. اختر مهمة صغيرة، غير حرجة، ومناسبة للـ Serverless (مثل مثال معالجة الصور) وجربها.
2. افهم التسعير جيدًا: تعلم كيف يحسب مزود الخدمة التكلفة. عادة ما تعتمد على عدد الطلبات، ومدة التنفيذ، وكمية الذاكرة المخصصة للدالة. الفهم الجيد يمنع المفاجآت.
3. تبنى البنية التحتية ككود (Infrastructure as Code – IaC): لا تقم بإعداد الدوال والموارد يدويًا عبر واجهة المستخدم الرسومية. استخدم أدوات مثل Serverless Framework أو AWS SAM أو Terraform. هذا يتيح لك تعريف كل بنيتك التحتية في ملفات نصية، مما يجعل النشر والتحديث والتكرار أمرًا سهلًا وموثوقًا. مش شغل كبسات بالماوس يا جماعة!
4. لا تهمل المراقبة والتسجيل (Monitoring & Logging): بما أنك لا تدير الخادم، فإن الطريقة الوحيدة لمعرفة ما يحدث هي من خلال السجلات (Logs) والمقاييس (Metrics). تعلم استخدام أدوات مثل Amazon CloudWatch جيدًا لتصحيح الأخطاء ومراقبة الأداء.

–

5. فكّر بطريقة “غير متزامنة” (Asynchronously): استغل قوة الخدمات مثل طوابير الرسائل (Amazon SQS) وحافلات الأحداث (Amazon EventBridge) لفصل مكونات نظامك عن بعضها. هذا يجعل نظامك أكثر مرونة وقابلية للتوسع.

الخلاصة: هل الحوسبة بدون خوادم هي المستقبل؟

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

الهدف ليس التخلص من الخوادم، بل التخلص من عبء إدارة الخوادم. الهدف هو الدفع مقابل القيمة الحقيقية، وليس مقابل الوقت الضائع.

يلا يا جماعة، ما تخلوا الفواتير تاكلكم وتوقف أحلامكم. جربوا هذا النهج في مشروعكم القادم، ولو على نطاق صغير، وصدقوني… قد تتفاجأون بالنتائج. ويعطيكم ألف عافية! 💪