آیا نیاز به بازگشت از ابر دارید؟

بازگشت به کشور یکی از مسیرهای صرفه جویی در هزینه است. تغییر الگوهای توسعه از سرویس های طولانی مدت به توابع بدون سرور مبتنی بر WebAssembly یکی دیگر از موارد است.

Buzz در حال ایجاد این ایده است که زمان آن رسیده است که خدمات ابری خود را پس بگیریم و یک بار دیگر مرکز داده شرکت را بازسازی کنیم. بازگشت. این عمل انتقال کار به خارج از ابر و بازگشت به سخت افزار داخلی یا خود مدیریت است. و توجیه اولیه برای این حرکت، به ویژه در زمان رکود اقتصادی، ساده است. با استفاده نکردن از AWS، Azure یا سایر خدمات میزبانی ابری در هزینه خود صرفه جویی کنید. با ایجاد و مدیریت زیرساخت های خود در هزینه صرفه جویی کنید.

از زمانی که یک پست آندریسن هوروویتز منجنیق این این ایده چند سال پیش در کانون توجه قرار گرفت، به نظر می رسد که در حال افزایش است. ۳۷Signals، سازندگان Basecamp و Hey (یک سرویس پست اینترنتی با پرداخت هزینه)، به طور منظم درباره نحوه آنها وبلاگ می نویسند بازگردانده شد. و یک گزارش اخیر نشان می‌دهد که از بین همه کسانی که در مورد بازگشت به میزبانی شخصی صحبت می‌کنند، دلیل اصلی مالی بود: ۴۵٪ گفتند که به دلیل هزینه است.

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

واضح‌ترین پاسخ به این احساس که ابر بیش از حد گران شده است چیست؟ این فراخوان بازگشت به وطن است: همه را به داخل خانه منتقل کنید!

Kubernetes در عمل گران است

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

پیشنهاد ارزش اصلی ماشین‌های مجازی میزبان (محاسبات ابری OG) این بود که می‌توانید کل سیستم عامل خود را بردارید، آن را بسته بندی کنید و برای اجرا به جای دیگری ارسال کنید. اما بخش عملیاتی این راه‌اندازی – چیزی که ما از تیم‌های devops و مهندسی پلتفرم خود درخواست کردیم تا با آن مقابله کنند، چیزی جز خوشایند بود. نگهداری یک جانور بود. ابزارهای مدیریت ابتدایی بودند. توسعه دهندگان شرکت نکردند. استقرارها کندتر از ملاس بود.

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

اما چیزی که در حین ساختن این دنیای جدید شجاع متوجه نشدیم هزینه‌ای است که متحمل می‌شویم. به طور خاص، به نام ثبات، هزینه را کم اهمیت جلوه دادیم. در Kubernetes، روش ترجیحی برای استقرار یک برنامه، حداقل سه نسخه از هر برنامه در حال اجرا را اجرا می کند، حتی زمانی که بار ورودی آن را توجیه نمی کند. ۲۴×۷، هر سرور در خوشه شما در سه نسخه (حداقل) اجرا می‌شود و انرژی و منابع مصرف می‌کند.

علاوه بر این، ما یک خورش درشت از سرویس‌های جانبی و خدمات کمکی قرار دادیم که همگی منابع بیشتری را مصرف کردند. ناگهان آن خوشه سه گره “شروع” Kubernetes هفت گره شد. سپس یک دوجین. طبق یک نظرسنجی اخیر CNCF، ۵۰٪ کامل از خوشه های Kubernetes بیش از ۵۰ گره دارد. هزینه خوشه سر به فلک کشید. و سپس همه ما خود را در آن موقعیت ناپسند نصب ابزار «کنترل هزینه» یافتیم تا به ما بگوییم که کجا می‌توانیم خوشه Kubernetes خود را در بودجه جدید شلوار جین اسکینی خود فشرده کنیم.

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

جای تعجب نیست که بازگشت به وطن باعث افزایش ابروها شده است.

آیا می‌توانیم مشکل را در فضای ابری حل کنیم؟

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

تکنولوژی و الگوی برنامه نویسی هر دو در حال حاضر اینجا هستند. و اسپویلر اینجاست: راه حل WebAssembly بدون سرور است.

بیایید این شرایط را یکی یکی در نظر بگیریم.

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

بهترین راه برای فکر کردن در مورد عملکرد بدون سرور، مدیریت رویداد است. یک رویداد خاص (یک درخواست HTTP و فرود آیتم در صف و غیره) یک تابع خاص را راه اندازی می کند. آن تابع شروع می شود، درخواست را مدیریت می کند و سپس بلافاصله خاموش می شود. یک تابع ممکن است برای میلی ثانیه، ثانیه یا شاید دقیقه اجرا شود، اما دیگر نه.

پس سروری که بدون سرور بدون سرور انجام می دهیم چیست؟ ما این ادعا را نداریم که به نوعی فراتر از سخت افزار سرور هستیم. در عوض، “بدون سرور” بیانیه ای در مورد الگوی طراحی نرم افزار است. هیچ فرآیند سرور طولانی مدت وجود ندارد. در عوض، ما فقط یک تابع می نویسیم – فقط یک کنترل کننده رویداد. و ما آن را به سیستم رویداد واگذار می کنیم تا فراخوانی کنترل کننده رویداد را فعال کند.

و آنچه از این تعریف خارج می‌شود این است که نوشتن توابع بدون سرور بسیار آسان‌تر از سرویس‌ها است – حتی microservices سنتی. این واقعیت ساده است که توابع بدون سرور به کد کمتری نیاز دارند، که به معنای توسعه، اشکال زدایی و وصله کمتر است. این به خودی خود می تواند به نتایج بزرگی منجر شود. همانطور که دیوید اندرسون در کتاب خود اثر فلایویل ارزش گزارش کرد: “یک وب واحد برنامه در Liberty Mutual به صورت بدون سرور بازنویسی شد و منجر به کاهش هزینه های تعمیر و نگهداری ۹۹.۸۹ درصد شد، از ۵۰۰۰۰ دلار در سال به ۱۰ دلار در سال. (اندرسون، دیوید. اثر فلایویل ارزش، ص ۲۷.)

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

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

این جایی است که WebAssembly وارد می شود.

WebAssembly به عنوان زمان اجرا بدون سرور بهتر

WebAssembly به عنوان یک زمان اجرا ایزوله بسیار ایمن، یک استراتژی مجازی سازی عالی برای توابع بدون سرور است. یک تابع WebAssembly کمتر از یک میلی ثانیه تا شروع سرد طول می کشد و برای اجرا به CPU و حافظه کمی نیاز دارد. به عبارت دیگر، آنها هم زمان و هم منابع سیستم را کاهش می دهند، به این معنی که در هزینه صرفه جویی می کنند.

چقدر کم می کنند؟ هزینه بسته به ابر و تعداد درخواست‌ها متفاوت خواهد بود. اما ما می‌توانیم یک خوشه Kubernetes را با استفاده از کانتینرها با خوشه‌ای که از WebAssembly استفاده می‌کند، مقایسه کنیم. یک گره Kubernetes می تواند حداکثر تئوری کمی بیش از ۲۵۰ پاد را اجرا کند. بیشتر اوقات، یک ماشین مجازی با اندازه متوسط ​​در به محدودیت‌های حافظه و قدرت پردازش می‌رسد. فقط چند ده ظرف. و این به این دلیل است که کانتینرها در تمام مدت فعالیت خود منابع مصرف می کنند.

در Fermyon ما به طور معمول توانسته‌ایم هزاران برنامه WebAssembly بدون سرور را روی گره‌هایی با اندازه متوسط ​​در یک خوشه Kubernetes اجرا کنیم. ما اخیراً ۵۰۰۰ برنامه بدون سرور آزمایش شده را بر روی یک خوشه گره دوکاره بارگذاری کردیم که در ۱۰ ثانیه به بیش از ۱.۵ میلیون فراخوانی تابع دست یافتیم. Fermyon Cloud، سیستم تولید عمومی ما، ۳۰۰۰ برنامه کاربردی ساخته شده توسط کاربر را روی هر ماشین مجازی ۳۲ گیگا بایتی ۸ هسته ای اجرا می کند. و این سیستم بیش از ۱۸ ماه در حال تولید بوده است.

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

ایمن تر از بازگشت به کشور

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

انتقال از ابر به on-prem مسیری است که کسب‌وکار شما را تغییر می‌دهد، و احتمالاً نه برای بهتر شدن.

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

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

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

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

این نه تنها مانع کمتری برای ورود است، بلکه چه کار کند یا نه، همیشه این گزینه برای انتخاب بازگشت به وطن بدون نیاز به انجام دومین مورد در مورد چهره وجود دارد، زیرا توابع بدون سرور WebAssembly به همان اندازه در حالت اولیه کار می کنند ( یا روی لبه، یا جای دیگر) همانطور که در ابر انجام می دهند.

صرفه جویی در هزینه به چه قیمتی؟

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

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

مت قصاب یکی از بنیانگذاران و مدیرعامل Fermyon، WebAssembly بدون سرور در شرکت ابری. او یکی از سازندگان اصلی Helm، Brigade، CNAB، OAM، Glide و Krustlet است. او کتاب‌های بسیاری از جمله «هدف یادگیری» و «به تمرین برو» نوشته و در نگارش مشارکت داشته است. او یکی از خالقان مجموعه «راهنمای مصور کودکان برای مجموعه Kubernetes» است. این روزها او بیشتر روی پروژه های WebAssembly مانند Spin، Fermyon Cloud و Bartholomew کار می کند. او دارای مدرک دکتری است. در فلسفه او در کلرادو زندگی می‌کند، جایی که مقدار زیادی قهوه می‌نوشد.

—

انجمن فناوری جدید مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.