أساسيات الحوسبة السحابية
نماذج تسعير السحابة
الدفع عند الطلب، والطاقة المحجوزة والملتزم بها، والتسعير الفوري (Spot) عبر AWS و Azure و Google Cloud: الخصم الذي يقايضه كل نموذج مقابل التزام، وأي عبء عمل يناسب كل واحد فعلياً.
- اشرح لماذا يمنح مزودو السحابة خصماً مقابل التزام بالاستخدام، وما الذي يتخلى عنه عبء العمل للحصول على هذا الخصم
- قارن بين التسعير عند الطلب، والمحجوز والملتزم به، والفوري (Spot) من حيث حجم الخصم، ومدة الالتزام، ومخاطرة المقاطعة
- طابق بين قابلية عبء العمل للتنبؤ وتحمّله للمقاطعة وبين نموذج التسعير الذي يناسبه
- احسب التوفير الشهري الذي يحققه خصم الاستخدام الملتزم مقارنة بالتسعير عند الطلب لإنفاق معيّن
دفع السعر نفسه سواء احتجت المرونة أم لا
شغّل خادم قاعدة بيانات على مدار الساعة، كل يوم، لثلاث سنوات متتالية، وستُحاسَب رغم ذلك بالسعر نفسه لكل ساعة الذي يُحاسَب به فريق قد يوقف خادمه غداً. التسعير عند الطلب مبني لهذا الفريق الثاني تحديداً، الذي يحتاج حرية الانسحاب في أي لحظة. إن كان عبء عمل لا ينسحب أبداً، فهذه المرونة المدمجة ليست مجانية. الفريق الذي يشغّله كل ساعة دون استثناء يدفع بصمت ثمن خيار لا يستخدمه أبداً.
عند الطلب: ادفع مقابل ما تستخدمه فعلاً، وقتما تستخدمه
لا يتضمن التسعير عند الطلب دفعة مقدمة ولا التزاماً طويل الأمد. تحاسب AWS نسخ EC2 عند الطلب بالساعة أو بالثانية، بحد أدنى 60 ثانية، بسعر يحدده المزوّد ولا يتأثر بمدة كونك عميلاً. هذا هو النموذج المبني تحديداً للمشكلة التي فتح بها الدرس الأول في هذا المجال: تخمين الطاقة التي سيحتاجها عبء عمل جديد أو غير متوقع. أخطئ التخمين على التسعير عند الطلب، ويكون الحل ببضع نقرات، لا إعادة عتاد.
التسعير المحجوز والملتزم به: مقايضة المرونة بخصم
التزم باستخدام ثابت لسنة أو 3 سنوات، ويسعّر المزوّد هذا اليقين بسعر أقل. تسمي AWS هذا Reserved Instances أو Savings Plans، بخصم يصل إلى 72% عن السعر عند الطلب، مع التزام 3 سنوات يمنح دائماً خصماً أكبر من التزام سنة واحدة لأنه يزيل قدراً أكبر من عدم اليقين عن تخطيط المزوّد نفسه. يمكن تقسيم الدفع 3 طرق: All Upfront، وPartial Upfront، وNo Upfront، وعموماً كلما دفعت أكثر مقدماً، كبر الخصم.
تأتي Reserved Instances في فئتي عرض، والفرق بينهما يستحق معرفته بدقة. تثبّت Standard Reserved Instances أكبر خصم، لكن عائلة النسخة والمنطقة ثابتتان طوال مدة الالتزام؛ يمكن تعديلها ضمن حدود لكن لا يمكن استبدالها بشيء مختلف أبداً. تتنازل Convertible Reserved Instances عن جزء من ذلك الخصم مقابل حق استبدال الحجز لاحقاً بعائلة نسخة مختلفة، مفيدة لفريق يتوقع تغيّر احتياجاته قبل نهاية المدة.
يبيع مزودون آخرون الفكرة الأساسية نفسها بأسماء مختلفة. تسمي Azure نسختها Reserved VM Instances، بخصم يصل أيضاً إلى 72% عن التسعير بالدفع أولاً بأول، وتضيف شيئاً خاصاً بعملها: يتيح Azure Hybrid Benefit لشركة تملك بالفعل تراخيص Windows Server أو SQL Server تطبيقها في السحابة، مع تراكم هذا مع حجز لخصم مجمّع يصل إلى 85%. تسمي Google Cloud المعادل لهذا Committed Use Discounts، بخصم يصل إلى 55% عن أنواع الأجهزة القياسية و70% عن الأنواع المُحسَّنة للذاكرة، مقابل التزام السنة أو الـ 3 سنوات نفسه.
تضيف Google Cloud خصماً ثانياً لا تقدمه AWS ولا Azure على الإطلاق: خصم الاستخدام المستمر (Sustained Use Discount)، يُطبَّق تلقائياً، دون أي التزام من أي نوع. شغّل جهازاً افتراضياً مؤهلاً أكثر من 25% من شهر الفوترة، وتبدأ Google Cloud بخصمه من تلقاء نفسها، ويكبر الخصم كلما اقترب زمن تشغيل الجهاز من الشهر الكامل، حتى نحو 30%. على AWS وAzure، لا يوجد خصم إلا إذا التزمت به مسبقاً. على Google Cloud، مجرد تشغيل عبء عمل طويلاً بما يكفي يكسبك خصماً تلقائياً. هذا فرق بنيوي حقيقي في كيفية تسعير المزودين الثلاثة للالتزام، لا مجرد 3 أسماء للآلية نفسها.
الطاقة الفورية والقابلة للاستباق: أعمق خصم، مع مأخذ حقيقي
يبيع التسعير الفوري (Spot) طاقة فائضة يفضّل المزوّد خصمها بشدة على تركها خاملة. تخصم Amazon EC2 Spot Instances حتى 90% عن السعر عند الطلب، لكن يمكن لـ AWS استرجاع تلك الطاقة بإشعار مدته دقيقتان فقط متى احتاجتها لعميل عند الطلب أو ملتزم بدلاً منك. تخصم Azure Spot Virtual Machines حتى 90% عن أسعار الدفع أولاً بأول ولا تقدّم خيار حجز على الإطلاق. تخصم Google Cloud Spot VMs حتى 91%، ويمكن استباقها في أي وقت.
يناسب هذا النموذج العمل المتحمّل للأخطاء والمقاطعة: معالجة بيانات دفعية، وخطوط CI/CD، ومهام العرض (rendering)، أي شيء يحفظ تقدمه بتكرار كافٍ ليكلّف الانقطاع دقائق، لا مهمة فاشلة.
من المغري معاملة التسعير الفوري كنسخة أرخص فقط من التسعير عند الطلب. ليس كذلك. إنه طاقة غير ملتزم بها في جوهره، يستطيع المزوّد استرجاعها متى احتاجها عميل عند الطلب أو ملتزم يدفع فعلياً. وضع قاعدة بيانات إنتاجية، شيء لا يتحمّل إيقافاً مفاجئاً، على التسعير الفوري واحد من أكثر أخطاء تحسين التكلفة شيوعاً بين الفرق، وفخ متكرر في سيناريوهات الاختبارات لهذا السبب تحديداً.
النماذج الثلاثة، جنباً إلى جنب
| عند الطلب | محجوزة / ملتزم بها | فورية (Spot) / قابلة للاستباق | |
|---|---|---|---|
| الخصم عن سعر الطلب | لا يوجد (هذا هو الأساس) | حتى 72% (AWS، Azure)، حتى 70% (Google Cloud) | حتى 90 إلى 91% |
| الالتزام | لا يوجد | سنة أو 3 سنوات | لا يوجد |
| قابلية الانقطاع | لا | لا | نعم، بإشعار قليل أو معدوم |
| الأنسب لـ | أعباء غير متوقعة أو قصيرة العمر أو جديدة تماماً | طاقة أساسية ثابتة ومتوقعة | عمل دفعي متحمّل للانقطاع والأخطاء |
مثال محلول: ما تساويه الطاقة الملتزم بها فعلياً
لنفترض أن عبء عمل يعمل بثبات كافٍ ليبلغ فاتورته عند الطلب $1,000 شهرياً. التزم بهذا العبء بخطة Savings Plan لثلاث سنوات عند السقف الذي تعلنه AWS، حتى 72%، ويكلّف العبء نفسه نحو $280 شهرياً بدلاً من ذلك، توفير يقارب $720 شهرياً، أو نحو $8,640 سنوياً، مقابل التخلي عن القدرة على الانسحاب دون غرامة.
لا يُجدي هذا الخصم إلا إذا استُخدم الالتزام فعلاً. Reserved Instance لثلاث سنوات مُحجَّمة لمشروع يُلغى بعد 8 أشهر أصبحت الآن تكلفة ثابتة، مع 28 شهراً متبقياً ولا شيء يُشغَّل عليها، وهذا بالضبط سبب وجوب أن يتبع الالتزام استخداماً ثابتاً ومقيساً، لا تخميناً للنمو المستقبلي، مشكلة التخمين نفسها التي جعلت تقنية المعلومات التقليدية داخل الشركة مكلفة أصلاً.
إلى أين يقودك هذا
طابق الالتزام مع مدى ثقتك، ومع التكلفة الحقيقية للمقاطعة. عبء عمل يعمل كل يوم للسنوات الـ 3 القادمة ينتمي إلى سعر ملتزم به. عبء عمل يستطيع خسارة ساعة من تقدمه وإعادة التشغيل ببساطة ينتمي إلى التسعير الفوري. كل ما بينهما يبقى عند الطلب حتى يتوفر تاريخ استخدام كافٍ للالتزام بثقة. لا يروي أي من هذه الأسعار بالساعة القصة كاملة رغم ذلك: السعر في هذه الصفحة ليس الشيء نفسه الذي يكلّفه عبء عمل فعلياً لشركة تشغّله، بمجرد احتساب الأفراد والأدوات وكل ما يُبنى حوله. هذه الفجوة بالضبط ما تقيسه التكلفة الإجمالية للملكية، وهناك يذهب هذا الموضوع تالياً.
