مهندسی پلتفرم جایگزین DevOps می‌شود — این در سال ۲۰۲۶ واقعاً به چه معناست

زمانی که شرکت‌ها یک دهه پیش DevOps را پذیرفتند، وعده‌ای فرهنگی در کار بود: توسعه‌دهندگان و مهندسان عملیات باید با یکدیگر همکاری می‌کردند و دیوار میان «ما می‌نویسیم» و «شما اجرا می‌کنید» را فرو می‌ریختند. اما آنچه بسیاری از سازمان‌ها به جای آن به دست آوردند، تبدیل شدن هر توسعه‌دهنده به یک مهندس زیرساخت نیمه‌وقت بود — چرخش‌های کشیک، اشکال‌زدایی از Kubernetes در نیمه‌شب، و مدیریت انحراف وضعیت Terraform در زمانی که می‌خواستند قابلیت‌های جدید ارائه دهند. زحمتی که DevOps وعده حذف آن را داده بود، از تیم‌های عملیات به تیم‌های توسعه منتقل شد.

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

یک Internal Developer Platform واقعاً چیست

یک Internal Developer Platform (IDP) محصولی است که تیم‌های مهندسی پلتفرم آن را می‌سازند. این یک ابزار واحد نیست — بلکه لایه‌ای گزیده از انتزاعات، گردش‌کارهای خودکار، و رابط‌های سلف‌سرویس است که میان توسعه‌دهندگان و زیرساخت زیرین (ارائه‌دهندگان ابر، خوشه‌های Kubernetes، پایگاه‌های داده، کنترل‌های امنیتی، سامانه‌های پایش) قرار می‌گیرد.

یک IDP بالغ معمولاً موارد زیر را فراهم می‌کند:

• قالب‌های سرویس / اسکفولدینگ: نقاط شروع از پیش‌تعریف‌شده برای سرویس‌های جدید (قالب میکروسرویس، قالب ارائه مدل ML، قالب خط لوله داده) با پیش‌فرض‌های معقول برای CI/CD، ثبت رویداد، پایش، و امنیت که از پیش پیکربندی شده‌اند
• محیط‌های سلف‌سرویس: توسعه‌دهندگان می‌توانند محیط‌های dev/staging را بدون ثبت درخواست یا انتظار برای تأیید تیم عملیات تأمین کنند — پلتفرم به‌صورت خودکار محدودیت‌های حفاظتی را اعمال می‌کند
• گردش‌کارهای استقرار: دکمه‌ای برای «استقرار در محیط تولید» که آزمون‌های خودکار را اجرا می‌کند، خط‌مشی‌های امنیتی را بررسی می‌کند، تقسیم ترافیک به روش canary یا blue/green را اعمال می‌کند، و در صورت افزایش ناگهانی نرخ خطا بازگردانی می‌کند — بدون اینکه توسعه‌دهنده هیچ‌یک از این موارد را مدیریت کند
• کاتالوگ سرویس: فهرستی قابل جستجو از تمام سرویس‌ها، مالکان آن‌ها، وابستگی‌های آن‌ها، SLAهای آن‌ها، و runbookهای آن‌ها — که مشکل دانش قبیله‌ای را کاهش می‌دهد
• مشاهده‌پذیری آماده‌به‌کار: هر سرویس جدید به‌طور خودکار متریک‌ها، logها و traceهای استاندارد را منتشر می‌کند؛ توسعه‌دهندگان نیازی ندارند از ابتدا instrumentation را راه‌اندازی کنند

مفهوم کلیدی، مسیر طلایی است: روش توصیه‌شده برای انجام وظایف رایج (استقرار یک سرویس، افزودن یک پایگاه داده، راه‌اندازی یک cron job). مسیر طلایی دارای رویکرد مشخص و خودکار است. توسعه‌دهندگانی که از آن پیروی می‌کنند نیازی به درک جزئیات ندارند — پلتفرم آن‌ها را مدیریت می‌کند. توسعه‌دهندگانی که نیاز به انحراف دارند می‌توانند این کار را بکنند، اما از شبکه ایمنی خودکار خارج می‌شوند.

Backstage: بنیاد Open Source

Spotify در سال ۲۰۲۰ Backstage را Open Source کرد، پس از آن که از آن به‌صورت داخلی برای حل مشکل کاتالوگ سرویس و پورتال توسعه‌دهنده در مقیاس بزرگ استفاده کرده بود. این پروژه اکنون یک پروژه incubating در CNCF است و به بنیاد de facto برای IDP‌ها در شرکت‌های بزرگ تبدیل شده است: تخمین زده می‌شود که ۸۰٪ از شرکت‌های Fortune 100 آن را آزمایش کرده‌اند، و چند صد شرکت نمونه‌های تولیدی آن را مستقر کرده‌اند.

Backstage یک پورتال توسعه‌دهنده مبتنی بر پلاگین با یک کاتالوگ نرم‌افزاری در هسته خود فراهم می‌کند. به صورت پیش‌فرض، سرویس‌ها، API ها، مستندات، تیم‌ها و اجزای زیرساخت را فهرست‌بندی می‌کند. پلاگین‌ها آن را گسترش می‌دهند تا با Kubernetes، سیستم‌های CI/CD، ارائه‌دهندگان ابری، ابزارهای مدیریت رویداد و ده‌ها سیستم دیگر یکپارچه شود. نتیجه یک رابط یکپارچه است که در آن یک توسعه‌دهنده می‌تواند هر سرویسی را بیابد، مالکیت آن را درک کند، به مستنداتش دسترسی داشته باشد، وضعیت سلامت آن را بررسی کند و استقرارها را راه‌اندازی کند — بدون جابجایی بین ۱۲ ابزار مختلف.

ضعف Backstage این است که اساساً یک فرانت‌اند و کاتالوگ است. به تنهایی زیرساخت تأمین نمی‌کند و استقرارها را هماهنگ نمی‌کند — این قابلیت‌ها نیازمند یکپارچه‌سازی با سیستم‌های زیرین (Terraform، Crossplane، Argo CD، GitHub Actions) و تخصص لازم برای اتصال آن‌ها به یکدیگر هستند. به همین دلیل است که یک بازار ثانویه از ارائه‌دهندگان Backstage-as-a-service پدید آمده است: Roadie، Port و Cortex همگی نسخه‌های میزبانی‌شده یا بهبودیافته از مفهوم IDP را ارائه می‌دهند که هدف آن‌ها تیم‌هایی است که می‌خواهند از مزایا بهره‌مند شوند بدون آنکه بار نگهداری Backstage را تحمل کنند.

توپولوژی‌های تیمی و اهمیت این سازماندهی مجدد

مدل سازمانی پشت مهندسی پلتفرم، وامدار قابل‌توجهی به کتاب Team Topologies نوشته متیو اسکلتون و مانوئل پائیس (۲۰۱۹) است؛ کتابی که چارچوبی برای ساختارهای تیمی در سازمان‌های نرم‌افزاری معرفی کرده است. بینش محوری مرتبط در اینجا، تمایز میان تیم‌های هم‌راستا با جریان (تیم‌هایی که مستقیماً به کاربران ارزش ارائه می‌دهند و بر اساس حوزه‌های کسب‌وکار سازمان‌دهی شده‌اند) و تیم‌های پلتفرم (تیم‌هایی که با ارائه خدمات داخلی قابل‌اعتماد، بار شناختی تیم‌های هم‌راستا با جریان را کاهش می‌دهند) است.

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

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

آنچه داده‌ها نشان می‌دهند

بررسی مهندسی پلتفرم CNCF در سال ۲۰۲۵ نشان داد که ۷۸٪ از سازمان‌هایی با بیش از ۵۰۰ مهندس، مهندسی پلتفرم را یا پذیرفته بودند یا به‌طور فعال در حال پیاده‌سازی آن بودند. معیارهای DORA (DevOps Research and Assessment) که عملکرد تحویل نرم‌افزار را اندازه‌گیری می‌کنند، به‌طور مداوم نشان می‌دهند که سازمان‌های دارای پلتفرم‌های داخلی بالغ در فراوانی استقرار (هر چند وقت یک‌بار کد ارسال می‌شود)، زمان انتظار برای تغییرات (مدت زمان از commit تا محیط تولید)، نرخ شکست تغییرات، و میانگین زمان بازیابی، نسبت به همتایان خود عملکرد بهتری دارند.

یافتن داده‌های دقیق مطالعات موردی در زمان انتشار دشوارتر است، چراکه اکثر سازمان‌ها پلتفرم خود را به‌عنوان یک مزیت رقابتی تلقی می‌کنند، اما Shopify، Lyft، Airbnb و Stripe همگی گزارش‌های عمومی از دستاوردهای بهره‌وری ناشی از سرمایه‌گذاری در پلتفرم‌های داخلی منتشر کرده‌اند. سرمایه‌گذاری Shopify در مهندسی پلتفرم در سال‌های ۲۰۲۲–۲۰۲۳ به‌عنوان یک عامل تسهیل‌کننده کلیدی در بهبود ۳۳ درصدی توان عملیاتی استقرار توسعه‌دهندگان ذکر شده است. Lyft زمان راه‌اندازی سرویس‌های جدید را از چند هفته به کمتر از یک روز کاهش داده است.

لایه انتزاع ابری

IDP‌های مدرن به‌طور فزاینده‌ای جزئیات مربوط به ارائه‌دهندگان ابری را پنهان می‌کنند. یک توسعه‌دهنده که سرویس جدیدی را مستقر می‌کند، نباید نیاز داشته باشد که بداند شرکتش از کدام ناحیه ابری استفاده می‌کند، چگونه VPCها را پیکربندی کند، یا چه نقش IAM را باید پیوست کند. پلتفرم‌هایی که بر پایه Crossplane (ابزاری بومی Kubernetes برای مدیریت اعلانی منابع ابری) یا انتزاعات Terraform ساخته شده‌اند، می‌توانند یک رابط ساده ارائه دهند — «یک پایگاه داده Postgres با این مشخصات به من بده» — در حالی که پلتفرم منبع ابری واقعی را تأمین می‌کند، سیاست‌های امنیتی را اعمال می‌کند، نظارت را اضافه می‌کند و وابستگی را در کاتالوگ ثبت می‌کند.

این انتزاع علاوه بر تجربه توسعه‌دهنده، یک مزیت استراتژیک دارد: وابستگی به ابر را در لایه اپلیکیشن کاهش می‌دهد. وقتی توسعه‌دهندگان با رابط IDP تعامل می‌کنند به‌جای اینکه مستقیماً با AWS API کار کنند، مهاجرت زیرساخت زیرین یک مشکل تیم پلتفرم است نه بازنویسی کل شرکت. سازمان‌هایی که بر پایه انتزاع‌های پلتفرم ساخته‌اند، مهاجرت‌های ابری کاهش هزینه در دوران پاندمی را به‌مراتب آسان‌تر از آن‌هایی یافتند که این کار را نکرده بودند.

زمانی که مهندسی پلتفرم منطقی است — و زمانی که منطقی نیست

مهندسی پلتفرم هزینه راه‌اندازی دارد. ساخت و نگهداری یک IDP کار واقعی مهندسی محصول است و بازگشت سرمایه‌گذاری به تعداد کافی تیم‌هایی نیاز دارد که از پلتفرم استفاده می‌کنند تا سرمایه‌گذاری توجیه شود. نقطه عطفی که در آن مهندسی پلتفرم از نظر مالی منطقی می‌شود معمولاً ۵۰ تا ۱۰۰ مهندس ذکر می‌شود، هرچند پشته‌های فناوری بسیار پراکنده می‌توانند آن را زودتر توجیه کنند.

در زیر آن آستانه، هزینه‌های ساخت و نگهداری یک IDP احتمالاً از دستاوردهای بهره‌وری بیشتر می‌شود. یک استارتاپ ۱۰ نفره باید از سرویس‌های ابری مدیریت‌شده و ابزارهای آماده CI/CD استفاده کند، نه اینکه انتزاع‌های داخلی بسازد. اشتباهی که بسیاری از شرکت‌های در حال رشد مرتکب می‌شوند این است که خیلی دیر دست به کار می‌شوند — تلاش برای پذیرش مهندسی پلتفرم زمانی که از قبل ۳۰۰ مهندس، یک دهه ابزارهای ناهمگون انباشته‌شده، و عادات عمیقاً ریشه‌دار «فقط از تیم زیرساخت بپرسید» دارند.

نتیجه‌گیری‌های عملی

• با کاتالوگ سرویس شروع کنید، نه با خط لوله استقرار: سریع‌ترین دستاورد برای اکثر سازمان‌ها این است که به توسعه‌دهندگان یک فهرست جستجوپذیر و به‌روز از آنچه وجود دارد و مالک آن کیست داده شود. Backstage که تنها با پلاگین کاتالوگ استقرار یافته، ارزش فوری ارائه می‌دهد و پایه‌ای برای همه چیز دیگر می‌سازد.
• مسیرهای طلایی بر الزامات برتری دارند: اجبار توسعه‌دهندگان به استفاده از گردش‌های کاری استانداردشده موجب نارضایتی می‌شود. واقعاً آسان‌تر کردن مسیر استاندارد نسبت به گزینه‌های جایگزین موجب پذیرش آن می‌شود. ابتدا مسیر مطلوب را بسازید، سپس بر اساس جاهایی که توسعه‌دهندگان از آن منحرف می‌شوند آن را بهبود دهید.
• تجربه توسعه‌دهنده را به صراحت اندازه‌گیری کنید: معیارهای SPACE (رضایت، عملکرد، فعالیت، ارتباطات، کارایی) یا چارچوب‌های مشابه به تیم‌های پلتفرم یک حلقه بازخورد می‌دهند. فقط به شمارش بسته شدن تیکت‌ها اکتفا نکنید.
• آنچه را که می‌توانید بخرید، نسازید: اکوسیستم SaaS مربوط به Backstage (Roadie، Port، Cortex) به طور قابل توجهی بالغ شده است. برای تیم‌هایی که مهندسان پلتفرم اختصاصی ندارند، یک راه‌حل مدیریت‌شده احتمالاً سریع‌تر و ارزان‌تر از میزبانی شخصی Backstage و ساختن افزونه‌ها از صفر است.
• تیم پلتفرم به درک محصول نیاز دارد: رایج‌ترین حالت شکست، تیم پلتفرمی است که آنچه را فکر می‌کند توسعه‌دهندگان نیاز دارند می‌سازد، نه آنچه را که توسعه‌دهندگان واقعاً می‌خواهند. توسعه‌دهندگان داخلی را به عنوان مشتری در نظر بگیرید. تحقیقات کاربری انجام دهید. معیارهای پذیرش را در اولویت قرار دهید.