أهلًا بكم في نشرة اقرأ-تِك الأسبوعية 👋
نشرة اسبوعية بنتكلم فيها عن مواضيع متنوعة في هندسة البرمجيات بشكل بسيط وبرسومات توضيحية
السلام عليكم ورحمة الله وبركاته ,
أهلًا بيكم في النشرة الأسبوعية من اقرأ-تك 🎉
هنتناول بشكل أسبوعي مواضيع مختلفة ومتنوعة ليها علاقة بهندسة البرمجيات وهنبسط المفاهيم دي بشكل سلس وجميل من خلال رسوم توضيحية معمولة باتقان وجودة عالية ❗️
فشكرًا ليكم على انضمامكم لمجتمع اقرأ-تِك , واللي هدفنا فيه اننا نثري المحتوى التقني العربي ونقدم محتوى تقني بجودة عالية يليق بالوطن العربي 🚀
ايه الفرق بين الموقع والنشرة الأسبوعية ؟
النشرة الاسبوعية هتكون شيء منفصل تمامًا عن موقع اقرأ-تِك الأصلي واللي فيه المحتوى هينزل عادي جدًا من مقالات وترشيحات كتب ومحتوى ورقة وقلم 🌟
ولكن موقع اقرأ-تِك الأصلي هيكون فقط متاح للاشتراكات المدفوعة بسبب بعض القيود, والنشرة الاخبارية هتكون مجانية تمامًا للجميع 🎉
موقع اقرأ-تِك الأصلي هيتنزل عليه محتوى مجاني متاح لكل الناس بدون اشتراك , بالإضافة لمحتوى يتطلب الاشتراك بخطط الاشتراك المدفوعة , ولكن الاشتراك في النشرة الاخبارية هيكون مجاني للجميع 😍
عينة عشوائية من المواضيع اللي بنتكلم فيها
Serverless Architecture
من زمان والناس نفسها انه تتيح للـ Developers الفرصة أنهم يركزوا على جزء الـ Development وانهم يكونوا قادرين على بناء Services قوية ويبدعوا فيها بدون عوائق الـ Infrastructure أو التفكير فيها ..
بحيث يركزوا على الـ Core Product أو المنتج اللي مهتمين بيه بمعنى أصح ، من غير ما يهتموا بازاي هيديروا البنية التحتية للـ Product ده
💡
وعشان كده ظهر الـ Serverless Architecture كطريقة أو نمط للتصميم يسمح للـ Developers بتحقيق الأمنية دي , وإن هم يبقوا قادرين على بناء الـ Software بدون الاهتمام بالبنية التحتية واداراتها
ازاي Serverless Architecture بتشتغل ؟
كلنا عارفين أن الـ Servers عشان تسمح للـ Users بإنهم يتواصلوا مع أي تطبيق والـ Business Logic بتاعه , ده هيتطلب Resources وبنية تحتية هتطلب موارد واهتمام وادارة زي :
Server Hardware
Security Updates
Backups
Resources Management
ومن خلال اتباع الـ Serverless Architecture احنا بنشيل العبء ده كله وبنخلي الـ Developers يهتموا بس بجزء الـ Business Logic / Core Product وانهم يكتبوا الـ Application Code وبنشيل عبء البنية التحتية ونخليها مسئولية Third Party Provider زي الـ Cloud Services اللي موجودة دلوقتي ومن أشهرهم AWS , Google Cloud , Microsoft Azure
أحد أشهر الـ Serverless Architecture هي الـ FaaS واللي هي اختصار لـ Function as a Service , واللي من خلالها الـ Developers بيكتبوا الـ Application بتاعهم والـ Core Product اكنه بالظبط عبارة عن مجموعة محددة من الـ Functions اللي بتتنفذ واللي بيحصلها Triggering من خلال الـ Events زي مثلا ان حد يبعت رسالة لحد , أو ان يتبعت Email أو ان يحصل HTTP Request بشكل معين.
وبالشكل ده انت كـ Developer مسئول عن :
كتابة الـ Function أو الـ Application Code على هيئة الـ Functions دي وتعملها Upload / Deploy على الـ Cloud Provider
تحدد الـ Trigger أو ايه هو الحدث اللي هيتسبب في إن الـ Function بتاعتك يحصلها Invocation ويتم تنفيذها ؟ يعني امتة بالظبط الـ Cloud Provider ينادي عليها وينفذها ؟
وبعد ما تعمل ده أول مالـ Cloud Provider بيعرف أن حصل Trigger بيبدأ هو يعمل Execution للـ Function بتاعتك على أحد الـ Servers واللي ده بيكون من اختصاصه هو, ولو ماكنش فيه Servers وقتها قايمة فدوره انه يعمل Spawning لواحد ويبدأ ينفذ عليه الـ Function بتاعتك.
وبالشكل ده الـ Developer بيكون معزول تماما عن ايه بيحصل من ناحية البنية التحتية , ولكن بيكون تركيزه منصب في الـ Function Logic فقط
أمثلة على الـ FaaS
الـ FaaS ظهرت بشكل كبير أول ما AWS قدمت لينا AWS Lambda واللي بيتم استعمالها دلوقتي بشكل كبير جدًا من عدد كبير من الـ Developers في أنحاء العالم بالإضافة لإن عندنا كذلك :
Google Cloud Functions - GCF
Microsoft Azure Functions
بعض المفاهيم في الـ Serverless Architecture
مهم جدًا للـ Developers إنهم يكونوا عارفين بعض المفاهيم المتعلقة بالنمط ده من التصميم , وعشان كده فيه بعض المفهايم زي :
Invocation : وده معناه ان الـ Function بيحصلها Execution أو اتنادى عليها بمعنى أصح
Duration : وده الوقت اللي بتاخده الـ Function عشان تتنفذ
Cold Start : ودي المدة اللي بتحصل بين ما الـ Function يحصلها Triggering كأول مرة أو كبعد فترة من الخمول
Concurrency Limit : وده عدد الـ Function اللي ممكن يتعملها Run في نفس الوقت مع بعض
Timeout : وده الوقت اللي الـ Cloud Provider بيتييحه للـ Developers أن الـ Function تبقى شغالة قبل ما يحصلها Termination وتتقفل
مميزات الـ Serverless Architecture
Cost : تكلفة الـ Serverless Function بتكون Cost Effective وده لانك بتتحاسب على كل Invocation بيحصل ليها وبالتالي مش بتدفع لو عندك Server مش بيتم استعماله أو استغلاله بشكل ما أو بآخر لأي سبب من الأسباب
Scalability : الـ Function Instances بيحصلها Creation بشكل اوتوماتيك , وبتتشال كذلك بشكل اوتوماتيك بناء وعلى حسب الـ Traffic , وطبعا ده برضو مع الاخذ في الاعتبار الـ Concurrency limit اللي انت محددها , ودي ميزة قوية جدًا تفرق نمط التصميم ده عن الـ Containerized Applications واللي بتحتاج فيهم حاجة زي Kubernetes أو أي Container Orchestration عشان عملية الـ Scalability واداراتها
Productivity / Time : بتحسن من انتاجية الفريق وبتقلل من الوقت الكلي لانهاء المشروع وده لان كل اللي بيتم بعد مجرد كتابة الـ Code هو انه يتعمله Deploy من غير ما نشغل بالنا باداراة الـ Servers واللي بالطبع هيسرع من عملية الـ Development
عيوب وتحديات الـ Serverless Architecture
Control : للأسف مالناش تحكم في البنية التحتية زي ما شوفنا وبالتالي الـ Cloud Provider هو المسئول الأول والأساسي في الموضوع ده عن ادارة البنية التحتية , فلو حصل أي Hardware Fault / Data Center Outage مش هيكون لينا أي حل نقدر نعمله
Security : دي برضو هتكون مسئولية الـ Cloud Provider , فلو الـ Function بتـ Run على Server Vulnerable مش بعيد الـ Data يحصلها Exposure بشكل ما أو بآخر
Performance : لو نلاحظ كنا اتكلمنا فوق عن ان ممكن لما يحصل Invocation للـ Function ما يكونش فيه Server قايم وقتها , وبالتالي هيضر الـ Cloud Provider انه يقوم Instance يـ Run عليها الـ Function وبالتاللي ده هياخد وقت وهيكون ليه Performance Impact بشكل ملحوظ
امتة نستخدم الـ Serverless Architecture
Trigger Based Tasks : لو فيه مهام بتطلب حدوث حدث معين عشان تتنفذ زي مثلا User Activity محدد هيتم بناء عليه سلسلة من الـ Events , فوقتها الـ Serverless Architecture هيكون مناسب جدًا على سبيل المثال : لو فيه User بيعمل Sign up للتطبيق ومحتاجين على ده يكون فيه سلسلة من الـ Events زي اننا نعمل Database Change وكمان نبعت Welcome Email
Building RESTful APIs : احيانا كتير بيكون أسهل اننا نبني RESTful APIs من خلال اننا نستغل الـ API Gateway اللي موجود في الـ Cloud Provider مع الـ Functions زي مثلا لو حد بعت GET / POST Request على Route معين زي /Users نخلي ده الـ Trigger اللي يستقبله الـ API Gateway ويبعته للـ Function المسئولة عن انها تعمل Handling للنوع ده من الـ HTTP Request
Asynchronous Processing : المهام اللي بتتطلب عمليات Aysnc أو غير متزامنة , النمط ده بيكون فعال جدا معاها لان في الـ Background ممكن يحصل حاجات زي Thumbnail Creation / Trsnacodinq Videos أو أي مهام غير متزامنة مش محتاجة يبقى ليها Interruption مع الـ Flow الطبيعي بتاع التطبيق
في الختام
أحيانا كتير الشركات بتكون عاوزة تقلل الوقت اللي تدخل في السوق وتنافس وفي نفس الوقت تبني Scalable Applications وتكون برضو حاجة خفيفة , فممكن الـ Serverless Architecture يكون خيار أمثل بالنسبالهم , ولكن لو الـ Application بتاعك بيتطلب عدد كبير من الـ Process الـ Long Running واللي بتتم بشكل متتابع , فوقتها الـ Virtual Machines أو الـ Containers ممكن يكونوا خيار أفضل بكتير جدًا.
💡
وكمان كويس اننا نفهم الـ Business بتاعنا , لان ممكن نستغل الاتنين ويبقى عندنا بنية تحتية Hybrid بين الاتنين نقدر نحقق بيها أكبر فايدة ممكنة , فالـ Bulk Requests ممكن تروح للـ Containers / VMs ولكن المهام القصيرة والـ Short Running زي اني اخزن حاجة في الـ Database ممكن تروح للـ Serverless Functions.