پیروزی مهندسی پلتفرم در برابر چالشی تازه
مهندسی پلتفرم تاکنون موفق بوده است. طبق آمار، حدود ۹۰٪ از سازمانها حداقل یک پلتفرم داخلی را پذیرفتهاند؛ مسیرهای طلایی به یک اصل بدیهی تبدیل شده و درخواستهای محیطی که قبلاً روزها طول میکشید، اکنون در عرض چند ساعت انجام میشود. بر اساس معیارهای این حوزه، این یک پیروزی بزرگ محسوب میشود.
اما حالا پیچیدهترین مشتری که پلتفرم تاکنون دیده است، پا به میدان گذاشته و این مشتری یک توسعهدهنده نیست. عامل کدنویسی (Coding Agent) که میخواهد کار خود را تأیید کند، محیط را دقیقاً مثل یک کلاینت که API را صدا میزند درخواست میکند: به صورت انفجاری، همزمان، با طول عمر چند دقیقه و انتظاری در حد ثانیه.
تصور کنید سازمانی با ۱۰۰ توسعهدهنده که هر مهندس روزانه چند جلسه عامل را مدیریت میکند. تا قبل از ناهار صدها درخواست محیط ثبت میشود. هر درخواست نیاز به وابستگیهای واقعی دارد و به محض پایان اعتبارسنجی، به بار مرده تبدیل میشود. این یک صف بلیط نیست. این ترافیک است.
چالشبرانگیزترین مستأجر تاریخ پلتفرمها
این تقاضا خیالی نیست. گزارش Octoverse گیتهاب نشان میدهد که ماهانه ۴۳.۲ میلیون درخواست کشش (Pull Request) ادغام میشود که ۲۳٪ رشد سالانه دارد. تنها عامل کدنویسی Copilot در پنج ماه اول خود بیش از یک میلیون درخواست کشش باز کرده است. هر یک از این تغییرات قبل از ادغام نیاز به یک محیط واقعی برای اجرا دارند.
ترکیب مستأجران در حال تغییر است. نظرسنجی سال ۲۰۲۵ استکاورفلو نشان داد نیمی از توسعهدهندگان حرفهای روزانه از ابزارهای هوش مصنوعی استفاده میکنند و هر کاربر روزانه میتواند دو، سه یا پنج جلسه عامل همزمان را اجرا کند. تقاضای محیط دیگر بر اساس تعداد کارمندان نیست، بلکه حاصل ضرب تعداد کارمندان در تعداد عوامل در تعداد تکرارها است.
عوامل کدنویسی درخواستهای محیط را به ترافیک تبدیل کردند: همزمان، کوتاهمدت و بیامان. تیمهای پلتفرمی که عقب نمیمانند، آنهایی خواهند بود که از تأمین محیط دست میکشند و شروع به سرویسدهی به آن میکنند.
تیمهای پلتفرم میتوانند آینده را ببینند. آخرین گزارش وضعیت مهندسی پلتفرم نشان داد که ۹۴٪ از سازمانها هوش مصنوعی را برای آینده مهندسی پلتفرم حیاتی میدانند و موضوع اصلی آن تغییر از پلتفرمهای بومی ابری به پلتفرمهای بومی هوش مصنوعی است.
آنچه تغییر کرده تنها حجم نیست، بلکه شکل تقاضا نیز تغییر کرده است. تقاضای انسانی روزانه، قابل مذاکره و تحملکننده تأخیر یک صبح است. اما عوامل کدنویسی دوباره تلاش میکنند، گسترش مییابند و در حلقههای تنگ تکرار میشوند و شکلی از تقاضا را ایجاد میکنند که در سراسر پلتفرم نامی دارد: ترافیک.
مدل تکراری: منحنی هزینه قاتل
مدل تکراری به هر درخواست یک کپی کامل از پشته (Stack) میدهد. بیایید هزینه را حساب کنیم: یک سیستم ۴۰ سرویس با پایگاههای داده و صفهایش برای هر کپی چند دلار در ساعت هزینه دارد، دهها دقیقه برای مونتاژ زمان میبرد و در طول پنجره کوتاه اعتبارسنجی که برای آن ساخته شده عمدتاً بیکار میماند.
وقتی این مدل را با همزمانی ضرب کنید، فرو میریزد. صدها درخواست در روز با همپوشانی متوسط یعنی دهها کپی کامل همزمان و صورتحسابی که خطی با فعالیت عامل افزایش مییابد. تأخیر هم یک مرتبه بزرگی اشتباه است، چون عاملی که در چند ثانیه تکرار میشود نمیتواند دهها دقیقه برای رسیدن محیط صبر کند.
پیشتأمین یک استخر گرم (Warm Pool) هم مدل را نجات نمیدهد، فقط اتلاف را جابجا میکند. تقاضای عامل انفجاری است: استخری که برای اوج طراحی شده در پایینترین سطح بیکار است و استخری که برای پایینترین سطح طراحی شده در اوج صف میکشد. پرداخت هزینه کپی کامل برای ظرفیتی که بیشتر از آن استفاده نمیکنید، تعریف منحنی هزینه اشتباه است.
مدل اشتراکی: صفهایی که شما را نابود میکنند
مدل اشتراکی یک محیط استیجینگ واحد را اجرا میکند و مستأجران را به نوبت میپذیرد. نظریه صفبندی این حالت شکست را از سال ۱۹۶۱ توصیف کرده است. قانون لیتل (Little's Law) میگوید تعداد درخواستها در سیستم برابر نرخ ورود ضربدر زمان در سیستم است. با نزدیک شدن نرخ ورود به ظرفیت محیط، زمان انتظار به جای کاهش تدریجی، منفجر میشود. عوامل تعداد ورود را ۵ تا ۱۰ برابر میکنند در حالی که نرخ تکمیل ثابت میماند.
استیجینگ مشترک همچنین از نظر ایزولاسیون شکست میخورد. یک تغییر خراب محیط را برای همه مستأجران پشت سر آلوده میکند؛ بنابراین صف نه تنها طولانی میشود، بلکه به طور دورهای ریست میشود.
راهحل: محیطهای سرویسشونده به جای تأمینشونده
تیمهای پلتفرم باید از منطق «تأمین محیط» به «سرویسدهی محیط» تغییر رویه دهند. به جای کپی کامل پشته یا اشتراک یک محیط، باید از تکنیکهایی مانند محیطهای زودگذر (Ephemeral Environments) و مجازیسازی سبک استفاده کنند. این رویکردها به عوامل کدنویسی اجازه میدهند در چند ثانیه محیط خود را دریافت کنند، بدون اینکه هزینههای گزاف یا صفهای طولانی ایجاد شود.
پلتفرمهای مدرن باید از معماریهایی مانند میکروسرویسها و کانتینرها بهره ببرند تا بتوانند هر درخواست عامل را به صورت ایزوله و با سرعت بالا پاسخ دهند. این تغییر نه تنها هزینه را کاهش میدهد، بلکه سرعت تحویل نرمافزار را نیز افزایش میدهد.
در نهایت، مهندسی پلتفرم با چالشی تاریخی روبرو است. عوامل کدنویسی دیگر یک دکوراسیون نیستند؛ آنها بار اصلی مصرف محیط را تشکیل میدهند. تیمهایی که این تغییر را درک کنند و روشهای خود را متحول کنند، در عصر جدید توسعه نرمافزار پیشرو خواهند بود.
