AWS SAA 14 - Building Serverless Architectures

🎯 Building Serverless Architectures — بناء البنى السحابية بدون خوادم

تُعد هذه الوحدة دليلك الشامل إلى عالم البنى السحابية بدون خوادم Serverless Architectures والخدمات المصغرة Microservices على منصة Amazon Web Services (AWS). ستتعرف من خلالها على كيفية تصميم وبناء تطبيقات لا تتطلب إدارة الخوادم باستخدام AWS Lambda وAmazon API Gateway وAWS Step Functions وخدمات الحاويات. تمنحك هذه الوحدة المهارات اللازمة لبناء تطبيقات قابلة للتوسع ومرنة وفعالة من حيث التكلفة باستخدام أحدث الأنماط المعمارية السحابية.

1️⃣ What Is Serverless — ما هي البنية بدون خوادم

📖 ما المقصود بالبنية السحابية بدون خوادم (Serverless Architecture)؟
البنية بدون خوادم هي نمط معماري يمكنك من نشر التطبيقات دون الحاجة إلى التفكير في الخوادم أو حجمها. تدير AWS بيئة التشغيل بالكامل وحجم الخدمة نيابة عنك. يمكنك التركيز على منتجك الأساسي وجعل نشر التطبيقات أصغر وأسرع. فمثلاً يمكن نشر دوال AWS Lambda بنقرة واحدة في وحدة التحكم وتكون جاهزة خلال ثوانٍ. نموذج التسعير يعتمد على الاستخدام الفعلي حيث تدفع فقط مقابل ما تستخدمه، مما يلغي الحاجة للدفع مقابل خدمات لا تعمل.

📋 فوائد البنية بدون خوادم:

• لا توجد إدارة للخوادم (No server management) — AWS تدير كل شيء من نظام التشغيل إلى التصحيح الأمني.
• خدمات تدفع مقابل القيمة (Pay-for-value services) — تسعير يعتمد على حجم الاستخدام والتخزين.
• توسع مستمر (Continuous scaling) — الموارد تتوسع وتتقلص تلقائياً بناءً على حركة المرور.
• توفر عالٍ مدمج (Built-in high availability) — مخازن البيانات تعمل عبر 3 مناطق توفر.
• مناسبة للبنى المعتمدة على الأحداث (Event-driven architectures) والخدمات المصغرة.

🔑 فكرة محورية: تعتبر الخدمة "بلا خوادم" (serverless) عندما يمكنك نشر تطبيق دون التفكير في الخوادم أو حجمها. AWS تدير بيئة التشغيل بالكامل وتحديد حجم الخدمة.

على سبيل المثال شركة ناشئة تريد إطلاق تطبيق ويب بتكلفة منخفضة وبدون فريق بنية تحتية.
تستخدم AWS Lambda للحوسبة وAmazon API Gateway للواجهة وAmazon DynamoDB كقاعدة بيانات.
لا تحتاج لإدارة أي خوادم وتدفع فقط عند استخدام التطبيق، مما يبقي التكاليف شبه معدومة في المراحل الأولى.

2️⃣ Three-Tier Design Comparison — مقارنة التصميم ثلاثي الطبقات

📖 ما الفرق بين التصميم ثلاثي الطبقات التقليدي والتصميم بدون خوادم؟
في التصميم التقليدي داخل VPC تستخدم Application Load Balancer يشير إلى طبقة ويب تعمل على عدة Amazon EC2 عبر منطقتي توفر مع Auto Scaling. أما طبقة البيانات فتعتمد على Amazon RDS Multi-AZ المُدار. في التصميم بدون خوادم تستبدل الطبقات بخدمات مدارة بالكامل: Amazon CloudFront لتوزيع المحتوى الثابت من Amazon S3 وAmazon Cognito للمصادقة وAPI Gateway مع Lambda لمنطق الأعمال وDynamoDB لقاعدة البيانات. هذا يقلل الأعباء التشغيلية بشكل كبير لأن AWS تتولى مسؤولية إدارة الخوادم وتطبيق التصحيحات الأمنية والتوسع التلقائي.

📋 مقارنة المهام التشغيلية:

• تكوين خادم: مطلوب في VPC ← غير مطلوب في البنى بدون خوادم.
• تحديث نظام التشغيل: مطلوب في VPC ← غير مطلوب في البنى بدون خوادم.
• تثبيت منصة التطبيق: مطلوب في VPC ← غير مطلوب في البنى بدون خوادم.
• بناء ونشر التطبيقات: مطلوب في كلا النموذجين.
• تكوين التوسع التلقائي وموازنة الأحمال: مطلوب في VPC ← غير مطلوب في البنى بدون خوادم.
• مراقبة التطبيقات وصيانتها: مطلوب في كلا النموذجين.

على سبيل المثال مطور وحيد يريد إطلاق تطبيق ويب دون فريق دعم تقني.
في البنية التقليدية يحتاج لتكوين EC2 وLoad Balancer وAuto Scaling وتطبيق تحديثات أمنية أسبوعياً.
في البنية بدون خوادم يكتب كود Lambda فقط ويربطه بـ API Gateway وDynamoDB وكل شيء آخر تديره AWS.

3️⃣ AWS Serverless Services — خدمات AWS بدون خوادم

📖 ما هي خدمات AWS التي تتبع النموذج بدون خوادم؟
طورت AWS خدمات بدون خوادم للطبقات الثلاث لتطبيقك: الحوسبة والتكامل التطبيقي ومخازن البيانات. وهناك خدمات متخصصة للمجالات مثل التحليلات. في الحوسبة لديك AWS Lambda للدوال التي تعتمد على الأحداث وAWS Fargate للحاويات بدون خوادم مع Amazon ECS أو Amazon EKS. في التكامل التطبيقي لديك Amazon API Gateway لنشر REST وHTTP APIs وAWS AppSync لـ GraphQL APIs وAmazon SQS للرسائل وAmazon SNS للإشعارات وAWS Step Functions لتنسيق سير العمل وAmazon EventBridge للحافلات الحدثية.

📋 خدمات AWS بدون خوادم حسب الفئة:

• الحوسبة: AWS Lambda وLambda@Edge وAWS Fargate.
• التكامل التطبيقي: Amazon API Gateway وAWS AppSync وAmazon SQS وAmazon SNS وAmazon EventBridge وAWS Step Functions.
• مخازن البيانات: Amazon S3 وAmazon EFS وAmazon DynamoDB وAmazon Aurora Serverless وAmazon Redshift Serverless وAmazon OpenSearch Serverless وAmazon Neptune Serverless.
• المصادقة: Amazon Cognito.
• استضافة الويب: AWS Amplify.
• توصيل المحتوى: Amazon CloudFront.

على سبيل المثال فريق تطوير يبني تطبيقاً للتجارة الإلكترونية بالكامل بدون خوادم.
يستخدم Amplify لاستضافة الواجهة الأمامية وCognito للمصادقة وAPI Gateway مع Lambda لمنطق الأعمال وDynamoDB للتخزين وStep Functions لتنظيم سير عمل الطلبات وSNS للإشعارات.
كل هذه الخدمات مدارة بالكامل ولا تحتاج لأي إدارة خوادم.

تماماً مثل استئجار شقة مفروشة بدلاً من شراء منزل وبناءه من الصفر — Serverless يشبه الشقة المفروشة حيث تجد كل شيء جاهزاً للاستخدام فوراً.
وكما تدفع إيجار الشقة فقط عند سكنك فيها تدفع مقابل خدمات serverless فقط عند استخدامك لها.
لا تهتم بتصليح السباكة أو تغيير اللمبات — AWS تهتم بكل تفاصيل البنية التحتية.

✅ خلاصة: التفكير بدون خوادم

• البنية بدون خوادم تلغي الحاجة لإدارة الخوادم ونظام التشغيل والتصحيحات الأمنية.
• نموذج الدفع حسب الاستخدام يخفض التكاليف خاصة للشركات الناشئة والتطبيقات ذات الحركة المتغيرة.
• الخدمات بدون خوادم تتوسع تلقائياً وتتمتع بتوفر عالٍ مدمج.
• توفر AWS خدمات بدون خوادم للحوسبة والتكامل التطبيقي ومخازن البيانات والمصادقة.
• مناسبة بشكل خاص للتطبيقات المعتمدة على الأحداث (event-driven) والخدمات المصغرة (microservices).
• في التصميم بدون خوادم، مهام التشغيل الوحيدة عليك هي البناء والنشر والمراقبة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Serverless Architecture	بنية بدون خوادم	نمط معماري لا يتطلب إدارة الخوادم حيث تدير AWS بيئة التشغيل بالكامل.
Event-driven architecture (EDA)	بنية تعتمد على الأحداث	نمط حديث من خدمات صغيرة منفصلة تنشر وتستهلك الأحداث للتواصل.
AWS Fargate	Fargate	محرك حاويات بدون خوادم يعمل مع Amazon ECS وAmazon EKS.
Lambda@Edge	Lambda عند الحافة	امتداد لـ Lambda يتيح تشغيل الدوال في مواقع CloudFront الطرفية.
Amazon DynamoDB	DynamoDB	قاعدة بيانات NoSQL مدارة بالكامل بزمن استجابة بالميلي ثانية.
Amazon EventBridge	حافلة الأحداث	خدمة حافلة أحداث لتوجيه الأحداث إلى الوجهات المكونة.
Pay-for-value	ادفع مقابل القيمة	نموذج تسعير يعتمد على الاستخدام الفعلي وليس على الحجز المسبق.
AWS AppSync	AppSync	خدمة لنشر وإدارة واجهات GraphQL API بشكل بدون خوادم.

1️⃣ Microservice Characteristics — خصائص الخدمات المصغرة

📖 ما هي الخدمات المصغرة (Microservices)؟
الخدمات المصغرة هي نمط معماري يبني التطبيق كمكونات مستقلة كل منها يدير عملية معينة كخدمة منفصلة. تتواصل هذه الخدمات من خلال واجهات محددة باستخدام واجهات برمجة خفيفة APIs. كل خدمة مبنية لقدرة عمل محددة وتؤدي وظيفة واحدة فقط. ونظراً لأنها تعمل بشكل مستقل يمكن تحديث كل خدمة ونشرها وتوسيع نطاقها بشكل منفصل. تتميز الخدمات المصغرة بخاصيتين رئيسيتين: الاستقلالية (autonomous) والتخصص (specialized).

📋 خصائص الخدمات المصغرة:

• استقلالية (Autonomous): يمكن تطويرها ونشرها دون التأثير على الخدمات الأخرى وتتوسع بشكل مستقل ولا تشارك الكود مع خدمات أخرى.
• تخصص (Specialized): تؤدي وظيفة عمل واحدة وتحل مشكلة محددة ويمتلكها فريق تطوير صغير يختار أدواته بنفسه.
• عديمة الحالة (Stateless): لضمان سرعة التهيئة والتوسع. يُفضل تخزين الحالة مؤقتاً (caching state) للتعافي السريع من الأعطال.
• مخزن بيانات خاص: تملك كل خدمة قاعدة بيانات خاصة بها لتسهيل المعاملات الذرية والمتسقة والمعزولة والمتينة (ACID).

على سبيل المثال تطبيق منتدى للنقاش مبني بطريقة متجانسة (monolithic) حيث المستخدمون والمواضيع والرسائل كلها في عملية واحدة.
عند ازدياد الطلب على خاصية الرسائل يجب توسيع نطاق التطبيق بالكامل.
بعد التحويل إلى خدمات مصغرة تصبح كل من خدمة المستخدمين وخدمة المواضيع وخدمة الرسائل منفصلة تتوسع كل منها حسب احتياجها الخاص.

2️⃣ Benefits of Microservices — فوائد الخدمات المصغرة

📖 ما هي الفوائد التي تقدمها الخدمات المصغرة مقارنة بالتطبيقات المتجانسة؟
توفر الخدمات المصغرة ست فوائد رئيسية تحسن سرعة الفريق ومرونة التطبيق. تسمح بتنظيم فرق صغيرة مستقلة تمتلك خدماتها مما يقصر دورات التطوير بشكل كبير. كما تتيح إعادة استخدام الخدمات لبناء ميزات جديدة دون كتابة كود من الصفر، وتوسيع النطاق المرن لكل خدمة حسب الطلب على الميزة التي تدعمها.

📋 فوائد الخدمات المصغرة:

• سرعة الفريق (Team agility): فرق صغيرة مستقلة تعمل بشكل أسرع ضمن سياق مفهوم جيداً.
• إعادة استخدام الكود (Reusable code): يمكن استخدام الخدمة كلبنة بناء لميزات أخرى دون كتابة كود جديد.
• توسع مرن (Flexible scaling): كل خدمة تتوسع بشكل مستقل مما يسمح بقياس دقيق للتكلفة.
• حرية تقنية (Technological freedom): كل فريق يختار أفضل أداة لحل مشكلته المحددة.
• مرونة (Resilience): فشل خدمة لا يؤدي لانهيار التطبيق بالكامل بل لتدهور وظيفة محددة.
• نشر مبسط (Simplified deployment): استخدام CI/CD pipelines يسرع تجربة الأفكار الجديدة والتراجع عند الحاجة.

على سبيل المثال تطبيق التجارة الإلكترونية الكبير مقسم إلى خدمات مصغرة: خدمة المنتجات وخدمة السلة وخدمة الدفع وخدمة التوصيل.
عند موسم العروض يرتفع الطلب على خدمة المنتجات فقط فتتوسع منفردة دون بقية الخدمات.
إذا توقفت خدمة الدفع مؤقتاً يظل بإمكان العملاء تصفح المنتجات وإضافتها للسلة لحين عودة الخدمة.

3️⃣ Microservice Serverless Patterns — أنماط الخدمات المصغرة بدون خوادم

📖 ما هي أنماط الخدمات المصغرة بدون خوادم المتاحة على AWS؟
هناك ثلاثة أنماط رئيسية للحوسبة في الخدمات المصغرة بدون خوادم: واجهات RESTful APIs والحاويات (Containers) والتاريخ (Streaming). نمط RESTful APIs يستخدم Amazon API Gateway مع AWS Lambda وهو الأنسب للدوال عديمة الحالة التي لا تتجاوز 15 دقيقة. نمط الحاويات يستخدم AWS Fargate خلف Application Load Balancer وهو مناسب للخدمات التي تحتاج أكثر من 15 دقيقة لإكمال عملها. نمط التاريخ يستخدم AWS Lambda مع Amazon Kinesis لمعالجة البيانات المتدفقة بشكل مستمر.

على سبيل المثال تطبيق خدمة مصرفية يريد معالجة معاملات متعددة الأنواع.
يستخدم REST API مع Lambda للمعاملات السريعة (الاستعلام عن الرصيد).
يستخدم Fargate مع API Gateway للمعاملات الطويلة (تحويل مبلغ كبير بموافقات متعددة).
ويستخدم Lambda مع Kinesis لتحليل تدفق المعاملات واكتشاف الاحتيال فورياً.

🔑 هام: الخدمات المصغرة تعمل في طبقة التطبيق (app tier) وطبقة البيانات (data tier) ولا تمثل حلاً كاملاً للبنية ثلاثية الطبقات بذاتها.

مثل فريق مطعم حيث كل طباخ مسؤول عن طبق محدد ولا يتدخل في عمل الآخر — هكذا الخدمات المصغرة كل منها مستقل ومتخصص.
وكما لو توقف أحد الطهاة عن العمل يستمر المطعم بتقديم باقي الأطباق — هكذا فشل خدمة مصغرة لا ينهي التطبيق بأكمله.

✅ خلاصة: تصميم الخدمات المصغرة بدون خوادم

• الخدمات المصغرة هي تطبيقات مكونة من خدمات مستقلة ومتخصصة تتواصل عبر واجهات API خفيفة.
• الاستقلالية تعني القدرة على التطوير والنشر دون التأثير على الخدمات الأخرى.
• التخصص يعني أن كل خدمة تؤدي وظيفة عمل واحدة يملكها فريق صغير.
• فوائد الخدمات المصغرة تشمل سرعة الفريق وإعادة استخدام الكود والتوسع المرن والحرية التقنية.
• الأنماط المتاحة بدون خوادم: RESTful APIs والحاويات والتاريخ.
• الخدمات المصغرة تشكل جزءاً من البنية ثلاثية الطبقات في طبقة التطبيق والبيانات.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Microservices	الخدمات المصغرة	نمط معماري يبني التطبيق كمكونات مستقلة تتواصل عبر APIs خفيفة.
Monolithic application	تطبيق متجانس	تطبيق تجمع كل عملياته في خدمة واحدة مترابطة بإحكام.
Autonomous	استقلالي	خاصية تمكن الخدمة من العمل والتوسع دون التأثير على الخدمات الأخرى.
Stateless	عديم الحالة	لا يحتفظ بحالة بين الطلبات لضمان سرعة التهيئة والتوسع.
ACID transactions	معاملات ACID	مجموعة خصائص لضمان موثوقية معاملات قواعد البيانات.
CI/CD pipeline	خط أنابيب التكامل والنشر المستمر	أتمتة بناء واختبار ونشر التطبيقات لضمان السرعة والجودة.
RESTful API	واجهة REST	نمط معماري لواجهات البرمجة يعتمد على موارد عديمة الحالة.

1️⃣ AWS Lambda Overview — نظرة عامة على AWS Lambda

📖 ما هي خدمة AWS Lambda؟
AWS Lambda هي خدمة حوسبة تتيح لك تشغيل دوال برمجية دون توفير أو إدارة الخوادم. تقوم Lambda بتشغيل الكود على بنية تحتية عالية التوفر وتؤدي كل مهام إدارة موارد الحوسبة. يمكنك تكوين الدالة بلغة التشغيل المفضلة وحجم الذاكرة (من 128 ميجابايت إلى 10,240 ميجابايت) ومدة المهلة القصوى (حتى 15 دقيقة كحد أقصى صارم). تدعم Lambda نوعين من حزم النشر: صور الحاويات (container images) وأرشيفات .zip. تدفع فقط مقابل وقت الحوسبة الذي تستهلكه ولا توجد رسوم عندما لا يعمل الكود.

📋 خصائص AWS Lambda:

• تشغيل الدوال دون توفير أو إدارة الخوادم — AWS تدير كل شيء.
• تكوين مرن: لغة تشغيل وحجم ذاكرة ومدة مهلة.
• الحد الأقصى لمدة التشغيل: 15 دقيقة (حد صارم من AWS).
• نشر الدوال كصور حاويات أو أرشيفات .zip.
• توسع تلقائي: تشغل Lambda نسخاً متعددة من الدالة بالتوازي.
• تسعير حسب الاستخدام: تدفع فقط لوقت الحوسبة الذي تستهلكه.

على سبيل المثال شركة وسائط تحتاج لتحويل الفيديوهات المُرفوعة إلى صيغ متعددة.
تستخدم Lambda التي تُشغل تلقائياً عند رفع ملف فيديو إلى Amazon S3.
تستدعي الدالة خدمة تحويل وسائط ثم تخزن النتيجة في مجلد آخر في S3 — كل هذا دون أي خادم يُدار.

2️⃣ Lambda Function Location — مواقع تشغيل دوال Lambda

📖 أين يمكن تشغيل دوال Lambda؟
يمكن تشغيل دالة Lambda داخل VPC المملوكة لخدمة Lambda أو في ذاكرة تخزين مؤقت طرفية لـ Amazon CloudFront عبر Lambda@Edge. عند إنشاء دالة Lambda تنشرها في منطقة AWS حيث تريد تشغيلها. عند استدعاء الدالة يقوم Lambda بتهيئة جهاز افتراضي Firecracker microVM على خادم EC2 في VPC الخدمة. Lambda@Edge يسمح بتشغيل دوال Node.js أو Python في مواقع CloudFront الطرفية الأقرب للمستخدم لتقليل زمن الاستجابة.

على سبيل المثال متجر ملابس إلكتروني يريد عرض ألوان مختلفة لنفس المنتج حسب اختيار المستخدم.
يستخدم Lambda@Edge دالة Python في موقع CloudFront طرفي تقرأ cookie اللون المفضل.
تعدل الدالة الطلب قبل أن يصل لخادم المنشأ ليعيد صورة المنتج باللون الصحيح — مما يقلل زمن التحميل بشكل كبير.

3️⃣ Lambda Function Handler — معالج دالة Lambda

📖 ما هو معالج دالة Lambda وكيف يعمل؟
معالج الدالة (function handler) هو نقطة الدخول في كود الدالة الذي يعالج الأحداث. عند استدعاء الدالة يقوم Lambda بتشغيل معالج الدالة. يستقبل المعالج وسيطين: كائن الحدث (event object) وهو مستند JSON يحتوي بيانات الإدخال ومعلومات الخدمة المستدعية، وكائن السياق (context object) الذي يوفر خصائص ومعلومات عن بيئة التشغيل. من أفضل الممارسات الحفاظ على معالج الدالة صغيراً ووضع منطق الأعمال في دوال منفصلة لتقليل زمن التحميل.

على سبيل المثال دالة Lambda تحسب مساحة غرفة باستخدام الطول والعرض المُرسلين عبر API.
المعالج يستخرج الطول والعرض من كائن الحدث ثم يستدعي دالة calculate_area المنفصلة.
يعيد النتيجة كمستند JSON — هذا الفصل بين المعالج ومنطق الأعمال يجعل الكود أنظف وأسرع تحميلاً.

4️⃣ Lambda Layers — طبقات Lambda

📖 ما هي طبقات Lambda وما فائدتها؟
طبقة Lambda هي أرشيف .zip يحتوي كوداً تكميلياً مثل مكتبات التبعيات أو بيئة تشغيل مخصصة أو ملفات إعدادات. يمكن تطبيق الطبقة على أي عدد من الدوال في حسابك. تقليل حجم حزمة النشر: بدلاً من تضمين كل التبعيات مع كود الدالة تضعها في طبقة منفصلة مما يبقي الحزم صغيرة ومنظمة. فصل منطق الدالة الأساسي عن التبعيات: يسمح بتحديث التبعيات بشكل مستقل عن كود الدالة والعكس. ومشاركة التبعيات عبر دوال متعددة دون تكرارها في كل حزمة نشر.

📋 فوائد استخدام طبقات Lambda:

• تقليل حجم حزم النشر بإخراج التبعيات إلى طبقة منفصلة.
• فصل منطق الدالة الأساسي عن التبعيات لتحديث كل منهما بشكل مستقل.
• مشاركة التبعيات عبر دوال متعددة في الحساب دون تكرار.
• تمكين استخدام محرر كود Lambda عندما يكون حجم الحزمة صغيراً بما يكفي.

على سبيل المثال شركة لديها 10 دوال Lambda تستخدم كلها مكتبة Pandas لتحليل البيانات.
بدلاً من تضمين Pandas في كل دالة على حدة تنشئ طبقة واحدة تحتوي المكتبة وتطبقها على جميع الدوال.
عند تحديث المكتبة تغير الطبقة مرة واحدة وتصبح جميع الدوال محدثة تلقائياً.

5️⃣ Lambda Invocation Modes — أنماط استدعاء Lambda

📖 ما هي الأنماط المختلفة لاستدعاء دوال Lambda؟
تدعم Lambda ثلاثة أنماط رئيسية للاستدعاء: المتزامن (synchronous) وغير المتزامن (asynchronous) والتاريخ (streaming). الاستدعاء المتزامن: يقدم الطالب طلباً وينتظر رداً خلال فترة زمنية محددة. مثال شائع هو تطبيقات الويب عبر API Gateway أو عناوين Lambda Function URL. الاستدعاء غير المتزامن: يقدم الطالب طلباً ولا ينتظر رداً. تضع Lambda الحدث في طابور وتعيد استجابة نجاح بدون معلومات إضافية. استدعاء التاريخ: يتم عبر تعيين مصدر حدث (event source mapping) حيث تقرأ Lambda من تيار بيانات مثل DynamoDB Streams أو Kinesis أو SQS.

على سبيل المثال تطبيق متجر إلكتروني يستخدم أنماط الاستدعاء الثلاثة معاً:
استدعاء متزامن عبر API Gateway عند إضافة منتج إلى سلة التسوق.
استدعاء غير متزامن عند معالجة الدفع حيث توضع رسالة في SQS وتعالجها Lambda لاحقاً.
استدعاء تاريخ عبر DynamoDB Streams لتسجيل كل تغيير في حالة الطلب لإرسال إشعارات للعميل.

💡 مقارنة أنماط استدعاء Lambda:

النمط	الوصف	متى يُستخدم
متزامن (Synchronous)	يطلب ويستجيب فوراً	تطبيقات الويب والخدمات المصغرة واستدلالات ML
غير متزامن (Asynchronous)	يضع في طابور ويعيد استجابة نجاح	أحداث مجدولة ومعالجة الصور وتحويل الملفات
تيار (Streaming)	يقرأ من تيار بيانات ويُعالج دفعات	تطبيقات التدفق وتحليلات البيانات في الوقت الفعلي

✅ خلاصة: بناء البنى بدون خوادم باستخدام AWS Lambda

• AWS Lambda هي خدمة حوسبة بدون خوادم تدير AWS كل جوانب البنية التحتية لها.
• يمكن تشغيل الدوال داخل VPC الخدمة أو عند الحافة عبر Lambda@Edge.
• يمكن ربط الدالة بشبكة VPC خاصة بك للوصول لخدمات داخل الشبكة.
• تدعم ثلاثة أنماط استدعاء: متزامن وغير متزامن والتاريخ عبر تعيين مصادر الأحداث.
• استخدم طبقات Lambda لحزم التبعيات وبيئات التشغيل المخصصة لإعادة استخدامها عبر الدوال.
• أفضل ممارسة: إبقاء معالج الدالة صغيراً وفصل منطق الأعمال في دوال منفصلة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
AWS Lambda	Lambda	خدمة حوسبة بدون خوادم لتشغيل الدوال دون إدارة الخوادم.
Lambda Layer	طبقة Lambda	أرشيف .zip يحتوي تبعيات أو بيئات تشغيل مخصصة لإعادة الاستخدام.
Event Source Mapping	تعيين مصدر الحدث	مورد Lambda يقرأ من مصدر أحداث ويستدعي دالة Lambda.
Firecracker microVM	الجهاز الافتراضي الدقيق	تقنية من AWS لإنشاء أجهزة افتراضية دقيقة في أقل من ثانية.
Lambda Function URL	رابط دالة Lambda	نقطة نهاية HTTPS مخصصة ومولدة تلقائياً لدالة Lambda.
Context Object	كائن السياق	كائن يمرر لمعالج الدالة يوفر معلومات عن بيئة التشغيل والاستدعاء.
Hyperplane ENI	واجهة الشبكة Hyperplane	واجهة شبكة مُدارة تربط دالة Lambda بشبكة VPC خاصة.

1️⃣ Containers in AWS — الحاويات في AWS

📖 ما هي الحاويات (Containers) وكيف تستخدمها AWS للخدمات المصغرة؟
الحاوية هي طريقة لتغليف التطبيق وتبعياته (المكتبات وملفات الإعدادات ونظام التشغيل) معاً لتشغيله بشكل متسق عبر أي بيئة. الحاويات أخف وزناً من الأجهزة الافتراضية التقليدية. تقدم AWS خيارات حاويات مُدارة بالكامل: Amazon Elastic Container Service (ECS) وهو خدمة حاويات أصلية من AWS وAmazon Elastic Kubernetes Service (EKS) وهو Kubernetes مُدار. AWS Fargate هو محرك حاويات بدون خوادم يتيح تشغيل الحاويات دون إدارة الخوادم أو مجموعات الحاويات. يمكنك استخدامه مع كل من ECS وEKS.

📋 خيارات الحاويات في AWS:

• Amazon ECS: خدمة حاويات أصلية عالية الأداء ومدارة بالكامل من AWS.
• Amazon EKS: Kubernetes مُدار يتيح تشغيل أحمال العمل الحاوية مع التوافق مع معايير CNCF.
• AWS Fargate: محرك حاويات بدون خوادم يلغي الحاجة لإدارة البنية التحتية للحاويات.
• Amazon ECR: مستودع صور حاويات آمن ومُدار لتخزين واسترجاع صور الحاويات.

على سبيل المثال فريق يطور تطبيق خدمات مصغرة يحتاج لبيئة تشغيل متسقة بين أجهزة المطورين وبيئة الإنتاج.
يستخدم Docker لتغليف كل خدمة مصغرة في حاوية منفصلة ثم ينشرها على Amazon ECS مع Fargate.
كل حاوية تعمل بشكل معزول مع مواردها الخاصة وتتوسع حسب الطلب دون إدارة أي خوادم.

2️⃣ Image vs Container — الفرق بين الصورة والحاوية

📖 ما الفرق بين صورة الحاوية (Container Image) والحاوية (Container)؟
صورة الحاوية هي قالب ثابت قابل للتنفيذ يحتوي تعليمات لإنشاء حاوية. تتضمن نظام تشغيل وتطبيقاً وكوداً وتبعيات ومكتبات وملفات إعدادات ومتغيرات بيئة. الحاوية هي نسخة قابلة للتشغيل من الصورة يتم إنشاؤها في وقت التشغيل. يمكن أن يكون لديك عدة حاويات تعمل من نفس الصورة في آن واحد. يمكن تخزين الصور في Amazon Elastic Container Registry (ECR) أو مستودعات خارجية مثل Docker Hub.

على سبيل المثال مطور يبني تطبيق Node.js للخدمات المصغرة.
ينشئ Dockerfile يحدد صورة القاعدة (مثل node:18) وينسخ الكود ويحدد أمر التشغيل.
يبني الصورة ويرفعها إلى Amazon ECR ثم ينشر حاويات متعددة من نفس الصورة على ECS — كل حاوية تتعامل مع مجموعة مختلفة من الطلبات.

3️⃣ Container Orchestration — تنسيق الحاويات

📖 كيف تدير AWS تنسيق الحاويات للخدمات المصغرة؟
عندما يكون لديك عدة خدمات مصغرة تعمل في حاويات متعددة تحتاج أداة تنسيق (orchestrator) لإدارة نشر هذه الحاويات وتوسيعها ومراقبتها. Amazon ECS هو المُنسّق الأصلي من AWS ويدير دورة حياة الحاويات عبر task definitions وservices. يمكنك تعريف مهمة (task) تحدد صورة الحاوية والذاكرة ووحدة المعالجة وعدد النسخ. Amazon EKS هو Kubernetes مُدار يتيح استخدام بيئة Kubernetes القياسية مع التكامل مع خدمات AWS مثل ALB وIAM وVPC.

على سبيل المثال منصة SaaS تدير 15 خدمة مصغرة (مستخدمين ومدفوعات وإشعارات وتحليلات...).
تستخدم Amazon ECS مع Fargate لتعريف كل خدمة كمهمة منفصلة بصورتها الخاصة.
عند ازدياد الطلب على خدمة المستخدمين يتوسع ECS تلقائياً بعدد نسخ أكبر من حاويات تلك الخدمة فقط.

🔑 اختيار الأداة المناسبة: استخدم ECS إذا كنت تفضل البساطة والتكامل العميق مع AWS. استخدم EKS إذا كنت بحاجة لتوافق Kubernetes القياسي أو تنقل أحمال العمل بين السحابات (multi-cloud).

صورة الحاوية مثل وصفة طبخ: القائمة الثابتة للمكونات والتعليمات. والحاوية مثل الوجبة الجاهزة المصنوعة من تلك الوصفة.
وكما يمكن لمطعم تحضير 100 وجبة من نفس الوصفة يمكن تشغيل مئات الحاويات من نفس الصورة في آن واحد.

✅ خلاصة: بناء تطبيقات الخدمات المصغرة بحاويات AWS

• الحاويات تغلف التطبيق وتبعياته في وحدة واحدة متسقة عبر أي بيئة تشغيل.
• Amazon ECS وAmazon EKS هما خيارا تنسيق الحاويات المُدارة في AWS.
• AWS Fargate يوفر حاويات بدون خوادم تلغي الحاجة لإدارة البنية التحتية.
• صورة الحاوية هي قالب ثابت والحاوية هي نسخة قابلة للتشغيل من الصورة.
• Amazon ECR هو مستودع صور آمن ومُدار لتخزين الصور.
• اختر ECS للبساطة أو EKS لتوافق Kubernetes القياسي.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Container	حاوية	وحدة برمجية تغلف التطبيق وتبعياته لتشغيله بشكل متسق عبر البيئات.
Amazon ECS	ECS	خدمة حاويات مُدارة أصلية من AWS عالية الأداء.
Amazon EKS	EKS	خدمة Kubernetes مُدارة من AWS.
AWS Fargate	Fargate	محرك حاويات بدون خوادم يعمل مع ECS وEKS.
Amazon ECR	ECR	مستودع صور حاويات آمن ومُدار بالكامل.
Task Definition	تعريف المهمة	ملف JSON يحدد صورة الحاوية والموارد وإعدادات المهمة في ECS.
Container Image	صورة الحاوية	قالب ثابت قابل للتنفيذ يحتوي تعليمات إنشاء الحاوية.

1️⃣ AWS Step Functions Overview — نظرة عامة على AWS Step Functions

📖 ما هي خدمة AWS Step Functions؟
AWS Step Functions هي خدمة تنسيق بدون خوادم (serverless orchestration service) تسمح بدمج خدمات AWS المتعددة في سير عمل (workflow) يسمى آلة الحالة (state machine). تستخدم آلات الحالة في Step Functions كلما احتجت سير عمل. تشمل حالات الاستخدام: تنسيق الخدمات المصغرة ومعالجة البيانات والتعلم الآلي وأتمتة الأمن. توفر Step Functions قابلية التوسع والموثوقية والتوفر اللازمة لإدارة سير عمل معالجة البيانات. يمكن إدارة ملايين التنفيذات المتزامنة لأنها تتوسع أفقياً وتوفر سير عمل متسامح مع الأعطال.

📋 أنواع سير العمل في Step Functions:

• سير العمل القياسي (Standard Workflows): للمهام طويلة الأمد. يُحسب بناءً على عدد انتقالات الحالة.
• سير العمل السريع التزامني (Synchronous Express Workflows): للمهام قصيرة الأمد عالية الحجم التي تتطلب استجابة فورية. مناسب لتطبيقات الويب والجوال.
• سير العمل السريع غير التزامني (Asynchronous Express Workflows): للمهام قصيرة الأمد التي لا تحتاج استجابة فورية.

على سبيل المثال موقع تجارة إلكترونية يحتاج سير عمل لمعالجة الطلب من الاستلام إلى التوصيل.
يستخدم Step Functions Standard Workflow لتنسيق Lambda للتحقق من المخزون وSQS للطلب وSNS للإشعارات.
عند نجاح الدفع ينتقل السير عمل تلقائياً إلى مرحلة التوصيل وعند الفشل يرسل إشعار إلغاء.

2️⃣ State Machine State Types — أنواع حالات آلة الحالة

📖 ما هي أنواع الحالات (states) في آلة الحالة؟
تصنف حالات آلة الحالة إلى ثلاث مجموعات: حالات العمل (work states) وحالات الانتقال (transition states) وحالات الإيقاف (stop states). حالات العمل تشمل: Task (وحدة عمل تتكامل مع خدمات AWS) وActivity (مهمة مستضافة في أي مكان) وPass (تمرير أو تصفية بيانات الإدخال) وWait (تأخير سير العمل لمدة محددة). حالات الانتقال تشمل: Choice (شروط للتحكم بتدفق التنفيذ) وParallel (فروع متوازية من آلات الحالة المتداخلة) وMap (فصل سير العمل لكل سجل بيانات). حالات الإيقاف تشمل: Success (إيقاف وتسجيل نجاح) وFail (إيقاف وتسجيل فشل) ومعامل End (إيقاف آلة الحالة).

📋 أنواع الحالات بالتفصيل:

• Task: يؤدي وحدة عمل تتكامل مع خدمة AWS أو يستدعي نقطة نهاية HTTP.
• Activity: مهمة يؤديها عامل (worker) يمكن استضافته في أي مكان (EC2 أو Lambda أو جهاز محمول).
• Pass: يمرر المدخلات إلى المخرجات دون عمل. مفيد لبناء وتصحيح آلات الحالة.
• Wait: يؤخر سير العمل لوقت محدد (نسبي بالثواني أو مطلق كطابع زمني).
• Choice: يضيف منطقاً شرطياً لتحديد الحالة التالية بناءً على قواعد مقارنة.
• Parallel: يضيف فروعاً متوازية من آلات حالة متداخلة تعمل في آن واحد.
• Map: يشغل سير عمل لكل عنصر في مجموعة بيانات بالتوازي (JSON array أو S3 objects أو CSV).
• Success / Fail: يوقف آلة الحالة ويسجل نجاحاً أو فشلاً.

على سبيل المثال سير عمل لمعالجة طلب شراء أسهم:
حالة Task تستدعي Lambda لحساب قيمة الصفقة ثم حالة Choice تتحقق هل تتجاوز 100$؟
إذا نعم → حالة Task ترسل بريداً لطلب موافقة بشرية عبر SNS ← حالة Choice للتحقق من الموافقة.
إذا تمت الموافقة → Task لتنفيذ الصفقة ← إما Success أو Fail.

3️⃣ Amazon States Language — لغة Amazon States

📖 ما هي لغة Amazon States Language (ASL)؟
Amazon States Language هي لغة منظمة قائمة على JSON تُستخدم لتعريف آلة الحالة ومجموعة الحالات في Step Functions. تستخدم آلة الحالة أزواج المفتاح-القيمة لتحديد الحقول والقيم وتحدد دائماً الحالة التي يتم تشغيلها أولاً عبر حقل StartAt. حقل States يحتوي مجموعة من مستندات JSON المتداخلة التي تحدد الحالات في آلة الحالة. كل حالة لها اسم كمعرف ونوع في حقل Type. تستخدم الحالات حقلاً Next لتمرير التحكم للحالة التالية. الحالة الأخيرة تستخدم حقل End أو حالة Success أو Fail لإنهاء آلة الحالة.

على سبيل المثال آلة حالة بسيطة من حالتين:
الحالة الأولى من نوع Task تستدعي دالة Lambda وتحوي Next: "2 Success state".
الحالة الثانية من نوع Succeed تنهي آلة الحالة.
حقل StartAt يشير إلى الحالة الأولى ليبدأ التنفيذ منها.

✅ خلاصة: تنسيق الخدمات المصغرة باستخدام AWS Step Functions

• AWS Step Functions هي خدمة تنسيق بدون خوادم لإدارة سير العمل بين خدمات AWS.
• آلة الحالة (state machine) هي سلسلة من الحالات التي تعتمد على الأحداث.
• تصنف الحالات إلى: حالات العمل وحالات الانتقال وحالات الإيقاف.
• حالة Task يمكنها استدعاء خدمة AWS أو طلب نشاط مستضاف على أي خدمة حوسبة.
• Amazon States Language هي لغة JSON لتعريف آلات الحالة.
• أنواع سير العمل: قياسي (طويل) وسريع تزامني (قصير مع استجابة) وسريع غير تزامني (قصير بدون استجابة).

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
AWS Step Functions	Step Functions	خدمة تنسيق بدون خوادم لإدارة سير العمل بين خدمات AWS.
State Machine	آلة الحالة	سلسلة من الحالات التي تعتمد على الأحداث تشكل سير عمل.
Amazon States Language	لغة Amazon States	لغة JSON هيكلية لتعريف آلات الحالة في Step Functions.
Standard Workflow	سير عمل قياسي	سير عمل طويل الأمد يُحسب بعدد انتقالات الحالة.
Express Workflow	سير عمل سريع	سير عمل قصير عالي الحجم يُحسب بعدد الطلبات ومدته.
Task State	حالة مهمة	حالة تؤدي وحدة عمل وتتكامل مع خدمة AWS أو HTTP.
Choice State	حالة اختيار	حالة تضيف منطقاً شرطياً لتحديد مسار التنفيذ التالي.
Map State	حالة خريطة	حالة تشغل سير عمل لكل عنصر في مجموعة بيانات بالتوازي.

1️⃣ Benefits of APIs — فوائد واجهات البرمجة

📖 لماذا تعتبر واجهات البرمجة (APIs) ممارسة مثلى للخدمات المصغرة؟
تعمل واجهات البرمجة كجسر أو وسيط لربط التطبيقات المكتوبة بلغات مختلفة بأنواع بيانات مختلفة. توفر APIs توثيقاً يشرح كيفية استخدامها وكيفية تنسيق الطلب بشكل صحيح. الفائدة الأساسية هي أن التطبيق الطالب لا يحتاج لفهم تعقيد أو تفاصيل تنفيذ الخدمة المصغرة. APIs تخفي تعقيد التنفيذ خلف واجهة بسيطة وموحدة. كما توفر APIs حماية للخدمات المصغرة عبر آليات التوثيق والتحقق من تنسيق الطلب وتحديد معدل الطلبات (throttling) وتقييد الوصول للموارد.

📋 فوائد APIs للخدمات المصغرة:

• توحيد التواصل: ربط تطبيقات بلغات مختلفة بطريقة موحدة وإخفاء تعقيد التنفيذ.
• حماية الخدمات المصغرة: اختيار اشتراط التوثيق أم لا والتحقق من تنسيق الطلبات وتحديد عدد الطلبات والتحكم بالوصول للموارد.
• تحقيق الدخل والتتبع: تتبع استخدام العميل لأغراض الفوترة وتقديم إحصائيات الاستخدام لكل عميل.
• تخزين مؤقت للردود: يمكن تخزين الردود الشائعة مؤقتاً لتقليل زمن الاستجابة وعدد الطلبات للخدمة الخلفية.

على سبيل المثال تطبيق جوّال لشركة توصيل طعام يتصل بخدمة مصغرة للطلبات.
يستخدم API GET /orders لجلب الطلبات و POST /orders لإنشاء طلب جديد.
التطبيق لا يعرف إذا كانت الخدمة مكتوبة بـ Python أو Java أو تعمل على Lambda أو ECS — فقط يرسل الطلب عبر API الموثّق ويستلم الرد.

2️⃣ Amazon API Gateway Overview — نظرة عامة على Amazon API Gateway

📖 ما هي خدمة Amazon API Gateway؟
Amazon API Gateway هي خدمة مُدارة بالكامل تمكّنك من إنشاء ونشر ومراقبة وتأمين واجهات البرمجة (APIs) بأي حجم. يمكنك استخدامها لإنشاء واجهات RESTful وWebSocket APIs تعمل كنقطة دخول للتطبيقات للوصول إلى الموارد الخلفية. الموارد الخلفية يمكن أن تكون تطبيقات على EC2 أو دوال Lambda أو حاويات ECS أو تطبيقات خاصة في VPC أو نقاط نهاية عامة. تدير API Gateway كل المهام المتعلقة بقبول ومعالجة مئات الآلاف من الطلبات المتزامنة وتوفر ميزات إدارة حركة المرور والتوثيق والتحكم بالوصول وإدارة إصدارات API.

📋 ميزات Amazon API Gateway:

• إنشاء ونشر وصيانة واجهات REST وHTTP وWebSocket APIs.
• إدارة حركة المرور والتوثيق والتحكم بالوصول إلى الموارد بشكل قابل للتكوين.
• الوصول إلى خدمات AWS ونقاط النهاية العامة.
• استضافة إصدارات ومراحل متعددة من API التطبيق.
• إنشاء خطط استخدام للعملاء لتحقيق الدخل والتحكم في واجهات API.
• تخزين الردود الشائعة مؤقتاً (API caching) لتحسين الأداء.
• التكامل مع Amazon Cognito للتوثيق وإمكانية إضافة دوال Lambda لحلول توثيق مخصصة.

على سبيل المثال تطبيق تحليلات في الوقت الفعلي يستقبل آلاف الطلبات في الثانية.
يستخدم API Gateway مع Lambda حيث يستقبل API Gateway الطلبات ويتحقق من صحتها ويرسلها لـ Lambda للمعالجة.
مع تمكين التخزين المؤقت (caching) تقل الطلبات للخدمة الخلفية بنسبة 60% مع تحسين زمن الاستجابة.

3️⃣ Choosing an API Type — اختيار نوع API المناسب

📖 ما هي أنواع API التي تدعمها Amazon API Gateway؟
تقدم Amazon API Gateway خيارين لواجهات RESTful APIs (واجهات HTTP APIs وREST APIs) وخياراً لواجهات WebSocket APIs. واجهات REST APIs تقدم مجموعة واسعة من ميزات إدارة API مثل خطط الاستخدام والتحقق من صحة الحمولة ونقاط النهاية الخاصة وسياسات الموارد. وهي مناسبة عندما تحتاج تحكماً كاملاً. واجهات HTTP APIs محسّنة للبنى بدون خوادم وتتميز بزمن استجابة أقل وتكلفة أقل. وهي مثالية للخدمات المصغرة باستخدام Lambda وحاويات ECS. واجهات WebSocket APIs تحافظ على اتصال دائم بين العميل والخادم لتمكين التواصل الفوري في الوقت الفعلي مثل تطبيقات الدردشة.

💡 مقارنة أنواع API Gateway:

النوع	الوصف	حالات الاستخدام
REST APIs	مجموعة كاملة من ميزات إدارة API وتحكم كامل	تطبيقات تحتاج خطط استخدام وتحقق من الحمولة ونقاط نهاية خاصة
HTTP APIs	خفيفة الوزن بزمن استجابة أقل وتكلفة أقل	الخدمات المصغرة بدون خوادم مع Lambda وECS
WebSocket APIs	اتصال دائم بين العميل والخادم	تطبيقات الوقت الفعلي مثل الدردشة والألعاب متعددة اللاعبين

كل من REST APIs وHTTP APIs تدعم CORS (Cross-Origin Resource Sharing) المطلوبة عادة لبناء تطبيقات ويب تصل إلى APIs مستضافة على نطاق مختلف.

على سبيل المثال شركة تطور ثلاثة أنواع من التطبيقات:
تطبيق ويب يحتاج خطط استخدام للعملاء ← تستخدم REST API لإدارة المفاتيح والحدود.
تطبيق خدمات مصغرة داخل الشركة ← تستخدم HTTP API لخفة الوزن والسرعة.
تطبيق دردشة فورية ← تستخدم WebSocket API للاتصال الدائم ثنائي الاتجاه.

4️⃣ API Gateway Backend Integrations — تكاملات API Gateway الخلفية

📖 كيف تتكامل API Gateway مع الخدمات الخلفية؟
تدعم API Gateway ثلاثة أنواع رئيسية من التكاملات الخلفية: تكامل Lambda وتكامل وكيل HTTP والتكامل المباشر مع خدمات AWS. تكامل Lambda هو الأنمط الأكثر شيوعاً للبنى بدون خوادم حيث تستدعي API Gateway دالة Lambda لتنفيذ منطق الأعمال. تكامل وكيل HTTP يسمح بربط مسار API بنقطة نهاية HTTP عامة حيث تمرر API Gateway الطلب والاستجابة بالكامل. التكامل المباشر مع خدمات AWS يتيح ربط مسار API مباشرة بخدمة AWS مثل إرسال رسالة إلى SQS أو بدء آلة حالة Step Functions.

📋 أنماط التكامل الخلفي:

• تكامل Lambda: API Gateway تستدعي دالة Lambda لتنفيذ منطق الأعمال.
• وكيل HTTP: API Gateway تمرر الطلب والاستجابة بالكامل إلى نقطة نهاية HTTP عامة.
• تكامل مباشر مع خدمات AWS: ربط مسار API مباشرة بخدمة AWS مثل SQS أو Step Functions.
• VPC Link: الوصول إلى Network Load Balancer أو Application Load Balancer داخل VPC للوصول لخدمات خاصة.

على سبيل المثال تحليل تطبيق متجر إلكتروني متجانس إلى خدمات مصغرة:
خدمة سلة التسوق تستخدم HTTP API مع Lambda وDynamoDB للمعاملات السريعة بالميلي ثانية.
خدمة الدفع تستخدم HTTP API مع ALB وECS لأنظمة الدفع المبنية على حاويات مع تغييرات كود ضئيلة.
خدمة التوصيل تستخدم HTTP API مع Step Functions Standard Workflow لأنها عملية طويلة قد تستغرق أياماً مع استدعاء.

✅ خلاصة: توسيع البنى بدون خوادم باستخدام Amazon API Gateway

• Amazon API Gateway تتيح إنشاء ونشر وصيانة واجهات APIs للتطبيقات.
• توفر الوصول إلى خدمات AWS ونقاط النهاية العامة.
• استخدم REST APIs عندما تحتاج إدارة وتحكماً كاملين في API.
• استخدم HTTP APIs عندما تحتاج زمن استجابة وتكلفة أقل للخدمات المصغرة.
• استخدم WebSocket APIs للتطبيقات الفورية التي تحتاج اتصالاً نشطاً.
• تدعم التكامل مع Lambda ووكيل HTTP والتكامل المباشر مع خدمات AWS و VPC Link.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon API Gateway	API Gateway	خدمة مُدارة لإنشاء ونشر ومراقبة وتأمين واجهات APIs بأي حجم.
REST API	واجهة REST	واجهة APIs كاملة الميزات مع خطط استخدام وتحقق من الحمولة وسياسات موارد.
HTTP API	واجهة HTTP	واجهة APIs خفيفة محسّنة للبنى بدون خوادم بزمن استجابة منخفض.
WebSocket API	واجهة WebSocket	واجهة APIs تحافظ على اتصال دائم للتواصل الفوري ثنائي الاتجاه.
CORS	مشاركة الموارد عبر الأصول	آلية أمنية تسمح لتطبيقات الويب بالوصول لـ APIs من نطاقات مختلفة.
VPC Link	رابط VPC	يتيح لـ API Gateway الوصول إلى الموارد داخل VPC عبر NLB أو ALB.
Usage Plan	خطة الاستخدام	تعلن حدود الطلبات وتحديد المعدل لمطوري الطرف الثالث مع مفاتيح API.
API Caching	تخزين API المؤقت	تخزين ردود الـ API مؤقتاً لتقليل عدد الطلبات للخدمة الخلفية وتحسين الأداء.

1️⃣ Failure Management — إدارة الأعطال

📖 ما هي أفضل ممارسات إدارة الأعطال في التطبيقات بدون خوادم؟
تتكون التطبيقات بدون خوادم من استدعاءات غير متزامنة لمكونات متعددة. عندما تفشل هذه الاستدعاءات يجب التقاطها وإعادة المحاولة كلما أمكن لمنع فقدان البيانات وتدهور تجربة العميل. استخدام آلية طابور الرسائل الميتة (dead-letter queue): تسمح AWS Lambda بإرسال المعاملات الفاشلة إلى طابور Amazon SQS مخصص للرسائل الميتة لكل دالة على حدة. تراجع المعاملات الفاشلة: للأجزاء المتزامنة التي تعتمد على ضمانات معينة يمكن استخدام آلات حالة AWS Step Functions لفصل وتبسيط منطق التراجع.

على سبيل المثال تطبيق معالجة طلبات يتلقى آلاف الطلبات يومياً عبر Lambda.
عند فشل معالجة طلب معين ترسله Lambda تلقائياً إلى طابور SQS dead-letter للرسائل الميتة.
فريق التطوير يراجع الطابور يومياً ويحقق في سبب الفشل ويعيد معالجة الطلبات بعد التصحيح دون فقدان أي بيانات.

2️⃣ Identity and Access Management — إدارة الهوية والوصول

📖 كيف تتحكم بالوصول إلى تطبيقات serverless؟
واجهات API غالباً ما تكون هدفاً للمهاجمين بسبب العمليات التي تؤديها والبيانات القيمة التي تصل إليها. هناك عدة آليات للدفاع. التحكم بالوصول إلى API: يمكن استخدام Amazon Cognito أو Lambda authorizer أو سياسات موارد API Gateway لتوثيق الطلبات. إدارة الحدود الأمنية للتطبيق: لدوال Lambda يُوصى باتباع مبدأ الامتياز الأقل (least-privileged access) وإعطاء الدالة فقط الصلاحيات اللازمة لأداء مهمتها.

على سبيل المثال تطبيق مصرفي يستخدم API Gateway مع Cognito للتوثيق.
دالة Lambda للاستعلام عن الرصيد تملك فقط صلاحية القراءة من DynamoDB.
دالة تحويل الأموال تملك صلاحية الكتابة فقط ولا يمكنها قراءة أرصدة العملاء الآخرين. هذا يضمن الأمان حتى لو اخترقت إحدى الدوال.

3️⃣ Data Protection — حماية البيانات

📖 كيف تحمي البيانات في التطبيقات بدون خوادم؟
يجب تشفير البيانات الحساسة أثناء النقل (in transit) وأثناء التخزين (at rest) في جميع الطبقات الممكنة. تشفير البيانات أثناء النقل: البيانات الحساسة يجب تشفيرها من جهة العميل قبل إرسالها كجزء من طلب HTTP أو إرسالها كحمولة في طلب POST. تشفير البيانات أثناء التخزين: دوال Lambda يجب أن تخزن البيانات المشفرة في DynamoDB أو S3 مع تشفير عند التخزين. أمان التطبيق: التحقق من صحة الأحداث الواردة وتنقيتها وإجراء مراجعة أمنية للكود كما في التطبيقات التقليدية.

على سبيل المثال موقع e-commerce يتعامل مع بيانات بطاقات الائتمان.
يُشفر العميل رقم البطاقة من المتصفح قبل إرسال طلب POST إلى API Gateway.
دالة Lambda تخزن البيانات مشفرة في DynamoDB مع تشفير AWS KMS عند التخزين.
حتى لو تم اعتراض الطلب أو اختراق قاعدة البيانات تبقى البيانات غير قابلة للقراءة.

4️⃣ Performance Optimization — تحسين الأداء

📖 كيف تحسن أداء التطبيق بدون خوادم؟
لأن مكونات التطبيق بدون خوادم تتوسع بمعدلات مختلفة من المهم ضمان الأداء الأمثل عبر اختبار التطبيق بطرق متنوعة. مع Amazon API Gateway: استخدم نقاط النهاية الطرفية (edge endpoints) للعملاء الموزعين جغرافياً ونقاط النهاية الإقليمية للعملاء المحليين. مع AWS Lambda: اختبر إعدادات الذاكرة المختلفة لأن وحدة المعالجة والشبكة والـ IOPS تُخصص بشكل نسبي مع زيادة الذاكرة. مع AWS Step Functions: اختبر سير العمل القياسي والسريع ولاحظ معدلات بدء التنفيذ وانتقال الحالة في الثانية.

على سبيل المثال فريق يواجه بطئاً في استجابة دالة Lambda.
يختبر إعدادات ذاكرة مختلفة: 512MB ثم 1024MB ثم 2048MB.
يكتشف أن زيادة الذاكرة من 512MB إلى 1024MB يسرع الدالة 3 مرات لأن Lambda تخصص وحدة معالجة نسبياً مع الذاكرة — والتكلفة الإضافية ضئيلة مقارنة بتحسين الأداء.

5️⃣ Cost Optimization — تحسين التكلفة

📖 كيف تحسن تكلفة التطبيقات بدون خوادم؟
البنى بدون خوادم أسهل في الإدارة من حيث تخصيص الموارد الصحيح. بفضل نموذج الدفع حسب القيمة والتوسع حسب الطلب تقلل البنى بدون خوادم جهد تخطيط السعة بشكل فعال. نظراً لأن Lambda تخصص وحدة المعالجة والشبكة والـ IOPS بشكل نسبي بناءً على الذاكرة، كلما كانت الدالة أسرع كلما كانت أرخص وأكثر قيمة بسبب الفوترة بالمللي ثانية.

على سبيل المثال شركة ناشئة كانت تدفع 300$ شهرياً لخادم EC2 يعمل 24/7 لمعالجة طلبات API.
بعد التحويل إلى Lambda + API Gateway أصبحت تدفع 15$ شهرياً فقط.
التوفير يأتي لأن Lambda تعمل فقط عند وجود طلبات (ربما 4 ساعات نشاط يومياً) ولا تدفع شيء عندما لا يعمل التطبيق.

6️⃣ Optimizing Over Time — التحسين المستمر

📖 كيف تحسن تطبيقك بدون خوادم مع الوقت؟
استخدم تكاملات AWS المباشرة حيثما أمكن. إذا كانت دالة Lambda لا تؤدي منطقاً مخصصاً أثناء التكامل مع خدمات AWS أخرى فقد تكون غير ضرورية. خدمات مثل API Gateway وStep Functions وEventBridge وLambda Destinations يمكنها التكامل مباشرة مع العديد من الخدمات وتوفر قيمة أكبر وعبء تشغيلي أقل. مثال: بدلاً من استخدام API Gateway ← Lambda ← Kinesis Data Firehose ← S3، يمكن إرسال بيانات clickstream مباشرة من العميل إلى Kinesis Data Firehose مما يوفر تكلفة API Gateway وLambda.

على سبيل المثال تطبيق تحليلات كان يستخدم مساراً معقداً: العميل → API Gateway → Lambda → Kinesis → S3.
بعد المراجعة اكتشف الفريق أن دالة Lambda لا تؤدي أي منطق سوى تمرير البيانات.
استبدلوا المسار بـ: العميل → API Gateway → Kinesis مباشرة ← توفير 40% من التكلفة وتقليل زمن الاستجابة.

✅ خلاصة: تطبيق مبادئ إطار العمل المعماري المتقن

• استخدم آلية طابور الرسائل الميتة للاحتفاظ بالمعاملات الفاشلة والتحقيق فيها وإعادة محاولتها.
• تراجع المعاملات الفاشلة باستخدام AWS Step Functions.
• تحكم بالوصول إلى API باستخدام Cognito وLambda authorizer وسياسات الموارد.
• تحكم بالوصول إلى التطبيق عبر مبدأ الامتياز الأقل لدوال Lambda.
• شفر البيانات أثناء النقل وأثناء التخزين باستمرار.
• طبق أمان التطبيق عبر التحقق من صحة الأحداث الواردة وتنقيتها.
• حسن الأداء عبر اختبار إعدادات الذاكرة في Lambda ونقاط النهاية في API Gateway.
• حسن التكلفة عبر الاستفادة من نموذج الدفع حسب الاستخدام والتوسع حسب الطلب.
• استخدم تكاملات AWS المباشرة حيثما أمكن لتقليل التكلفة والعبء التشغيلي.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Dead-letter queue	طابور الرسائل الميتة	طابور SQS مخصص للاحتفاظ بالمعاملات الفاشلة للتحقيق وإعادة المحاولة.
Least-privileged access	الامتياز الأقل	مبدأ أمني يمنح المستخدم أو الخدمة أقل الصلاحيات اللازمة لأداء المهمة.
Lambda Authorizer	مفوض Lambda	دالة Lambda مخصصة للتحقق من صحة طلبات API وتنفيذ منطق توثيق مخصص.
Lambda Destinations	وجهات Lambda	توجيه نتائج استدعاء Lambda (نجاح أو فشل) إلى خدمات أخرى كـ SQS أو SNS أو EventBridge.
Clickstream	تيار النقرات	بيانات تتبع تفاعلات المستخدم مع التطبيق مثل النقرات وزيارات الصفحات.
Serverless Applications Lens	عدسة التطبيقات بدون خوادم	إضافة متخصصة لإطار Well-Architected Framework تغطي سيناريوهات serverless.

1️⃣ The Evolving Café Architecture: Version 7 — تطور بنية المقهى: الإصدار السابع

📖 ما هو الإصدار السابع (V7) من بنية المقهى؟
يريد أحمد وسارة الحصول على تقارير يومية عبر البريد الإلكتروني عن جميع الطلبات التي تم وضعها على الموقع الإلكتروني للمقهى. أحمد يريد توقع الطلب ليخبز العدد الصحيح من الحلويات (تقليل الهدر). سارة تريد تحديد أي أنماط في أعمال المقهى (تحليلات). حالياً قامت سلمى بإعداد مهمة مجدولة (cron job) على خادم الويب ترسل تقارير الطلبات اليومية بالبريد الإلكتروني. لكن هذه المهمة تستنزف الموارد وتقلل أداء خادم الويب. تنصح ليلى بأن مهام التقارير غير الحيوية يجب فصلها عن خادم الويب. يريد سلمى وخالد فصل المهمة المجدولة إلى بيئة مُدارة بدون خوادم تتوسع جيداً وتقلل التكاليف.

📋 تطور بنية المقهى عبر الإصدارات:

• V1: موقع ثابت على Amazon S3 للتعريف بالمقهى.
• V2: إضافة الطلبات الإلكترونية عبر Amazon EC2 مع قاعدة بيانات.
• V3: فصل قاعدة البيانات ونقلها إلى Amazon RDS على شبكة خاصة.
• V4: تعزيز الأمان باستخدام ميزات Amazon VPC لفصل الشبكات.
• V5: إضافة موازن تحميل وتوسع تلقائي عبر منطقتي توفر.
• V6: أتمتة النشر عبر AWS CloudFormation ونشر البنية في منطقة أخرى.
• V7: نشر دوال Lambda تتصل بقاعدة Amazon RDS وتُنشئ تقريراً بناءً على جدول زمني — تحسين الأداء وتقليل التكاليف.

على سبيل المثال كان المقهى يعاني من بطء موقع الويب في أوقات الذروة بسبب مهمة التقارير المجدولة التي تستهلك 70% من موارد الخادم.
بعد التحويل إلى Lambda مع Amazon EventBridge Scheduler أصبحت التقارير تُنشأ دون التأثير على أداء الموقع.
تكلفة تشغيل دالة Lambda لدقائق قليلة يومياً أقل بكثير من تشغيل خادم إضافي أو إبطاء الخادم الحالي.

2️⃣ Serverless Café Lab Tasks — مهام معمل المقهى بدون خوادم

📖 ما هي المهام التي ستنفذها في معمل المقهى؟
في هذا المعمل ستقوم بتنفيذ بنية بدون خوادم لتوليد تقرير مبيعات يومي باستخدام خدمات AWS Lambda وAmazon EventBridge وAmazon RDS وAmazon SES. ستتعلم كيفية إنشاء دالة Lambda تستخرج البيانات من قاعدة Amazon RDS وتوليد تقرير مبيعات وإرساله عبر البريد الإلكتروني. ستقوم بتكوين مجدول EventBridge لتشغيل الدالة يومياً في وقت محدد بدلاً من المهمة المجدولة التقليدية على الخادم.

على سبيل المثال في المعمل ستقوم بإنشاء دالة DataExtractor Lambda تتصل بقاعدة RDS للمقهى.
تستخرج الدالة إجمالي المبيعات اليومية وعدد الطلبات وأكثر المنتجات طلباً.
ترسل النتيجة عبر Amazon SES إلى أحمد وسارة كل صباح الساعة 7:00.
هذا يمثل تحولاً من بنية تقليدية تعتمد على خادم واحد إلى بنية بدون خوادم مدارة بالكامل.

✅ خلاصة: معمل المقهى — تنفيذ بنية بدون خوادم

• الإصدار السابع من بنية المقهى يستبدل المهمة المجدولة (cron job) بدوال Lambda مُدارة.
• يهدف التحديث إلى تحسين أداء خادم الويب وتقليل التكاليف التشغيلية.
• تستخدم Lambda لاستخراج بيانات المبيعات من Amazon RDS.
• يستخدم Amazon EventBridge كمجدد زمني لتشغيل الدالة يومياً.
• تُرسل التقارير عبر Amazon SES بالبريد الإلكتروني.
• يمثل هذا التحول تطبيقاً عملياً لمبادئ البنى بدون خوادم والخدمات المُدارة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon EventBridge Scheduler	مجدول EventBridge	خدمة لجدولة تشغيل دوال Lambda أو إرسال رسائل في أوقات محددة.
Amazon SES	خدمة البريد الإلكتروني البسيط	خدمة إرسال بريد إلكتروني مُدارة تتكامل مع Lambda لإرسال التقارير.
Cron job	مهمة مجدولة	مهمة تعمل في أوقات محددة على نظام Unix/Linux لتشغيل أوامر دورية.
Data Extractor	مستخرج البيانات	دالة Lambda تستخرج بيانات المبيعات من قاعدة البيانات لإنشاء التقارير.

1. A company runs a Node.js application on an EC2 instance that processes user uploads. To reduce operational overhead, they want to move to a serverless architecture. Each upload must be processed within 30 seconds and the team wants the lowest maintenance solution. Which combination should they use?

A) Amazon S3 to trigger AWS Lambda directly using an S3 event notification, with the Lambda function processing the file B) Amazon S3 to trigger Amazon SQS, then a long-running EC2 instance polls the queue and processes files C) Amazon S3 to trigger an EC2 Auto Scaling group that launches instances on each upload D) Use AWS Fargate with a container that continuously polls S3 for new objects

Correct! S3 event notifications can directly invoke Lambda, which is serverless, has no infrastructure to manage, and executes within the 15-minute Lambda timeout — well within the 30-second requirement.

Incorrect. The correct answer is A. S3 event notifications directly triggering Lambda is the simplest serverless pattern for file processing.

2. A company wants to expose a REST API to external customers that integrates with multiple backend AWS services. They need API keys, usage plans, request throttling, and request/response transformation. Which API Gateway type should they choose?

A) Amazon API Gateway REST API B) Amazon API Gateway HTTP API C) Amazon API Gateway WebSocket API D) Application Load Balancer with Lambda target

Correct! REST APIs offer the most features including API keys, usage plans, throttling, and request/response mapping via VTL templates.

Incorrect. The correct answer is A. REST API Gateway provides API keys, usage plans, throttling, and request/response transformation.

3. A team is building a multi-step order processing workflow that includes payment validation, inventory check, shipping arrangement, and notification. Steps must run in order with error handling and retry logic. What should they use?

A) Hard-code the workflow logic in a single AWS Lambda function B) Use Amazon SQS to queue messages between separate Lambda functions C) Use AWS Step Functions to orchestrate the workflow with individual Lambda functions D) Use Amazon EventBridge to trigger each step sequentially

Correct! AWS Step Functions is designed for orchestrating multi-step workflows with built-in error handling, retry logic, and state management.

Incorrect. The correct answer is C. Step Functions provides state management, sequencing, error handling, and retry logic out of the box.

4. A company has a Lambda function that processes orders. Under normal load it takes 2 seconds, but during flash sales concurrency spikes to over 1,000 simultaneous invocations and some time out. What should the architect do?

A) Increase the Lambda function timeout to 15 minutes B) Provision a larger Lambda function with more memory and CPU C) Request a service quota increase for Lambda concurrency and implement reserved concurrency D) Move the order processing to an EC2 instance behind an ALB

Correct! Lambda has a regional concurrency limit (default 1,000). Requesting a quota increase and using reserved concurrency ensures critical functions have capacity.

Incorrect. The correct answer is C. Reserved concurrency guarantees capacity for critical functions, and a quota increase raises the regional limit.

5. An e-commerce platform uses Lambda behind API Gateway that queries DynamoDB for product details. Response times are slower than expected. Which solution is MOST effective to reduce latency?

A) Increase the Lambda function memory to the maximum 10,240 MB B) Switch from DynamoDB to Amazon RDS with read replicas C) Enable DynamoDB Accelerator (DAX) as a caching layer D) Replace API Gateway REST API with HTTP API

Correct! DAX is an in-memory cache for DynamoDB that delivers microsecond response times with minimal code changes.

Incorrect. The correct answer is C. DAX is designed specifically to reduce DynamoDB response times to microseconds with minimal code changes.

6. A company needs to build a real-time chat application where users can send and receive messages instantly with persistent two-way connections. Which AWS service should handle the API layer?

A) Amazon API Gateway REST API B) Application Load Balancer with sticky sessions C) Amazon API Gateway WebSocket API D) Amazon SQS with long polling

Correct! WebSocket APIs maintain persistent two-way connections, making them ideal for real-time applications like chat.

Incorrect. The correct answer is C. WebSocket APIs maintain persistent bidirectional connections between clients and the server.

7. A company is migrating a monolithic application to microservices. One service needs to run continuously and handle processes that exceed the Lambda 15-minute timeout. Which compute option should they use?

A) AWS Lambda with reserved concurrency B) AWS Fargate running behind an Application Load Balancer C) Amazon API Gateway with Lambda integration D) Amazon SQS with Lambda poller

Correct! AWS Fargate has no maximum runtime limit, making it suitable for long-running processes while remaining serverless.

Incorrect. The correct answer is B. Lambda has a 15-minute execution timeout. Fargate (serverless containers) has no such limit.

8. A company uses EventBridge to route events from multiple SaaS applications to various targets. They want a fan-out pattern where one event is sent to multiple targets simultaneously. How should they configure this?

A) Create multiple EventBridge rules matching the same event pattern with different targets B) Create one rule with multiple SQS queues as targets C) Configure the event source to send copies to different event buses D) Use a single Lambda target that invokes all other targets sequentially

Correct! Multiple EventBridge rules with the same event pattern but different targets trigger simultaneously for fan-out without custom code.

Incorrect. The correct answer is A. Multiple EventBridge rules can match the same event pattern, each routing to different targets simultaneously.

9. A company is comparing a three-tier architecture on EC2 with a serverless architecture. Which task remains the customer's responsibility in BOTH architectures?

A) Applying operating system security patches B) Configuring Auto Scaling policies C) Building, deploying, and monitoring the application D) Managing the web server software

Correct! The customer is always responsible for the application code — building, deploying, and monitoring it — regardless of architecture.

Incorrect. The correct answer is C. Serverless shifts infrastructure management to AWS, but application logic is always the customer's domain.

10. A company runs a nightly batch job that generates sales reports from RDS. The job takes ~45 minutes and must not interfere with business hours. Which serverless pattern should they use?

A) AWS Lambda with a 45-minute timeout triggered by EventBridge Scheduler B) An EC2 instance that starts at midnight via Instance Scheduler C) AWS Fargate task triggered by EventBridge Scheduler with a container that performs the ETL D) Amazon EMR cluster launched manually each night

Correct! Fargate is serverless with no runtime limit, handling the 45-minute job. EventBridge Scheduler triggers it at midnight, running only when needed.

Incorrect. The correct answer is C. The job takes 45 minutes, exceeding Lambda's 15-minute limit. Fargate has no timeout and is serverless.

🚀 الخاتمة

في هذه الوحدة تعمقنا في عالم البنى السحابية بدون خوادم Serverless Architectures والخدمات المصغرة Microservices على منصة AWS. استعرضنا مفهوم التفكير بدون خوادم وفوائده الرئيسية من إلغاء إدارة الخوادم إلى التوسع المستمر والتوفر العالي المدمج. تعرفنا على خصائص الخدمات المصغرة وأنماطها المختلفة وقارناها بالتطبيقات المتجانسة مع أمثلة عملية. اكتسبنا مهارات عملية في استخدام AWS Lambda لبناء دوال برمجية بدون خوادم مع فهم أنماط الاستدعاء المختلفة وطبقات Lambda ومعالج الدالة. تعرفنا على خيارات الحاويات في AWS باستخدام Amazon ECS وAWS Fargate لتشغيل الخدمات المصغرة. استعرضنا AWS Step Functions لتنسيق سير العمل بين الخدمات المتعددة وأنواع الحالات في آلة الحالة ولغة Amazon States Language. تعلمنا كيفية توسيع البنى بدون خوادم باستخدام Amazon API Gateway بأنواعها الثلاثة: REST APIs وHTTP APIs وWebSocket APIs. وأخيراً طبقنا مبادئ AWS Well-Architected Framework على التطبيقات بدون خوادم مع التركيز على إدارة الأعطال والتحكم بالوصول وحماية البيانات وتحسين الأداء والتكلفة والتحسين المستمر.

تعديل المقال