دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که وقتی تعداد کاربران یک سامانه به میلیون‌ها نفر می‌رسد، کدهای ما چطور روی هزاران سرور مختلف اجرا و مدیریت می‌شوند؟ چطور می‌توانیم مطمئن باشیم که با خراب‌شدن سخت‌افزارها، سرویس ما از دست نمی‌رود؟
کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل بیست‌وپنجم به سراغ یکی از بنیادی‌ترین مفاهیم زیرساختی یعنی محاسبات به عنوان سرویس (Compute as a Service) می‌رود و نشان می‌دهد که چطور باید بستر سخت‌افزاری و نرم‌افزاری را برای مقیاس‌های بزرگ طراحی کرد.
در روزهای اولیه، مهندسان نرم‌افزار مجبور بودند کدهای خود را به صورت دستی روی تک‌تک ماشین‌ها کپی کنند، آن‌ها را اجرا کنند و نگران خرابی تک‌تک سیستم‌ها باشند. با رشد شرکت، این روش سنتی به کابوسی از کارهای تکراری تبدیل شد. راه‌حل اولیه استفاده از اسکریپت‌های ساده و ابزارهای مانیتورینگ بود، اما در مقیاس‌های کلان، سازمان به برنامه‌ریزی خودکار برای تخصیص ماشین‌ها نیاز دارد. برای نمونه، گوگل سیستم مدیریت خوشه‌ای خود یعنی «بورگ» را ساخت تا وظایف پردازشی را به صورت خودکار روی منابع موجود پخش کند و در صورت خرابی ماشین، کار را به سرعت به سرور دیگری منتقل سازد.
مشکل بعدی این بود که اختصاص دادن یک سرور کامل به یک برنامه، اسراف بزرگی در مصرف منابعی مثل پردازنده و حافظه به حساب می‌آمد. راه‌حل این بود که چندین برنامه روی یک ماشین مشترک اجرا شوند، اما این کار خطراتی مثل تداخل منابع به همراه داشت. وقتی برنامه‌ای بیش از حد حافظه مصرف کند، سیستم‌عامل می‌تواند کل فرآیند را متوقف کند. استفاده از ماشین‌های مجازی هم راه‌حل سنگینی بود، زیرا سیستم‌عامل کامل خود را نیاز داشت. بنابراین گوگل به سراغ کانتینرسازی (Containerization) رفت که تکنیکی سبک‌وزن برای جداسازی فرآیندها روی یک سیستم‌عامل واحد است.
تغییر زیرساخت به سیستم‌های خودکار نیازمند تغییر نگاه ما به نرم‌افزار هم هست؛ سرویس‌ها نباید مثل حیوانات خانگی نگهداری شوند که اگر بیمار شدند بالاسرشان بنویسیم، بلکه باید مثل دام و گله (Cattle) با آن‌ها رفتار کرد؛ یعنی اگر نمونه‌ای از کار افتاد، خودکار حذف شود و یک نمونهٔ سالم جایگزینش گردد. در این مدل، وضعیت برنامه‌ها باید ناپایدار (Transient) در نظر گرفته شود و داده‌های مهم در فضای ذخیره‌سازی ماندگار نگهداری شوند. برای مثال، اگر در یک پردازش دسته‌ای (Batch Job) یکی از کارگرها وسط کار بسوزد، سامانه باید کار را به تکه‌های کوچک‌تر خرد کرده باشد تا فقط همان تکهٔ کوچک دوباره پردازش شود.
با گذشت زمان، مفهوم کانتینر فراتر از یک ابزار جداسازی رفت و به عنوان یک لایهٔ انتزاعی عمل کرد تا برنامه‌ها نیازی به دانستن جزئیات سخت‌افزار زیر پای خود نداشته باشند. اما قانون هایروم (Hyrum’s Law) یادآوری می‌کند که وقتی سیستم به اندازهٔ کافی کاربر داشته باشد، حتی رفتارهای ناخواسته یا محدودیت‌های سیستم‌عامل مثل تعداد شناسهٔ فرآیندها به قراردادی پنهان تبدیل می‌شوند که کاربران به آن وابستگی پیدا می‌کنند و تغییر دادنشان بسیار پرهزینه خواهد شد.
پیشنهاد من این است که هنگام طراحی سامانه‌های خود، از همان ابتدا فرض را بر این بگذارید که سخت‌افزار و سرورها ممکن است هر لحظه از دست بروند و نرم‌افزار خود را به گونه‌ای بنویسید که بدون وابستگی به یک ماشین خاص، به صورت خودکار بازیابی شود.
مدیریت درست زیرساخت محاسباتی ستون فقرات پایداری هر سازمان نرم‌افزاری بزرگ است و شناخت الگوهای موفق گوگل به ما کمک می‌کند تا در مقیاس‌های بالا دچار بحران نشویم.