ما یک خوشه Mesos 70 هزار گره برای توسعه دهندگان خود ساخته ایم، اما آنها از آن استفاده نمی کنند. آیا می توانید کمک کنید؟» این آغاز گفتگو با معاون عملیات زیرساخت در یک شرکت بسیار بزرگ و مشهور بود. اگرچه موفقیت چشمگیر برای انجام آن بود، اما به مراتب بزرگترین راه اندازی زیرساخت کانتینری بود که دیده بودم که استفاده نشده بود و متاسفانه این یک حادثه منحصر به فرد نبود
.من در مورد این برخورد با تعداد زیادی از مشتریان، تحلیلگران، دوستان، همکاران، شرکا، سرمایه گذاران خطرپذیر و رقبا صحبت کرده ام. همه ما تجربیات مشابهی را بیان کردیم و همه می خواستیم بدانیم چرا چنین است. به هر حال، اگر منابع زیادی در صنعت ما هدر می رود، همه ما با درک و حل نکردن مشکل به خطر زیادی می رویم. در غیر این صورت، موج بعدی پذیرندگان ممکن است شک کنند که کانتینر ها می توانند به کسب و کارشان کمک کنند و همه ما باید شروع به اصلاح رزومه های خود کنیم.
من باید در اینجا صادق باشم: من یک توسعه دهنده، یک مهندس و یک تکنولوژیست هستم که عاشق ساخت محصولات و استفاده از آخرین فن آوری ها هستم. بنابراین، اولین جایی که در تلاش برای یافتن پاسخ به این سوال ۷۰۰۰۰ گره به آن نگاه کردم، تکنولوژیهای مورد استفاده بود. آیا Mesos تکنولوژی اشتباه بود؟ آیا به روش اشتباهی اجرا شده است؟ آیا آنها از منبع باز استفاده می کردند یا از منبع بسته استفاده می کردند؟ آیا یک SI درگیر بود؟ سوالاتی مثل این ابتدا به ذهنم افتاد. در عقب نگاهی فکر می کنم احتمالا این سوالات اشتباه بوده اند
.پاسخ به من زمانی رسید که روزی از شغلم ۱۵ سال پیش را به یاد آوردم: پشت میز کار خود به عنوان یک توسعه دهنده در یک بانک بزرگ نشسته بودم، یادم می آید که فروشندگان لباس بی عیب و نقص به اتاق جلسات ما می آمدند و به اتاق جلسات ما می رفتند و با معاون زیرساخت و تیمش دوست داشتند. آنها از VMware بودند، در آن زمان شرکتی برای زیر ساخت های مجازی شده. من فقط یک توسعه دهنده در بانک بودم، اما حتی رئیس من یا رئیس او یا حتی رئیس رئیس او به هیچ یک از رویدادهای شام استیک خانه دعوت نشده بودند که تقریباً هر هفته افراد VMware میزبانی می کردند. فروشندگان VMware فقط به تصمیمگیرندگان عملیات و زیرساخت علاقه داشتند. دو یا سه ماه بعد، به تیم ما گفته شد که قراردادی با VMware امضا شده است و ما به زودی خدمات خود را به VMs منتقل خواهیم کرد و کمی پس از آن این حرکت طی چند آخر هفته انجام شد
.سپس یک صبح روز دوشنبه، خدماتی که تیم من مسئول آن بودند، به جای سرورهای قدیمی با چراغ های آبی چشمک زن و برق و طرفداران پر سر و صدا بر روی ماشین های مجازی کار می کردند. همش همین بود. کل زیرساخت های ما در عرض چند ماه مجازی شد بدون اینکه توسعه دهندگان حرفی بزنند، و در حالی که ما در حال مقاومت جعلی برای این تغییر بودیم (و چه کسانی تغییر را دوست دارند؟) و با ناامیدی موافقت کردیم که چند آخر هفته در حالت آماده به کار باشیم، واقعاً نمی توانستیم تفاوت بین تنظیمات قدیمی و جدید بگوییم: همه چیز یکسان بود. سرورهای VM ما رفتار می کردند و مانند سرورهای «واقعی» احساس می کردند. من مطمئن هستم که ما نمی توانستیم تفاوت را در یک آزمایش دوکور تشخیص دهیم اگر شخصی آن را انجام داده بود
.به یاد آوردن آن روزها باعث شد تعجب کنم که چرا موج کانتینری جدید تغییر زیرساخت ها به همان شیوه کار نمی کند. چرا نمی توانیم یک خوشه Mesos یا Kubernetes را طی یک یا دو آخر هفته بسازیم و یادداشتی را برای توسعه دهندگان با موضوع ارسال کنیم: «به آینده زیرساخت ها خوش آمدید. خوش آمدید!»؟
پاسخ همانطور که همه می دانیم این است که کانتینریزاسیون بدون دخالت و خرید توسعه دهندگان کار نمی کند. توسعه دهندگان نیاز به ساخت برنامه هایی برای یک تنظیمات کانتینر دار دارند، اما ذاتی در کانتینر ها، با APIهایی مانند Kubernetes در سراسر چرخه عمر نرم افزار، ضروری است که توسعه دهندگان و اپراتورها تغییر نحوه کار و ارتباط با یکدیگر را تغییر دهند. دلیل وجود یک خوشه براق ۷۰۰۰۰ گره که به جای برنامههای تجاری، tumbleweed را اجرا میکند این است که ابزارهایی که برای این انتقال جدید ساخته ایم، به این تغییر اساسی و ضروری سازمانی، یعنی پیوستگی توسعه دهندگان و اپها، پرداختن نمیکنند. واقعیت هیجان انگیز این است که راه اندازی زیرساخت های کانتینری آسان تر می شود، زیرا راه حل های منبع باز فراوانی وجود دارد که شما را با یک خوشه Kubernetes آماده می کند. اگر در حال حاضر بر روی یک ارائه دهنده ابری بزرگ کار می کنید، فقط چند کلیک فاصله دارید تا خوشه کانتینری خود را داشته باشید، مدیریت، سرویس داده شده و هر دقیقه صورتحساب کنید. مزایای اجرای یک زیرساخت کانتینری برای تیم های عملیاتی قابل مشاهده است: سرورهای تک پیکربندی (دیگر «دانه های برفی» وجود ندارد)، در دسترس بودن و انعطاف پذیری بالا داخلی و بهبود استفاده از منابع، برای ذکر چند مورد. توسعه دهندگان همچنین ارزش اجرای در یک تنظیمات کانتینری را می بینند: نفوذ بیشتر بر محیط در حال اجرا، کنترل بهتر بر کتابخانه ها و وابستگی ها و کاهش شکاف بین محیط های تولید و توسعه برخی از این موارد است. هر طرف این معادله (devs و ops) فروشندگان، ابزارها و پروژه های منبع باز خاص خود را دارد تا به آنها در آنچه برای حرکت به یک دنیای کانتینر لازم است کمک کند - اما این کافی نیست. ما هنوز چارچوبی را برای توسعه دهندگان و اپراتورها برای همکاری با یکدیگر برای موفقیت در دست داریم. ابزارها و فن آوری های بسیار کمی در دسترس هستند که این ارتباطات را تسهیل می کنند.
همه ما آنقدر روی حوزه های نوآوری خود - از شبکه گرفته تا ذخیره سازی و ارکستر - متمرکز هستیم که می توانیم تمرکز خود را بر دستیابی مشتریانمان به اهداف تجاری خود از دست بدهیم. در چنین محیطی، شرکت های ادغام کننده سیستم، مشاوره و خدمات حرفه ای عملکرد خوبی دارند، زیرا آنها تنها کسانی هستند که بر نتیجه و ارائه در سراسر زنجیره تامین نرم افزار متمرکز هستند؛ اما این پایدار نیست. تکنولوژیهایی که مشتریان را ملزم میکنند تا این حد به مشاوران پرداخت کنند تا آنها کار کنند، تکنولوژیهای پیشرفته نخواهند بود. بیایید با آن روبرو شویم: اگر مجازی سازی نیاز داشت که مک کینزی همیشه در لیست حقوق و دستمزد حضور داشته باشد تا کار کند، امروز هیچ ابر وجود نخواهد داشت
.برای اینکه همه ما بتوانیم از یک فناوری پیشرفته مانند کانتینری سازی زیرساخت بهره مند شویم، باید گستردهتر از ابزارهای تک منظوره یا حوزه های تمرکز اولیه خود فکر کنیم و نحوه ساخت محصولات برای این صنعت را تجدید نظر کنیم. این با انقلاب مجازی سازی و ابر متفاوت است و هرچه زودتر متوجه آن شویم، مزایای مشتریان ما بیشتر خواهد بود.
Devops فقط یک دسته از ابزارهای تکه شده یا یک پروژه فانتزی «تحول دیجیتال» نیست، بلکه روشی برای کار مشترک بین توابع است که توسط تکنولوژی فعال می شود. بنابراین، هر فناوری با هدف بازار devops، به ویژه در حوزه کانتینریزاسیون، باید قبل از هر چیز دیگری ذهنیت همکاری مداوم را بررسی کند. بنابراین، بیایید همه محصولات را با این در نظر بسازیم تا مکالمه ای بین توسعه دهندگان و اپراتورها را شروع و حفظ کنیم.
این پست برای اولین بار در اینجا منتشر شد