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

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

خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس قاسي عن إدارة المصاريف في عالم الحوسبة السحابية. وقتها كنت متحمس لمشروع جانبي صغير، أداة بسيطة بتساعد المصممين يختاروا ألوان متناسقة لمشاريعهم. برمجة الواجهة الخلفية (Backend) ما أخذت مني وقت طويل، وكنت مبسوط على حالي. رفعت المشروع على خادم سحابي (Cloud VM) من أحد المزودين المشهورين، خادم صغير وبمواصفات متواضعة، وقلت “يلا، خليه شغال”.

مرّ الشهر الأول، إجتني الفاتورة… مبلغ بسيط، قلت مش مشكلة. الشهر الثاني، نفس الإشي. المشكلة كانت إنه الأداة استخدامها متقطع جدًا، يعني ممكن يدخل عليها 50 واحد في ساعة معينة، وبعدها تضل 10 ساعات ما حدا يستخدمها بالمرة. لكن الخادم؟ الخادم يا جماعة شغال 24 ساعة في اليوم، 7 أيام في الأسبوع. كنت حرفيًا “بحرق مصاري” على الفاضي. كنت بدفع ثمن الكهرباء والمعالج والذاكرة سواء استخدمهم حدا أو لأ. شعور محبط جدًا، وكأني بستأجر محل كبير وبدفع إيجاره كامل مع إني ببيع فيه غرض واحد كل يومين!

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

ما هي الحوسبة التقليدية؟ (ولماذا كانت “مصيبة” لمشروعي)

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

1. بتروح على مزود خدمة سحابية مثل AWS, Azure, Google Cloud, أو غيرهم.
2. بتستأجر “خادم افتراضي” (Virtual Machine)، زي EC2 في أمازون.
3. بتختار مواصفاته: كم معالج (CPU)، كم ذاكرة (RAM)، ومساحة التخزين.
4. بتنصّب عليه نظام التشغيل، وقاعدة البيانات، وكل البرمجيات اللازمة لتشغيل تطبيقك.
5. بترفع الكود تبعك، وبتخليه شغال ومستني الطلبات (Requests) من المستخدمين.

المشكلة؟ زي ما حكيت في قصتي، إنت بتدفع على هذا الخادم سواء كان مشغول أو نايم. تخيل أنك استأجرت باص كبير عشان يوصلك كل يوم على الشغل. رح تدفع إيجار الباص كامل، حتى لو كنت الراكب الوحيد فيه. ولو فجأة قرروا كل أهل الحارة يروحوا معك، الباص ما رح يوسعهم! وقتها لازم تستأجر باص أكبر وتدفع أكثر. هذه هي باختصار معضلة التكاليف والتوسع (Scaling) في العالم التقليدي.

دخول عالم “الحوسبة بدون خوادم” (Serverless): الفكرة اللي غيّرت كل شي

هنا يأتي دور الـ Serverless ليقلب الطاولة. الفكرة عبقرية في بساطتها.

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

لا طبعًا، أكيد في سيرفرات! الاسم تسويقي أكثر منه تقني. لكن الفكرة هي أنك أنت كمطور، لا تتعامل مع هذه الخوادم إطلاقًا. لا بتشوفها، ولا بتديرها، ولا بتعمللها تحديثات، ولا بتخاف من أعطالها. كل هذه المسؤولية تقع على عاتق مزود الخدمة السحابية (مثل أمازون أو جوجل).

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

كيف تشتغل بالضبط؟ (نموذج Functions as a Service – FaaS)

القلب النابض للـ Serverless هو مفهوم “الدوال كخدمة” أو FaaS. بدل ما يكون عندك تطبيق ضخم شغال طول الوقت، بتقسّم الكود تبعك لوحدات صغيرة ومستقلة اسمها “دوال” (Functions). وكل دالة مسؤولة عن شغلة محددة.

هذه الدالة بتكون “نايمة” ومش بتستهلك أي موارد. وفجأة، لما يصير “حدث” (Event) معين، بتصحى الدالة وبتشتغل.

ما هي الأحداث اللي ممكن تشغّل الدالة؟

• طلب HTTP جديد (حدا فتح رابط معين في تطبيقك).
• ملف جديد تم رفعه على خدمة تخزين سحابي (زي Amazon S3).
• رسالة جديدة وصلت على قائمة انتظار (Queue).
• تغيير حصل في قاعدة البيانات.
• جدول زمني محدد (مثلاً، تشغيل دالة كل ساعة لتنظيف البيانات).

لما يصير الحدث، مزود الخدمة السحابية بيقوم بالآتي في أجزاء من الثانية:

1. يجد حاوية (Container) فارغة.
2. يضع الكود تبع دالتك فيها.
3. يشغّل الدالة وينفذ المطلوب منها.
4. بعد ما تخلص شغلها، بيطفّي الحاوية.

والأهم؟ أنت لا تدفع إلا مقابل مدة تشغيل الدالة بالمللي ثانية (millisecond)! إذا ما حدا استخدم تطبيقك، فاتورتك بتكون صفر أو قريبة من الصفر. هذا بالضبط ما كنت أحتاجه.

تجربتي العملية: نقل مشروعي إلى Serverless (مع مثال عملي)

قرار التحويل كان سهل. بدأت بواجهة برمجية (API) بسيطة كانت جزءًا من مشروعي. كانت عبارة عن نقطة نهاية (endpoint) بترجع قائمة الألوان عند استدعائها.

المثال: واجهة برمجية بسيطة

في الطريقة التقليدية، كان عندي ملف `server.js` شغال على خادم Express.js (باستخدام Node.js) بهذا الشكل تقريبًا:

// server.js - الطريقة التقليدية على خادم VM
const express = require('express');
const app = express();
const port = 3000;

// هذه الدالة تمثل منطق العمل
function getColors() {
  // تخيل هنا كود يتصل بقاعدة بيانات ويجلب الألوان
  return [
    { name: 'أحمر قُدسي', hex: '#882426' },
    { name: 'أخضر زيتوني', hex: '#556B2F' }
  ];
}

app.get('/api/colors', (req, res) => {
  const colors = getColors();
  res.json(colors);
});

app.listen(port, () => {
  console.log(`الخادم يعمل على مدار الساعة على المنفذ ${port}`);
});

هذا الخادم لازم يضل شغال 24/7 عشان يستجيب للطلبات. الآن شوفوا كيف صار شكله في عالم الـ Serverless (باستخدام AWS Lambda كمثال):

// handler.js - دالة Serverless على AWS Lambda
// لا يوجد Express، لا يوجد خادم، لا يوجد منفذ!

// هذه الدالة تمثل منطق العمل
function getColors() {
  // نفس الكود الذي يتصل بقاعدة بيانات ويجلب الألوان
  return [
    { name: 'أحمر قُدسي', hex: '#882426' },
    { name: 'أخضر زيتوني', hex: '#556B2F' }
  ];
}

exports.handler = async (event) => {
  // كل المعلومات عن الطلب (الـ request) موجودة في الـ event object
  console.log('تم استدعاء الدالة!');
  
  const colors = getColors();

  const response = {
    statusCode: 200,
    headers: {
      'Content-Type': 'application/json',
      'Access-Control-Allow-Origin': '*' // للسماح بالوصول من أي نطاق
    },
    body: JSON.stringify(colors),
  };

  return response;
};

لاحظتوا الفرق؟ الكود الثاني هو مجرد “دالة” (function). لا يوجد أي ذكر لخادم أو منفذ (port). أنا فقط كتبت منطق العمل (Business Logic)، ومزود الخدمة (أمازون في هذه الحالة) يتكفل بالباقي عبر خدمات مثل API Gateway التي تستقبل طلبات الـ HTTP وتمررها للدالة.

النتيجة؟ فاتورتي الشهرية للمشروع تحولت من حوالي 20-30 دولار شهريًا إلى أقل من دولار واحد! وفي بعض الأشهر كانت مجانية تمامًا بفضل الطبقة المجانية (Free Tier) السخية التي تقدمها معظم الخدمات السحابية.

الفوائد اللي لمستها بنفسي (مش بس توفير المصاري)

صحيح أن توفير المال كان الدافع الأكبر، لكني اكتشفت فوائد أخرى غيّرت طريقة عملي تمامًا:

1. توفير التكاليف “الدراماتيكي”

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

2. التوسع التلقائي (Auto-Scaling) اللي بريّح الراس

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

3. التركيز على الكود، مش على إدارة السيرفرات

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

طيب يا أبو عمر، هل Serverless هي الحل السحري لكل شي؟ (العيوب والتحفظات)

لكل تقنية مزايا وعيوب، والـ Serverless ليست استثناء. من المهم أن نكون واقعيين:

• مشكلة “البداية الباردة” (Cold Start): أول طلب لدالة “نائمة” منذ فترة قد يستغرق وقتًا أطول بقليل (من 100 مللي ثانية إلى ثانية أو أكثر أحيانًا) لأن المنصة تحتاج “لإيقاظها”. هذا قد لا يكون مقبولًا في التطبيقات شديدة الحساسية لزمن الاستجابة.
• التعقيد في المراقبة وتصحيح الأخطاء: عندما يكون لديك عشرات أو مئات الدوال الصغيرة التي تتحدث مع بعضها، يصبح تتبع الأخطاء أصعب من تتبعها في تطبيق واحد متكامل (Monolith). تحتاج لأدوات متخصصة مثل AWS X-Ray أو Datadog.
• التقييد بالمنصة (Vendor Lock-in): الكود الذي تكتبه لـ AWS Lambda قد يحتاج لتعديلات ليعمل على Google Cloud Functions. استخدام أطر عمل مثل Serverless Framework يمكن أن يخفف من هذه المشكلة.
• محدودية وقت التنفيذ: معظم المنصات تضع حدًا أقصى لزمن تشغيل الدالة (مثلاً 15 دقيقة في AWS Lambda). هذا يجعلها غير مناسبة للمهام الطويلة جدًا (مثل تدريب نماذج تعلم الآلة لساعات).

خلاصة الكلام ونصيحة من أخوكم أبو عمر 💡

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

• الواجهات البرمجية (APIs) ذات الاستخدام المتقطع.
• المشاريع الجانبية والشركات الناشئة في بداياتها.
• مهام معالجة البيانات التي تعمل بناءً على أحداث (مثل معالجة الصور عند رفعها).
• الـ Chatbots والمهام التي تتكامل مع خدمات أخرى.

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

بالتوفيق يا جماعة، وإن شاء الله دايماً مشاريعكم ناجحة وفواتيركم قليلة 😉.