مهندسی پلتفرم چیست و آیا کسب و کارها باید آن را بپذیرند؟

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

مهندسی پلتفرم چیست؟

مهندسی پلتفرم فرآیند ساخت زنجیره‌های ابزار و گردش کار است که توسعه دهندگان را با قابلیت‌های سلف‌سرویس توانمند می‌کند و به آنها امکان می‌دهد تا به طور مستقل کل چرخه عمر توسعه نرم افزار را مدیریت کنند. این زنجیره‌های ابزار و گردش‌های کاری با هم به عنوان یک پلتفرم شناخته می‌شوند که در هسته آن بستر توسعه‌دهنده داخلی (IDP) قرار دارد.

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

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

هیاهوی مهندسی پلتفرم

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

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

چرا؟ ضد الگوهای (anti-patterns) مختلفی وجود دارد (که به عنوان anti-types نیز شناخته می‌شود) که اثربخشی پروژه‌های DevOps را تضعیف می‌کند. ضدالگو یک پاسخ متداول به یک فرآیند تکرار شونده است که به شدت معکوس می‌شود.

مهندسی پلت فرم چگونه کار می کند

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

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

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

توسعه نسل جدیدی از ابزارها، مهندسی پلتفرم را به یکی از داغ ترین موضوعات گفتگو در جامعه DevOps تبدیل کرده است. هدف این ابزارها ایجاد و نگهداری پلتفرم ها آسان تر است.

شکست DevOps ؛ زمانی که توسعه دهندگان با مدیریت زیرساخت دچار مشکل می‌شوند

یکی از ضد الگوهای اولیه برای DevOps  - و یک دلیل رایج برای شکست پروژه‌های DevOp  - عدم انسجام است. یک تیم کوچک در سازمان (اغلب توسعه دهندگان) با ساختن ساختارها و گردش کار خود برای پیاده سازی و اجرای DevOps کار می‌کنند. این تیم مسئولیت جمع‌آوری ابزارها و گردش‌های کاری مورد نیاز را برای مدیریت موثر وظایف توسعه و عملیات بر عهده می‌گیرد و به طور موثر تبدیل به نقطه کانونی برای تبدیل مفهوم انتزاعی DevOps به یک چارچوب عملکردی می‌شود.

نتیجه؟ عرضه ناموفق DevOps یا کاهش کارایی، که منجر به کندتر ارائه نرم افزار یا راه حل می شود. این دقیقا برعکس چیزی است که شما از پیاده سازی DevOps  انتظار دارید.

چگونه پلتفرم‌های توسعه‌دهنده داخلی به رفع شکاف‌های زیرساخت کمک می‌کنند

اگر با مفهومی در ITIL به نام سرویس کاتالوگ (service catalog) آشنا باشید، آنگاه مفهوم پلتفرم‌های توسعه دهنده داخلی را درک خواهید کرد. هم سرویس کاتالوگ ITIL و هم یک IDP در مهندسی پلتفرم به عنوان منابع متمرکزی برای تسهیل ارائه و مدیریت خدمات در یک سازمان عمل می‌کنند.

• سرویس کاتالوگ ITIL یک نمای کلی ساختار یافته از خدمات فناوری اطلاعات موجود، توضیحات آنها و قراردادهای مربوط به سطح خدمات ارائه می‌دهد.
• به طور مشابه، یک IDP، مانند Backstage یا Humanitec، به عنوان یک کاتالوگ برای توسعه دهندگان عمل می‌کند و یک پورتال سلف سرویس برای دسترسی به ابزارها، خدمات و منابع مورد نیاز برای توسعه نرم افزار ارائه می‌دهد.
• هر دو امکان مشاهده پیشنهادات موجود را فراهم می‌کنند، استانداردسازی را ترویج می‌کنند و تیم‌ها را قادر می‌سازند تا به راحتی خدمات مورد نیاز خود را کشف و استفاده کنند.

در نهایت، هم سرویس کاتالوگ ITIL و هم IDP هدفشان افزایش کارایی، همکاری و شفافیت در حوزه‌های مربوطه است.

مهندسی پلتفرم جایگزین DevOps نیست

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

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

مسیر طلایی برای موفقیت DevOps و استفاده از طرز فکر محصول

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

شما باید مهندسی پلتفرم را به عنوان یک محصول داخلی و تیم های توسعه خود را به عنوان مشتریان خود در نظر بگیرید. شما باید اصول مدیریت محصول را در توسعه و تکامل IDPها به کار ببرید. این یعنی:

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

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

چه زمانی سازمان من باید مهندسی پلتفرم را بپذیرد؟

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

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

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