کتاب‌های برنامه‌های ابری

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

کتاب «فراتر از اپلیکیشن دوازده‌عاملی» نوشتهٔ کوین هافمن به ما نشان می‌دهد که برای ساخت نرم‌افزارهای مدرن در دنیای ابر، رعایت اصول سنتی دیگر کافی نیست و باید نگاه تازه‌ای به ساختار برنامه‌های خود داشته باشیم.

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

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

در بخش ثبت رویدادها، چالش اصلی کنترل مقصد و نحوهٔ ذخیره‌سازی Logs (لاگ‌ها) است. برنامه‌های سنتی عادت دارند فایل‌های لاگ را روی دیسک ذخیره کنند و خودشان مسئولیت چرخش و مدیریت حجم آن‌ها را به عهده بگیرند، اما در زیرساخت‌های ابری، سیستم‌عامل موقتی است. راه‌حل بومی ابر این است که برنامه تمام خروجی‌های خود را صرفاً روی stdout و stderr بنویسد و جمع‌آوری، پردازش و ذخیره‌سازی آن‌ها را به ابزارهای جانبی واگذار کند. این کار باعث ساده‌تر شدن کد و تمرکز بیشتر روی ارزش تجاری اصلی می‌شود.

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

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

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

امیدوارم از این بررسی کوتاه لذت برده باشید و این نکات در طراحی سیستم‌های بعدی به کار شما بیاید.

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

در کتاب «فراتر از اپلیکیشن دوازده‌عاملی» نوشته «کوین هافمن»، اصول پایه‌ای و ساختاری بررسی می‌شود که برای ساخت اپلیکیشن دوازده‌عاملی (Twelve-Factor App) به عنوان مجموعه‌ای از اصول برای ساخت اپلیکیشن‌های ابری قابل‌حمل و مقیاس‌پذیر، به شدت به آن‌ها نیاز داریم.

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

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

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

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

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

امیدوارم این مرور کوتاه به شما کمک کرده باشد نگاه دقیق‌تری به ساختار نرم‌افزارهای ابری داشته باشید.

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

امروز در ادامه بحث از کتاب «فراتر از اپلیکیشن دوازده‌عاملی» نوشته «کوین هافمن»، به سراغ چالش‌های «هم‌سانی محیط‌ها» و چند مفهوم کلیدی دیگر در طراحی برنامه‌های بومی ابر می‌رویم که به ما کمک می‌کنند تا به عملکرد اپلیکیشن‌هایمان در هر محیطی اعتماد بیشتری داشته باشیم.

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

عامل دیگری که به هم‌سانی محیط‌ها آسیب می‌زند، «منابع» هستند. وقتی برای راه‌اندازی سریع چیزی عجله داریم، اغلب سازش‌هایی می‌کنیم. مثلاً، ممکن است اپلیکیشن ما در تولید به یک پایگاه داده قوی مثل اوراکل نیاز داشته باشد، اما برای توسعه محلی، از یک پایگاه داده در حافظه استفاده کنیم. هر بار که چنین سازشی می‌کنیم، شکاف بین محیط‌های توسعه و تولید را افزایش می‌دهیم و هر چه این شکاف بیشتر باشد، پیش‌بینی‌پذیری رفتار اپلیکیشن کمتر می‌شود و قابلیت اطمینان آن کاهش می‌یابد. امروزه ابزارهای زیادی در دسترس توسعه‌دهندگان است. می‌توان از همان نوع «سرویس پشتیبان (Backing service)» در همه محیط‌ها استفاده کرد، یا ابزارهایی مانند داکر (Docker) به ایجاد محیط‌های شبیه تولید روی ایستگاه‌های کاری توسعه‌دهندگان کمک می‌کنند. هر تصمیمی که شکاف عملکردی بین محیط‌های استقرار شما را افزایش می‌دهد، باید مورد سؤال قرار گیرد و باید در برابر وسوسه تفاوت قائل شدن بین محیط‌ها مقاومت کرد.

حالا به سراغ «فرایندهای مدیریتی (Admin process)» می‌رویم. این فرایندها کارهای یک‌باره یا نگهداری هستند که جدا از فرایند اصلی اپلیکیشن اجرا می‌شوند. توصیه اصلی اپلیکیشن دوازده‌عاملی این بود که این کارها به عنوان فرایندهای یک‌باره اجرا شوند، اما کوین هافمن معتقد است که این توصیه می‌تواند گمراه‌کننده باشد. مشکل اینجاست که استفاده از زمان‌بندهای خارجی مثل کرون (Cron) یا حتی اجرای اسکریپت‌های تعاملی، در محیط ابری می‌تواند منجر به هرج و مرج و خطاهای داده‌ای شود، به خصوص وقتی چندین نمونه از اپلیکیشن در حال اجرا هستند. مثلاً، اگر یک کار دسته‌ای شبانه را با یک زمان‌بند داخلی در هر نمونه از اپلیکیشن اجرا کنید، ممکن است این کار چندین بار اجرا شود و داده‌ها را خراب یا تکراری کند.

برای حل این مشکل، راه‌حل‌های بهتری وجود دارد. یکی از جذاب‌ترین آن‌ها، این است که قابلیت‌های موقت و مدیریتی را از طریق یک «پایانه REST (REST endpoint)» در اپلیکیشن خود ارائه دهید. این کار به شما اجازه می‌دهد که این قابلیت‌ها را به صورت کنترل‌شده و امن فراخوانی کنید. راهکار دیگر این است که کد مربوط به کارهای دسته‌ای را از اپلیکیشن اصلی جدا کرده و به یک «میکروسرویس (Microservice)» جداگانه تبدیل کنید. این میکروسرویس می‌تواند به صورت مستقل مقیاس‌پذیر باشد و از مزایای دیگر ابر نیز بهره‌مند شود. حتی می‌توانید از توابع بومی ابر مانند AWS Lambda استفاده کنید که فقط در صورت نیاز فراخوانی می‌شوند و نیازی به سرورهای همیشه روشن ندارند.

در نهایت، به «اتصال پورت (Port binding)» می‌رسیم. اپلیکیشن‌های بومی ابر باید سرویس‌های خود را از طریق اتصال پورت ارائه دهند. در محیط‌های غیرابری، به خصوص در سازمان‌های بزرگ، معمولاً چندین اپلیکیشن در یک «کانتینر (Container)» سرور وب میزبانی می‌شوند و با شماره پورت‌های مختلف از هم جدا می‌شوند. این کار مدیریت پورت‌ها را پیچیده می‌کند. اما در محیط ابری، ارائه‌دهنده خدمات ابری مسئولیت مدیریت پورت‌ها، مسیریابی، مقیاس‌گذاری و دسترسی بالا را بر عهده دارد.

و در نهایت، فصل دوازدهم به «فرایندهای بی‌حالت (Stateless Processes)» می‌پردازد. یک فرایند بی‌حالت هیچ فرضی دربارهٔ محتوای حافظه پیش یا پس از پردازش درخواست ندارد؛ می‌تواند در میانهٔ کار وضعیت موقت بسازد، اما پس از پاسخ دادن، آن وضعیت باید از بین برود. هر وضعیت ماندگار باید به یک سرویس پشتیبان مثل پایگاه داده منتقل شود. به همین دلیل، یک میکروسرویس مدیریت کاربران بی‌حالت است و فهرست کاربران در پایگاه داده نگهداری می‌شود. هافمن الگوی «هیچ‌چیز مشترک (Share-Nothing)» را هم توصیه می‌کند: هر دادهٔ مشترک بین فرایندها یک نقطهٔ شکست است، و چون فرایندها در ابر هر لحظه ممکن است حذف یا جابه‌جا شوند، اشتراک وضعیت می‌تواند باعث شکست زنجیره‌ای شود. حتی فایل‌سیستم هم سرویس پشتیبان محسوب نمی‌شود.