المنصة كخدمة (PaaS)

ماذا لو لم ترد لمس نظام التشغيل إطلاقاً

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

تعريف NIST، على أرض الواقع

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

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

من يدير ماذا، بعد التحديث

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

منتجات حقيقية تقدّم PaaS

• AWS Elastic Beanstalk: يحزم نسخ EC2 وموازن تحميل ومجموعة قياس تلقائي خلف نشرة واحدة، مبني فوق IaaS الخاصة بـ AWS في جوهره، لكنك لا تلمس تلك القطع مباشرة أبداً
• Heroku: تشغّل git push heroku main، ويكتشف Heroku لغتك، ويثبّت الاعتماديات، وينشر، دون ضبط خادم لأطر العمل القياسية
• Google App Engine وAzure App Service: المقايضة نفسها، ترفع الكود، والمنصة تشغّله

مثال محلول: التطبيق نفسه، بطريقتين

نشر تطبيق Ruby صغير عبر EC2 يعني إطلاق نسخة، وتثبيت Ruby واعتمادياته، وضبط خادم ويب، وربط موازن تحميل، وإعداد مجموعة قياس تلقائي، خطوات منفصلة عدة، كل واحدة عليك ضبطها والحفاظ على تحديثها. نشر التطبيق نفسه عبر Heroku يعني تشغيل git push heroku main. يقرأ Heroku الكود، يتعرف على حاجته لبيئة Ruby، يبنيها، ويبدأ خدمة حركة البيانات، كل ذلك من أمر واحد.

هذا ليس نسخة أصغر من المهمة نفسها. إنها مهمة مختلفة: توقفت عن إدارة البنية التحتية وبدأت بإدارة تطبيقك فقط.

الالتباس: PaaS ليست "بلا قرارات بنية تحتية إطلاقاً"

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

الحد القادم: PaaS مقابل SaaS

لا تزال PaaS تطلب منك كتابة التطبيق. هذا هو الخط الذي يمحوه الدرس التالي تماماً.

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

تقايض PaaS بعض التحكم الذي منحتك إياه IaaS بالسرعة: تتوقف عن إدارة الخوادم وتبدأ بتسليم الكود مباشرة لمنصة تشغّله. يغطي الدرس التالي ما يحدث حين لا يعود الكود نفسه ملكك لكتابته.