زیرساخت باید در خدمت برنامه باشد، نه مانعی در مسیر آن

عنوان سخنرانی: Application-Driven Infrastructure
همایش: XConf Europe 2025
سخنران: Kief Morris
برگزارکننده: Thoughtworks
مدت ویدئو: ۲۷ دقیقه و ۱۹ ثانیه
لینک ویدئو: https://youtu.be/sG3Cgf8x0_k?si=iLX2jNLDTNBWEFoA

امروزه بسیاری از سازمان‌ها از رایانش ابری، خطوط تحویل خودکار و زیرساخت به‌عنوان کد استفاده می‌کنند؛ اما با وجود این ابزارها، آماده‌سازی محیط و زیرساخت همچنان می‌تواند یکی از کندترین بخش‌های توسعه نرم‌افزار باشد. مهم‌ترین برداشتی که من از سخنرانی Application-Driven Infrastructure داشتم این بود که خودکارسازی به‌تنهایی کافی نیست. اگر فرایند قدیمی حفظ شود و فقط اجرای آن با ابزارهای جدید انجام شود، همچنان تیم توسعه برای دریافت پایگاه داده، شبکه، دسترسی یا محیط اجرایی باید درخواست ثبت کند و منتظر تیم زیرساخت بماند. در این حالت، ابزارها مدرن شده‌اند، اما شیوه همکاری و معماری تحویل زیرساخت تغییر اساسی نکرده است.

Kief Morris مدل سنتی را به‌صورت رویکردی از پایین به بالا توصیف می‌کند. در این مدل، تیم زیرساخت ابتدا یک محیط بزرگ و تقریبا یکپارچه می‌سازد و سپس تیم‌های برنامه باید راهی برای اجرای نرم‌افزار خود در همان محیط پیدا کنند. مشکل اینجاست که زیرساخت بدون شناخت دقیق نیازهای هر برنامه طراحی می‌شود و برای هر تغییر نیز هماهنگی میان چند تیم ضروری است. نتیجه معمولا ایجاد صف درخواست‌ها، انتظار طولانی، وابستگی سازمانی و کاهش سرعت تحویل نرم‌افزار است. حتی اگر همه منابع با Terraform یا ابزارهای مشابه ایجاد شوند، این وابستگی همچنان باقی می‌ماند؛ زیرا کنترل فرایند هنوز در اختیار یک تیم مرکزی است.

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

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

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

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

هم‌راستا‌شدن چرخه عمر برنامه و زیرساخت نیز نکته ارزشمند دیگری بود. در معماری سنتی، ممکن است منابع زیرساختی مدت‌ها پس از پایان آزمایش یا حذف برنامه همچنان باقی بمانند و هزینه ایجاد کنند. در مدل برنامه‌محور، زیرساخت می‌تواند همراه با برنامه ایجاد، تغییر و در صورت بی‌نیازی حذف شود. این هماهنگی علاوه بر کاهش کار دستی، دید بهتری نسبت به مالکیت و هزینه منابع فراهم می‌کند؛ زیرا مشخص است هر منبع برای کدام برنامه و با چه هدفی ایجاد شده است. مقاله Morris درباره Infrastructure as Data نیز توضیح می‌دهد که منابع می‌توانند بر اساس توصیف استقرار برنامه و از طریق یک حلقه کنترل، به‌طور مداوم با وضعیت موردانتظار هماهنگ نگه داشته شوند.

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

به نظر من، اجرای این رویکرد فقط با خرید یک ابزار یا ایجاد یک پرتال Self-Service کامل نمی‌شود. مؤلفه‌ها باید رابط‌های پایدار، نسخه‌بندی روشن، تست خودکار، مستندات مناسب و مشاهده‌پذیری کافی داشته باشند. تیم پلتفرم نیز باید مصرف‌کنندگان خود را مانند کاربران یک محصول در نظر بگیرد و کیفیت تجربه توسعه‌دهنده را بررسی کند. معیار موفقیت نباید صرفا تعداد منابع ساخته‌شده یا میزان استفاده از Terraform باشد؛ بلکه باید دید آیا زمان انتظار تیم‌ها کاهش یافته، تغییرات سریع‌تر و مطمئن‌تر منتشر شده‌اند و تیم‌های برنامه استقلال بیشتری پیدا کرده‌اند یا خیر. سخنران در معرفی نسخه دیگر این ارائه نیز بر ایجاد بهبودهای قابل‌اندازه‌گیری در اثربخشی تحویل نرم‌افزار تاکید می‌کند.

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

منابع

• ویدئوی رسمی Application-Driven Infrastructure در کانال Thoughtworks :
  https://youtu.be/sG3Cgf8x0_k?si=iLX2jNLDTNBWEFoA

• صفحه رسمی XConf Europe 2025 در Thoughtworks :
  https://www.thoughtworks.com/about-us/events/xconf/2025/europe

• گفت‌وگوی Infrastructure as Code in 2025 با Kief Morris :
  https://www.thoughtworks.com/insights/podcasts/technology-podcasts/infrastructure-as-code-in-2025

• مقاله Infrastructure as Data نوشته Kief Morris :
  https://infrastructure-as-code.com/posts/infrastructure-as-data.html

اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است 🌱