دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چرا گاهی برنامه‌ای که روی کامپیوتر شخصی شما بدون هیچ مشکلی کار می‌کند، وقتی روی سرور اصلی قرار می‌گیرد دچار اختلال می‌شود؟ چه چیزی میان کد برنامه‌نویسی و محیط اجرای آن پنهان است که می‌تواند همه‌چیز را به هم بریزد؟
کتاب «فراتر از اپلیکیشن دوازده‌عاملی» نوشتهٔ کوین هافمن به ما نشان می‌دهد که برای ساخت نرم‌افزارهای مدرن در دنیای ابر، رعایت اصول سنتی دیگر کافی نیست و باید نگاه تازه‌ای به ساختار برنامه‌های خود داشته باشیم.
نخستین چالش جدی، مدیریت تنظیمات برنامه است که نویسنده پیشنهاد می‌کند تنظیمات و اعتبارنامه‌ها را به عنوان مواد فراری در نظر بگیریم که با ترکیب شدن منفجر می‌شوند. مشکل اینجاست که قرار دادن اطلاعاتی مانند آدرس پایگاه داده یا رمزهای عبور در داخل کدهای برنامه، انعطاف‌پذیری را از بین می‌برد و امنیت را به خطر می‌اندازد. در روش سنتی، توسعه‌دهندگان از فایل‌های تنظیمات محلی استفاده می‌کنند، اما این کار مانع از داشتن build (ساخت) یکتا می‌شود. راه‌حل این است که از Configuration (پیکربندی) خارج از کد استفاده کنیم و مقادیر را به وسیله متغیرهای محیطی یا ابزارهای تخصصی به برنامه برسانیم، به طوری که اگر روزی سورس‌کد روی گیت‌هاب قرار گرفت، هیچ اطلاعات حساسی افشا نشود.
موضوع مهم بعدی نحوهٔ مدیریت اطلاعات مربوط به Credentials (اعتبارنامه) است که شامل نام‌های کاربری، رمزهای عبور و کلیدهای دسترسی به سرویس‌های شخص ثالث می‌شود. اگر این موارد حساس در فایل‌های منابع همراه برنامه بسته‌بندی شوند، همچنان بخشی از سورس‌کد محسوب می‌شوند و قانون جداسازی را نقض می‌کنند. در روش اصولی، این اطلاعات هرگز نباید در مخزن کد وجود داشته باشند و باید در زمان اجرا از محیط ابری دریافت شوند تا برنامه‌ها کاملاً مستقل بمانند.
در بخش ثبت رویدادها، چالش اصلی کنترل مقصد و نحوهٔ ذخیره‌سازی Logs (لاگ‌ها) است. برنامه‌های سنتی عادت دارند فایل‌های لاگ را روی دیسک ذخیره کنند و خودشان مسئولیت چرخش و مدیریت حجم آن‌ها را به عهده بگیرند، اما در زیرساخت‌های ابری، سیستم‌عامل موقتی است. راه‌حل بومی ابر این است که برنامه تمام خروجی‌های خود را صرفاً روی stdout و stderr بنویسد و جمع‌آوری، پردازش و ذخیره‌سازی آن‌ها را به ابزارهای جانبی واگذار کند. این کار باعث ساده‌تر شدن کد و تمرکز بیشتر روی ارزش تجاری اصلی می‌شود.
چالش چهارم مربوط به Disposability (قابلیت دور انداختن) است که به سرعتِ آغاز به کار و توقف نرم‌افزار مربوط می‌شود. اگر برنامه‌ای برای بالا آمدن به چند دقیقه زمان نیاز داشته باشد، در زمان اوج ترافیک یا مقیاس‌پذیری خودکار دچار مشکل می‌شود و درخواست‌های کاربران را از دست می‌دهد. ترفند کار در این است که فعالیت‌های طولانی‌مدت مانند بارگذاری کش را از مرحلهٔ راه‌اندازی اولیه خارج کنیم تا نمونه‌های جدید برنامه در کسری از ثانیه آماده سرویس‌دهی یا متوقف شدن باشند.
در نهایت، برنامه‌ها برای انجام کارهای خود به Backing Service (سرویس پشتیبان) نیاز دارند که شامل پایگاه‌های داده، سیستم‌های پیام‌رسان و فضاهای ذخیره‌سازی می‌شود. مشکل اینجاست که اتصال مستقیم و سخت‌کدشده به این سرویس‌ها، برنامه را در برابر خرابی آن‌ها آسیب‌پذیر می‌کند. راه‌حل درست این است که سرویس‌های پشتیبان به عنوان منابع متصل در نظر گرفته شوند تا اگر پایگاه داده‌ای از کار افتاد، مدیر سیستم بتواند بدون نیاز به تغییر کد برنامه، اتصال آن را به یک نمونه سالم دیگر تغییر دهد.
پیشنهاد شخصی من این است که هنگام توسعه برنامه‌ها، همیشه فرض کنید سرور شما هر لحظه ممکن است خاموش شود و از بین برود؛ این فرض ساده کمک می‌کند تا وابستگی‌های پنهان را حذف کنید و نرم‌افزاری انعطاف‌پذیر بسازید.
امیدوارم از این بررسی کوتاه لذت برده باشید و این نکات در طراحی سیستم‌های بعدی به کار شما بیاید.