يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.
خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة بتلخص معاناة كثير من المطورين والشركات الصغيرة. كنا في بداية مشروعنا، وكله حماس وطموح، وبنينا خدمة لمعالجة تقارير مالية للمستخدمين. الفكرة كانت بسيطة: المستخدم برفع ملف، نظامنا بعالجه، وبطلعله تقرير مفصل. شغل مرتب، صح؟
المشكلة وين؟ المشكلة إنه هاي العملية كانت تصير مرة واحدة في اليوم، بالليل، لما النظام يجمع كل الملفات ويعالجها دفعة واحدة. استأجرنا خادم (Server) من أحد المزودين الكبار، وركبنا عليه كل برامجنا، وكان الخادم شغال 24 ساعة في اليوم، 7 أيام في الأسبوع. طيب شو كان يعمل باقي الـ 23 ساعة؟ الجواب: ولا إشي! كان قاعد “بشرب قهوة وبدخن”، حرفيًا خامل، واحنا بندفع عليه الفاتورة كاملة آخر الشهر.
كنت أفتح لوحة المراقبة وأشوف استهلاك المعالج (CPU) 1% أو 2% معظم اليوم، والذاكرة مستخدم منها جزء بسيط. كنت أحكي لحالي: “يا زلمة شو هالحكي؟ إحنا بندفع حق باص كامل عشان نوصل راكب واحد مرة باليوم!”. كانت المصاري تروح هدر، والقلب يوجعنا. وهون كانت القشّة اللي قصمت ظهر البعير، وقررنا إنه لازم نلاقي حل جذري لهدر الموارد هذا.
النموذج التقليدي: سفينة مربوطة في الميناء
قبل ما نحكي عن الحل، خلينا نفهم أصل المشكلة. الطريقة التقليدية (واللي للأسف لسا كثير ناس شغالة عليها) هي إنك تستأجر خادم افتراضي (Virtual Machine) أو حتى خادم حقيقي (Dedicated Server). هذا الخادم مثل بيت إنت استأجرته، سواء نمت فيه أو لأ، لازم تدفع الإيجار كامل.
في هذا النموذج، أنت مسؤول عن كل شيء:
- التجهيز (Provisioning): اختيار حجم الخادم (كم معالج، كم ذاكرة، كم مساحة تخزين).
- الإعداد (Configuration): تثبيت نظام التشغيل، تحديثه، تثبيت البرامج اللازمة (مثل Node.js, Python, PHP)، ضبط قواعد الجدار الناري (Firewall)، وغيرها من التفاصيل المملة.
- الصيانة (Maintenance): المراقبة المستمرة، تطبيق التحديثات الأمنية، والتأكد من أن الخادم “صاحي” وشغال.
- التوسع (Scaling): إذا زاد الضغط فجأة، لازم تكون عامل حسابك وتجهز خوادم إضافية وتضبط موازِن الأحمال (Load Balancer). عملية معقدة وبدها شغل.
المشكلة الكبرى، كما في قصتنا، هي عندما يكون الحمل على نظامك متقطعًا وغير منتظم. أنت تضطر لشراء خادم قادر على تحمل أقصى ضغط متوقع، ولكنه سيظل خاملًا معظم الوقت، وهذا هو تعريف “جحيم الموارد المهدرة”.
الحل السحري: الحوسبة عديمة الخادم (Serverless)
بعد بحث وتجربة، وجدنا ضالتنا في مفهوم جديد وقتها اسمه “Serverless”. للوهلة الأولى، الاسم خادع. كيف يعني “بدون خوادم”؟ هل الكود تبعنا رح يشتغل في الهواء؟
كيف يعني “بدون خوادم”؟
المصطلح الأدق هو “الحوسبة التي لا تُعنى فيها بإدارة الخوادم”. الخوادم موجودة طبعًا، وموجودة بكثرة في مراكز بيانات عملاقة، لكن أنت كمطور، ما إلك علاقة فيها نهائيًا. كل ما عليك هو كتابة الكود الخاص بك على شكل “دالة” (Function)، ورفعها على المنصة السحابية (مثل AWS Lambda, Google Cloud Functions, Azure Functions).
المزود السحابي هو من يتكفل بكل شيء آخر: هو يوفر الخادم، ويهيئ بيئة التشغيل، ويشغّل دالتك فقط عند الحاجة، ثم يطفئها. أنت لم تعد تستأجر البيت، بل أصبحت تدفع فقط مقابل الدقائق التي تقضيها في غرفة الفندق.
النموذج القائم على الحدث (Event-Driven)
جوهر الـ Serverless هو أنها تعمل بنظام “رد الفعل” أو “النموذج القائم على الحدث”. الدالة تبعتك بتكون “نائمة” ولا تكلفك شيئًا، إلى أن يقع “حدث” (Event) معين يوقظها.
ما هي هذه الأحداث؟ أمثلتها كثيرة:
- طلب HTTP جديد (API Gateway).
- رفع ملف جديد على خدمة تخزين (مثل Amazon S3).
- رسالة جديدة في طابور رسائل (مثل SQS).
- تغيير في قاعدة البيانات (مثل DynamoDB Streams).
- جدول زمني محدد (مثل “شغّل هذه الدالة كل يوم الساعة 2 صباحًا”).
بمجرد وقوع الحدث، تقوم المنصة السحابية فورًا بتشغيل نسخة من دالتك، تمرر لها معلومات الحدث، وتتركها تقوم بعملها. انتهت الدالة من عملها؟ تعود لتنام، ويتوقف عداد التكلفة فورًا.
كيف أنقذتنا الـ Serverless عمليًا؟
بالعودة لقصتنا مع خدمة التقارير، الحل كان واضحًا كالشمس. قمنا بإعادة كتابة منطق معالجة التقارير على شكل دالة AWS Lambda.
- الحدث: قمنا بربط الدالة بخدمة التخزين S3. الحدث الذي يوقظ الدالة هو “إنشاء كائن جديد” (ObjectCreated) في مجلد معين.
- التنفيذ: عندما يقوم المستخدم برفع ملف التقرير إلى S3، يتم إطلاق الدالة تلقائيًا.
- المعالجة: الدالة تستلم معلومات الملف الذي تم رفعه، تقوم بتحميله، تعالجه، وتُنشئ التقرير النهائي، ثم تحفظه في مجلد آخر على S3.
النتيجة؟ بدلًا من خادم يعمل 24/7 بتكلفة تقارب 50-70 دولارًا شهريًا وهو خامل 95% من الوقت، أصبحنا ندفع فقط مقابل الثواني القليلة التي تعمل فيها الدالة عند رفع كل ملف. الفاتورة الشهرية انخفضت من عشرات الدولارات إلى أقل من دولار واحد! نعم، أقل من دولار. هذا ليس خيالًا علميًا، هذه هي قوة نموذج الدفع مقابل الاستخدام الفعلي.
مثال عملي: دالة Lambda لمعالجة الصور (Python)
لتقريب الصورة، دعنا نأخذ مثالًا شائعًا آخر: دالة تقوم بإنشاء نسخة مصغرة (Thumbnail) من أي صورة يتم رفعها على S3. هذا الكود هو مثال مبسط جدًا لما يمكن عمله.
import boto3
from PIL import Image
import io
s3 = boto3.client('s3')
def lambda_handler(event, context):
# 1. استخراج اسم الحاوية (Bucket) واسم الملف (Key) من الحدث
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
# التأكد من أننا لا نعالج الصور المصغرة التي ننشئها (لتجنب حلقة لا نهائية)
if 'thumbnails/' in key:
print("This is already a thumbnail. Exiting.")
return
print(f"Processing image: {key} from bucket: {bucket}")
try:
# 2. تحميل الصورة الأصلية من S3
response = s3.get_object(Bucket=bucket, Key=key)
image_content = response['Body'].read()
# 3. استخدام مكتبة Pillow لإنشاء نسخة مصغرة
with Image.open(io.BytesIO(image_content)) as image:
image.thumbnail((128, 128)) # تحديد أبعاد الصورة المصغرة
# حفظ الصورة المصغرة في الذاكرة المؤقتة
buffer = io.BytesIO()
image.save(buffer, format="JPEG")
buffer.seek(0)
# 4. رفع الصورة المصغرة إلى مجلد آخر في S3
new_key = f"thumbnails/{key.split('/')[-1]}"
s3.put_object(
Bucket=bucket,
Key=new_key,
Body=buffer,
ContentType='image/jpeg'
)
print(f"Successfully created thumbnail: {new_key}")
return {'status': 'success'}
except Exception as e:
print(f"Error processing image: {e}")
raise e
هذا الكود البسيط، عند رفعه كدالة Lambda وربطه بـ S3، يقوم بأتمتة عملية كاملة كانت تتطلب خادمًا يعمل باستمرار وبرامج مراقبة معقدة.
نصائح من خبرة أبو عمر
بعد سنوات من العمل مع الـ Serverless، تعلمت بعض الدروس التي أحب أن أشاركها معكم:
“مش كل إشي بينفعله سيرفرلس، كل شيخ وإله طريقة.”
صحيح أن الـ Serverless رائعة، لكنها ليست الحل المناسب لكل المشاكل. إليك بعض النقاط لتأخذها في الحسبان:
- المهام طويلة الأمد: معظم منصات FaaS تضع حدًا أقصى لزمن تشغيل الدالة (مثلًا 15 دقيقة في AWS Lambda). إذا كانت عمليتك تتطلب ساعات، فالـ Serverless قد لا تكون الخيار الأنسب مباشرة، وقد تحتاج إلى حلول أخرى مثل AWS Fargate أو Step Functions لتنسيق دوال متعددة.
- مشكلة “البداية الباردة” (Cold Start): عندما لا يتم استدعاء دالتك لفترة، فإن المنصة “تطفئها” لتوفير الموارد. عند أول طلب جديد بعد فترة الخمول، تحتاج المنصة لبعض الوقت (من بضع أجزاء من الثانية إلى عدة ثوانٍ) لتهيئة بيئة التشغيل من جديد. هذا التأخير يسمى “Cold Start”. للمهام غير الحرجة (مثل مثالنا لمعالجة التقارير) هذا لا يمثل مشكلة، لكن للتطبيقات التي تتطلب استجابة فورية جدًا، قد يكون هذا التأخير ملحوظًا. (هناك حلول لهذه المشكلة مثل Provisioned Concurrency لكنها تزيد التكلفة).
- التعقيد في المراقبة: المراقبة هنا مختلفة. أنت لا تراقب صحة خادم واحد، بل تراقب آلاف أو ملايين الاستدعاءات لدوال متفرقة. ستحتاج إلى استخدام أدوات مثل AWS CloudWatch, Datadog, أو غيرها لفهم سلوك نظامك وتتبع الأخطاء والتكاليف.
- الارتباط بالمزوّد (Vendor Lock-in): عندما تكتب كودًا خاصًا بـ AWS Lambda، قد يكون من الصعب نقله كما هو إلى Azure Functions. هناك أطر عمل (Frameworks) مثل “Serverless Framework” تحاول حل هذه المشكلة عبر توفير طبقة تجريدية (Abstraction Layer)، لكن يبقى هناك درجة من الارتباط بالمنصة التي تختارها.
نصيحتي لك
إذا كنت جديدًا على هذا العالم، ابدأ صغيرًا. لا تحاول تحويل نظامك بأكمله إلى Serverless دفعة واحدة. اختر مهمة صغيرة، محددة، وغير حرجة في نظامك الحالي. هل لديك “Cron Job” يعمل كل ليلة لإنشاء نسخة احتياطية؟ هل لديك وظيفة لمعالجة الصور؟ هل لديك Webhook يستقبل بيانات من خدمة خارجية؟ هذه هي المرشحات المثالية لتكون أولى تجاربك مع الـ Serverless. جربوها على شغلة صغيرة، وشوفوا النتيجة بعينكم.
الخلاصة النهائية 🏁
الانتقال إلى الحوسبة عديمة الخادم (Serverless) كان نقلة نوعية في طريقة تفكيرنا وبنائنا للبرمجيات. لقد حررتنا من صداع إدارة الخوادم، وسمحت لنا بالتركيز على ما يهم حقًا: كتابة كود يحل مشاكل المستخدمين ويضيف قيمة للعمل.
الأهم من ذلك، أنها أنقذتنا من “جحيم الموارد المهدرة” وحولت التكلفة من نموذج الإيجار الثابت إلى نموذج الدفع مقابل الاستخدام الفعلي بالمللي ثانية. في عالم الشركات الناشئة والمشاريع الصغيرة حيث كل قرش مهم، هذا التوفير ليس مجرد تحسين، بل هو شريان حياة.
جربوها، تعلموها، وابدأوا بتطبيقها على مشاريعكم. قد تكون هي الشيء الذي يحتاجه مشروعكم لينمو ويزدهر دون أن يغرق في فواتير البنية التحتية. بالتوفيق يا جماعة! 👍
