يا جماعة الخير، السلام عليكم ورحمة الله.
قبل كم سنة، كنت قاعد في مكتبي الصغير، بشرب كاسة شاي بالمرمية وبقلّب في فواتير آخر الشهر. كان عندي تطبيق صغير عملته، أداة بسيطة بتساعد المصممين على تحويل صيغ معينة من ملفات التصميم. التطبيق كان فكرته حلوة، وبخدم شريحة معينة، بس استخدامه كان متقطع جداً. يعني ممكن يمر يوم كامل ما حدا يستخدمه، وفجأة في ساعة وحدة ييجيه عشرين طلب.
المشكلة ما كانت في التطبيق نفسه، المشكلة كانت في فاتورة السيرفر الشهرية اللي بتوصلني. كنت حاجز سيرفر افتراضي (VPS) متواضع، مش إشي خارق، بس كنت بدفع عليه مبلغ ثابت كل شهر، سواء حدا استخدم التطبيق أو لأ. كنت حاسس حالي زي اللي مستأجر محل كبير وفاتحه 24 ساعة عشان يبيع غرض واحد في اليوم. إحساس بالهدر مش طبيعي، مصاري بتنكب عالفاضي، وموارد أنا مش مستفيد منها.
وقتها، كنت بسمع مصطلح “Serverless” أو “الحوسبة الخادومية” من بعيد لبعيد، وكنت مفكره موضة تقنية جديدة ورح تروح لحالها. بس لما زاد وجع الفاتورة، قررت أعطي الموضوع فرصة وأقرأ عنه بجدية. وهون كانت نقطة التحول… خلوني أحكيلكم كيف هالتكنولوجيا أنقذتني من هدر الموارد وخلتني أركز على اللي بحبه: كتابة الكود.
ما هي مشكلة السيرفرات التقليدية؟
قبل ما نغوص في عالم الـ Serverless، خلينا نفهم المشكلة الأساسية مع النموذج التقليدي. لما تبني تطبيق، أنت بحاجة لمكان تشغّله عليه، وهذا المكان هو “السيرفر”. في العادة، عندك خيارات مثل:
- السيرفرات المخصصة (Dedicated Servers): جهاز كامل إلك، قوة كبيرة بس تكلفة أعلى وإدارة معقدة.
- السيرفرات الافتراضية الخاصة (VPS): جزء من سيرفر مخصص، مرونة جيدة وتكلفة أقل. وهذا اللي كنت بستخدمه.
- منصات الحوسبة السحابية (مثل AWS EC2, Azure VMs): بتعطيك سيرفرات افتراضية مرنة جداً، بس بتضل الفكرة نفسها: أنت بتحجز “آلة” وبتحاسب عليها بالساعة أو بالشهر.
المشكلة المشتركة في كل هدول، وخصوصاً للمشاريع الصغيرة أو اللي عليها استخدام متقلب، هي إنك تدفع مقابل الوقت، وليس مقابل الاستخدام الفعلي. السيرفر شغال 24/7، سواء كان بيستقبل ألف طلب في الدقيقة أو كان “صافن في السقف” ما بيعمل إشي. وهذا هو تعريف هدر الموارد بعينه.
الـ “Serverless”: الحل الذي لم أكن أعرف أنني أحتاجه
كلمة “Serverless” أو “بدون خوادم” هي تسمية مضللة شوي. أكيد في خوادم بالموضوع! بس الفكرة إنه أنت كمطور ما بتتعامل معها نهائياً. ما في داعي تختار نظام تشغيل، ولا تحدث برامج، ولا تقلق من الحماية، ولا تفكر في حجم الرام والمعالج.
ببساطة شديدة، الحوسبة الخادومية هي نموذج بتكتب فيه الكود تبعك على شكل “وظائف” (Functions) صغيرة ومستقلة. وبدل ما تشغّل سيرفر عشان يستنى حدا يطلب هاي الوظيفة، أنت بترفعها على منصة سحابية (مثل AWS Lambda أو Azure Functions). المنصة هاي بتتكفل بكل شيء:
- لما يوصل طلب (مثلاً، حدا ضغط على زر في تطبيقك)، المنصة بتصحّي الوظيفة تبعتك.
- بتشغّل الكود وبتعطيه الموارد اللازمة.
- بعد ما يخلص الكود ويرجع النتيجة، المنصة بتطفي كل إشي.
والأهم من كل هاد؟ أنت بتدفع فقط على عدد المللي ثانية (Milliseconds) اللي اشتغل فيها الكود تبعك! إذا ما حدا استخدم تطبيقك، ما بتدفع ولا قرش. بالزبط زي فاتورة الكهرباء، بتدفع على قد ما بتستهلك.
كيف حوّلت تطبيقي “الكسلان” إلى آلة فعّالة وموفرة؟
لما فهمت المبدأ، تحمست جداً. قررت أحوّل تطبيقي الصغير من سيرفر VPS إلى بنية Serverless على AWS Lambda. العملية كانت أسهل مما توقعت.
الخطوة الأولى: تفكيك التطبيق لوظائف (Functions)
تطبيقي كان بسيط، عبارة عن واجهة برمجية (API) فيها نقطة وصول (endpoint) واحدة. المستخدم بيرفع ملف، الكود بيعمل عليه شوية معالجة، وبرجعله رابط لملف جديد.
هذا معناه إني بحاجة لوظيفة (Function) واحدة بس. هاي الوظيفة بتستقبل طلب HTTP POST فيه الملف، وبتنفذ منطق المعالجة.
الخطوة الثانية: كتابة أول دالة لامدا (AWS Lambda)
أنا بشتغل كثير بلغة بايثون، فكتبت الوظيفة تبعتي ببايثون. الكود كان شبه مطابق للكود اللي كان شغال على السيرفر، مع شوية تعديلات بسيطة عشان يتناسب مع بيئة Lambda.
هاي نسخة مبسطة جداً من الكود عشان توصل الفكرة:
import json
# هاي هي الوظيفة الأساسية اللي بتستدعيها AWS Lambda
def lambda_handler(event, context):
"""
وظيفة لامدا بسيطة بتستقبل اسم وبترجع رسالة ترحيب.
"""
# الـ "event" هو قاموس (dictionary) فيه كل معلومات الطلب
# مثلاً، لو الطلب جاي من API Gateway، بنلاقي الـ body جواته
print("تم استدعاء الوظيفة!")
try:
# بنحاول نقرأ الجسم تبع الطلب ونحوله من نص JSON لكائن بايثون
body = json.loads(event.get('body', '{}'))
name = body.get('name', 'يا حبيبنا')
except:
name = 'يا طيب'
message = f"أهلاً وسهلاً فيك يا {name} من عالم الـ Serverless!"
# لازم نرجع استجابة بصيغة معينة عشان الـ API Gateway يفهمها
return {
'statusCode': 200,
'headers': {
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': '*' # للسماح بالطلبات من أي مكان
},
'body': json.dumps({'message': message})
}
لاحظوا بساطة الكود. ما في أي إشي إله علاقة بالسيرفرات أو الشبكات. مجرد وظيفة بتستقبل مدخلات (event) وبترجع مخرجات. هذا هو جوهر الـ Serverless.
الخطوة الثالثة: ربط كل شيء معاً
بعد ما كتبت الكود، رفعت وظيفة الـ Lambda على حسابي في AWS. الخطوة الأخيرة كانت إني أربطها مع خدمة اسمها Amazon API Gateway. هاي الخدمة بتعطيني رابط (URL) عام على الإنترنت. أي حدا بيبعت طلب HTTP على هذا الرابط، الـ API Gateway بشكل تلقائي بستدعي وظيفة الـ Lambda تبعتي وبمرر إلها الطلب.
وهيك، صار عندي API كامل شغال بدون سيرفر واحد أديره!
النتائج على أرض الواقع: الأرقام لا تكذب! 😮
بعد ما نقلت التطبيق، راقبت الفواتير للشهر اللي بعده. النتيجة كانت صادمة (بشكل إيجابي جداً):
- التكلفة قبل (VPS): حوالي 20$ شهرياً، ثابتة.
- التكلفة بعد (AWS Lambda + API Gateway): أول شهر كانت الفاتورة 0.00$!
ليش صفر؟ لأنه AWS بتعطي طبقة مجانية (Free Tier) سخية جداً لخدمة Lambda و API Gateway. بتعطيك مليون طلب ومليون استدعاء مجاني كل شهر. تطبيقي الصغير ما كان يوصل حتى لـ 1% من هاي الحصة المجانية. حتى لو تجاوزت الحصة المجانية، التكلفة كانت رح تكون سنتات قليلة جداً.
مش بس التكلفة، أنا ارتحت من هم كبير:
- لا مزيد من التحديثات الأمنية: ما عدت أقلق من تحديث نظام التشغيل أو المكتبات. AWS بتتولى كل هاد.
- توسع تلقائي (Auto-scaling): لو فجأة صار على تطبيقي ضغط كبير وأجاني 1000 طلب في نفس الثانية، Lambda بتشغل 1000 نسخة من الكود تبعي بشكل متوازي بدون أي تدخل مني.
- التركيز على المهم: صرت أقضي كل وقتي في تحسين الكود وإضافة ميزات جديدة، بدل ما أضيعه في إدارة البنية التحتية.
هل الـ Serverless هو الحل السحري لكل شيء؟ (Spoiler: لا)
رغم كل هالحماس، مهم نكون واقعيين. الـ Serverless مش حل مناسب لكل أنواع التطبيقات. من خبرتي، هاي أفضل حالات الاستخدام:
حالات استخدام مثالية للـ Serverless
- الواجهات البرمجية (APIs): خصوصاً اللي عليها استخدام متقلب أو غير متوقع.
- مهام الخلفية (Background Jobs): مثل معالجة الصور بعد رفعها، إرسال إيميلات، تحليل بيانات.
- تطبيقات الـ “胶水” (Glue Code): كود بسيط بيربط بين خدمات سحابية مختلفة. مثلاً، وظيفة Lambda بتشتغل لما ينضاف ملف جديد على S3 وبتحفظ معلومات عنه في قاعدة بيانات DynamoDB.
- روبوتات الدردشة (Chatbots) والمساعدات الصوتية.
متى يجب أن تفكر مرتين؟
- التطبيقات ذات الحمل الثابت والعالي: لو عندك تطبيق بيستقبل عدد ضخم وثابت من الطلبات 24/7، ممكن حجز سيرفر مخصص يكون أرخص على المدى الطويل.
- المهام طويلة الأمد: وظائف Lambda الها حد أقصى للتشغيل (حالياً 15 دقيقة). لو عندك مهمة بتحتاج ساعات، الـ Serverless مش الخيار المناسب.
- مشكلة “البداية الباردة” (Cold Start): أول طلب لوظيفة كانت “نائمة” لفترة طويلة ممكن ياخد وقت أطول بشوي (أجزاء من الثانية أو ثانية) لأنه المنصة بتحتاج تجهز البيئة لتشغيل الكود. هاي المشكلة بتقل مع الاستخدام المستمر وصار في حلول كثيرة الها، بس لازم تكون على علم فيها.
نصائح عملية من دفتر أبو عمر
“فكّر بالوظائف، مش بالسيرفرات.” هذا هو التحول الذهني الأهم اللي لازم تعمله لما تنتقل لعالم الـ Serverless.
- ابدأ صغيراً: لا تحاول تحويل تطبيقك الضخم كله مرة واحدة. اختار جزء صغير وغير حرج من النظام، مثل وظيفة إرسال إشعارات، وحوّلها لـ Serverless. شوف النتائج وتعلم من التجربة.
- استخدم أطر العمل (Frameworks): أدوات مثل Serverless Framework أو AWS SAM بتسهل عليك عملية بناء ونشر وإدارة تطبيقات الـ Serverless بشكل كبير جداً. بتخليك تكتب كل إعدادات البنية التحتية في ملف واحد.
- راقب وظائفك: استخدم أدوات مثل Amazon CloudWatch لمراقبة أداء وظائفك، كم مرة تم استدعاؤها، كم استهلكت وقت، وهل في أخطاء أو لأ. المراقبة هي عينك اللي بتشوف فيها صحة تطبيقك.
- افهم التسعير جيداً: رغم إنه رخيص جداً، لازم تفهم كيف بتنحسب التكلفة (عدد الاستدعاءات + مدة التشغيل بالمللي ثانية + حجم الذاكرة المحجوزة) عشان ما تتفاجأ.
الخلاصة: ركز على الكود، ودع الباقي للسحابة
تجربتي مع الحوسبة الخادومية كانت أكثر من مجرد توفير للمال. كانت تحول في طريقة تفكيري كمهندس برمجيات. بدل ما أكون “مدير سيرفرات” نص الوقت، صرت أركز 100% من وقتي على بناء قيمة حقيقية للمستخدم من خلال الكود.
إذا كان عندك مشروع جانبي، أو تطبيق صغير، أو حتى جزء من نظام كبير استخدامه متقطع، أنا بنصحك بشدة تلقي نظرة على عالم الـ Serverless. رح تتفاجأ من كمية الوقت والمال والجهد اللي رح توفره.
جربوها، ومش رح تندموا. ويلا، شدوا حيلكم يا شباب! 💪
