الـ Serverless Architecture طلعت كـ design pattern يخلي الـ Developers ينجموا يحقّقو الأمنية اللي ديما يحلمو بيها: يطرّقوا الـ Software من غير ما يوجّعوا روسهم بالبنية التحتية وكيفاش تتدار.

من زمان والناس تحب تعطي فرصة للـ Developers باش يركّزو على الـ Development، ويبنيو Services قويّة ويبدعو فيها من غير ما يعطّلنهم وجيعة الرأس متاع الـ Infrastructure.

يعني يركّزو على الـ Core Product اللي يخدمو عليه، من غير ما يتقلّقو: “كيفاش باش ندير الـ infrastructure؟ شنوّة السيرفرات؟ شكون يبدّل الـ hardware؟”…

على خاطر هذا، ظهر الـ Serverless Architecture باش يعطي حلّ، ويخلّي الـ Developers يبنيو الـ Software وهوما مرتاحين بلا وجيعة الـ servers وإدارتهم.

---

كيفاش تخدم الـ Serverless Architecture؟

احنا نعرفو اللي أي application باش يتواصل مع الـ Users لازم يكون عندو servers مجهّزين وحاضرين. وهذيك تتطلب موارد:

• Server Hardware
• Security Updates
• Backups
• Resources Management

أمّا مع الـ Serverless Architecture، الحكاية تتبدّل:
إحنا نشيلو الحمل هذا الكل من فوق ظهر الـ Developer، ونخليّو مسؤولية السيرفرات على الـ Cloud Provider (بحذاك AWS، Google Cloud، Microsoft Azure…).

الـ Developer ما يهتمّ كان بالـ Business Logic ويكتب الـ Application Code، والباقي الكل يتكفّل بيه الـ provider.

---

Serverless Architecture In a Nutshell

أشهر مثال على الـ Serverless هو الـ FaaS – Function as a Service.
الفكرة بسيطة: الـ Developer يكتب الـ application متاعو كأنها Functions تتنفّذ وقت يصير Event معيّن:

• رسالة تبعث،
• Email،
• HTTP Request،
• Event داخلي… إلخ.

بالتالي إنت كـ Developer لازمك:

1. تكتب الـ Function / ال Application Code وتعملو Upload على الـ Cloud Provider.
2. تحدّد الـ Trigger: شنوّة الحدث اللي يخلي الـ Function تتنفّذ؟
3. وقت يصير الـ Trigger، الـ Cloud Provider يعمل Execution للـ Function.
   ولو ما ثماش Server واقف، هو يقوم واحد بنفسو ويشغّلو.

بالشكل هذا، الـ Developer ماعادش يشوف البنية التحتية أصلاً، يركّز كان على الـ Function Logic.

---

أمثلة على الـ FaaS

أول ما بدات الحكاية كانت مع AWS Lambda اللي تستعمل اليوم بشكل كبير برشا.
وزيد عندك:

• Google Cloud Functions – GCF
• Microsoft Azure Functions

---

مفاهيم مهمّة في Serverless Architecture

لازم أي Developer يكون يعرف شوية مصطلحات:

• Invocation: وقت الـ Function تتنادى وتتخدّم.
• Duration: وقت التنفيذ.
• Cold Start: الوقت اللي ياخذو الـ Provider باش يشغّل Instance جديدة للـ Function بعد فترة خمول.
• Concurrency Limit: قدّاش Functions تنجّم تتخدم في نفس الوقت.
• Timeout: الحدّ الأقصى للوقت المسموح قبل ما الـ Provider يقطع التنفيذ.

---

مميزات الـ Serverless Architecture

1. Cost

ما تخلّص كان على Invocation.
ما ثماش Server واقف يشفط في فلوسك وهو ما يخدمش.

2. Scalability

التوسع تلقائي:
Instances تتخلق وتتقصّ عالأخر حسب الـ traffic، بلا ما تحتاج Kubernetes ولا orchestrator آخر.

3. Productivity / Time

الفريق يخدم أسرع، المشروع يكمّل بدري، على خاطر العملية:
نكتب الكود → نعمل Deploy → خلاص.

---

عيوب وتحديات الـ Serverless Architecture

1. Control

ما عندك حتى تحكّم في الـ infrastructure.
لو يصير Hardware Fault ولا Data Center outage، ما تنجم تعمل شيء.

2. Security

الأمان مسؤولية الـ Provider.
لو الـ Function تخدم على Server vulnerable تنجم البيانات تتعرّض للخطر.

3. Performance

وقت يصير Cold Start، الشيرة تاخو وقت وتعمل Delay واضح في الأداء.

---

وقتاش نستعمل Serverless Architecture؟

Trigger Based Tasks

مهام مربوطة بـ Event معيّن:
مثلاً: User يعمل Sign Up → يتبعها:

• Database update
• Welcome email
• Logging

Building RESTful APIs

الـ API Gateway مع Functions حلّ ممتاز للـ GET/POST Requests بطريقة خفيفة وسريعة.

Asynchronous Processing

عمليات Async، كيف:

• Thumbnail generation
• Video transcoding
• Jobs في الخلفية ما تحتاجش blocking

---

في الختام

برشا شركات تحب تبني حاجات خفيفة، scalable، وتدخل للسوق بسرعة.
الـ Serverless Architecture حل ممتاز ليهم.

أمّا:
لو عندك تطبيق فيه عمليات Long-running ومتتابعة، الـ Virtual Machines ولا الـ Containers باش يكونو أفضل بكثير.