عندما لا تنجح علاقات (خدمة التقنية)

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

تذكر تلك الأيام عندما قابلت حب حياتك. كانت المشاعر متبادلة. بدا العالم مكانًا أفضل، وكنت في رحلة مثيرة مع شريك حياتك. كنتما كلاكما “مستثمرين بالكامل” بينما كنتما تخططان لحياة معًا.

كانت الحياة رائعة… حتى لم تعد كذلك.

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

صدق أو لا تصدق، علاقتنا بالتكنولوجيا ليست مختلفة كثيرًا.

الانفصال عن خدمة

كان هناك وقت قررت فيه اعتماد خدمة – ربما كانت خدمة SaaS، أو PaaS، أو شيء أكثر عمومية. في ذلك الوقت، هل اتخذت القرار مع مراعاة الوقت الذي لن تخطط فيه لاستخدام الخدمة بعد الآن؟ على الأرجح لا. كنت تفكر فقط في جميع الاحتمالات الرائعة للمستقبل.

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

أحيانًا، يبدو فك الارتباط المثالي على النحو التالي: توقف عن الدفع مقابل الخدمة، لكن احتفظ بالوصول إلى مصدر البيانات لفترة من الزمن. هل هذه حتى إمكانية؟ نعم، هي كذلك!

قوة الربط الافتراضي بين الشبكات

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

تسمح لنا VPCs بمنح الوصول إلى موارد أخرى في نفس مزود الخدمة السحابية، ولكن يمكننا أيضًا استخدامها لـ منح الوصول إلى خدمات خارجية. اعتبر خدمة تم التخلي عنها مؤخرًا ولكن مع ترك مصدر البيانات الأصلي في مكانه. إليك كيف يمكن أن يبدو:

تسمى هذه الفكرة ربط VPC، وهي تسمح بإنشاء اتصال خاص من شبكة أخرى.

مثال على ترحيل الخدمة

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

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

إليك كيف سيبدو الترتيب الجديد:

ربط VPC مع Heroku

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

بعد ذلك، ستحتاج إلى تلبية المتطلبات الشبكية البسيطة التالية:

  • يجب أن يستخدم VPC كتلة CIDR IPv4 متوافقة في تكوين الشبكة الخاصة به.
  • يجب أن يستخدم VPC كتلة CIDR RFC1918 (10.0.0.0/8، 172.16.0.0/12، أو 192.168.0.0/16).
  • يجب ألا تتداخل كتلة CIDR الخاصة بـ VPC مع نطاقات CIDR لمساحتك الخاصة. النطاقات الافتراضية هي 10.0.0.0/16، 10.1.0.0/16، و 172.17.0.0/16. 

مع تشغيل مساحتك الخاصة، ستحتاج إلى استرداد معلومات الربط الخاصة بها:

Shell

 

انسخ معرف حساب AWS (647xxxxxx317) و معرف VPC لـ AWS (vpc-e285ab73). ستحتاج إلى تقديم هذه المعلومات لمزود الطرف الثالث الذي يتحكم في مصدر بيانات AWS. من هناك، يمكنهم استخدام إما واجهة التحكم AWS أو CLI لـ إنشاء اتصال تشاركي. ستبدو عمليتهم مثل هذا:

Shell

 

يتم إنشاء طلب التشارك. بمجرد أن يفعل ذلك مزود الخدمة، يمكنك عرض الطلب المعلق من جانب Heroku:

Shell

 

في اللقطة أدناه، يمكننا رؤية حالة الانتظار لاتصال التشارك.

من هنا، يمكنك قبول طلب الاتصال التشاركي:

Shell

 

نتحقق من حالة الطلب مرة ثانية:

Shell

 

نرى أن اتصال التشارك نشط.

في هذه النقطة، ستتمكن التطبيق الذي يعمل في مساحة Heroku الخاصة لدينا من الوصول إلى مصدر بيانات AWS دون أي مشاكل.

الاستنتاج

حقيقة محزنة في الحياة هي أن العلاقات قد تكون غير ناجحة بنفس التكرار الذي تكون فيه طويلة الأمد. ينطبق هذا على الناس، وينطبق على التكنولوجيا.

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

لحسن الحظ، توفر Heroku حلاً للانتقال ببطء بعيدًا عن الحلول السحابية الحالية مع الاحتفاظ بالوصول إلى البيانات المستضافة خارجياً. تتيح لك التكامل السهل لـ VPC peering with AWS الوصول إلى الموارد التي تحتاج للاستمرار في التنفيذ التقليدي، حتى لو انتقلت باقيك.

سيسمح اتباع هذا النهج لخدمتك الجديدة بالازدهار دون انقطاع في خدمة المستهلك.

Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out