DKeepaDKeepa Plus

رویکرد Project-as-a-Service در توسعه پلتفرم های نرم افزاری

M
Mohammad Alipourنویسنده و کارشناس محتوا
۲۵ خرداد ۱۴۰۵زمان مطالعه: 3 دقیقه
رویکرد Project-as-a-Service در توسعه پلتفرم های نرم افزاری

خلاصه هوشمند مقاله

جری ون هولست و مارسل کرکر در رویداد KubeCon & CloudNativeCon با بررسی چالش‌های خودمختاری کامل توسعه‌دهندگان، نشان دادند که چگونه تغییر استراتژی به‌سمت توانمندسازی و استفاده از رویکرد Project-as-a-Service می‌تواند درگیری ذهنی تیم‌ها با زیرساخت را به‌طور چشمگیری کاهش دهد

این تیم در سال ۲۰۱۷ کار خود را با یک Proof of Concept کوچک روی OpenShift آغاز کرد. فلسفه‌ی اولیه‌ی آن‌ها بر پایه‌ی خودمختاری کامل توسعه‌دهندگان بنا شده بود؛ پلتفرم ارائه می‌شد و برنامه‌نویسان مسئولیت کل چرخه‌ی حیات نرم‌افزار را بر عهده داشتند. با این حال، با گسترش کاربران در سال ۲۰۱۹، تیم‌ها با چالش‌های جدی و رشد دردناکی مواجه شدند. کاربران جدید احساس می‌کردند یادگیری این سیستم به‌شدت زمان‌بر و طاقت‌فرساست و با بار اضافه‌ی کوبرنیتیز و درگیری‌های فرسایشیِ آن دست‌وپنجه نرم می‌کردند؛ وضعیتی که در آن توسعه‌دهندگان زمان بیشتری را صرف مدیریت پلتفرم و کانفیگ‌ها می‌کردند تا نوشتن کد اصلی برنامه.

مشکل دیگر، پراکندگی دانش و نبود استانداردسازی بود. تیم‌های مختلف برای حل مشکلات یکسانی مانند لاگینگ یا پیکربندی Ingress، راه‌حل‌های کاملاً متفاوتی خلق می‌کردند که حتی درون یک کلاستر واحد نیز باعث هرج‌ومرج مطلق و فضایی بی‌قانون شده بود؛ مسئله‌ای که فرآیند پشتیبانی را برای مهندسان زیرساخت به یک کابوس تبدیل می‌کرد. برای عبور از این بحران، آن‌ها به یک معماری کاملاً Automation-first روی آوردند. اکنون اپراتور Project-as-a-Service به تیم‌ها اجازه می‌دهد تا محیط‌های خود را، از Namespaces و RBAC گرفته تا Resource Quota، تنها با یک فایل YAML ساده ایجاد کنند و خود را از شر پیچیدگی‌های فنی رها سازند.

در این معماری جدید، اولویت اصلی تغییر نقشِ پلتفرم از ارائه‌ی پشتیبانیِ منفعلانه (Support) به توانمندسازیِ فعال (Enablement) است. هدف نهایی، ایجاد حس خودکفایی و اعتمادبه‌نفس در میان بیش‌از ۹۹ تیم DevOps است تا مهندسان پلتفرم صرفاً نقش یک میز امداد برای بستن تیکت‌ها را نداشته باشند. برای مقیاس‌پذیری دانش، آن‌ها از استراتژی‌هایی مانند تشکیل Communities of Practice و برگزاری جلسات Container User Group استفاده می‌کنند. تأثیرگذارترین اقدام در این مسیر، برگزاری رویدادهای Accelerator Hackathon است؛ جایی که متخصصان پلتفرم به‌جای ارائه‌ی داکیومنت‌های خشک، یک روز کامل در کنار تیم توسعه‌دهنده می‌نشینند تا اولین اپلیکیشن آن‌ها را به‌صورت عملی روی پلتفرم بالا بیاورند.

دسترسی دادن به سرور در دنیای Cloud-native کافی نیست؛ وظیفه‌ی مهندس پلتفرم صرفاً ارائه‌ی زیرساخت نیست، بلکه حذف کامل اصطکاک‌هایی است که مانع رسیدن کد به محیط Production می‌شوند.

تیم توسعه‌ی این پلتفرم اکنون تمرکز خود را روی مفهومی به نام Golden Path گذاشته است تا استانداردهای توسعه‌ی نرم‌افزار را در ابزارهایی مثل Backstage و قالب‌های CI/CD یکپارچه کند و دغدغه‌های حاشیه‌ای برنامه‌نویس را به حداقل برساند. آن‌ها همچنین در حال ادغام هوش مصنوعی برای بهینه‌سازی عملیات ChatOps و پاسخ‌گویی خودکار به تیکت‌های روتین هستند. این اتوماسیون به مهندسان اجازه می‌دهد تا زمان خود را روی توانمندسازی‌های باارزش‌تر سرمایه‌گذاری کنند. در نهایت، تمرکز بی‌وقفه بر نیازهای برنامه‌نویسان و استانداردسازی فرآیندها نه‌تنها از دوباره‌کاریِ تیم‌ها جلوگیری می‌کند، بلکه فرآیند پذیرش پلتفرم را برای مهندسان بسیار بصری‌تر و هموارتر می‌سازد.

اشتراک‌گذاری:

نظرات کاربران (0)

اولین نفری باشید که نظر می‌دهد!

ثبت نظر جدید