آیا Kubernetes ارزش آن را دارد؟

یک راز کوچک کثیف در دنیای ابری این است که حجم کاری کانتینر هزینه کل مالکیت بالاتری نسبت به آنچه باید دارد دارد.

من ادامه می‌دهم و این را می‌گویم: وقتی به کل هزینه مالکیت (TCO) مرتبط با Kubernetes نگاه می‌کنیم، روش‌های توسعه سنتی‌تر همچنان مزایای قانع‌کننده‌ای دارند. همانطور که در حال جمع‌آوری یک KubeCon دیگر هستیم، شاید وقت آن رسیده است که در این مورد تحقیق کنیم.

این موضع نادری است که باید اتخاذ کرد. من از کانتینرها و Kubernetes از زمانی که سال ها پیش برای اولین بار در صحنه محاسبات ابری ظاهر شدند، استفاده کرده ام. من سیستم های مقیاس پذیر متعددی را با استفاده از این فناوری بر روی ابرهای عمومی طراحی و ساخته ام، بنابراین می دانم که کار می کند و به خوبی کار می کند. حرف من این است که اغلب از آن بیش از حد استفاده می شود. سازندگان سیستم‌ها به جای یافتن راه‌حل‌هایی که بیشترین ارزش کسب‌وکار را به دست می‌آورند، به‌جای یافتن راه‌حل‌هایی که این روزها بچه‌های باحال انجام می‌دهند، انگیزه دارند.

در نتیجه، من مطمئن هستم که میلیون‌ها دلار با ادامه این اشتباهات معماری هدر می‌رود. وقت آن است که بهتر عمل کنیم. شاید شما موافق باشید.

چه چیزی را باید در نظر گرفت

همانطور که این تجزیه و تحلیل را انجام می‌دهیم، متوجه می‌شوید که برخی از این موارد ممکن است برای شما و سازمانتان اعمال شود یا نباشد. گفتن “بستگی دارد” برای بسیاری به نظر یک پلیس است، اما معمولاً پاسخ صحیح است. شما باید هر حجم کاری و مجموعه داده را ارزیابی کنید که آیا در حال مهاجرت به ابر هستید یا سیستم‌های جدید شبکه می‌سازید. شما باید برای استفاده از بهترین راه حل های فناوری برای نیازهای سیستم خود آماده باشید. متاسفم که حامل خبر بد هستم.

Kubernetes سطحی از پیچیدگی را معرفی می‌کند که ابزارهای توسعه سنتی‌تر آن را ندارند. مدیریت یک خوشه Kubernetes نیاز به درک عمیق معماری و اجزای آن، از شبکه تا ذخیره سازی و امنیت دارد. این پیچیدگی به پرسنل ماهری نیاز دارد که بتوانند محیط Kubernetes را مدیریت و بهینه کنند.

در مقابل، روش‌ها و ابزارهای توسعه سنتی اغلب بر معماری‌های ساده‌تری تکیه می‌کنند که می‌توانند با مجموعه مهارت‌هایی که اکثر شرکت‌ها از قبل دارند مدیریت شوند. البته، این از یک شرکت به شرکت دیگر بسیار متفاوت خواهد بود، اما هزینه کسب مهارت‌های Kubernetes یا آموزش کارکنان موجود معمولاً بسیار بیشتر از مزایای استفاده از این فناوری است.

یک خوشه Kubernetes به مقدار زیادی سربار نیاز دارد، اگرچه Kubernetes قول کاهش هزینه‌های زیرساخت را از طریق هماهنگ‌سازی کانتینر کارآمد می‌دهد. این شامل گره هایی است که خوشه را تشکیل می دهند و منابع مورد نیاز برای مدیریت failover. همچنین، اگر زیرساختی برای مدیریت افزونگی و مقیاس پذیری داشته باشید، کمک خواهد کرد. ممکن است منابع بیشتری نسبت به آنچه لازم است بپردازید.

رویکردهای توسعه سنتی ممکن است از معماری های یکپارچه تری استفاده کنند. انعطاف‌پذیری کمتر می‌تواند منجر به کاهش هزینه‌های سرمایه اولیه و هزینه‌های مداوم شود. من یک پروژه داشتم که سیستم مشابهی را با استفاده از هر دو روش ساخت. هزینه زیرساخت معماری یکپارچه سنتی یک سوم استقرار Kubernetes بود – فقط برای آن سیستم خاص. البته، می‌تواند دلایل دیگری برای همراهی با Kubernetes وجود داشته باشد، فراتر از این که در CV خوب به نظر برسد.

حفظ محیط Kubernetes از نظر عملیاتی پیچیده است. برای اطمینان از ایمن، کارآمد و قابل اعتماد بودن محیط، نظارت، تنظیم و به‌روزرسانی‌های مداوم مورد نیاز است. باز هم، این تعمیر و نگهداری مستمر به کارکنان ماهر و ابزارهای مدرن نیاز دارد که هم TCO را بالا می‌برد و هم در برخی موارد، آن را دو برابر می‌کند.

تنظیم و پیکربندی اولیه می‌تواند زمان‌بر و پیچیده باشد، حتی اگر Kubernetes بتواند فرآیندهای استقرار را خودکار و ساده کند. این می تواند زمان استقرار و زمان عرضه به بازار را برای بسیاری از سیستم ها به تاخیر بیاندازد و شما را در معرض خطاهای احتمالی بیشتری قرار دهد. روش‌های توسعه و استقرار سنتی ممکن است به مزایای اتوماسیون کانتینر و مقیاس‌پذیری بیشتری نیاز داشته باشند. با این حال، آنها اغلب ساده‌تر و سریع‌تر برای برنامه‌های کاربردی خاص اجرا می‌شوند.

ماهیت توزیع‌شده این سیستم‌ها خطرات و نقاط خرابی جدیدی را معرفی می‌کند. Kubernetes و استقرارهای مبتنی بر کانتینر مقیاس‌پذیری بالا و سطوح تحمل خطا را ارائه می‌کنند، به همین دلیل است که ما از آنها استفاده می‌کنیم، اما آنها مشکلاتی دارند. ما توسعه سنتی را نمی بینیم. اینها می توانند از “گسترش کانتینر” تا آسیب پذیری های امنیتی در اکوسیستم کانتینر، با ابزارهای جدیدی که برای اجرای صحیح آنها به مهارت های به روز نیاز دارند، متغیر باشد. متوجه شده ام که چه زمانی یک شکست رخ نمی دهد. این چند رخ خواهد داد. با استقرار Kubernetes، خرابی‌ها همیشه بیشتر است.

معماری‌های سنتی ممکن است گزینه‌های مقیاس‌پذیری کمتری را ارائه دهند، اما می‌توانند محیط محدودتری را فراهم کنند که امن‌تر و مدیریت آن آسان‌تر باشد. این به هزینه های کمتر و همچنین قابلیت های کمتر ترجمه می شود. گاهی اوقات، این مبادله حس تجاری خوبی دارد.

اهمیت تجزیه و تحلیل TCO

اگرچه Kubernetes و کانتینرها مزایای قابل توجهی در مقیاس‌پذیری، کارایی و استفاده از منابع ارائه می‌دهند، TCO آن‌ها گاهی اوقات ممکن است از بین برود. البته، متوجه شده ام که تحلیل TCO اغلب نادیده گرفته می شود. کسانی که این فناوری را انتخاب می کنند، در مورد مبادلاتی که انجام می شود، کنترل خوبی ندارند. من معمولاً سؤالاتی در مورد مبادله استفاده از رویکردهای سنتی تر می پرسم و اغلب نگاه های خالی و بدون پاسخ می گیرم که نشان می دهد تجزیه و تحلیل TCO انجام نشده است. از طرف دیگر، از من می پرسند که آیا می خواهم خیلی به KubeCon بروم، بنابراین وجود دارد.

پیچیدگی‌ها و هزینه‌های مدیریت یک محیط Kubernetes نشان می‌دهد که روش‌های توسعه و استقرار سنتی هنوز ارزش دارند. در واقع، اگر سازمانی با منابع محدود فناوری اطلاعات هستید، واقعاً باید به TCO توجه کنید.

پولی که برای سیستم های مبتنی بر Kubernetes خرج می شود، منابع دیگر نیازهای مبرم را حذف می کند. من یک سازمان فناوری اطلاعات را نمی شناسم که بودجه نامحدودی داشته باشد تا تمام فناوری های جدید را امتحان کند. شما باید نبردهای خود را با دقت انتخاب و انتخاب کنید.