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

حكاية “السيرفر الشبح”: لما كانت فواتيرنا تحرق جيوبنا على الفاضي

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

كل شهر، كانت تجينا فاتورة الخدمات السحابية زي الصاعقة. عشان نتحمل الضغط العالي في ساعات الذروة، كنا حاجزين خوادم (Servers) بمواصفات “محترمة”. المشكلة وين؟ الضغط العالي هاد كان يستمر 3-4 ساعات باليوم بس. باقي الـ 20 ساعة، كانت الخوادم قاعدة “بتشم الهوا”، ما بتعمل إشي تقريبًا، بس عدّاد الفلوس شغال. كنت أفتح لوحة المراقبة وأشوف استهلاك المعالج (CPU) خط شبه مستقيم عند 5% معظم اليوم، وفجأة بقفز لـ 90% لساعتين ثلاث وبرجع بنام. والله يا جماعة شعور بقهر، زي اللي مستأجر قاعة أفراح ضخمة طول الشهر عشان يعمل فيها حفلة عيد ميلاد صغيرة يوم واحد.

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

إيش هي “الحوسبة الخادومية” (Serverless)؟ وهل عنجد فش سيرفرات؟

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

خليني أبسطها: تخيل إنك بدك كهربا في بيتك. عندك خيارين:

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

الـ Serverless هي الخيار الثاني. أنت كمبرمج، كل همك هو كتابة الكود اللي بحل مشكلة معينة (وظيفة – Function). بترفع هاد الكود على منصة سحابية زي AWS Lambda أو Azure Functions، والمنصة هاي بتتولى كل شي ثاني: بتشغل الكود تبعك لما حدا يطلبه، وبتعمله توسيع (scaling) لو صار عليه ضغط، ولما يخلص الطلب، بتطفيه. والأهم؟ أنت بتدفع فقط على عدد المللي ثواني اللي اشتغل فيها الكود تبعك. ولا قرش زيادة على وقت الفراغ.

من “الحيوانات الأليفة” إلى “قطيع الماشية”… ثم إلى “الوظائف العابرة”

في عالم الحوسبة السحابية، في تشبيه مشهور بوضح تطور إدارة البنية التحتية:

• الخوادم كالحيوانات الأليفة (Pets): زمان، كان كل سيرفر له اسم (زي “zeus” أو “apollo”). لو مرض (صار فيه مشكلة)، بنجيبله “طبيب” (مهندس أنظمة) يعالجه ويرجعه يشتغل. بنحبه وبندللـه.
• الخوادم كقطيع الماشية (Cattle): مع الحوسبة السحابية، صرنا نتعامل مع الخوادم كأرقام. لو سيرفر خرب، ما بنصلحه. ببساطة “بنتخلص منه” وبنجيب واحد جديد مكانه بشكل آلي. ما في علاقة عاطفية معهم.
• الحوسبة الخادومية كالوظائف العابرة (Ephemeral Functions): هنا، إحنا ما منشوف السيرفر أصلاً. كل اللي بيهمنا هو “الوظيفة” (Function) اللي بتظهر للوجود، بتنفذ مهمة سريعة، وبتختفي. زي الشرارة، بتضوي للحظة وبتطفي.

كيف بتشتغل هاي القصة؟ نظرة على “الوظائف كخدمة” (FaaS)

القلب النابض للـ Serverless هو نموذج اسمه Function as a Service (FaaS) أو “الوظيفة كخدمة”. الفكرة قائمة على مبدأ “ردة الفعل” أو ما يسمى بالـ Event-Driven Architecture.

بدل ما يكون عندك سيرفر شغال 24/7 بستنى طلبات، نظام الـ FaaS بكون نايم. لما يصير “حدث” (Event) معين، بيصحى وبينفذ الكود تبعك. شو ممكن تكون هاي الأحداث؟

• طلب HTTP جديد على API Gateway (مثلاً، مستخدم طلب بيانات من تطبيقك).
• رفع ملف جديد على خدمة تخزين مثل Amazon S3 (زي مثالنا تبع معالجة الصور).
• رسالة جديدة وصلت على طابور رسائل (Message Queue) مثل SQS.
• تغيير حصل في قاعدة بيانات (مثلاً، إضافة مستخدم جديد في جدول).
• جدول زمني محدد (Cron Job)، مثلاً “شغّل هذا الكود كل يوم الساعة 3 الفجر”.

بمجرد وقوع الحدث، المنصة السحابية بتعمل التالي بشكل آلي:

1. بتلاقي سيرفر فاضي أو بتجهز واحد جديد بسرعة.
2. بتحمل الكود تبعك عليه.
3. بتنفذ الكود وبتمررله معلومات الحدث اللي صار.
4. بترجع النتيجة.
5. بتطفي كل شي وبترجع تستنى الحدث اللي بعده.

نصيحة من أبو عمر: أهم خاصية لازم تفهمها في دوال الـ Serverless هي أنها عديمة الحالة (Stateless). يعني كل مرة بتشتغل فيها، ما بتتذكر أي شي من المرة اللي قبلها. لو بدك تحفظ معلومات، لازم تستخدم خدمة خارجية مثل قاعدة بيانات (DynamoDB, Firestore) أو خدمة تخزين مؤقت (Redis).

مثال عملي: بناء وظيفة Lambda لمعالجة الصور

خلينا نرجع لمشكلة شركتنا الأولى ونشوف كيف الـ Serverless (باستخدام AWS Lambda كمثال) حلتها بشكل أنيق وفعال من ناحية التكلفة.

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

الخطوة الأولى: كتابة الكود (Python كمثال)

رح نستخدم لغة بايثون ومكتبة معالجة الصور الشهيرة Pillow. الكود بسيط ومباشر.

الخطوة الثانية: الإعدادات والتشغيل على AWS Lambda

هاي الخطوات بشكل مختصر جداً (التفاصيل بتحتاج مقالة لحالها):

1. بتكتب الكود اللي تحت وبتحفظه بملف (مثلاً `lambda_function.py`).
2. بتجهز حزمة (deployment package) فيها الكود والمكتبات اللي بيعتمد عليها (زي Pillow).
3. بتروح على AWS Lambda Console، بتعمل وظيفة جديدة، وبتختار Python.
4. بترفع الحزمة تبعتك.
5. أهم خطوة: بتحدد “المُحفِّز” (Trigger). في حالتنا، رح نختار S3 ونحدد اسم الـ Bucket ونوع الحدث (مثلاً `s3:ObjectCreated:*`).
6. بتعطي للوظيفة الصلاحيات اللازمة عشان تقدر تقرأ وتكتب على الـ S3 Bucket.

وهيك، صار النظام جاهز. ما في سيرفرات لإدارتها، ما في تحديثات نظام تشغيل، ولا أي شي من وجع الراس هاد.

الكود يا جماعة

هذا مثال لكود بايثون ممكن يشتغل على AWS Lambda ليقوم بالمهمة المذكورة:

import boto3
from PIL import Image
import io
import os

# Initialize S3 client
s3 = boto3.client('s3')

def lambda_handler(event, context):
    # 1. Get the bucket and key (file path) from the trigger event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # 2. Define the output path to avoid infinite loops
    # We will save thumbnails in a 'thumbnails' folder
    # and we check if the file is already a thumbnail
    if key.startswith('thumbnails/'):
        print("This is already a thumbnail. Exiting.")
        return

    try:
        # 3. Download the image from S3 into memory
        response = s3.get_object(Bucket=bucket, Key=key)
        image_content = response['Body'].read()

        # 4. Use Pillow to resize the image
        image = Image.open(io.BytesIO(image_content))
        thumbnail_size = (200, 200) # Define thumbnail size
        image.thumbnail(thumbnail_size)

        # 5. Save the resized image to a buffer in memory
        buffer = io.BytesIO()
        image.save(buffer, format="JPEG")
        buffer.seek(0) # Rewind the buffer to the beginning

        # 6. Upload the thumbnail back to S3 in the 'thumbnails' folder
        thumbnail_key = f"thumbnails/thumb-{os.path.basename(key)}"
        s3.put_object(
            Bucket=bucket,
            Key=thumbnail_key,
            Body=buffer,
            ContentType='image/jpeg'
        )

        print(f"Successfully created thumbnail: {thumbnail_key}")
        return {
            'statusCode': 200,
            'body': f"Thumbnail created at {thumbnail_key}"
        }

    except Exception as e:
        print(f"Error processing image {key} from bucket {bucket}.")
        print(e)
        raise e

طيب يا أبو عمر، شو الفايدة من كل هالوجع الراس؟

بعد ما طبقنا الحل هاد، الفاتورة الشهرية المتعلقة بهي الميزة انخفضت بنسبة 90%! نعم، تسعين بالمية. ليش؟ لأنه صرنا ندفع بس على الثواني اللي بتشتغل فيها وظيفة معالجة الصور، مش على 24 ساعة من الفراغ. الفوائد ما بتوقف عند الفلوس:

• توفير هائل في التكاليف (Cost-Effective): هاي الفائدة الأوضح. لا تكاليف للخوادم وهي فارغة. تدفع مقابل القيمة الحقيقية فقط.
• توسع تلقائي فوري (Automatic Scaling): لو رفعوا مليون مستخدم صور بنفس الدقيقة، المنصة السحابية رح تشغل مليون نسخة من وظيفتك بالتوازي (طبعًا في حدود معينة). ما بتحتاج تفكر بالـ Auto Scaling Groups ولا بالـ Load Balancers.
• تقليل العبء التشغيلي (Reduced Operational Overhead): انسى تحديثات الأمان، والـ patching، ومراقبة صحة السيرفرات. فريقك بقدر يركز على كتابة الكود اللي بضيف قيمة للمستخدمين. زي ما بنحكيها “ركّز على الكود واترك الباقي عليهم”.
• سرعة في التطوير والنشر (Faster Time-to-Market): بتقدر تطور وتنشر وظائف صغيرة ومستقلة بسرعة كبيرة، بدون ما تحتاج تعمل deploy لتطبيق كامل.

مش كل شي وردي: متى لازم تفكر مرتين قبل ما تستخدم Serverless؟

زي أي تقنية، الـ Serverless مش حل سحري لكل المشاكل. في حالات لازم تكون حذر فيها:

• البداية الباردة (Cold Starts): أول مرة بتشتغل فيها الوظيفة بعد فترة من السكون، بتحتاج وقت أطول بشوي (من مئات المللي ثانية إلى ثواني قليلة) لأنه المنصة بتحتاج تجهز البيئة الها. هاي مشكلة للتطبيقات اللي بتحتاج استجابة فورية دائمًا. (في حلول لهالمشكلة مثل Provisioned Concurrency بس بتكلف زيادة).
• التقييد بالمنصة (Vendor Lock-in): لما تبني نظامك بعمق على خدمات شركة معينة (مثل AWS Lambda مع S3 و DynamoDB)، بصير صعب تنقله على شركة ثانية. لازم تكون واعي لهاد الاشي.
• صعوبة المراقبة والتصحيح (Monitoring & Debugging): لما يكون عندك مئات الوظائف الصغيرة اللي بتتكلم مع بعض، تتبع مشكلة معينة ممكن يكون أصعب من تتبعها في تطبيق متكامل (Monolith). بتحتاج تستخدم أدوات متخصصة مثل AWS X-Ray.
• قيود الموارد (Resource Limits): في قيود على مدة تشغيل الوظيفة (مثلاً 15 دقيقة في AWS Lambda) وعلى حجم الذاكرة. بالتالي هي غير مناسبة للمهام الطويلة جدًا أو اللي بتحتاج معالج قوي لفترة طويلة.

نصايح من أبو عمر (من الكيس مباشرةً)

بعد شغل طويل مع الـ Serverless، هاي كم نصيحة عملية بحب أشاركها معكم:

اختر المعركة الصح

الـ Serverless مثالية لـ: واجهات برمجة التطبيقات (APIs)، مهام معالجة البيانات غير المتزامنة (زي مثالنا)، روبوتات المحادثة (Chatbots)، الأنظمة الخلفية لإنترنت الأشياء (IoT)، والعمليات الآلية. لكنها قد لا تكون الخيار الأفضل لقواعد البيانات العلاقية التقليدية أو للتطبيقات اللي بتحتاج حالة مستمرة (Stateful) ومعقدة.

فكّر بـ “الوظائف” مش بـ “التطبيقات”

غيّر طريقة تفكيرك. بدل ما تفكر بتطبيق ضخم، فككه لوظائف صغيرة جدًا، كل وظيفة مسؤولة عن شي واحد فقط وبتعمله بشكل ممتاز. هاد المبدأ (Single Responsibility Principle) بكون في أبهى صوره مع الـ FaaS.

احذر من “الجحيم” الجديد: جحيم الفواتير غير المتوقعة

صحيح إنها بتوفر، بس خطأ بسيط ممكن يكلفك كثير. تخيل لو وظيفة بتستدعي حالها بالخطأ في حلقة لا نهائية (Infinite Loop). ممكن تتفاجأ بفاتورة بآلاف الدولارات. نصيحة ذهبية: دائمًا، وأبدًا، فعّل تنبيهات الفواتير (Billing Alarms) على حسابك السحابي عشان يوصلك إشعار لو التكاليف زادت عن حد معين.

الخلاصة: هل الـ Serverless هي المستقبل؟ 🚀

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

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

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