(ممكن تقرا ما بين ال 🔴 و ال 🔴 الأخرى لاختصار الموضوع لو مستعجل يعني)
بأول مقال من سلسلتنا ، رح نتطرق لأول موضوع و هو المقارنة بين ال PaaS ، BaaS ، و SaaS. طيب لي اخترت هاد الموضوع بالذات لابدا في السلسلة؟
اغلب ال المنتجات اللي بنبنيا مهما كان توجها او مجالا ، لازم بشكل من الأشكال تندرج تحت واحد من هالتصنيفات (في مسمى رابع و هو Infrastructure As A Service ، IaaS ، بس هاد بكون على نطاقات اكبر بكتير من يلي اغلب المهندسين ممكن يشتغلو في ، ف استثنيتو من السياق ، أما بالنسبة للي رح يستخدمو فهو بكل بساطة الخدمات اللي بتقدم الهاردوير المستخدم في بناء أي منتج الكتروني متل السيرفرات ، و مثال عليها Digital Ocean). فبالتالي معرفة نوع المنتج اللي رح نشتغل على بناءو ، أو المنتج اللي رح نستخدمو أثناء عملنا ، بتوضحلنا نقاط كتيرة لازم ناخدا بعين الاعتبار أثناء تعاملنا مع اي فئة من هالفئات.
🔴
قبل ما ندخل بصلب الموضوع ، خلينا أول شي نعرف كل واحد من هالفئات على حدة:
- PaaS: اختصار ل Platform As A Service ، هو اللفل الاعلى من ال IaaS على طول ، بكون فيه موفر الخدمة متحكم و مدير لل Infrastructure و ال OS المشغل الو ، و ما تبع الو من حماية و تنظيم أداء و ما الى هنالك ، و مثال عليه vercel ، sevalla ، AWS ، و غيرها.
- BaaS: اختصار ل Back end As A Service ، و بدورو اللفل الأعلى من ال PaaS على طول ، و فيه بكون موفر الخدمة متحكم بما سبق ، و زيادة عليه جزو كبير من ال code المستخدم ببناء مشروعك متل firebase ، supabase ، appwrite ، و أحيانا بكون بمتحكم بكل الكود الخاص بجانب كامل من مشروعك ، و منال قوي على هالشي workOS لخدمات ال authentication و Stripe لخدمات تنظيم المعاملات البنكية.
- SaaS: الاسم الترننننندي جدا ، اختصار ل Software As A Service ، و هو المنتج النهائي المدار و موفر بالكامل من قبل جهة ما ، و في بكون المستخدم النهائي غير مسؤول عن ادارة ما يقارب 90% من الخدمة ، بما في ذلك انشاءا و تشغيلا و ادارتا. كل المطلوب هو استخدام المنتج لا غير ، و مثال على هالفئة اي تطبيق موجو في هواتفنا ، اي موقع سوشيال ميديا ، اي بلاتفورم بندخل نخلص في معاملة حكومية ، اي منتج مستهلك بشكل مباشر من قبل جهة ما.
حلو …. الان بعد ما عرفنا معنى كل مصطلح و خلفية بسيطة عنو ممكن نترك البوست عادي 😂🔴 ….
او ممكن نتعمق بتفاصيل كل مبدأ من هالمبادئ ، و نعرف الفروقات اللي لازم ناخدا بعين الاعتبار في حال كنا على أي جهة من جهتي المستخدم أو الموفر. ممكن نبدا ناخد النقاط تبعنا وحدة وحدة:
Shared Responsibility Model: بكل حالة من حالات استخدامنا لأي منتج تحت أي تصنيف نم تصنيفاتنا ، لازم أول شي نحدد "مين المهام اللي أنا بتحمل مسؤوليتا كمهندس ، و مين المهام اللي بقدر اريح راسي منا" ، و هاد الشي بيعطيك توجه أولي لبداية تصميمك و تخطيطك للمنتج اللي رح تبني/تشتغل عليه. مثلا ، في ال PaaS Products ، كمستخدم ، بتقدر تتوقع من موفر الخدمة يجهزلك بيئة العمل الكاملة اللي رح تشغل عليها منتجك/نظامك ، و في بعض الأحيان كل اللي عليك أنك تكتب config file بس يوجه ال PaaS Product للاتجاه اللي أنت بدك يا ، و أحيانا حتى هاد الشي ما بتطر تعملو ، و أنت بدورك بتركز على scope ما دااااخل ال code الخاص فيك من a الى z. و بالجانب اﻵخر ، لو كنت أنت رح تبني PaaS Product ، ف همك الأساسي هو أنك توفر البيئة اللي بتحتاجا الفئة الأنت مستهدفا (مبرمجين PHP ، مبرمجين Nodejs ، بياعين بطاطا ، الخ) ، الشي اللي بيشمل امور متل ال Security ، Availability ، Up time ، و وجع راس كبير.
ف ال shared responsibility model هو الاتفاق الضمني بين الطرفين على أنو أنت عطيني هالجزئية بكفائة ما أفكر فيا مرة تانية ، حتى أفكر بالجزئية الباقية من منتجي بشكل كامل و مطلق.
Velocity vs. Control: بما انو بكل حالة من حالات استخدامنا لأي فئة من هالفئات ، فعليا نحت بنقسم الشغل على مشروعنا بينا و بين الخدمات اللي رح نختارا (و اللي هو أول نقطة كتير من ال junrior devs بيوقعو فيها ، أنو بيفتكرو أنو منتجهم هو الشي اللي بيشتغلو هم و بس) ، ف هاد التقسيم بحدد أول شي سرعة تنفيذنا للفكرة اللي في راسنا. مثلا ، لو أخدنا أي BaaS خاص بال authentication متل clerk ، رح نلاحظ أنو اختصرنا جزو كبير من هندلة ال configuration ، logic ، edge cases ، identity providers integration ، و جزو كبير كتير من اضافة خاصية ال authentication لمنتجك. ما طيب ال Baas عالم وردي صح؟ هممم … اييييه ….
مقابل اختصار الوقت و المجهود المهولين اللي كسبناهم لمن لجأنا الى استخدام حل Baas ، طلع من ايدنا جزو كبير جدا من التحكم على الأسس اللي بتشتغل عن طريقا هالخدمة اللي اخترناها , بحالتنا clerk ، متل حجم ال bundle اللي رح نضيفو لمشروعنا ، ال latency اللي رح يضيفا ال middleware الخاص بالخدمة ، ال logic الخاص بال session handling اللي طلع من ايدنا ، و كل التفاصيل اللي بتدير عمل ال authentication الخاص فينا. أيوا نحن عنا خيارات ال configuration الكتيرة جدا اللي بتجي مع الخدمة ، بس ، بضل التحكم بتفاصيلا و طريقة عملا و العبئ اللي بتضيفو على منتجنا مو بايدنا ، بايد موفر الخدمة.
Architectural Approach - Who is your Client: بكل حالة من حالات تصميم منتجنا ، الفئة المستهدفينا و المشكلة اللي رح نحلا ، بتحدد بشكل كبير الفئة اللي رح نندرج تحتا ، و بالتالي المسؤوليات و التحكم اللي رح يكونو عندنا vs عند المستخدم. مثلا ، لو كان عندنا خدمة dropbox ، بنشوف أنو موفر الخدمة مسؤول من أنو يصمملي الخدمة من و الى كل المتطلبات اللي بيحتاجا المستخدم لحل مشكلتو (نقل الملفات بشكل امن) ، و ما بينقص الخدمة الا مستخدم الخدمة لحتى تكتمل حلقة الموفر/مستخدم. أنا الموفر؟ عندي كامل الكونترول على تفاصيل الخدمة ، و بالتالي عندي كامل المسؤولية أني اتكفل بجوانب عمل الخدمة ، أما المستخدم عندو أبسط تحكم في الخدمة و اللي هو أنو يستخدما أو لا 😂 ، بس بالتالي ما علي أي مسؤولية لتشغيل الخدمة غير أنو "للاستفادة من الخدمة ، لازم يكون عندك جهاز يشغلا" لا أكثر.
أنت كمهندس Back End لازم تقدر تتعرف على البيئة اللي بينتمي لها مشروعك ، أو نوع الخدمة اللي رح تستخدما بمشروعك ، لانو معرفة الفكر خلف كل فئة من الفئات اللي ذكرناها في ما سبق بتساعدك تكون ال mind model الخاص بالمشروع اللي رح تبنيه ، مسؤوليتك vs رفاهيتك بالمشروع ، المساحة اللي أنت مستعد تتنازل عن التحكم فيها لمستخدمك/موفر الخدمة مقابل السرعة اللي رح تحصل عليها/رح تتحملا أثناء عملك على أي مشروع بتقرر تدخل فيه.
