سرورهای دانه برف را بکشید تا ابر بتواند جای آنها را بگیرد

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

طبق اسطوره‌های یونانی، اگر بخواهید به دریاچه خاصی در لرنا بروید، هیدرای چند سر را می‌بینید، یک هیولای آبی مارپیچ که راز معماری مدرن ابر را در خود دارد. چرا؟ از بین بردن این چیز سخت است، دقیقاً مانند آنچه می خواهید زیرساخت ابری شما باشد. شما یک سر را قطع می کنید و دو سر دیگر رشد می کند.

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

ما پتانسیل واقعی اتوماسیون زیرساخت را برای ارائه راه‌حل‌های خودترمیمی و مقیاس‌پذیر خودکار با در دسترس بودن بالا از دست داده‌ایم. چرا؟ زیرا همه افراد در C-suite انتظار دارند یک انتقال به موقع و مرتب به ابر، با کمترین تغییر واقعی ممکن انجام شود.

این تیم‌ها را تشویق می‌کند تا پایگاه کدهای قدیمی خود را به ماشین‌های مجازی (VM) که دقیقاً شبیه مرکز داده اولیه آنها هستند، «بالا و تغییر» دهند. در حالی که سناریوهایی وجود دارد که در آنها این رویکرد ضروری و مناسب است – مانند زمانی که از یک مرکز داده اجاره ای مهاجرت می کنید در یک مهلت بسیار محدود – در بیشتر موارد شما فقط به یک دگرگونی واقعی دست می زنید. تیم‌ها که در ظاهری آشنا هستند، همچنان بر پیکربندی‌های دانه‌های برف گذشته تکیه می‌کنند، در حالی که حتی استقرارهای ظاهراً «اتوماتیک» همچنان نیازمند بهینه‌سازی دستی سرورها هستند.

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

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

نتیجه نهایی؟ علیرغم انجام سرمایه‌گذاری‌های قابل توجه در فضای ابری، سازمان‌ها از این فرصت استفاده کردند تا از قابلیت‌های آن استفاده کنند.

چرا هرگز با استقرار سرویس‌های رایانش ابری AWS، Azure، Google Cloud یا سایر سرویس‌های رایانش ابری به همان روشی رفتار می‌کنید که با یک مرکز داده در حالی که ایدئولوژی‌های حاکم اساساً متفاوتی دارند، رفتار می‌کنید؟

خشم علیه ماشین مجازی. بدون تابعیت بروید.

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

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

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

ما باید از Google به خاطر خروج از سرورهای بزرگ اولیه و کالایی کردن بارهای کاری که این مقیاس سریع رعد و برق را ممکن می‌کند تشکر کنیم. لری پیج و سرگی برین را در گاراژ با ۱۰ هارد ۴ گیگابایتی روی هم در کابینت ساخته شده از LEGO که با یک سری کامپیوترهای رومیزی کالا به هم متصل شده اند. آنها اولین گوگل را ایجاد کردند در حالی که جرقه انقلاب “من دیگر به سرور بزرگ نیاز ندارم” را برانگیختند. وقتی می‌توانید از قدرت محاسباتی استاندارد برای به کارگیری آنچه نیاز دارید، در مواقعی که به آن نیاز دارید، استفاده کنید، و به محض اینکه کارتان تمام شد، آن را ارسال کنید، چرا زحمت بکشید؟

بازگشت به ظروف. ظروف را به عنوان سر هیدرا در نظر بگیرید. وقتی یکی از کار می افتد، اگر ابر خود را به درستی در Kubernetes، Amazon ECS، یا هر سرویس هماهنگ کانتینری دیگر پیکربندی کرده باشید، ابر به سادگی آن را بلافاصله با کانتینرهای جدیدی جایگزین می کند که می توانند از جایی که فرد افتاده ادامه دهد.

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

معماری مبتنی بر هیدرا چه شکلی است؟

اکنون که می‌دانیم چرا سرهای هیدرا برای معماری ابر امروزی ضروری هستند، چگونه آنها را ایجاد می‌کنید؟

پیکربندی را از کد جدا کنید

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

هرگز محلی، همیشه خودکار

سیستم‌های فایل را غیرقابل تغییر و هرگز محلی در نظر بگیرید. تکرار می کنم: IO ​​محلی یک نه است. گزارش‌ها باید به Prometheus یا Amazon CloudWatch بروند و فایل‌ها به ذخیره‌سازی blob مانند Amazon S3 یا Azure Blob Storage بروند. همچنین باید مطمئن شوید که سرویس‌های اتوماسیون را برای یکپارچه‌سازی مداوم (CI)، تحویل مداوم (CD)، و بازیابی بلایا (DR) اجرا کرده‌اید تا کانتینرهای جدید در صورت لزوم به‌طور خودکار بچرخند.

اجازه دهید بسته بندی سطل راهنمای شما باشد

برای کنترل هزینه ها و کاهش ضایعات به اصول بسته بندی سطل های ظروف مراجعه کنید. برخی از پلتفرم‌های ابری برای شما بسته می‌شوند در حالی که برخی دیگر به رویکرد دستی‌تری نیاز دارند، اما در هر صورت باید منابع خود را بهینه کنید. اینطور فکر کنید: ماشین ها مانند فضای ذخیره سازی در یک کشتی هستند – شما فقط بسته به CPU و RAM دارید. کانتینرها جعبه هایی هستند که قرار است در کشتی حمل کنید. شما قبلاً برای ذخیره سازی (یعنی ماشین های زیربنایی) هزینه کرده اید، بنابراین می خواهید تا آنجا که می توانید برای به حداکثر رساندن سرمایه خود در آن هزینه کنید. در اجرای ۱:۱، شما برای چندین کشتی که هر کدام فقط یک جعبه را حمل می کنند، هزینه پرداخت می کنید.

سرویس‌های خود را با اندازه مناسب

انتخاب کنید

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

از کجا متوجه می شوید که موفق شده اید؟

چگونه متوجه می شوید که ظروف خود را به درستی پیکربندی کرده اید تا به مقیاس افقی برسید؟ تست تورنسل در اینجا آمده است: اگر بخواهم یک سرور مستقر یا پنج سرور را خاموش کنم، آیا زیرساخت شما بدون نیاز به مداخله دستی زنده می شود؟ اگر پاسخ مثبت است، به شما تبریک می گویم. اگر پاسخ منفی است، به تابلوی نقاشی برگردید و دلیل این کار را بفهمید، سپس آن موارد را حل کنید. این مفهوم صرف نظر از ابر عمومی شما اعمال می شود: همه چیز، از جمله استراتژی های DR خود را هر جا مقرون به صرفه است، به صورت خودکار انجام دهید. بله، ممکن است لازم باشد نحوه واکنش برنامه خود به این سناریوها را تغییر دهید.

به عنوان یک امتیاز، در وقت خود صرفه جویی کنید

هنگامی که برای مقیاس‌بندی خودکار افقی و خودترمیمی تنظیم شدید، زمانی را که قبلاً برای امنیت و انطباق صرف کرده‌اید نیز آزاد خواهید کرد. با خدمات مدیریت شده، به لطف مدل مسئولیت مشترک، دیگر نیازی به صرف زمان زیادی برای وصله سیستم عامل ندارید. اجرای سرویس‌های مبتنی بر کانتینر در دستگاه شخص دیگری همچنین به این معنی است که به آنها اجازه دهید با امنیت سیستم عامل میزبان و تقسیم‌بندی شبکه سروکار داشته باشند و راه را برای انطباق با SOC و HIPAA آسان‌تر کنید.

اکنون، بیایید به کدنویسی برگردیم

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

بنابراین ادامه دهید و با اطمینان از اینکه هیدرا همیشه سر دیگری تولید می کند، وارد پروژه بعدی خود شوید. زیرا در نهایت، چیزی به نام پرواز خیلی نزدیک به ابر وجود ندارد.