الملخص

السؤال المفيد ليس ما إذا كانت Parler Cloud موجودة

Parler Cloud موجودة في سجلات البنية التحتية العامة. السؤال الأصعب هو ما يمكن للعميل الخارجي الاعتماد عليه عندما يفشل حساب خدمة، أو تكوين CDN، أو عقدة سحابية خاصة، أو بادئة موجهة، أو وعد أمني عند الساعة 02:00. تدعم الأدلة العامة أطروحة حذرة: تمتلك Parler Cloud هوية شبكة حية صغيرة تحت AS63322 وسرد منتج أوسع حول Triton وEdgecast ونظام Parler البيئي، لكن الأدلة لا تدعم بعد معاملة كل عبارة سحابية أو حافة مسوقة كبصمة تشغيلية مثبتة ومتاحة للعملاء.

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

لدى أدلة Parler Cloud قطبان مرئيان. على جانب واحد سجل الشبكة الضيق: AS63322، تخصيص IPv4 مباشر، ستة إعلانات توجيه IPv4 مرئية، وجاران علويان. يسمي ARIN RDAP الخاص بـ AS63322 PARLER-CLOUD ويسجل Parler Cloud كمسجل:https://rdap.arin.net/registry/autnum/63322. يسمي سجل شبكة ARIN لـ 142.147.0.0/21 PARLER CLOUD TECHNOLOGIES ويسرد الكتلة كتخصيص مباشر:https://rdap.arin.net/registry/ip/142.147.0.0. يرى RIPEstat حاليًا أن AS63322 معلن:https://stat.ripe.net/data/as-overview/data.json?resource=AS63322.

على الجانب الآخر توجد قصة الشركة والمنتج الأكبر بكثير. يقول بيان Parler أن Parler Cloud Technologies استحوذت على أصول Edgecast وتضع الخطوة حول خدمات الحافة، CDN، تسليم الوسائط، والبنية التحتية للعملاء:https://www.parler.com/releases/parler-cloud-technologies-acquires-edgios-edgecast-assets. يقدم موقع Edgecast الحالي مسرع Web3 آمن، حماية DDoS، WAF، إدارة الروبوتات، بوابة IPFS، CDN وادعاءات شبكة حافة عالمية:https://www.edgecast.io/. يقدم Triton مركز بيانات نفسه كنظام تشغيل لتشغيل الحاويات والآلات الافتراضية على المعدن العاري ويوفر روابط لوثائق المشغل للتركيب، الشبكات، المرونة، واستخدام API:https://tritondatacenter.com/documentationوhttps://apidocs.tritondatacenter.com/cloudapi.

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

AS63322 يظهر سطح شبكة حي لكن ضيق

أقوى دليل على البنية التحتية لـ Parler Cloud هو AS63322. سجل ARIN يعطي الشبكة هوية رسمية. يسرد AS63322 كنشط، يسميه PARLER-CLOUD ويسجل أحداث التسجيل والتغيير:https://rdap.arin.net/registry/autnum/63322. نفس السجل يربط المسجل بـ Parler Cloud في عنوان بلانو، تكساس ويتضمن Parler Cloud Technologies في تعليقات التسجيل. هذا لا يثبت جودة الخدمة، لكنه يؤسس لحامل توجيه حقيقي بدلاً من علامة تجارية زخرفية بحتة.

دليل تخصيص IP مهم أيضًا. صفحة ARIN RDAP لـ 142.147.0.0 تظهر تخصيصًا مباشرًا من 142.147.0.0 إلى 142.147.7.255، بطول CIDR /21 واسم الشبكة PARLER CLOUD TECHNOLOGIES:https://rdap.arin.net/registry/ip/142.147.0.0. التخصيص المباشر يعني أن المنظمة لديها موارد عنوان على جانب السجل. لا يعني أن كل عنوان نشط، نظيف، متاح للعملاء، أو مستضاف في مرفق معين.

يعطي عرض التوجيه الحالي لـ RIPEstat الصورة التشغيلية. في نافذة الاستعلام المنتهية في 2026-07-14 16:00 UTC، كان AS63322 معلنًا ومرئيًا لـ IPv4، مع ستة بادئات و1,792 عنوان IPv4:https://stat.ripe.net/data/routing-status/data.json?resource=AS63322. يسرد نقطة النهاية للبادئات المعلنة 142.147.0.0/23 وخمسة /24s: 142.147.3.0/24، 142.147.4.0/24، 142.147.5.0/24، 142.147.6.0/24 و142.147.7.0/24:https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS63322. تؤكد صفحات نظرة عامة على البادئة في RIPEstat أن 142.147.0.0/23 و142.147.3.0/24 معلنان بواسطة AS63322:https://stat.ripe.net/data/prefix-overview/data.json?resource=142.147.0.0/23وhttps://stat.ripe.net/data/prefix-overview/data.json?resource=142.147.3.0/24.

عرض الجيران الحالي بسيط. يرى نقطة نهاية الجيران في RIPEstat جارين يساريين لـ AS63322: AS174 وAS6939:https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS63322. يحدد RIPEstat AS174 كـ Cogent Communications وAS6939 كـ Hurricane Electric:https://stat.ripe.net/data/as-overview/data.json?resource=AS174وhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6939. هذا شكل عبور معقول لسطح موجه صغير. ليس دليلاً على التكرار متعدد المواقع. يمكن تسليم ASNs علويين في مرفق واحد، عبر مرافق متعددة، عبر ترتيب إعادة بيع الاتصال المتقاطع، أو عبر مزيج يتحكم فيه طرف آخر. BGP العام وحده لا يجيب على ذلك.

IPv6 غائب عن السطح المرئي الحالي. يُظهر إخراج حالة التوجيه في RIPEstat صفر بادئات IPv6 مرئية وصفر /48s لـ AS63322 في العرض الحالي:https://stat.ripe.net/data/routing-status/data.json?resource=AS63322. تظهر نقطة نهاية تناسق التوجيه AS أيضًا 2001:470:312::/48 موجودة في whois لكن ليس في BGP لتاريخ الاستعلام:https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS63322. لذلك يجب على العميل الذي لديه متطلبات IPv6 أن يعالج توفر IPv6 على أنه غير مثبت حتى تقدم Parler Cloud إجابة حالية خاصة بالخدمة.

أمان أصل التوجيه يحتاج أيضًا إلى تسمية تحذير. يعيد فحص التحقق من RPKI في RIPEstat لـ 142.147.0.0/23 مع AS63322 غير معروف، دون ROAs مصادقة في الاستجابة:https://stat.ripe.net/data/rpki-validation/data.json?resource=63322&prefix=142.147.0.0/23. نفس الحالة تظهر لـ 142.147.3.0/24:https://stat.ripe.net/data/rpki-validation/data.json?resource=63322&prefix=142.147.3.0/24. غير معروف ليس غير صالح، وليس نتيجة توقف. يعني أن الأدلة العامة لا تظهر تفويض أصل التوجيه لتلك الأزواج المفحوصة. يجب على العملاء الذين لديهم ضوابط أمان توجيه صارمة أن يسألوا عما إذا كانت ROAs موجودة في مكان آخر، وما إذا كانت مخططة، وما هو وضع أمان التوجيه المطبق على فضاء العميل.

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

PeeringDB يؤكد الهوية لكن لا يصل إلى النطاق التشغيلي

يضيف PeeringDB سياق هوية وإشارة غياب. يسرد ملف شبكة PARLER-CLOUD AS63322، الاسم الطويل Parler Cloud Technologies، LLC، الموقع الإلكترونيhttps://www.parlercloud.ioوالاسم المستعار PCT:https://www.peeringdb.com/api/net?asn=63322. يعطي ملف المنظمة عنوان بلانو ولا يظهر أي مرافق مدرجة، أو اتصالات تبادل، أو ناقلين، أو سجلات حرم جامعي:https://www.peeringdb.com/api/org/40322. يبلغ ملف الشبكة أيضًا عن عدم وجود IPv6 وعدم وجود حركة مرور أو نطاق مفصح عنه.

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

PeeringDB مفيد بشكل خاص هنا لأنه يتناقض بشكل حاد مع الملف العام الأقدم لـ Edgecast. ملف شبكة Edgecast PeeringDB لـ AS15133 يُسمى Edgecast وله اسم مستعار يشير صراحة إلى Pulse وParler:https://www.peeringdb.com/api/net?asn=15133. يبلغ عن خصائص شبكة محتوى ونطاق تاريخي ذاتي الوصف أكبر بكثير، بما في ذلك حركة مرور صادرة كثيفة ونطاق عالمي. يستخدم ملف منظمة Edgecast أيضًا عنوان بلانو مرتبطًا بـ Pulse وParler:https://www.peeringdb.com/api/org/1464. لكن عرض توجيه RIPEstat بتاريخ 2026-07-14 يحدد AS15133 على أنه غير معلن حاليًا ولا يظهر جيرانًا حاليين:https://stat.ripe.net/data/routing-status/data.json?resource=AS15133وhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS15133.

هذا الانقسام هو مركز نقطة مراقبة Edgecast. يمكن لملف دليل ذاتي الصيانة أن يحمل نطاقًا قديمًا. يمكن لـ BGP الحالي أن يظهر أن ASN القديم هادئ. يمكن أن يكون كلاهما صحيحًا في آن واحد. لا ينبغي للمشتري الاعتماد على ملف Edgecast التاريخي الأكبر ما لم تستطع Parler Cloud إظهار الأصول النشطة، وأي ASNs حية، وأي بادئات تخدم المشتري، وأي نقاط حضور في الخدمة، وأي مكتب دعم يمكنه التصرف عندما تفشل عقدة حافة أو درع مصدر.

Edgecast يجعل قصة الأعمال أكبر، لكن قصة الشبكة الحية أصغر من التسويق

استحواذ Edgecast لعام 2025 يجعل Parler Cloud أكثر من مجرد حالة استضافة صغيرة ASN. أعلنت Parler أن Parler Cloud Technologies استحوذت على أصول Edgecast من Edgio، مقدمة الصفقة كخطوة نحو منصة سحابية خاصة وخدمات حافة:https://www.parler.com/releases/parler-cloud-technologies-acquires-edgios-edgecast-assets. أبلغت مركز بيانات Dynamics عن الاستحواذ ولاحظت خططًا لإعادة تسمية أجزاء من الخدمة كـ EdgeCast Cloud Services، مع شرح أيضًا أن Akamai اشترت أصول Edgio مختارة سابقًا وأن صفقة Parler تعلقت بأصول غير مشمولة في شراء Akamai:https://www.datacenterdynamics.com/en/news/parler-cloud-technologies-acquires-assets-from-bankrupt-edgio/. إعلان Akamai نفسه عن أصول Edgio المختارة هو سياق مفيد لأنه يظهر أن ممتلكات Edgio تم تقسيمها بدلاً من نقلها كوحدة تشغيلية سليمة:https://www.akamai.com/intelligence team/press-release/akamai-completes-acquisition-of-select-edgio-assets.

هذا السياق المؤسسي مهم، لكنه لا يحل السؤال التشغيلي. لقد أشار Edgecast تاريخيًا إلى بصمة على مستوى CDN. لا تظهر أدلة التوجيه العامة الحالية تلك البصمة القديمة لـ AS15133 تعمل بنفس الطريقة. لا يزال ARIN يسرد AS15133 كنشط ومسجل لـ Edgecast Inc.:https://rdap.arin.net/registry/autnum/15133. ومع ذلك، يحدد RIPEstat AS15133 على أنه غير معلن في العرض الحالي 2026-07-14، مع صفر بادئات IPv4 حالية، صفر بادئات IPv6 حالية، وصفر جيران ملاحظين:https://stat.ripe.net/data/routing-status/data.json?resource=AS15133. تظهر نقطة نهاية البادئات المعلنة فقط رؤية قصيرة العمر لشهر يوليو 2026 لـ /24s في نافذة الأسبوعين الحالية ولا توجد مسارات حالية في أحدث وقت استعلام:https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS15133.

هذه ليست اتهامًا بأن خدمة Edgecast غير متاحة. إنها حد لما يمكن لأدلة المسار العام إثباته. يمكن لخدمة CDN أو أمن الحافة استخدام ASN آخر، أو موازن تحميل سحابي، أو حافة طرف ثالث، أو ترحيل جزئي، أو اتصال خاص، أو بيئة إطلاق هادئة. يمكن أن يكون لديها أيضًا موقع منتج قبل أن تكون خريطة حافة الإنتاج عامة بالكامل. المشكلة هي تحقق المشتري. إذا طُلب من العميل الثقة في خدمة "حافة عالمية"، فيجب أن يسأل عن أي ASNs وبادئات ونقاط حضور وسياسات توجيه ستحمل هذا النطاق المحدد.

موقع Edgecast الحالي غني بالمنتجات. تصف بيانات HTML العامة الوصفية الخاصة به "Edgecast by Triton Cloud (Parler)" كمسرع Web3 آمن مع حصانة DDoS، WAF، حماية الروبوتات، بوابة IPFS وادعاءات CDN عالمية:https://www.edgecast.io/. يتضمن النص المجمع خلف الموقع لغة تسعير وتوثيق لحماية DDoS، ميزات Web3، تكوين المصدر، التخزين المؤقت، قواعد WAF، تسليم السجلات ومسارات API:https://www.edgecast.io/pricingوhttps://www.edgecast.io/docs. تظهر هذه الصفحات عرضًا تجاريًا. لا تقدم قائمة POP حالية، خريطة مرفق، سعة مقاسة بشكل مستقل، قائمة عملاء، أو جدول أصل توجيه.

هناك تحذير آخر: DNS العام لموقع Edgecast لا يظهر بنفسه تسليم Parler Cloud الخاص. أعاد فحص DNS الحالي لـ edgecast.io وwww.edgecast.io34.111.179.208، الذي يربطه RIPEstat بـ 34.108.0.0/14 وAS396982، المحدد من قبل RIPEstat كـ Google Cloud Platform:https://stat.ripe.net/data/network-info/data.json?resource=34.111.179.208وhttps://stat.ripe.net/data/as-overview/data.json?resource=AS396982. يمكن لشركة استخدام صفحات تسويقية مستضافة على Google أثناء تشغيل بنيتها التحتية الخاصة في مكان آخر. لكن بالنسبة للمشتري، هذا يعني أن الموقع العام نفسه ليس دليلاً على حافة Edgecast ذاتية التشغيل.

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

Triton يغير سؤال الأصول من "منطقة سحابية" إلى "من يملك المعدن"

يعيد Parlercloud.io حاليًا التوجيه إلى Triton مركز بيانات:https://www.parlercloud.io/. تصف الصفحة الرئيسية العامة لـ Triton منصة بنية تحتية سحابية مفتوحة المصدر لتشغيل الحاويات والآلات الافتراضية على أجهزة يتحكم فيها المشغل:https://tritondatacenter.com/. تربط صفحة التوثيق بتركيب السحابة الخاصة، الشبكات، الحالات، الصور، المستخدمين، الصيانة، المرونة ومراجع API:https://tritondatacenter.com/documentation. دليل تركيب السحابة الخاصة صريح بأنه يمكن تثبيت Triton في الموقع ويتضمن اختيار الأجهزة، تخطيط الشبكة، تخطيط النشر، وسائط التركيب، العقد الرئيسية، وعقد الحوسبة:https://docs.tritondatacenter.com/private-cloud/install.

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

توثيق Triton الخاص يعزز أن تشغيل السحابة الخاصة كثيف البنية التحتية. يغطي توثيق الشبكة الشبكات المنطقية، تجمعات الشبكة، علامات NIC، شبكات النسيج، وقواعد جدار الحماية:https://docs.tritondatacenter.com/private-cloud/networks. يغطي توثيق شبكات السحابة العامة خدمة اسم الحاوية، شبكات النسيج، وموضوعات جدار الحماية للمستخدمين:https://docs.tritondatacenter.com/public-cloud/network. صفحة المرونة معنونة حول الخدمات الأساسية والمرونة والاستمرارية:https://docs.tritondatacenter.com/private-cloud/resilience. يغطي توثيق CloudAPI التزويد والإدارة عبر API:https://apidocs.tritondatacenter.com/cloudapi.

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

تشير الأدلة المتعلقة بـ OCP في نفس الاتجاه. رابط الحل العام لمشروع الحوسبة المفتوحة لـ Parler Cloud Technologies Enterprise Private Cloud موجود فيhttps://www.opencompute.org/solutions/45/parler-cloud-technologies-enterprise-private-cloud، وتصف مقتطفات البحث العامة حول تلك الصفحة أول سحابة خاصة مؤسسية OCP مقبولة وملهمة تعتمد على شبكات Edgecore، وحوسبة MiTAC OCP، وخدمات Parler Cloud، وبرمجيات Triton مركز بيانات. هذه إشارة عمارة أجهزة وبرمجيات. إنها ليست نفس سجل السعة الحية للعملاء الخارجيين. يمكن للتصميم المُتحقق أن يُظهر مسار بناء موثوقًا. لا يخبر المشتري أي الأرفف حية، وكم عدد العقد المثبتة، وكم عددها القابل للاستخدام، وكم هو مباع، أو أي وعود استرداد تنطبق.

لغة تصميم OCP مهمة لأنها تبقى المقال صادقًا. قصة سحابة Parler Cloud ليست فقط قصة CDN وليست فقط قصة خلفية وسائط اجتماعية. يبدو أنها تتضمن مكدس بنية تحتية حيث من المفترض أن تجتمع المعدن العاري، والشبكات، وأجهزة الحوسبة المفتوحة، وإدارة SmartOS/Triton، وخدمات الحافة معًا. هذا نموذج خدمة سحابية معقول. لكن بالنسبة لمشتري السعة المستضافة، الكفاية ليست كافية. إنهم بحاجة إلى مخزون حالي، وتنوع المواقع، وتسليم تشغيلي، وأدلة استعادة.

المواقع العامة تظهر طبقة اعتماد أخرى

تضيف أدلة الموقع العام تفصيلًا صغيرًا لكن كاشفًا: بعض خصائص الويب المتعلقة بـ Parler Cloud مرئية من خلال منصات طرف ثالث كبيرة. يعيد Parlercloud.io التوجيه إلى tritondatacenter.com، وأعاد فحص DNS لـ tritondatacenter.com 34.111.179.208، الذي يربطه RIPEstat بـ AS396982 Google Cloud Platform:https://stat.ripe.net/data/network-info/data.json?resource=34.111.179.208وhttps://stat.ripe.net/data/as-overview/data.json?resource=AS396982. أعاد فحصwww.tritondatacenter.com198.62.109.41، الذي يربطه RIPEstat بـ AS62821 MNX Solutions:https://stat.ripe.net/data/network-info/data.json?resource=198.62.109.41وhttps://stat.ripe.net/data/as-overview/data.json?resource=AS62821. تم حل Edgecast.io أيضًا إلى عنوان Google Cloud Platform في نفس الفحص.

هذه ليست عيوب خدمة. غالبًا ما تعيش مواقع التسويق والتوثيق على منصات استضافة ويب بينما تقع البنية التحتية للإنتاج في مكان آخر. لكنها أدلة تشغيلية. لا يمكن للعميل استنتاج نموذج استضافة الإنتاج لـ Parler Cloud من موقع البروشور. في الواقع، يظهر موقع البروشور أن Parler Cloud مستعدة لاستخدام استضافة خارجية للعرض التقديمي على الويب العام. هذا طبيعي. يعني أيضًا أنه يجب على المشتري أن يسأل أي الأسطح تستخدم AS63322 الخاص بـ Parler Cloud، وأي الأسطح تستخدم بنية Edgecast التحتية، وأي الأسطح تستخدم Google أو MNX أو Amazon أو Meta أو أطرافًا أخرى، وأي فريق دعم يمتلك كل نوع حادث.

الوصول العام الحالي لـ cloud.parler.com هو أيضًا نقطة مراقبة. محاولة جلب عام مباشرة أثناء هذا التمرير البحثي لم تُرجع صفحة قابلة للاستخدام قبل نافذة مهلة قصيرة:https://cloud.parler.com/. قد يكون ذلك مؤقتًا، أو خاصًا بالمنطقة، أو متعلقًا بحماية الروبوتات، أو غير ذي صلة بخدمة الإنتاج. لا ينبغي معاملته كدليل على انقطاع. يجب معاملته كسؤال مفتوح: إذا كان لدى Parler Cloud سطح تحكم للعملاء على هذا المضيف، يجب أن يعرف العملاء صفحة الحالة، وطريق الدعم، ومسار تجاوز الفشل المطبق عندما يكون سطح التحكم بطيئًا أو غير متاح.

يضيف سطح خدمة المستهلك الأوسع لـ Parler المزيد من أسئلة الاعتماد. أعاد فحص DNS لـ app.parler.com عنوان شبكة Meta في هذا التمرير، الذي يربطه RIPEstat بـ AS32934 Facebook:https://stat.ripe.net/data/network-info/data.json?resource=157.240.3.8وhttps://stat.ripe.net/data/as-overview/data.json?resource=AS32934. لا يصف ذلك منصة استضافة Parler Cloud. إنه مجرد تذكير آخر بأن الخصائص العامة يمكن تقسيمها عبر منصات خارجية. يجب على المشتري أن يطلب أدلة خاصة بالخدمة بدلاً من افتراض أن كل اسم متعلق بـ Parler يشارك قاعدة بنية تحتية واحدة.

ادعاءات السعة تحتاج إلى فصل إلى تصميم، مثبت، ومتاح للعملاء

تتضمن القصة العامة لـ Parler Cloud عدة عبارات تشبه السعة: خدمات الحافة، CDN، سحابة خاصة، حماية DDoS، شبكة عالمية، Triton، أجهزة OCP، وتحكم مستضاف. لغة السعة سهلة القراءة المفرطة. يمكن للتصميم دعم عمارة معينة. يمكن للرف أن يحتوي على خوادم مثبتة. يمكن للشبكة أن يكون لها حجم منفذ. يمكن لجدول التوجيه أن يظهر وصولية العنوان. يمكن للشركة أن تمتلك برمجيات. يمكن لموقع المنتج أن يقدم خطة. لا تخبر أي من هذه الحقائق وحدها العميل عن مقدار السعة القابلة للاستخدام والمحجوزة والقابلة للدعم الموجودة لعبء عمل اليوم.

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

يعطي AS63322 سطح توجيه حي صغير، وليس مخزون سحابي. ستة إعلانات IPv4 لا تقول كم خادمًا خلف الشبكة، وما إذا كانت تلك الخوادم موجهة للعملاء، وما إذا كانت العناوين تستخدم للإدارة، وما إذا كان أي فضاء عنوان محجوز للخدمات الداخلية، أو ما إذا كان نفس الموقع الفعلي يحمل كل الإعلانات. نقص المرافق المدرجة في PeeringDB يعني أن الأدلة العامة لا تحدد الأرفف. توضح وثائق Triton كيف يمكن تشغيل سحابة خاصة، وليس ما إذا كانت Parler Cloud قد نشرت عقدًا كافية للطلب الخارجي. تظهر صفحات Edgecast عرض منتج، وليس قائمة POP مقاسة.

سؤال المشتري عملي إذن: لحساب معين، ما هو تخصيص السعة الفعلي؟ إذا كانت الخدمة مثيل سحابة خاصة Triton، اسأل عن المنطقة، نموذج التوفر، فئة المضيف، فئة التخزين، موقع النسخ الاحتياطي، مسار الشبكة، وسياسة الصيانة. إذا كانت الخدمة هي Edgecast CDN أو تسريع Web3، اسأل عن قائمة POP، موقع درع المصدر، مسار إنهاء TLS، عمارة تنظيف DDoS، السجلات، دلالات المسح، تصعيد الدعم، وأصل التوجيه. إذا كانت الخدمة سحابة خاصة مُدارة، اسأل من يملك الأجهزة ومن لديه سلطة التدخل اليدوي.

نفس المنطق ينطبق على وعود الدعم. يمكن لفريق الدعم الإجابة على التذاكر. قد لا يكون لديه وصول فعلي إلى رف. يمكن لخدمة التحكم السحابي إعادة تشغيل مثيل. قد لا تكون قادرة على استبدال SSD فاشل دون شريك مرفق أو أجهزة. يمكن لبوابة CDN مسح ذاكرة التخزين المؤقت. قد لا تكون قادرة على استعادة مسار حافة فاشل ما لم يتماشى فريق الشبكة والعقود العلوية. لا تسمح المواد العامة لـ Parler Cloud بعد للغريب بتحديد تلك السلطات.

مسار الفشل الأول: التغييرات العلوية والتوجيه

أكثر مسار فشل وضوحًا هو التوجيه. يعتمد AS63322 حاليًا على جارين علويين ملاحظين في عرض RIPEstat: Cogent وHurricane Electric:https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS63322. إذا كان عبء عمل العميل يستخدم فضاء 142.147.0.0/21، يجب أن يعرف العميل ما إذا كان كلا المزودين العلويين متاحين في نفس الموقع، وما إذا كانت جلسات BGP متنوعة، وما إذا كانت هناك موجهات مستقلة، وما إذا كانت مرشحات التوجيه موثقة، وما إذا كان هناك تجاوز فشل مُختبر بين الناقلين.

حالة RPKI غير المعروفة هي نقطة تحكم ذات صلة. لا يعني ذلك أن المسارات خاطئة. يعني أن فحص التحقق العام لم يجد ROA مصادقة لأزواج البادئة والأصل المختبرة:https://stat.ripe.net/data/rpki-validation/data.json?resource=63322&prefix=142.147.0.0/23. يجب على العملاء الذين يهتمون بمقاومة اختطاف التوجيه، أو خدمة DDoS المُدارة، أو المشتريات العامة، أو حركة المرور المنظمة أن يسألوا عن خطة أمان التوجيه. قد تكون الإجابة "سننشر ROAs"، أو "نستخدم ضوابط المزود العلوي"، أو "لدينا سياسة توجيه مختلفة لبادئات العملاء"، أو "غير مدعوم حاليًا". كل إجابة تغير المخاطرة.

يضيف Edgecast مخاطرة تغيير توجيه أخرى. إذا اشترى العميل خدمة تحمل علامة Edgecast، يجب ألا يفترض أن AS15133 هو ASN التسليم الحي لأن بيانات RIPEstat الحالية لا تظهر AS15133 معلنًا:https://stat.ripe.net/data/as-overview/data.json?resource=AS15133. قد تستخدم الخدمة ASN آخر. قد تستخدم موازنة تحميل سحابية. قد تكون في مرحلة انتقالية. يحتاج العميل إلى خريطة تسليم حالية، وليس اسم AS تاريخي.

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

مسار الفشل الثاني: الرف والطاقة وإصلاح الأجهزة

مسار الفشل الثاني مادي. تعمل سحابة خاصة Triton على خوادم فعلية ومعدات شبكات. تشير وثائق تركيب Triton إلى اختيار الأجهزة، إعداد العقدة الرئيسية، عقد الحوسبة، وتخطيط الشبكة:https://docs.tritondatacenter.com/private-cloud/install. هذه هي النقطة. نظام تشغيل سحابي لا يلغي الأجهزة. ينسقها. إذا فشلت تغذية طاقة، إذا فقدت نسيج المفتاح بطاقة خط، إذا تدهور تجمع أقراص، أو إذا أصبحت خدمة العقدة الرئيسية غير صحية، يجب على شخص ما تشخيص وإصلاح القاعدة المادية.

لا يحدد السجل العام مرافق Parler Cloud لـ AS63322. يسرد PeeringDB لا مرافق لملف AS63322:https://www.peeringdb.com/api/net?asn=63322. يسجل ARIN عنوان عمل بلانو، لكن هذا ليس موقع مركز بيانات:https://rdap.arin.net/registry/autnum/63322. لا ينبغي للمشتري استنتاج جغرافيا المرفق من عنوان بريدي. يجب أن يسأل أين تعمل الخدمة، ومن يدير المبنى، وما إذا كانت الأرفف مؤجرة أو مملوكة، وما هو تكرار الطاقة المطبق، ومن يستبدل القطع، وما هي شروط الأيدي البعيدة الموجودة، وما هي إشعارات الصيانة المقدمة.

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

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

مسار الفشل الثالث: الدعم والفواتير وسلطة الحساب

مسار الفشل الثالث إداري. يمكن أن يحدث حادث استضافة بسبب تجديد فاتورة فاشل، أو حساب معلق، أو شهادة منتهية الصلاحية، أو DNS قديم، أو تذكرة إساءة استخدام محظورة، أو استحقاق دعم مفقود، أو ملكية غير واضحة بعد الاستحواذ. تعبر هوية Parler Cloud العامة Parler، Parler Cloud Technologies، Triton، Edgecast، مراجع Pulse/Parler في PeeringDB، وأصول Edgio المستحوذة. هذا الكثير من الأسماء لعرض بنية تحتية حساس للدعم.

يحتاج العميل إلى مسار تصعيد واحد مسؤول. إذا كانت المشكلة هي توجيه AS63322، هل NOC Parler Cloud مسؤول؟ إذا كانت المشكلة هي Edgecast CDN، هل يتعامل فريق عمليات Edgecast السابق معها؟ إذا كانت المشكلة هي مجموعة سحابة خاصة Triton، هل تدعمها مجموعة هندسة Triton؟ إذا كانت المشكلة هي سطح تسويقي مستضاف على Google Cloud، من يفتح تذكرة السحابة؟ إذا كان لدى العميل سحابة خاصة مُدارة، من لديه الإذن بإعادة تشغيل عقدة رئيسية، أو استبدال أجهزة، أو تعديل مرشحات التوجيه؟

تظهر سجلات ARIN أدوار اتصال مختلفة لـ AS63322 الخاص بـ Parler Cloud وتتضمن سجلات فنية، توجيه، DNS، NOC، إدارية، وإساءة استخدام:https://rdap.arin.net/registry/autnum/63322. هذا مفيد. لكن جهات اتصال السجل ليست التزامات على مستوى الخدمة. يجب على المشتري أن يطلب أهداف الاستجابة، وأهداف الإصلاح، وأسماء التصعيد، وتغطية 24 ساعة، وتعريفات الشدة، وقواعد إشعار العميل، وصفحة حالة. يجب أن يسأل ما إذا كانت خدمات Edgecast وTriton تشارك نفس مكتب الدعم. يجب أن يسأل ما إذا كانت التذاكر يمكن أن تنتقل من دعم البرمجيات إلى أيدي المرفق دون أن ينسق العميل أطرافًا متعددة.

الفواتير جزء من البنية التحتية لأن التعليق يمكن أن يزيل الوصول بشكل فعال مثل انقطاع التيار الكهربائي. تظهر صفحات التسعير والتسجيل الحالية لـ Edgecast عرضًا استهلاكيًا مع مستويات مجانية ومدفوعة:https://www.edgecast.io/pricingوhttps://www.edgecast.io/signup. قد يكون ذلك مناسبًا للمطورين. يعني أيضًا أن مشتري الإنتاج يجب أن يفهموا ماذا يحدث عندما يفشل الدفع، أو يتم الوصول إلى حد الاستخدام، أو يتم تشغيل مراجعة احتيال، أو يحتاج العميل إلى تغيير خطة عاجلة أثناء حادث. لا تحسم الصفحات العامة تلك الشروط.

مسار الفشل الرابع: قابلية نقل البيانات ومحلية البيانات

خروج البيانات هو ميزة الاستعادة التي يمكن للعملاء اختبارها قبل أن يحتاجوها. إذا تم استخدام Parler Cloud للحوسبة، يجب أن يعرف العميل ما إذا كان يمكن تصدير الصور، ووحدات التخزين، واللقطات، والسجلات. إذا تم استخدامها لـ CDN أو تسريع Web3، يجب أن يعرف العميل مدى سرعة نقل أسماء المضيفين، والمصادر، وشهادات TLS، وقواعد المسح، وسياسات WAF، والسجلات إلى مزود آخر. إذا تم استخدامها لسحابة خاصة مُدارة، يجب أن يعرف العميل من يتحكم في وسائط التخزين وكيف يتم حذف البيانات.

يدعم Triton إدارة الحوسبة والشبكة من خلال APIs موثقة:https://apidocs.tritondatacenter.com/cloudapi. يمكن أن يكون ذلك إيجابيًا لقابلية النقل لأن APIs يمكن أن تقلل الاعتماد اليدوي. لكن وجود API ليس نفس حقوق التصدير. يجب على المشتري أن يسأل ما إذا كان يمكنه تنزيل الصور، والحفاظ على البيانات الوصفية، وتصدير قواعد جدار الحماية، ونسخ بيانات الكائنات، واسترداد اللقطات، وأتمتة إعادة البناء خارج Parler Cloud. يجب أن يسأل أيضًا ما إذا كان أي جزء من الخدمة يستخدم تكوين Edgecast مملوكًا يصعب تكراره في مكان آخر.

محلية البيانات غير محسومة بالمثل من الأدلة العامة. تم إدراج Parler Cloud في الدليل كعالمي ولديها عنوان سجل بلانو. يوجه AS63322 كتلة IPv4 صغيرة. تشير لغة منتج Edgecast إلى خدمات حافة عالمية. يمكن لـ Triton العمل حيثما يتم تثبيت الأجهزة. لا يخبر أي من هذا العميل أين توجد بياناته، وسجلاته، ومحتواه المخزن مؤقتًا، وسجلات الدعم، أو نسخه الاحتياطية. يجب على العملاء ذوي الاحتياجات التنظيمية أن يطلبوا مصفوفة موقع: بيانات الحساب، بيانات مستوى التحكم، السجلات، ذاكرة التخزين المؤقت، درع المصدر، النسخ الاحتياطي، وصول الدعم، الحذف، واختصاص الاستجابة للاستدعاء.

قضية السيادة ليست مجردة لخدمات الحافة. قد يخزن CDN محتوى في بلدان متعددة. قد يسجل WAF بيانات طلب التعريف. قد تخزن بوابة IPFS محتوى لامركزي. قد يحمل مخبأ RPC بيانات طلب blockchain. قد تخزن مجموعة سحابية خاصة صور VM وبيانات اعتماد. إذا كان عرض Parler Cloud يعبر Edgecast وTriton واستضافة سحابية خارجية، يحتاج العميل إلى حدود مكتوبة. لا توفر صفحات التسويق العامة تلك الحدود.

من يتأثر إذا فشل مكدس Parler Cloud

المجموعة الأولى المتأثرة هي النظام البيئي الخاص لـ Parler Cloud. يصف بيان Parler الاستحواذ فيما يتعلق بـ Parler Cloud Technologies واستراتيجية منصة أوسع:https://www.parler.com/releases/parler-cloud-technologies-acquires-edgios-edgecast-assets. إذا كانت تطبيقات Parler، أو خدمات الوسائط، أو أنظمة الحساب تعتمد على بنية Parler Cloud التحتية، يمكن أن يؤثر انقطاع على المستخدمين النهائيين حتى لو لم يروا اسم Parler Cloud مطلقًا.

المجموعة الثانية المتأثرة هي المشترين الخارجيين لخدمات السحابة أو الحافة أو Web3. يستهدف موقع Edgecast العام الحالي تطبيقات العملات المشفرة، مشاريع Web3، مستخدمي CDN، خطط البث، عملاء WAF، مستخدمي إدارة الروبوتات، ومستخدمي بوابة IPFS:https://www.edgecast.io/featuresوhttps://www.edgecast.io/web3-pricing. لدى هؤلاء المستخدمين ملفات مخاطرة مختلفة. قد يتحمل موقع هواة تجاوز فشل غير مؤكد. قد لا يتحمل واجهة DeFi أمامية، محفظة، خدمة بث، أو تطبيق اتصالات عامة. بالنسبة لهؤلاء العملاء، يجب أن تعني "الحافة العالمية" مسار تسليم مُختبر، وليس مجرد واجهة ذات علامة تجارية.

المجموعة الثالثة المتأثرة هي الشبكات العلوية والسفلية. إذا كان لدى AS63322 مشكلة توجيه، فإن Cogent وHurricane Electric جيران مرئيون في العرض العام:https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS63322. إذا كانت حركة Edgecast تستخدم ASNs أخرى، فقد تشارك تلك الشبكات أيضًا. يمكن أن تؤثر تسريبات التوجيه، وشكاوى إساءة الاستخدام، وتخفيف DDoS، وسمعة البادئة على الأقران والمزودين العلويين. يجب على العملاء أن يسألوا كيف تتعامل Parler Cloud مع مكاتب إساءة الاستخدام، وتصعيدات DDoS، وسحوبات البادئة، وعناوين الاستبدال.

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

ما من شأنه ترقية الأدلة

يمكن لـ Parler Cloud ترقية الأدلة العامة بشكل مادي بإفصاح موجز عن البنية التحتية. لن تحتاج إلى كشف تفاصيل حساسة للعملاء. يمكنها نشر مناطق الخدمة الحالية، وASNs المستخدمة لكل منتج، وقائمة POP أو مركز بيانات عالية المستوى، وحالة IPv6، وحالة أمان التوجيه، ووضع RPKI، وتغطية الدعم، وسياسة إشعار الصيانة، وحدود موقع البيانات، وصفحة حالة. يمكنها التمييز بين مسارات سحابة AS63322 ومسارات تسليم Edgecast والأسطح الخارجية لاستضافة التسويق.

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

القياسات المستقلة ستساعد أيضًا. نقاط نهاية النظر العامة، واتساق جامع التوجيه، وROAs RPKI، وتحديثات مرفق PeeringDB، وتاريخ الحالة، وقياسات وقت التشغيل، وتوثيق نوافذ الصيانة كلها من شأنها تحسين الثقة. وكذلك إرشادات الترحيل الواضحة للعملاء الذين ينتقلون من ترتيبات Edgecast/Edgio القديمة إلى أي خدمة Parler Cloud جديدة.

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

الخلاصة

تستحق Parler Cloud مقالًا عن البنية التحتية لأن لديها ما يكفي من الأدلة العامة لتكون مهمة: AS63322 نشط ومعلن حاليًا؛ 142.147.0.0/21 مسجل لـ Parler Cloud Technologies؛ لدى الشركة هوية PeeringDB؛ أعلنت Parler عن استحواذ أصول Edgecast؛ أصبح Triton مركز بيانات الوجهة العامة المرئية لـ parlercloud.io؛ وEdgecast لديه موقع منتج نشط. هذه الحقائق أقوى من بطاقة دليل رقيقة وحدها.

نفس الأدلة لا تثبت بعد سحابة عالمية ناضجة ومتاحة للعملاء. AS63322 صغير وIPv4 فقط في الرؤية العامة الحالية. يسرد PeeringDB لا مرافق Parler Cloud أو اتصالات تبادل. AS15133 التاريخي لـ Edgecast غير معلن حاليًا في عرض RIPEstat. تظهر المواقع العامة اعتماديات استضافة خارجية. Triton هو مكدس برمجيات سحابة خاصة جاد، لكن القدرة البرمجية ليست نفس السعة المثبتة والمزودة بالطاقة والمدعومة بقطع الغيار للعملاء.

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