دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چرا بعضی از نرم‌افزارها به محض قرار گرفتن روی ابر به مشکل برمی‌خورند، در حالی که بعضی دیگر به راحتی مقیاس‌پذیر می‌شوند و رشد می‌کنند؟ تفاوت اصلی در نحوه پی‌ریزی و رعایت استانداردهایی است که به سیستم اجازه می‌دهد در دنیای مدرن ابری دوام بیاورد و عملکرد روانی داشته باشد.
در کتاب «فراتر از اپلیکیشن دوازده‌عاملی» نوشته «کوین هافمن»، اصول پایه‌ای و ساختاری بررسی می‌شود که برای ساخت اپلیکیشن دوازده‌عاملی (Twelve-Factor App) به عنوان مجموعه‌ای از اصول برای ساخت اپلیکیشن‌های ابری قابل‌حمل و مقیاس‌پذیر، به شدت به آن‌ها نیاز داریم.
اولین چالش در این زمینه، بی‌نظمی در ساختار کد و داشتن مخازن متعدد برای یک اپلیکیشن واحد است. برخی تیم‌ها کدهای یک محصول را در چندین جای مختلف پخش می‌کنند که این کار خودکارسازی ساخت و انتشار را تقریباً غیرممکن می‌سازد. راه حل این است که کل سیستم را به عنوان یک مخزن کد واحد در کنترل نسخه ثبت کنیم و اگر چند بخش مجزا داریم، آن‌ها را به عنوان میکروسرویس‌های مستقل از هم جدا کنیم. به عنوان نمونه، داشتن یک اپلیکیشن یکپارچه بزرگ با اسکریپت‌های اجرایی متعدد نشان‌دهنده به هم ریختگی تیم‌هاست که مستقیماً در معماری نرم‌افزار هم منعکس می‌شود.
چالش بعدی در محیط‌های ابری پیچیده، نامشخص بودن قراردادهای ارتباطی بین تیم‌های مختلف است که باعث خطاهای یکپارچه‌سازی می‌شود. انتخاب بهینه این است که رویکرد API First در پیش بگیریم تا هر بخش از سیستم قبل از پیاده‌سازی کامل، قرارداد مشخصی برای تعامل داشته باشد. این رویکرد همکاری و تست را ساده می‌کند، اما نیازمند انضباط بالایی در مستندسازی است. برای مثال، استفاده از فرمت‌هایی برای تعریف این قراردادها به تیم‌ها اجازه می‌دهد بدون وابستگی به کدهای داخلی، هم‌زمان روی بخش‌های مختلف کار کنند.
مدیریت وابستگی‌ها نیز یکی از نقاط عطف در توسعه نرم‌افزار است که نباید به سرورهای سنتی و وابستگی‌های پنهان سیستم تکیه کند. در روش سنتی، برنامه‌ها متکی به پکیج‌های نصب‌شده روی سرور میزبان هستند که خطاهای عجیبی را به دنبال دارد، اما راهکار مدرن این است که وابستگی‌ها صریحاً اعلام و ایزوله شوند. کتاب اشاره می‌کند که ابزارهای مدیریت وابستگی، تمام کتابخانه‌های مورد نیاز را مستقیماً درون پکیج اجرایی اپلیکیشن بسته‌بندی می‌کنند تا اجرا در هر محیطی کاملاً قابل تکرار باشد.
چهارمین ایده کلیدی، جداسازی دقیق مرحله‌های طراحی، ساخت، انتشار و اجرا در چرخه حیات نرم‌افزار است. خیلی از تیم‌ها با مشکل مواجه می‌شوند چون تفاوت محیط توسعه و تولید را نادیده می‌گیرند و تست‌ها را روی نسخه‌های متغیر انجام می‌دهند. راهکار اصولی این است که یک کد واحد از طریق خط لوله (Pipeline) که زنجیرهٔ خودکار ساخت، آزمون و انتشار است، به یک بسته اجرایی تغییرناپذیر تبدیل شود. برای نمونه، فایلی که در محیط آزمون تأیید می‌شود، دقیقاً همان فایلی است که بدون هیچ‌گونه دستکاری دستی به محیط تولید ارسال می‌گردد.
پیشنهاد عملی من این است که پیش از افزودن هرگونه پیچیدگی به معماری سیستم، ابتدا مخزن کد و وابستگی‌های آن را کاملاً پاکسازی کنید و مطمئن شوید که فرآیند ساخت و انتشار شما به صورت خودکار انجام می‌شود.
امیدوارم این مرور کوتاه به شما کمک کرده باشد نگاه دقیق‌تری به ساختار نرم‌افزارهای ابری داشته باشید.