كيف تصمم معماريات بدون خوادم (Serverless) على AWS؟

Question

Accepted Answer

**معمارية بدون خوادم (Serverless architecture)** تبني التطبيقات من خدمات مُدارة وموجهة بالأحداث (Lambda و API Gateway و DynamoDB و S3 و SQS وغيرها) دون إدارة خوادم — AWS تتعامل مع التوسع والبنية التحتية. فهم كيفية تصميم الأنظمة بدون خوادم والمقابلات بينها مفيد جداً لمعمارية السحابة الحديثة.

## معمارية بدون خوادم نموذجية

```text
A serverless web app/API often combines:
  API GATEWAY → receives HTTP requests, routes to Lambda (the API entry point)
  LAMBDA → functions handle the business logic (run on demand, auto-scale)
  DYNAMODB → serverless NoSQL database (scales automatically)
  S3 → static assets / file storage (host the frontend, store uploads)
  COGNITO → managed authentication
  SQS/SNS/EventBridge → async messaging and event-driven flows
  CLOUDFRONT → CDN for the frontend
→ No servers to manage; everything scales automatically; pay per use.
```

## مبادئ تصميم البدون خوادم

```text
✓ EVENT-DRIVEN — components react to events (HTTP, queue messages, S3 events, schedules)
✓ Small, single-purpose FUNCTIONS (Lambda does one thing well)
✓ STATELESS functions — state lives in databases/storage (functions are ephemeral)
✓ Use MANAGED services for everything (database, auth, messaging) — no servers anywhere
✓ Decouple with queues/events for resilience and async processing
```

## الفوائد والمقابلات

```text
✓ NO server management; AUTO-SCALING (to zero and to huge); PAY-PER-USE (cheap at low/
  variable load); fast to build; high availability built in
✗ COLD STARTS (latency); execution limits (Lambda 15 min); complexity in distributed
  debugging/tracing; potential vendor lock-in; can cost more at very high constant scale
→ Great for: variable/bursty/event-driven workloads, APIs, automation, rapid development.
  Less ideal: long-running, constant heavy compute, very latency-sensitive (cold starts).
```

## لماذا يعتبر هذا مهماً

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

نهج البدون خوادم — بناء التطبيقات من **خدمات مُدارة وموجهة بالأحداث** (Lambda للمنطق، API Gateway للـ HTTP، DynamoDB للبيانات، S3 للتخزين، SQS/SNS/EventBridge للمراسلة، Cognito للمصادقة) **دون إدارة أي خوادم** — يمثل نموذج معماري مهم حيث AWS تتعامل مع كل التوسع والبنية التحتية، مما يسمح للفرق التركيز بشكل كامل على منطق التطبيق.

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

بشكل حاسم، فهم **الفوائد والمقابلات** مهم للقرارات السليمة: الفوائد (لا توجد إدارة خوادم، توسع تلقائي بما فيه الصفر، كفاءة التكلفة المدفوعة حسب الاستخدام عند الحمل المتغير، تطوير سريع، توفر عالي مدمج) تجعل البدون خوادم ممتازاً للأحمال المتغيرة والمتفجرة والموجهة بالأحداث والـ APIs والتطوير السريع — بينما المقابلات (كمون البدء البارد، حدود التنفيذ، تعقيد تصحيح الأخطاء في الأنظمة الموزعة، قد يكون هناك انحصار في البائع، وربما تكون التكلفة أعلى عند الحمل الثابت العالي جداً) تعني أنه أقل مثالية للأعمال طويلة المدى أو الحوسبة الثقيلة المستمرة أو أعباء العمل الحساسة جداً للكمون.

معرفة **متى يناسب البدون خوادم** (ومتى لا يناسب) يعكس الحكم المعماري الناضج.

لأن البدون خوادم هو نهج رئيسي حديث لتطبيقات السحابة (يوفر فوائد جاذبة للأعباء المناسبة) وتصميم الأنظمة بدون خوادم بشكل جيد يتطلب فهم الخدمات ومبادئ التصميم وخاصة المقابلات، فهم معمارية البدون خوادم على AWS هو معرفة قيّمة على مستوى الخبير لمعمارية السحابة الحديثة — نموذج متنام بشكل متزايد حيث فهم قوته وحدوده يمكّن من اختيار وتصميم حلول البدون خوادم بشكل مناسب، مما يعكس الاتساع المعماري المتوقع لأدوار السحابة العليا.