يا جماعة الخير، السلام عليكم ورحمة الله. اسمحولي اليوم أحكيلكم قصة من أيام زمان، قصة فيها شوية عذاب بس نهايتها حلوة وبتعلّم. قبل كم سنة، كنت ماسك مشروع كبير لواحد من تطبيقات التجارة الإلكترونية الصاعدة. كنا فريق صغير، بس طموحنا كان للسما.
جهّزنا كل شي لإطلاق موسم التخفيضات الكبرى. سهرنا ليالي واحنا بنكتب كود وبنختبر كل صغيرة وكبيرة. وفي ليلة الإطلاق، كنا كلنا مجتمعين في “غرفة الحرب” بتاعتنا، شاشات المراقبة قدامنا، والقهوة شغالة ٢٤ ساعة. أول ساعة، الأمور تمام. الساعة الثانية، بدأ الضغط يزيد. وفجأة، بدون سابق إنذار، صار إشي زي التسونامي! حملة إعلانية ناجحة زيادة عن اللزوم جابتلنا أضعاف أضعاف المستخدمين اللي كنا متوقعينهم.
الخوادم (السيرفرات) بلشت تصرخ وتستغيث. المعالج (CPU) وصل 100%، والذاكرة (RAM) بتترجانا نرحمها. والموقع صار أبطأ من سلحفاة. بلشت الاتصالات تنهال علينا من الدعم الفني: “الموقع واقع!”، “العملاء مش قادرين يدفعوا!”. يا عمي، كان يوم أسود. دخلنا في دوامة يدوية مرعبة: ادخل على لوحة تحكم شركة الاستضافة، اعمل نسخة جديدة من الخادم، استنى ربع ساعة لتجهز، ادخل عليها وثبّت كل البرامج من أول وجديد، ضيفها لموازن الأحمال (Load Balancer)… وبس نخلص كل هاد، يكون الضغط زاد أكتر ونرجع نعيد نفس الموال. حرفيًا، الحمل المفاجئ كان “يكسر ظهرنا”. خسرنا فلوس وزباين وأعصاب في ليلة واحدة. وقتها قلت لنفسي: “مستحيل ما يكون في حل أحسن من هيك!”.
وهون، يا جماعة، بدأت رحلتي مع عالم غيّر طريقة تفكيري في بناء التطبيقات تمامًا: عالم الحوسبة بدون خوادم أو الـ “Serverless”.
ما هي هذه الـ “Serverless” التي يتحدث عنها الجميع؟
أول ما تسمع كلمة “Serverless” (بدون خوادم)، ممكن تفكر إنه ما في خوادم بالموضوع بالمرة. هاد تفكير منطقي، بس مش دقيق. الخوادم لسا موجودة، بس الفرق الجوهري هو: أنت لم تعد مسؤولاً عنها.
تخيل الموضوع زي الكهرباء في بيتك. أنت لما بدك تضوي لمبة، بتكبس على الكبسة وبس. ما بتهمك المحولات الضخمة ولا محطات توليد الطاقة ولا الكوابل الممتدة لآلاف الكيلومترات. أنت بس بتستخدم الكهرباء وقت ما تحتاجها، وبتدفع فاتورة على قد استهلاكك. هاد بالزبط هو مبدأ الـ Serverless.
المزوّد السحابي (مثل Amazon AWS, Google Cloud, Microsoft Azure) هو اللي بتكفل بكل “وجع الراس”: إدارة الخوادم، تحديث أنظمة التشغيل، الحماية، والأهم من كل هاد، التوسع (Scaling).
من خادم كامل إلى مجرد “وظيفة” (Function)
الفكرة المحورية في عالم الـ Serverless هي “الوظائف كخدمة” أو Function as a Service (FaaS). بدل ما ترفع تطبيقك الكامل على خادم شغال ٢٤/٧، أنت بتقسّم تطبيقك لوظائف (functions) صغيرة ومستقلة. كل وظيفة مسؤولة عن مهمة محددة جدًا.
- وظيفة لإنشاء حساب مستخدم جديد.
- وظيفة لمعالجة عملية دفع.
- وظيفة لضغط صورة بعد رفعها.
- وظيفة لإرسال بريد إلكتروني.
وكل وظيفة من هدول بتشتغل فقط عند استدعائها (بسبب طلب HTTP، أو رفع ملف، أو حدث في قاعدة البيانات)، وبعد ما تخلص شغلها، “بتختفي” وما بتستهلك أي موارد. أنت بتدفع فقط على عدد المرات اللي اشتغلت فيها الوظيفة ومدة تشغيلها بالمللي ثانية. إشي خرافي، صح؟
كيف أنقذتنا الـ Serverless من جحيم التوسع اليدوي؟
لنرجع لقصتنا. المشكلة ما كانت في الكود تبعنا، المشكلة كانت في البنية التحتية اللي ما قدرت تستوعب النجاح المفاجئ. خلينا نقارن بين الطريقتين.
الجحيم اليدوي: التوسع التقليدي (The Old Way)
في النموذج التقليدي (سواء خوادم افتراضية VMs أو حتى حاويات Containers مدارة يدويًا)، التوسع عملية معقدة:
- التنبؤ: لازم تتوقع حجم الضغط مسبقًا وتجهز خوادم “احتياط” قبل أي حملة إعلانية. لو توقعك غلط، يا إما بتدفع فلوس على خوادم فاضية، أو بتنهار خوادمك لو الضغط كان أكبر.
- المراقبة المستمرة: فريق كامل لازم يراقب أداء الخوادم باستمرار.
- التدخل اليدوي: عند وصول التنبيهات، يبدأ السباق مع الزمن لإضافة خوادم جديدة وتجهيزها، وهي عملية بطيئة وعرضة للخطأ البشري.
- التكلفة العالية: أنت تدفع ثمن الخادم سواء كان يعمل بنسبة 100% أو 1%. هو شغال ومحجوز لك ٢٤/٧.
النعيم التلقائي: التوسع في عالم الـ Serverless
في عالم الـ Serverless، كلمة “توسع يدوي” بتصير من الماضي. المفهوم كله بيتغير:
تطبيقك لم يعد كيانًا واحدًا يتوسع، بل أصبح مجموعة من الوظائف التي يتم “استنساخها” آلاف المرات بشكل فوري وتلقائي حسب الحاجة.
لما يجي طلب واحد لوظيفتك، المزوّد السحابي بشغّل نسخة واحدة منها. لما يجي 10,000 طلب في نفس الثانية (زي ما صار معنا في قصتنا)، المزوّد السحابي بشغّل 10,000 نسخة متوازية من وظيفتك بشكل تلقائي وفوري وبدون أي تدخل منك. كل نسخة بتخدم طلب واحد وبعدها بتختفي. هاد هو السحر الحقيقي: التوسع اللانهائي (نظريًا) والفوري.
مثال عملي: من الفكرة إلى الكود
خلينا نأخذ مثال بسيط وواقعي: خدمة مصغّرة (Microservice) وظيفتها استقبال اسم المستخدم كمدخل، وترجع رسالة ترحيب شخصية بصيغة JSON. إشي بسيط جدًا.
باستخدام إطار عمل اسمه “Serverless Framework” (وهو إطار عمل رائع بيسهل التعامل مع مختلف المزودين السحابيين)، ممكن نعمل هاد الإشي بسهولة.
1. ملف الإعدادات (serverless.yml)
هاد الملف هو العقل المدبر. بنعرّف فيه كل إشي عن خدمتنا.
# serverless.yml
service: welcome-service # اسم الخدمة
frameworkVersion: '3'
provider:
name: aws # المزوّد السحابي، هنا استخدمنا أمازون
runtime: nodejs18.x # لغة البرمجة وبيئة التشغيل
region: us-east-1 # المنطقة الجغرافية للخوادم
functions:
sayHello: # اسم وظيفتنا
handler: handler.hello # المسار للملف والدالة المصدرة
events:
- httpApi: # هذه الوظيفة يتم استدعاؤها عبر طلب HTTP
path: /hello
method: get
2. الكود الفعلي (handler.js)
هاد هو الكود اللي رح يتنفذ. لاحظ بساطته الشديدة.
// handler.js
'use strict';
module.exports.hello = async (event) => {
// نستخرج اسم المستخدم من الـ query parameters في الرابط
// مثال: /hello?name=Omar
const name = event.queryStringParameters?.name || 'Guest';
const message = `مرحباً يا ${name}! أهلاً وسهلاً في عالم الـ Serverless.`;
return {
statusCode: 200,
body: JSON.stringify(
{
message: message,
},
null,
2
),
};
};
هاد كل إشي! حرفيًا، بهدول الملفين البسيطين، وبأمر واحد في الطرفية (serverless deploy)، بكون عندك نقطة نهاية API (API Endpoint) جاهزة لاستقبال ملايين الطلبات بدون ما تكتب سطر كود واحد لإدارة الخوادم أو التوسع.
لو أجا طلب واحد، بتشتغل. لو أجا مليون طلب، بتشتغل. أنت كـ”أبو عمر” المبرمج، بتقدر تركز على كتابة الكود اللي بيجيب قيمة للبزنس، مش على إطفاء حرائق الخوادم.
“طب شو القصة؟” – تحديات ونصائح من الميدان
طبعًا، ما في حل سحري لكل المشاكل. الـ Serverless إلها تحدياتها الخاصة، ومن خبرتي، هاي أهم النقاط اللي لازم تنتبهولها:
1. البدء البارد (Cold Start)
لما وظيفتك ما تكون شغالة لفترة، المزوّد السحابي “بطفيها” تمامًا. أول طلب بيجيها بعد فترة الخمول هاي بياخد وقت أطول بشوي (من بضع مللي ثواني إلى ثوانٍ قليلة) لأنه لازم يتم تحميل كود الوظيفة وتهيئتها. هاد اسمه “Cold Start”.
نصيحة عملية: للتطبيقات الحساسة للسرعة، معظم المزودين بيقدموا ميزة اسمها “Provisioned Concurrency” اللي بتخلي عدد معين من نُسخ وظيفتك “جاهزة ودافئة” دائمًا، مقابل تكلفة إضافية بسيطة.
2. التعقيد في إدارة الحالة (State Management)
الوظائف بطبيعتها “عديمة الحالة” (Stateless). يعني كل استدعاء هو عالم مستقل بذاته، ما بتذكر إشي عن الاستدعاء اللي قبله. هاد بيخلي التوسع سهل، بس بيصعّب الأمور اللي بتحتاج حالة مستمرة (مثل سلة التسوق أو جلسات المستخدم).
نصيحة عملية: لا تحاول تخزين الحالة داخل الوظيفة. استخدم خدمات خارجية مصممة لهاد الغرض: قواعد بيانات سريعة مثل Amazon DynamoDB أو Redis، أو خدمات تخزين مثل S3.
3. التقييد بمزوّد الخدمة (Vendor Lock-in)
لما تبني كل تطبيقك على وظائف AWS Lambda، بصير صعب جدًا تنقله لـ Azure Functions مثلاً، لأنك بتعتمد على كل النظام البيئي المحيط (API Gateway, SQS, DynamoDB).
نصيحة عملية: استخدام أطر عمل مثل Serverless Framework أو Architect بيساعد على تقليل التقييد لأنه بيوفر طبقة تجريدية (abstraction layer) فوق خدمات المزود. خلي منطق البزنس الأساسي في الكود بتاعك نقي ومستقل قدر الإمكان.
خلاصة الحكي: السيرفرلس مش عصا سحرية، بس قرّبت 😉
بعد سنوات من استخدام بنية الـ Serverless في مشاريع مختلفة، من تطبيقات الويب إلى معالجة بيانات الذكاء الاصطناعي، بقدر أقولكم إنها غيرت قواعد اللعبة. هي مش الحل لكل المشاكل، ولسه في مكان للخوادم التقليدية والتطبيقات المونوليثية في بعض الحالات.
لكن بالنسبة لأي تطبيق بيواجه أحمال متقلبة، أو أي فريق صغير بده يركز على المنتج بدل البنية التحتية، أو أي شركة بدها تدفع فقط على قد استخدامها الفعلي، فالـ Serverless هي أقرب إشي للعصا السحرية اللي كنا بنحلم فيها.
نصيحتي الأخيرة إلكم: لا تخافوا تجربوا. ابدأوا بشي صغير. خذوا جزء صغير من نظامكم، زي إرسال الإيميلات أو معالجة الصور، وحولوه لوظيفة Serverless. شوفوا بأنفسكم كيف بتقل التكلفة وبيختفي “وجع الراس” التشغيلي. رح تتفاجأوا بالنتيجة.
ويلا، شدوا حيلكم يا شباب!
