ما مدى جودة استراتيجية الخروج من السحابة لديك؟

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

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

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

هنا يأتي دور بنية الخروج من السحابة.

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

لماذا تُعد قابلية النقل متطلبًا تجاريًا؟

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

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

في تلك المرحلة، أنت لا تستخدم السحابة حقًا. بل هي التي تستخدمك.

كيف يمكن تصميم الأنظمة للخروج من السحابة؟

يجب أن تنتقل الهوية

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

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

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

البيانات هي الفخ الحقيقي

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

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

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

الشبكات تحدد مدى تعلقك

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

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

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

يجب أن تصف البنية التحتية كتعليمات برمجية النية

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

المشكلة هي التظاهر بأن هذا قابل للنقل لأنه تعليمات برمجية.

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

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

الخدمات الأصلية ليست العدو

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

الارتباط بمزود واحد ليس سيئًا دائمًا. الارتباط العرضي هو السيئ.

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

جرّب الأداة: منسق ومتحقق JSON