مک در هر مقیاس

به احتمال زیاد من را در X دیده اید: در حال باز کردن بسته بندی صدها مک بوک پرو برای استقرار در یک دیتاسنتر. این ویدئو اعصاب را به هم زد: در نگاه اول به اندازه کافی دیوانه کننده است، اما اگر بدانید ما اکنون چه می دانیم، به نوعی منطقی است.

جعبه گشایی Mac در مقیاس برای رک های سرور جدید ما.

بنابراین امروز می‌خواهم پیش‌زمینه‌ای را در مورد آنچه برای ساخت رک‌های مک سفارشی نیاز است، ارائه دهم، اینکه چگونه می‌توانیم نمونه‌های macOS را از ابتدا در چند ثانیه شروع کنیم و نسخه‌های جدید Xcode را تنها چند ساعت پس از انتشار اپل ارائه کنیم.

زیرا مشتریان ما به مک نیاز دارند. و چون اپل گزینه دیگری به ما نداد.

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

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

اما آیا واقعا سعی کرده اید چند صد مینی سفارش دهید؟ ما داریم. سفارش در ژانویه، تحویل در ژوئیه. به دنیای 2026 خوش آمدید، زمانی که زنجیره‌های تامین به هم ریخته است. نگران نباشید که اپل مدل های CPU به روز شده را به یکباره برای همه دستگاه ها عرضه نمی کند. بنابراین Mac Mini به مدت 10 ماه هسته های M5 را دریافت نکرد (و سپس ناگهان M6 را قبل از هر مدل دستگاه دیگری دریافت کرد!). ما بهترین و جدیدترین ها را به مشتریان خود قول می دهیم، بنابراین باید مبتکر باشیم. اینگونه بود که پروژه MacBook-in-Datacenter متولد شد.

طراحی خوب نیاز به تکرار دارد. و مطمئنا از همان اولین تلاش همه چیز را درست انجام ندادیم. اما من فکر می کنم که ما این سیستم را شکست داده ایم.

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

البته، هر مک بوک دارای یک کارت شبکه اترنت 10G خارجی است. بسیاری از افراد در Namespace متخصصان شبکه هستند و ما به سرعت اتصال و قابلیت اطمینانی که به مشتریان ارائه می دهیم افتخار می کنیم.

و سپس قدرت وجود دارد. بنابراین در مجموع، چهار کابل برای هر لپ تاپ، چهل و هشت کابل در هر قفسه، به اضافه دوازده کابل برای اترنت، به علاوه سیم کشی KVM. بیایید بگوییم که مدیریت دقیق کابل ضروری است.

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

طبیعتا انتظار مشکلات و چالش ها را داشتیم. نه جایی که ظاهر شدند.

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

و بله، من هم نگران آن بودم. اما واقعیت این است که موارد بسیار کمی از قطع اتصال MagSafe را دیده‌ایم.

غیر قابل اطمینان ترین کابل؟ HDMI! اغلب ضخیم و غیر قابل انعطاف است. هر بار که قفسه را لمس می کنید، تمایل به افتادن دارد.

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

منبع دیگر درد: رمزگذاری دیسک FileVault. یا بهتر بگویم رمزگشایی. هنگامی که یک مک بوک مجددا راه اندازی می شود (به شکلی برنامه ریزی نشده) از یک رمز عبور برای باز کردن قفل دیسک محلی درخواست می کند. اعلان روی صفحه نمایش داده می شود (یک لپ تاپ بسته در جایی در قفسه، doh). مشکلی نیست، ما فکر کردیم: ما KVM را فقط برای این مورد متصل کرده ایم!

نه، به این راحتی نیست. اعلان رمز عبور پس از 5 دقیقه عدم فعالیت از صفحه خارجی ناپدید می شود. سپس به یاد آوردیم که macOS Tahoe یک ویژگی مفید را معرفی کرد: می‌توانیم قفل FileVault را از راه دور با استفاده از پروتکل SSH باز کنیم. هنوز شانسی نیست در لپ تاپ ها نیز پس از 5 دقیقه منقضی می شود. به نظر می رسد تنها راه خروج از این حالت راه اندازی مجدد با فشار فیزیکی دکمه و مسابقه برای باز کردن قفل به موقع است. راه‌اندازی مجدد مک در حین این موضوع، یک نکته کوچک: می‌توانید مک را به گونه‌ای راه‌اندازی کنید که در صورت نیاز، قفل دیسک را باز نگه دارد: fdesetup authrestart .

و سپس به سادگی اشکالات وجود دارد. تحت شرایط خاص، یک NIC USB خارجی کار نمی کند و به گونه ای عمل می کند که گویی تغذیه نشده است و هیچ پیوندی را نشان نمی دهد. یک کابل دیگر، یک NIC دیگر، یک پورت سوئیچ دیگر امتحان کنید، شانسی ندارید. اما یک بازدید سریع از تنظیمات شبکه، حذف و ایجاد مجدد «سرویس شبکه» در تنظیمات MacOS، آن را زنده می‌کند.

در حال حاضر ما واقعا کارمان را آسان می کنیم: M5 و M6 Mac Minis و Studios به زودی وارد ناوگان ما خواهند شد. مدیریت آنها در DC بسیار ساده تر است: آنها یک کارت شبکه داخلی 10 گیگابیتی دارند، پس از یک چرخه برق به طور خودکار راه اندازی می شوند و سیستم عامل می تواند به طور کامل به طور خودکار از طریق MDM پیکربندی شود.

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

در پایان، نصب Mac Minis بسیار آسان است: آنها را از بسته بندی خارج کنید، 10 قطعه را داخل نگهدارنده بیندازید، برق و شبکه را وصل کنید و دکمه پاور را یک بار فشار دهید (معروف به نامناسبی قرار دارد). از آنجا به بعد اتوماسیون از آنها مراقبت می کند.

در زیر هود یک نمونه Namespace توسط یک ماشین مجازی پشتیبانی می شود. ما چندین موتور ماشین مجازی داریم که در یک پلتفرم یکپارچه برای اجرای نمونه‌های لینوکس، ویندوز و مک به کارآمدترین روش ادغام شده‌اند. به این ترتیب می‌توانیم همان ویژگی‌هایی را که Namespace را خاص می‌کند، مانند حجم‌های حافظه پنهان، تله متری یا اتصالات VPC ارائه کنیم.

جای تعجب نیست که راه حل مک ما بر اساس چارچوب مجازی سازی عالی اپل است. این یک موتور ماشین مجازی قابل جاسازی و انعطاف پذیر است. مقایسه آن با Firecracker از نظر تناسب با معماری سیستم آسان‌تر است: عملیات‌های عمومی VM را به‌صورت سرتاسری و همچنین تجهیزات جانبی معمولی را پیاده‌سازی می‌کند.

برای کامل‌تر شدن، اپل یک چارچوب Hypervisor سطح پایین‌تر نیز ارائه می‌کند که با KVM API لینوکس قابل مقایسه است. به عنوان مثال QEMU از آن در macOS زیر هود استفاده می کند. Hypervisor راهی برای اجرای کد ماشین به صورت مجزا ارائه می دهد، اما توسعه دهنده برنامه را ملزم به پیاده سازی بخش عمده ای از معماری ماشین و تجهیزات جانبی می کند. این می‌تواند کنترل زیادی به ما بدهد، اما متأسفانه نمی‌تواند macOS را اجرا کند (به یک محیط اختصاصی اپل نیاز دارد که اشخاص ثالث نمی‌توانند یا نباید سعی در ایجاد مجدد آن کنند).

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

یک محدودیت شناخته شده این است که اپل تنها به دو ماشین مجازی macOS در هر مک فیزیکی اجازه می دهد. این می تواند یک مک پرو با 24 هسته و 192 گیگابایت حافظه باشد، اما تنها به اجرای دو VM مهمان محدود می شود. این محدودیت در ارائه محصول ما آشکار می شود: ما فقط می توانیم منابع مک را در دو نیمه تقسیم کنیم. بنابراین ما نمونه‌هایی را با 6 یا 12 هسته در مک مینی‌های 14 هسته‌ای و نمونه‌های 8/16 هسته‌ای در مک‌بوک‌های 18 هسته‌ای اجرا می‌کنیم (چند هسته را برای سربار مدیریت رزرو می‌کنیم).

یک نکته مهم در مورد مجازی سازی VM این است که CPU مجازی توسط یک فرآیند سیستم عامل مجزا (فرآیند VMM در نمودار) از نرم افزار یکپارچه سازی مجازی سازی (در اینجا Namespace VM host) اجرا می شود. اگر بخواهیم برخی از رفتارهای VM را قلاب کنیم یا دستگاه‌های مجازی سفارشی را پیاده‌سازی کنیم، هر تعاملی با آن‌ها نیاز به یک IPC رفت و برگشت بین فرآیند VM و فرآیند «میزبان» دارد. چنین سوئیچ های زمینه اجتناب ناپذیر هستند و باید در هنگام طراحی سیستم مورد توجه قرار گیرند.

چارچوب مجازی سازی چند راه برای اتصال ماشین مجازی به شبکه ارائه می دهد. به عنوان مثال، حالت‌های شبکه‌ای Bridged و NAT ترافیک را مستقیما از فرآیند VMM به رابط‌های شبکه میزبان هدایت می‌کنند. اینها برای ماشین‌های مجازی که روی یک رایانه محلی اجرا می‌شوند که حجم کار مورد اعتماد است، مناسب هستند.

نمونه‌های فضای نام کدهای نامعتبر را اجرا می‌کنند و ما باید خط‌مشی‌هایی را در مورد آنچه که یک VM می‌تواند یا نمی‌تواند به آن دسترسی داشته باشد اعمال کنیم (این خط‌مشی‌ها می‌توانند توسط مشتری نیز تعریف شوند!). همچنین ما چند سرویس اضافی را برای نمونه‌هایی ارائه می‌کنیم که باید «به‌گونه‌ای» ظاهر شوند که در شبکه محلی برای سیستم مهمان هستند.

این امر مستلزم آن است که کنترل کامل شبکه مهمان را در حالتی در دست بگیریم که در آن هر بسته ای را که در نرم افزار بیرون می آید و وارد VM می شود پردازش می کنیم. ما شبکه‌های مهمان خود را بر روی پشته TCP/IP فضای کاربر از پروژه Google gVisor استوار کردیم و از آن برای پیاده‌سازی دروازه/فایروال IP برای نمونه‌ها استفاده می‌کنیم. به این ترتیب ما قرار گرفتن سیستم عامل میزبان را در معرض بسته های پردازش نشده کنترل نشده توسط مهمان به حداقل می رسانیم.

مدیریت بسته های شبکه باید بسیار کارآمد باشد، اما همانطور که در بالا ذکر شد مسیر شامل IPC است. فرآیند VMM ابتدا باید بسته ها را به فرآیند "میزبان VM" منتقل کند، که سپس آنها را پردازش کرده و به رابط شبکه ارسال می کند. برای به حداقل رساندن تعداد رفت و برگشتهای IPC، هر جا که ممکن است، نیاز به اجرای دقیق و پردازش دسته ای دارد.

رویکرد فوق به نمونه‌های MacOS Space اجازه می‌دهد تا به پهنای باند بالادستی 4 گیگابیت بر ثانیه (به ازای Fast.com) برسند. این متأسفانه هنوز کمتر از نرخ خط است. ما در حال بررسی رویکردهای جایگزین، از جمله ایده هایی در مورد چگونگی جلوگیری از IPC برای پردازش شبکه به طور کامل بوده ایم. اما تولید تنظیمات جدید هنوز برای آینده باقی مانده است. از این گذشته ، 4 گیگابیت در ثانیه هنوز کاملا قابل احترام است.

ایجاد اولین ماشین مجازی خود با استفاده از مجازی‌سازی اپل بسیار آسان است: یک نصب‌کننده macOS XIP را دانلود کنید، از UTM/Tart/هر یک از ده‌ها بسته مجازی‌سازی منبع باز برای راه‌اندازی یک ماشین استفاده کنید، از طریق Setup Assistant کلیک کنید، Xcode را نصب کنید و آماده هستید. اکنون یک تصویر VM دارید که می توانید هر بار کاری را به صورت محلی اجرا کنید.

اما باید روی چندین نسخه iOS تست کنید، بنابراین چند زمان اجرا iOS را نصب کنید. و سپس نسخه بتای Xcode را نصب می‌کنید (و همچنین زمان‌های اجرا جدید). و قبل از اینکه بدانید تصویر VM شما به 500 گیگابایت رسیده است (بسته های زمان اجرا iOS بسیار بزرگ هستند).

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

و سپس متوجه می‌شوید که نسخه بتا Xcode به‌طور نامحسوس Xcode‌های غیربتا را در همان سیستم می‌شکند (داستان واقعی!). پس از همه، نصب Xcode نسخه‌های «جهانی» CoreDevice و CoreSimulator را افزایش می‌دهد. از این رو هر گونه اشکال در شبیه ساز بتا Xcode زمانی که از نسخه های ظاهرا پایدار Xcode استفاده می کنید قابل مشاهده است. بنابراین اکنون نسخه های تصویری را با و بدون Xcodes پیش از انتشار نگهداری می کنید.

و اکنون شما 2 ترابایت تصویر VM دارید. روی چه چیزی؟ هارد مک بوک 2 ترابایتی؟

این چالشی است که ما با آن روبرو هستیم: ما باید تصاویر عظیمی را در ناوگان صدها ماشین بسازیم، توزیع کنیم و ذخیره کنیم.

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

توسط یک جریان کاری که به عنوان دنباله ای از عملیات در یک فایل YAML بیان می شود هدایت می شود. عملیات می تواند کنترل VM (به عنوان مثال راه اندازی مجدد)، اجرای یک اسکریپت پوسته یا تعامل برنامه ای با سیستم یا راه اندازی UI از طریق VNC باشد.

تصاویر VM حاصل به رجیستری تصویر داخلی Namespace تحویل داده می‌شوند، در واقع همانی که ذخیره، تکثیر و توزیع تصاویر لینوکس و ویندوز را مدیریت می‌کند (که در مقاله عالی Matteo پوشش داده شده است). البته تصاویر دیسک کاملا با تصاویر کانتینر معمولی متفاوت است: لایه‌های OCI تاربال‌های ساده فایل‌ها هستند، در حالی که دیسک‌ها معمولا آرایه‌های مسطح از بایت‌ها هستند. آرایه های بسیار بزرگ در واقع. و تا حد زیادی دارای فضای خالی هستند: این فضای دیسکی است که به عنوان فضای آزاد در دسترس کاربران قرار می گیرد.

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

و بهینه سازی مهم دیگری نیز وجود دارد. سناریوی مثال ذکر شده در بخش تصاویر ماشین مجازی را به خاطر بسپارید: ما تصویری از همان سیستم داریم که فقط علاوه بر نصب Xcode اضافی متفاوت است. بدیهی است که تصویر دوم با استفاده از اولی به عنوان پایه ساخته شده است و بیشتر بایت ها بدون تغییر هستند.

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

در این مرحله ما اکنون تصاویر را در یک رجیستری OCI داریم. اما مطمئنا چارچوب مجازی سازی نمی تواند یک ماشین مجازی را مستقیما با استفاده از دیسکی که در رجیستری قرار دارد راه اندازی کند. باید چیزی روی خود گره داشته باشد: یک دیسک VM می‌تواند توسط یک فایل تصویری روی SSD میزبان محلی پشتیبانی شود یا می‌تواند درخواست‌های ورودی/خروجی دیسک را با استفاده از پروتکل Network Block Device (NBD) به سرور هدایت کند. دومی به ما این امکان را می‌دهد تا داده‌های بسیار مورد نیاز را از یک حافظه پنهان محلی به‌طور هوشمندانه ارائه کنیم، در حالی که با ذخیره نکردن بلوک‌های غیرضروری، فضای روی دستگاه را حفظ کنیم.

اما NBD همان اشکال شبکه فضای کاربران را دارد: هر عملیات I/O حداقل یک IPC رفت و برگشت را شامل می شود، از جمله کپی بافر و سوئیچ های زمینه. شما همان الگوی شبکه را می بینید: یک گزینه بسیار مستقیم و سریع و یک گزینه غیرمستقیم "تعریف شده از طریق نرم افزار" اما به طرز ناامیدکننده ای کند.

در Namespace ما برای عملکرد ارزش زیادی قائل هستیم، بنابراین انتخاب واضح است: ما تصاویر را از دیسک محلی ارائه خواهیم کرد. ما باید آنها را از تصاویر OCI در رجیستری در SSD هر گره در ناوگان مادیت کنیم. 500 گیگ تصویر به صدها و هزاران گره. و ما باید این کار را سریع انجام دهیم.

بدیهی است که هر گره ای که ساده لوحانه از رجیستری مرکزی دانلود می شود کار نمی کند. با اعداد مثال، ما در مورد نیم پتابایت ترافیک منتقل شده در ده ها دقیقه صحبت می کنیم. رجیستری (و فابریک شبکه) باید ترابیت در ثانیه ارائه دهد!

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

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

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

برخی از شما احتمالا می دانید که اینها دقیقا انواع تکنیک های بهینه سازی ذخیره سازی هستند که با سیستم های فایل مدرن، یعنی APFS امکان پذیر است. کاربران ZFS Linux نیز همین ویژگی ها را در ZFS مشاهده کرده اند.

استفاده از این ویژگی های جالب نیز بسیار آسان است: یک فایل جدید برای نوشتن باز کنید، به دنبال جبران 100G باشید، یک بلوک بنویسید. و در آنجا فقط یک فایل با یک سوراخ بزرگ در آن ایجاد کردید. فقط بلوکی که نوشتی روی دیسک تخصیص داده میشه بقیه 100 گیگ صفرهای خیالی هستن. هنگام خواندن فایل حتی حفره ها را متوجه نمی شوید. سیستم عامل صفرهای واقعی را برمی گرداند.

به اشتراک گذاری بلوک ها به طور مشابه شفاف است: فقط از حالت cp -c یا syscall کلون فایل استفاده کنید. فایل جدید همان بلوک های دیسک را به اشتراک می گذارد و اساسا فضایی را اشغال نمی کند.

نوشتن در فایل شبیه‌سازی شده نیز شفاف است: به محض اینکه بخواهید برخی از بلوک‌ها را بازنویسی کنید، این بلوک‌های خاص روی دیسک تخصیص داده می‌شوند، در حالی که بخش مشترک به اشتراک گذاشته می‌شود.

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

ما هنوز هم می توانیم بهتر عمل کنیم! اگر یک دستگاه "Holly-Grail" برای میزبانی قفسه ای از مک بوک ها وجود داشته باشد و اتصالات برق، اترنت و KVM را از طریق یک کابل USB-C فراهم کند، چه؟ این باید امکان پذیر باشد، اما در حال حاضر هیچ سخت افزاری در بازار آزاد وجود ندارد که نیازهای ما را برآورده کند. بنابراین ما روی چیزی بسیار سفارشی کار می کنیم.

یا شاید کار دیوانه وار دیگری انجام دهیم؟ اگر تلفن ها را در دیتاسنتر مستقر کنیم چه؟ ببینید آینده به زودی چه چیزی را برای X ما به ارمغان می آورد!