DC West CloudSigma وسجل عبء العمل السحابي السيادي

ملخص

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

ادعاء السيادة لا يهم إلا بعد القبول

أصبحت عبارة "سحابة سيادية" سهلة الشراء وصعبة التحقق الآن. يمكن أن تعني مركز بيانات في بلد ما، أو شركة تشغيل محلية، أو عقدًا بموجب القانون المحلي، أو فريق دعم يمكن الوصول إليه باللغة المحلية، أو مستوى تحكم معزول، أو منطقة من مزودي الخدمات السحابية الكبرى مع التزامات الإقامة، أو حزمة خاصة تديرها لعميل واحد، أو مجرد غلاف تسويقي حول أجهزة افتراضية. تنتمي DC West CloudSigma إلى هذا النقاش لأن سطح CloudSigma مبني حول تقديم السحابة داخل الدولة، واستخدام موفري الخدمة، والبنية التحتية المرنة، والفصل القانوني حسب موقع السحابة. لكن هذه الادعاءات تصبح مفيدة فقط عندما تنجو من العمل الروتيني لقبول عبء العمل.

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

هذا التمييز مهم لـ CloudSigma لأن وضعها العام ليس مثل كتالوج مزودي الخدمات السحابية الكبرى. تصف الشركة منصة سحابة سيادية لموفري الخدمة، بما في ذلك موارد حوسبة وتخزين وشبكات وأمان وفواتير وأتمتة API قابلة للتكوين للتسليم داخل الدولة. كما تصف خوادم سحابية مع تحجيم حر للموارد، ومحاكاة افتراضية KVM، وصور مخصصة، ووصول جذر، وفوترة بالثانية في فترات فوترة قصيرة، وأتمتة API وعشرات المناطق داخل الدولة. الجاذبية التجارية واضحة: يمكن لموفر الخدمة أو المؤسسة أو المنظمة الخاضعة للتنظيم تجنب عائلات المثيلات الصلبة، واختيار موقع سحابي محلي، والاحتفاظ بمزيد من التحكم التشغيلي مما يسمح به عقد استضافة مُدارة بسيط.

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

لذلك يعامل هذا التقييم DC West CloudSigma كسطح تشغيلي وليس كملف مزود عام. الأدلة العامة حول علامة DC West ضيقة، بينما سطح خدمة CloudSigma واسع وموثق جيدًا. وهذا يعني أن الموقف الصحيح هو انضباط الحدود: لا تختلق عميلًا محددًا لـ DC West أو معيارًا أو حادثة أو هيكلًا محليًا؛ بدلاً من ذلك، اختبر سجل CloudSigma السحابي الذي سيتركه عبء العمل السيادي وراءه.

أدلة الموقع: الموقعية سلسلة وليست تسمية

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

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

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

الأدلة من واشنطن العاصمة مختلفة. صفحة مواقع CloudSigma تسرد موقعًا سحابيًا في واشنطن العاصمة مع رابط تطبيق ويب تحت رمز WDC وتحدد مشغل مركز بيانات وحرم IAD1. تصف مركز اتصال واستضافة في ستيرلينغ، فرجينيا، مع متطلبات أمان للمؤسسات والحكومة والمؤسسات المالية. كما تسرد سمات مادية وطاقة وتبريد وحماية من الحرائق وشهادات. هذه أدلة مفيدة لعبء عمل يريد سطحًا سحابيًا على الساحل الشرقي للولايات المتحدة. إنها ليست نفس دليل أن عبء العمل ينتمي إلى كيان محدد لـ DC West، ولا تجعل كل عبء عمل نشرًا بدرجة حكومية.

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

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

حقيقة التوفير: البنية التحتية الحرة لا تزال بحاجة إلى إيصال

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

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

نقطة النهاية للإمكانيات (capabilities endpoint) في CloudSigma تجعل هذا أكثر أهمية. تقول الوثائق إن الإمكانيات ديناميكية ويمكن أن تختلف حسب استخدام السحابة والموقع والمعلمات الأخرى. كما تقول إن الميزات غير المدعومة أو المعطلة يمكن أن تختفي من الاستجابة. هذه نقطة حاسمة للمشترين الذين يفترضون أن موقع CloudSigma واحد يتصرف مثل الآخر. قد تعتمد قصة السيادة على ولاية قضائية محددة، لكن القصة التقنية تعتمد على ما يمكن أن توفره سحابة تلك الولاية القضائية في وقت النشر. يجب أن يلتقط سجل عبء العمل المقبول الإمكانيات ذات الصلة بعبء العمل قبل قبول البناء.

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

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

هذا هو المكان الذي تختلف فيه الخدمة عن منصة مجردة بالكامل. CloudSigma تعطي العميل تحكمًا تفصيليًا؛ يجب على العميل الرد بالتحقق التفصيلي. السؤال المفيد ليس "هل أنشأت السحابة خادمًا؟" السؤال المفيد هو "هل تظهر الحالة المقبولة موارد الحوسبة والذاكرة والمشرف الافتراضي والأقراص ونوع التخزين وبطاقات الشبكة والموقع والمالك والأذونات والاشتراك والموارد القابلة للفوترة المطلوبة؟" عندما تتطابق هذه الحقول، يكون لادعاء السيادة جوهر تشغيلي. عندما لا تتطابق، يكون العميل يحمل وعدًا وليس نظامًا.

حالة التخزين: يمكن أن تفشل السيادة على طبقة القرص

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

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

تجميع التوفر (availability grouping) ووظيفة التجنب (avoid functionality) في CloudSigma مهمة أيضًا للتخزين. تشرح الوثائق أن الموارد عادة ما يتم تخصيصها لتعظيم الأداء، لكن أن الإعدادات المتكررة يمكن أن تضعف إذا شاركت الخوادم نفس مضيف الحوسبة أو شاركت الأقراص نفس مضيف التخزين. تقول إنه يمكن للعملاء الإشارة إلى أنه يجب وضع الموارد على مضيفين فعليين منفصلين ويمكنهم التحقق من التجميعات من خلال استدعاءات API للتجميع. هذا تحذير واقعي. العميل الذي يحتاج إلى تكرار لا يمكنه افتراض أن موردين مستقلين لمجرد أن لديهم أسماء مختلفة. يجب على السجل المقبول إثبات الفصل حيث يكون الفصل جزءًا من التصميم.

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

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

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

حالة الشبكة: الأسئلة العامة والخاصة والمنبع منفصلة

قبول الشبكة هو المكان الآخر الذي يمكن أن تصبح فيه لغة السيادة واسعة جدًا. قد يكون عبء العمل في البلد الصحيح ولكن لا يزال غير قابل للوصول، أو مكشوفًا بشكل زائد، أو معتمدًا على ناقل علوي قيد الصيانة، أو متصلًا بالشبكة الخاصة الخاطئة. وثائق CloudSigma مفيدة لأنها تفصل هذه المخاوف. يمكن أن تكون واجهات شبكة الخادم خاصة من خلال شبكات VLAN أو عامة من خلال تكوينات IPv4 و IPv6. يمكن أن تكون العنونة العامة ديناميكية أو ثابتة أو يدوية، وتشرح الوثائق أن تغيير تكوين NIC يتطلب عناية لأن عناوين MAC تحدد بطاقات الشبكة الموجودة وترتيب بطاقات الشبكة يقدم إلى VM.

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

واجهة برمجة تطبيقات الشبكات تعطي أدلة إضافية. شبكات VLAN هي موارد يمكن إدراجها وتفصيلها وإنشاؤها وتحريرها وإرفاقها بالخوادم. يمكن أيضًا إدارة موارد IP. API لا يجعل تصميم الشبكة آمنًا بحد ذاته. إنه يجعل حالة الشبكة قابلة للفحص. بالنسبة لعبء عمل سيادي، قابلية الفحص مفيدة لأنه يمكن للعميل تسجيل أي مسارات خاصة وعامة موجودة وأي حساب يملكها.

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

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

غالبًا ما تُباع الشبكات الافتراضية على أنها سهلة لأن السحابة تخفي الكابلات. يجب أن يجعل السجل المقبل الأمر صعبًا مرة أخرى بالطريقة الصحيحة. يجب أن يسمي الموقع وعناوين IP العامة وشبكات VLAN الخاصة وترتيب NIC ووضع DHCP أو الثابت وتوقع جدار الحماية واعتماد المسار وصفحة الحالة ومسار الدعم. إذا كانت هذه التفاصيل مفقودة، فإن خطأ الشبكة لن يكون مجرد انقطاع. سيكون جدالًا حول ما تم بناؤه بالفعل.

التحكم في العميل حقيقي، وكذلك عبء العميل

أقوى ادعاءات التحكم في العميل في CloudSigma مباشرة. تصف الوصول الجذر أو الإداري الكامل، والصور المخصصة، وأي نظام تشغيل متوافق، والتحجيم الحر، وأتمتة API. مادة الخصوصية القانونية تقول إن العميل يحتفظ بالوصول الجذر أو الإداري الكامل الوحيد على مستوى نظام الملفات لبياناته، وأن نظام المقاول لا يملك الوصول أو الرؤية داخل الخوادم السحابية أو بيانات القرص. هذا بيان تحكم ذو معنى للعملاء الذين يريدون استقلالية البنية التحتية.

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

سجل التحكم في الوصول يستحق اهتمامًا خاصًا. وثائق ACL الخاصة بـ CloudSigma تقول إن الأذونات يمكن منحها لمستخدم آخر لإدارة الموارد، بما في ذلك بدء أو إيقاف الخوادم، وإرفاق الموارد، وفتح VNC، والاستنساخ، والقائمة، والتحرير. كما تشرح أن الموارد تدعم حقول المالك والأذونات. هذا مفيد لموفري الخدمة وفرق المؤسسات لأنه يتيح الإدارة المشتركة. إنه أيضًا سطح مخاطرة. يمكن لـ ACL سيئة تحويل سحابة محكومة إلى مشكلة تغيير مشترك.

يجب أن يشمل سجل عبء العمل المقبول من يملك الخادم والأقراص وشبكات VLAN وعناوين IP؛ وأي ACLs تمنح أي حقوق؛ وأي المستخدمين يمكنهم بدء أو إيقاف أو استنساخ أو إرفاق الموارد؛ وأي مفاتيح عامة مرفقة؛ وأي بيانات وصفية موجودة؛ وما إذا كانت سجلات التدقيق تظهر تاريخ الفاعل المتوقع. واجهة برمجة تطبيقات سجل التدقيق في CloudSigma تتبع التغييرات التي أجراها العميل أو أطراف أخرى مثل موظفي CloudSigma أو الأشخاص المصرح لهم. هذه ميزة مساءلة كبيرة، لكن فقط إذا تم استخدامها. المشتري الذي لا يفحص السجلات أبدًا لن يستفيد من وجودها.

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

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

استمرارية الدعم سير عمل وليس وعدًا

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

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

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

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

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

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

اقتصاديات الوحدة: المرونة تنافس مع الحجم

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

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

لذلك تتحول اقتصاديات الوحدة إلى الاستبدال. البديل ليس دائمًا AWS أو Azure أو Google Cloud. يمكن أن يكون مجموعة محاكاة افتراضية محلية، أو مزود استضافة محلي، أو مزود خدمة مُدارة، أو سحابة خاصة قائمة على VMware، أو سحابة إقليمية بمجموعة منتجات أضيق، أو منطقة من مزود خدمات سحابية كبير مع التزامات تعاقدية لإقامة البيانات. كل بديل ينقل التكلفة بين رأس المال والعمليات والترحيل والدعم والارتباط. يمكن لدقة الموارد في CloudSigma أن تقلل من التجهيز الزائد لبعض أعباء العمل، بينما يمكن لنظامها البيئي الأصغر أن يزيد من عمل التكامل للآخرين.

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

إعلان الشراكة مع OCRE و GEANT مهم أيضًا كسياق. قالت CloudSigma علنًا إنها تم اختيارها كشريك سحابي رسمي لمشروع Open Clouds for Research Environments، الذي يهدف إلى اعتماد السحابة البحثية الأوروبية. هذا لا يشهد على كل عبء عمل سيادي، لكنه يظهر أن CloudSigma سعت إلى أسواق حيث يهتم المشترون المؤسسيون بخيار السحابة وأعباء العمل البحثية والتسليم الأوروبي. إنه مصدر إشارة سوقية، وليس دليلًا شاملاً على الملاءمة.

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

أنماط الفشل محددة تشغيليًا

أنماط الفشل المعروفة لـ DC West CloudSigma ليست غريبة. إنها حالات الفشل العادية التي تصبح أكثر تكلفة عندما توقع المشتري أن السيادة ستبسطها.

عدم تطابق التوفير هو الأول. يمكن إنشاء خادم بوحدة معالجة مركزية أو ذاكرة أو مشرف افتراضي أو قرص أو NIC أو منطقة أو مالك خاطئ. API لـ CloudSigma يجعل هذه الحقول مرئية، وهي ميزة، لكن الرؤية تساعد فقط إذا قام العميل بفحصها. سجل قبول جيد يقارن البناء المقصود بالبناء المعاد قبل نقل حركة المرور.

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

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

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

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

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

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

مفاجأة الفوترة هي الثامن. استهلاك الموارد الحر والاشتراكات وحركة المرور وعناوين IP وشبكات VLAN والتخزين والتراخيص مفيدة عند تتبعها ومكلفة عند تجاهلها. CloudSigma يعرض رصيد وتسعير واستخدام وواجهات برمجة تطبيقات الاستخدام الحالي. يجب على المشتري التوفيق بينها وبين قبول عبء العمل ومع سجلات التغيير الجارية.

فشل العودة للترحيل هو التاسع. نقل السحابة السيادية لا يكتمل عند بدء تشغيل VM. يكتمل عندما يتم اختبار البيانات والمسارات والهوية والنسخ الاحتياطي والمراقبة والتكلفة والدعم والعودة بما يكفي للمخاطرة التجارية. منصة CloudSigma تعطي العملاء العديد من عناصر التحكم المباشرة؛ لا تجعل العودة تلقائية.

ما يجب على العميل الجاد قبوله

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

ثم الشبكة: عناوين IP العامة، شبكات VLAN الخاصة، ترتيب NIC، وضع العنوان الثابت أو الديناميكي، توقع جدار الحماية، وصفحة حالة الموقع. ثم التحكم: المستخدمون، قوائم التحكم في الوصول، سجلات التدقيق، رصيد الفوترة، الاشتراكات، افتراضات التسعير، ومراجعة الاستخدام. ثم التشغيل: المراقبة، قنوات الصيانة، التصعيد، العودة، والملكية.

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

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

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

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

الحكم: مفيد حيث يوجد انضباط الأدلة

يجب الحكم على سجل عبء العمل السحابي السيادي المقبول لـ DC West CloudSigma من خلال الأدلة وليس الصفات. سجل CloudSigma العام يوفر لبنات بناء مفيدة: مواقع مسماة، لغة فصل قانوني، هوية شركة سويسرية، شروط معالجة البيانات ومستوى الخدمة، موارد API صريحة، حالة الخادم والقرص، قواعد واجهة الشبكة، تجميع التوفر، قوائم التحكم في الوصول، سجلات التدقيق، نقاط نهاية الفوترة والاستخدام، صفحات حالة الموقع، وتحديد المواقع التجارية الموجهة للشريك. هذه اللبنات أقوى من كتيب سحابة إقليمي عام.

إنها لا تزيل عدم اليقين. السجل العام لا يثبت عبء عمل عميل محدد لـ DC West، أو نتيجة أداء خاصة، أو بنية مخفية، أو حادثة عميل، أو ترتيب تشغيل محلي يتجاوز ما تنشره CloudSigma. كما أنه لا يمحو الفرق بين منصة يديرها المزود وبيئة ضيف يديرها العميل. لا يزال المشترون بحاجة إلى الإشراف على التوفير والتخزين والشبكات والوصول والفوترة والدعم والعودة.

هذا هو التوازن الصحيح. قيمة CloudSigma حقيقية عندما يريد المشتري التحكم ويكون مستعدًا للعمل مع التحكم. إنها أضعف عندما يريد المشتري أن تعني السيادة قرارات أقل. السجل المقبول هو خط التقسيم. إذا كان DC West CloudSigma يمكن أن يترك وراءه سجلًا نظيفًا للموقع والحوسبة والتخزين والشبكة والتحكم والدعم والتكلفة، يمكنه خدمة أعباء العمل الحساسة للسيادة التي تتناسب مع نموذج IaaS. إذا كان السجل مفقودًا، فإن لغة السيادة لا تنقذ النشر.