خدمات الحوسبة

ما الذي تستأجره فعلياً

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

الأجهزة الافتراضية: الوحدة الأساسية

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

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

تتبع أحجام النسخ داخل العائلة الواحدة نمط مضاعفة: من large إلى xlarge إلى 2xlarge، تقريباً بمضاعفة عدد المعالجات الافتراضية والذاكرة عند كل خطوة. رأيت في درس IaaS أن t3.micro، بمعالجين افتراضيين وذاكرة 1 غيغابايت، يكلّف نحو $7.59 شهرياً قبل احتساب التخزين. الانتقال لحجم أكبر يضاعف تقريباً الموارد والفاتورة معاً؛ الانتقال إلى عائلة مختلفة بحجم مشابه يغيّر نسبة الموارد بدلاً من ذلك.

التوسّع الرأسي مقابل التوسّع الأفقي

لنقل إن التطبيق نفسه بدأ يتأخر في الاستجابة تحت الضغط. نظرة سريعة على مقاييسه تُظهر المعالج عند 100% بينما استخدام الذاكرة منخفض. توجد طريقتان مختلفتان للاستجابة، وليستا قابلتين للتبادل.

التوسّع الرأسي يكبّر النسخة الحالية إلى نسخة أكبر، معالجات وذاكرة أكثر، الجهاز نفسه. بسيط، لكن له سقف، أكبر نوع نسخة متاح في العائلة، ويقاطع الجهاز لحظياً أثناء التكبير.

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

بالنسبة للتطبيق الذي وصلت معالجته إلى 100% بينما ذاكرته سليمة، تحل كلتا الخطوتين العرض. أي واحدة يختارها فريق حقيقي يعتمد على ما إذا كان التطبيق مبنياً للعمل على أكثر من نسخة في آن واحد، وهذا سؤال تصميم، لا سؤال حوسبة، لكنه سؤال تفرضه عليك خيارات الحوسبة نفسها.

الحوسبة المُدارة: من يشغّل الأسطول نيابة عنك

قابلت بالفعل AWS Elastic Beanstalk وGoogle App Engine ومنتجات مشابهة كأمثلة على PaaS. في الخلفية، ما زالت تشغّل كودك على أجهزة افتراضية، والفرق هو من يوفّر ويشغّل تلك الأجهزة. تتولى منصة الحوسبة المُدارة إطلاق النسخ، ونشر إصدارات جديدة من كودك، وفي أغلب الحالات، توسيع الأسطول صعوداً وهبوطاً مع تغيّر الزيارات. أنت من يختار بيئة التشغيل ويزوّد التطبيق؛ تتوقف عن كتابة السكريبتات التي كانت ستوفّر النسخ وتراقبها يدوياً.

طيف الحوسبة الكامل

الأجهزة الافتراضية والحوسبة المُدارة نقطتان على خط أطول. تقع الحاويات والدوال بلا خوادم أبعد على ذلك الخط، ويفرد هذا المجال درساً كاملاً لكل واحدة منهما لاحقاً. الآن، شكل الطيف كله أهم من آلية أي محطة بمفردها.

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

الالتباس: "الحوسبة بلا خوادم أرخص دائماً"

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

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

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