تقنية

البودكاست: تحديات تخزين الحاويات وكيفية التغلب عليها


في هذا البودكاست ، نتحدث إلى Pure Storage من Venkat Ramakrishnan حول تحديات العملاء عند التعامل معها الحاويات والتخزين وحماية البيانات.

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

هنا ، يحذر Ramakrishnan من حلول DIY ومفتوحة المصدر ، وكذلك المتطلبات المحتملة في المهارات الداخلية التي يمكن أن تتراكم مع أن عمليات نشر الحاويات تصبح أكثر تعقيدًا.

ما هي التحديات الرئيسية للعملاء في التخزين وحماية البيانات للحاويات؟

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

لماذا يجب أن يستخدم الناس الحاويات؟ لماذا يجب أن يدير الناس kubernetes؟ على المستوى الأساسي للغاية ، توفر الحاويات تطبيقات وقابلية للبيانات – خاصة أنه يمكنك إنشاء تطبيقك في أي مكان وتشغيله في أي مكان ، […] وهذا يعطي خفة الحركة.

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

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

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

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

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

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

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

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

يبدو أن هذه القضايا تنجم عن فوائد الحاويات والكوبنيت. كيف يبدأ العملاء في معالجة هذا النوع من القضايا؟

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

مثل؟ هل لديك أي إخفاقات مثيرة للاهتمام؟

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

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

ليس عليك بناء ملف الدين الفني نفسك. لا تحتاج إلى توظيف جيش من المطورين لتشغيله. يعد توظيف المطورين الجيدين مهمة صعبة – إنها مهمة صعبة حقًا للعثور على مطورين جيدين ومهندسين جيدين ومهارات دائمًا في الطلب المستمر. لذلك ، عندما يأخذ شخص ما كل هذا DIY ، فإنه يتسجيل بشكل أساسي للحفاظ على سلسلة الأدوات ، إلى [take on] ال الدين الفني. هذه مشكلة للشركات الكبيرة مثل Google و Microsoft. كل هذه الشركات تكافح مع ديون التكنولوجيا والمؤسسات ليست موجهة لذلك.

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

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

اختيار الحلول التي تدفع لأنفسهم. يتيح لك التحكم في التكاليف ، ويتيح لك خفض نفقاتك التشغيلية وأتيح لك الحصول على المزيد من البنية التحتية. هذه الأنواع من الحلول تدفع لأنفسهم. لذا ، بينما ينتهي بك الأمر إلى الدفع [rather than getting it for] مجانًا ، يصبح في النهاية مجانيًا لأن الحل يدفع لنفسه. إنه يوفر المزيد من الكفاءة التي توفر التكاليف وتحرر مؤسستك حتى تتمكن من استخدام ذلك لبناء أشياء أخرى.

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

كيف تتعامل مع كل ذلك؟ هذا شيء واحد أقوم بتدريبه على العملاء. [Also] فكر في رحلة عميل بأكملها. ماذا يحدث عندما يتم تقاعد التطبيق؟ أو عندما يتعين عليهم الترقية إلى تطبيق جديد؟ وماذا يحدث عندما يتعين عليهم إحضار بيانات من الإنتاج إلى الاختبار ، لاختبار الإصدار الجديد من التطبيق مع بيانات الإنتاج؟ هذه كلها الأشياء التي يكتشفونها عند بدء البحث عن حلول.

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



Source link

زر الذهاب إلى الأعلى