5 تحديات للذهاب إلى السحابة الأصلية - وكيفية حلها

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

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

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

ما هو مواطن السحابة؟

أولاً ، على الرغم من ذلك ، كلمة حول ما يعنيه السحابة الأصلية.

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

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

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

التحديات التي تواجه اعتماد السحابة الأصلية

1) تخزين البيانات المستمرة

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

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

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

2) تكامل الخدمة

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

ولكنه يعني أيضًا أن أعباء العمل الأصلية السحابية لديها العديد من القطع المتحركة التي تحتاج إلى ربطها معًا بسلاسة لتحقيق النجاح.

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

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

3) الإدارة والرصد

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

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

4) تجنب قفل السحابة

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

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

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

5) بناء تطبيقات خطوط أنابيب التوصيل السحابية الأصلية

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

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

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

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

خاتمة

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