أساسيات الحوسبة السحابية

IaaS مقابل PaaS مقابل SaaS

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

متوسط 19 دقائق 4 أهداف التعلّم
  1. قارن التوزيع الكامل للمسؤولية عبر IaaS وPaaS وSaaS، طبقة بطبقة
  2. طبّق الإشارات اللفظية لتحديد نموذج الخدمة الصحيح في سيناريو
  3. اشرح لماذا يقايض الصعود في الطبقات التحكم بالراحة بدل أن يكون تحسيناً بسيطاً
  4. قيّم سيناريو مقابل قيوده لاختيار نموذج الخدمة المناسب

تسمية النماذج سهلة. التفريق بينها هو المهارة الفعلية

تستطيع الآن تعريف IaaS وPaaS وSaaS كل على حدة. هذا وحده ليس مهارة مفيدة: لا أحد تقريباً يمنحك خدمة ويسألك "ما هذا؟" بمعزل عن أي سياق. ما يُختبر فعلياً، في شهادة وفي العمل، هو سيناريو بقيود: فريق، وموعد نهائي، ومتطلب امتثال، وسؤال عن أي النماذج الثلاثة يناسبه. هنا ينفق هذا الدرس جهده.

الطبقات الكاملة، جنباً إلى جنب

الطبقةIaaSPaaSSaaS
الشبكات والخوادم والمحاكاة الافتراضيةالمزوّدالمزوّدالمزوّد
نظام التشغيلأنتالمزوّدالمزوّد
بيئة التشغيل والوسائط البرمجيةأنتالمزوّدالمزوّد
كود التطبيقأنتأنتالمزوّد
البيانات وإعداداتك الخاصةأنتأنتأنت

اقرأ الجدول عموداً لا صفاً، وسيتضح النمط فوراً: كل خطوة من IaaS إلى SaaS تنقل طبقة إضافية واحدة من "أنت" إلى "المزوّد". البيانات وإعداداتك الخاصة هي الصف الوحيد الذي لا ينتقل أبداً، مهما كان النموذج الذي تختاره.

الفخ: هذه مقايضة، لا ترتيب تفضيلي

من المغري قراءة هذا الجدول من اليسار لليمين والاستنتاج أن SaaS هي ببساطة النموذج الأفضل، بما أن المزوّد يتحمّل أكبر قدر من العمل. هذا الاستنتاج خاطئ، وهو بالضبط الفخ الذي يضعه سؤال اختبار. ما تكسبه SaaS من راحة، تنفقه من تحكم. لا تستطيع تثبيت مكتبة مخصصة على خوادم Gmail، ولا تشغيل كودك الخاص على بنية Salesforce، ولا اختيار إصدار نواة مختلف لـ Microsoft 365. تعيد IaaS لك كل ذلك التحكم، مقابل تحمّل إدارة نظام التشغيل وبيئة التشغيل والتطبيق بنفسك. ليس أي طرف من الجدول "أفضل". كل واحد يناسب مجموعة قيود مختلفة.

إشارات لفظية للسيناريوهات

نادراً ما تقول سيناريوهات الاختبار "IaaS" أو "PaaS" مباشرة. تصف قيداً، والقيد يشير إلى النموذج.

حين يقول السيناريو...يشير إلى
"تحكم كامل بنظام التشغيل"، "إصدار نواة محدد"، "صلاحيات root"IaaS
"فقط انشر الكود"، "بلا إدارة خوادم"، "التركيز على التطبيق"PaaS
"بلا تثبيت"، "استخدمه كما هو فور فتحه"، "بلا مطورين في الفريق"SaaS

مثال محلول: سيناريوهان، إجابتان

يحتاج فريق مبيعات من 12 شخصاً نظام CRM جاهزاً للعمل الأسبوع المقبل، ولا مطورين لديه لبناء واحد من الصفر. لا يذكر السيناريو شيئاً عن كود، أو بنية تحتية، أو تخصيص يتجاوز الضبط. هذا الغياب هو الإشارة: هذا سيناريو SaaS، وأداة مثل Salesforce هي المناسبة، لا شيء يبنيه الفريق بنفسه.

غيّر القيد الآن. تعمل شركة تقنية مالية تحت لائحة تُلزمها بالتحكم بمستوى رقعة نظام التشغيل بدقة على كل خادم تشغّله، حتى إصدار النواة، وبتطبيق الرقع الأمنية بجدولها الخاص لا بجدول مزوّد. تأخذ PaaS وSaaS كلتاهما نظام التشغيل من يد العميل، وهذا بالضبط التحكم الذي تفرضه هذه اللائحة على الشركة الاحتفاظ به. يستبعد هذا الشرط الوحيد كليهما، ويترك IaaS النموذج الوحيد الذي يناسب.

السؤال الأساسي نفسه في الحالتين: إلى أي عمق في الطبقات يتطلب هذا السيناريو أن تصل. إجابة فريق المبيعات "لا شيء إطلاقاً". إجابة شركة التقنية المالية "حتى النواة نفسها".

الصلة بالمسؤولية المشتركة

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

إلى أين يقودك هذا

سؤال واحد يفصل بين هذه النماذج الثلاثة في أي سيناريو: إلى أي عمق في الطبقات يتطلب الموقف وصول المزوّد. صلاحيات root والتحكم بالنواة يجذبانك نحو IaaS. التركيز على شحن الكود بلا إدارة خوادم يجذبك نحو PaaS. غياب التثبيت وغياب المطورين داخل الفريق يجذبك نحو SaaS. ينتقل الموضوع التالي في هذا المجال بعيداً عن نماذج الخدمة، نحو اللبنات الأساسية التي يُبنى عليها كل واحد منها: المناطق، والحوسبة، والتخزين، وقواعد البيانات، والشبكات.