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

“يا زلمة شو هالفاتورة؟”: قصة بدأت بصدمة وانتهت بحل عبقري

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

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

مرّ الشهر الأول، وصلتني الفاتورة على الإيميل. فتحتها وأنا بشرب فنجان القهوة الصباحي، وبكل ثقة… وفجأة شرقِت بالقهوة! المبلغ كان أعلى بكثير من اللي توقعته. طلعت على تفاصيل الفاتورة، لقيت حالي دافع على الخادم لمدة 720 ساعة كاملة (24 ساعة * 30 يوم). طيب يا جماعة الخير، تطبيقي يمكن ما اشتغل فعليًا غير ساعة أو ساعتين متفرقات طول الشهر! ليش أدفع على كل هالوقت الضايع؟

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

ما هي مشكلة الخوادم التقليدية؟ (وجعة الراس اللي كنت فيها)

قبل ما ندخل في الحل، خلينا نفهم أصل المشكلة اللي كنت أعاني منها، واللي كثير من المطورين والشركات بعانوا منها. النموذج التقليدي للحوسبة السحابية (اللي يُعرف بـ IaaS – Infrastructure as a Service) بيعتمد على فكرة استئجار موارد حوسبية لفترة زمنية محددة.

ببساطة، أنت بتقول للمزوّد السحابي: “أعطيني جهاز كمبيوتر (خادم) بمواصفات كذا وكذا (مثلاً 2 CPU و 4GB RAM)، وأنا رح أدفعلك عليه إيجار شهري أو بالساعة”.

هذا النموذج يضعك أمام خيارين، أحلاهما مر:

• التجهيز المفرط (Over-provisioning): وهو ما فعلته أنا. تقوم بحجز موارد أكثر من حاجتك الفعلية تحسبًا لأي ضغط مفاجئ (Peak Traffic). النتيجة؟ تدفع أموالًا طائلة على موارد خاملة معظم الوقت.
• التجهيز الناقص (Under-provisioning): تحاول توفير المال عن طريق حجز موارد قليلة. النتيجة؟ عند حدوث أي زيادة في عدد المستخدمين، “بِفرُط” النظام ويتعطل تطبيقك، وتخسر المستخدمين وثقتهم.

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

دخول المنقذ: الحوسبة بدون خوادم (Serverless)

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

المزوّد السحابي (مثل Amazon Web Services, Google Cloud, Microsoft Azure) هو من يتكفل بكل شيء: تجهيز الخادم، إدارته، تحديثه، وتوسعته عند الحاجة. أنت كمطور، كل ما عليك فعله هو كتابة الكود الخاص بك على شكل “دوال” (Functions) ورفعها على المنصة.

وهنا تأتي النقطة الثورية:

أنت تدفع فقط عند تنفيذ الكود الخاص بك، وتُحاسب بالمللي ثانية!

إذا لم يتم استدعاء الكود الخاص بك طوال اليوم، فإن فاتورتك لذلك اليوم تكون صفرًا. لا يوجد إيجار شهري، لا يوجد رسوم على الموارد الخاملة. هذا النموذج يُعرف بـ “الوظائف كخدمة” (Functions as a Service – FaaS)، وهو أشهر تطبيقات الحوسبة بدون خوادم.

كيف تعمل “الوظائف كخدمة” (FaaS) على أرض الواقع؟

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

السيناريو التقليدي (الطريقة القديمة)

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

سيناريو الحوسبة بدون خوادم (باستخدام AWS Lambda كمثال)

هنا يتغير كل شيء. العملية تصبح “موجهة بالأحداث” (Event-driven):

1. الحدث (Trigger): يقوم المستخدم برفع صورة إلى خدمة تخزين مثل Amazon S3. هذا الرفع هو “الحدث” أو “الزناد”.
2. الدالة (Function): هذا الحدث يقوم تلقائيًا بتشغيل دالة AWS Lambda التي كتبتها أنت مسبقًا.
3. التنفيذ (Execution): الكود داخل الدالة يقرأ الصورة الجديدة، يغير حجمها، ويحفظ النسخة الجديدة في مكان آخر على S3.
4. التوقف (Termination): بمجرد انتهاء المهمة، تتوقف الدالة عن العمل تمامًا.

أنت تدفع فقط مقابل فترة التنفيذ القصيرة هذه (والتي قد تكون بضع مئات من المللي ثانية). إذا لم يتم رفع أي صور، فلن يتم تشغيل أي كود، وبالتالي لن تدفع أي شيء.

مثال كود بسيط (Python على AWS Lambda)

هذا مثال بسيط لدالة Lambda مكتوبة بلغة بايثون تقوم بتغيير حجم صورة عند رفعها إلى S3:

import boto3
from PIL import Image
import io

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

def lambda_handler(event, context):
    # 1. استخراج اسم الحاوية (bucket) واسم الملف (key) من الحدث
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    file_key = event['Records'][0]['s3']['object']['key']
    
    # تجنب الحلقات اللانهائية (لو كنا نكتب في نفس الحاوية)
    if "resized-" in file_key:
        return

    # 2. تحميل الصورة من S3
    response = s3_client.get_object(Bucket=bucket_name, Key=file_key)
    image_content = response['Body'].read()
    
    # 3. تغيير حجم الصورة باستخدام مكتبة Pillow
    image = Image.open(io.BytesIO(image_content))
    image.thumbnail((400, 400)) # تغيير الحجم ليصبح أقصى عرض/ارتفاع 400 بكسل
    
    # 4. حفظ الصورة الجديدة في ذاكرة مؤقتة (buffer)
    buffer = io.BytesIO()
    image.save(buffer, format="JPEG")
    buffer.seek(0)
    
    # 5. رفع الصورة الجديدة إلى حاوية أخرى أو بنفس الاسم مع علامة
    new_key = f"resized-{file_key}"
    s3_client.put_object(
        Bucket=bucket_name, # أو اسم حاوية آخر
        Key=new_key,
        Body=buffer,
        ContentType='image/jpeg'
    )
    
    print(f"Successfully resized {file_key} to {new_key}")
    return {'status': 'success'}

هذا الكود، مع بعض الإعدادات البسيطة على واجهة AWS، يحل مشكلة كاملة كانت تتطلب خادمًا وإدارة مستمرة، ويحولها إلى عملية تلقائية وفعالة من حيث التكلفة.

مزايا وعيوب الحوسبة بدون خوادم (من دفتر ملاحظاتي)

كأي تقنية، الـ Serverless ليست حلًا سحريًا لكل المشاكل. من خلال تجربتي، لخصت لكم أهم الإيجابيات والسلبيات.

المزايا (الجانب المشرق ✨)

• توفير هائل في التكاليف: هذه هي الميزة الأكبر. مثالية للمشاريع الناشئة، التطبيقات ذات الاستخدام المتقطع، أو المهام الخلفية التي تعمل بشكل دوري.
• التوسع التلقائي (Auto Scaling): هل استقبلت 10 طلبات في الدقيقة؟ أم 10,000؟ لا يهم. المنصة السحابية تتكفل بتشغيل العدد اللازم من نُسخ دالتك بشكل تلقائي وفوري. “إنسى الموضوع، همه بتكفلوا فيه”.
• التركيز على منطق العمل (Business Logic): بدلاً من قضاء وقتك في تحديث الخوادم، يمكنك تركيز كل طاقتك على كتابة كود يخدم مشروعك مباشرة. “بتكتب الكود وبتزته، والباقي عليهم”.
• سرعة التطوير والنشر: بما أنك لا تبني بنية تحتية من الصفر، يمكنك إطلاق ميزات جديدة بسرعة فائقة.

العيوب (الجانب اللي لازم تنتبهله ⚠️)

• البداية الباردة (Cold Start): إذا لم يتم استدعاء دالتك لفترة، فإن المنصة “تطفئها” لتوفير الموارد. عند أول طلب جديد، تحتاج الدالة لبضع ثوانٍ لـ “تستيقظ” وتبدأ العمل. هذا التأخير قد يكون مشكلة للتطبيقات الحساسة للسرعة. (لكن هناك حلول متقدمة لهذه المشكلة مثل Provisioned Concurrency).
• التقييد بالمزوّد (Vendor Lock-in): عندما تبني نظامك على AWS Lambda، يصبح من الصعب نقله إلى Azure Functions أو Google Cloud Functions. كل منصة لها آلياتها وأدواتها الخاصة. “زي اللي بتجوز من عيلة، صعب تطلع منها بسهولة”.
• التعقيد في المراقبة وتصحيح الأخطاء: لا يمكنك الدخول إلى الخادم عبر SSH لتفقد الأمور. عليك الاعتماد كليًا على أدوات التسجيل (Logging) والمراقبة التي يوفرها المزوّد السحابي (مثل Amazon CloudWatch).
• قيود التنفيذ: الدوال لها عمر افتراضي محدود (مثلاً 15 دقيقة في AWS Lambda) وموارد محدودة (ذاكرة). هذا يجعلها غير مناسبة للمهام الطويلة جدًا أو التي تتطلب قوة معالجة هائلة ومستمرة.

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

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

1. ابدأ صغيرًا: لا تحاول تحويل تطبيقك الضخم بالكامل إلى Serverless مرة واحدة. اختر مهمة صغيرة ومعزولة، مثل إرسال إيميل ترحيبي للمستخدمين الجدد، أو معالجة بيانات من نموذج اتصال، أو مثال تغيير حجم الصور الذي ذكرناه.
2. استخدم إطار عمل (Framework): لا تقم بكل شيء يدويًا. استخدم أدوات مثل Serverless Framework أو AWS SAM. هذه الأطر “بتلملم” لك كل الإعدادات في ملف واحد وتجعل عملية النشر والتحديث سهلة جدًا، وتوفر عليك “وجعة راس ما إلها أول من آخر”.
3. راقب تكاليفك وفواتيرك: صحيح أنها رخيصة، لكن خطأ برمجي بسيط (مثل دالة تستدعي نفسها في حلقة لا نهائية) يمكن أن يؤدي إلى فاتورة ضخمة. قم دائمًا بتفعيل تنبيهات الفواتير (Billing Alerts) لتصلك رسالة إذا تجاوزت التكلفة حدًا معينًا.
4. فكر بطريقة غير متزامنة (Asynchronously): قوة Serverless الحقيقية تظهر عند بناء أنظمة غير متزامنة وموجهة بالأحداث. تعلم استخدام خدمات الطوابير (Queues) مثل SQS وخدمات الأحداث (Event Buses) مثل EventBridge لربط دوالك ببعضها البعض بطريقة مرنة وقابلة للتوسع.

الخلاصة والزبدة 🚀

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

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

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