پلتفرم توسعه دهنده داخلی چیست؟ PaaS راه شما را انجام داد

سازمان‌هایی که با موفقیت فرهنگ توسعه را برای انتشار سریع و پایدار نرم‌افزار ایجاد کرده‌اند، اغلب به یک پلتفرم توسعه‌دهنده داخلی برای استقرار کد متکی هستند. اما “IDP” چیست و چگونه می توان آن را دریافت کرد؟

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

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

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

یک پلت فرم توسعه دهنده داخلی (IDP) چیست؟

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

همانطور که ایوان بوچر، رئیس مهندسی ThoughtWorks، نوشت، “Words سخت هستند، به نظر می رسد «پلتفرم» تقریباً مبهم‌ترین عبارتی است که می‌توانیم برای رویکردی استفاده کنیم که برای افزایش سرعت و کارایی تحویل در مقیاس بسیار مهم است.»

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

برای Camille Fournier، رئیس مهندسی پلتفرم در صندوق تامینی Two Sigma، موضوع به بخش نرم‌افزاری زیرساخت مربوط می‌شود. او در سال ۲۰۲۰ در پست وبلاگ در مورد موضوع.

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

“در هسته خود، یک پلت فرم توسعه دهنده داخلی موثر پیچیدگی را تقسیم می کند. کریس استفنسون، مدیر ارشد فناوری Humanitec که قبلاً پلتفرم‌های داخلی گوگل را ساخته بود، در پست وبلاگ.

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

مزایای یک پلت فرم توسعه دهنده داخلی

جدیدترین گزارش وضعیت Devops توسط Puppet و CircleCI پلتفرم‌های داخلی سلف‌سرویس را به عنوان یکی از سه عنصر کلیدی که سازمان‌های بالغ را متمایز می‌کند، در کنار مدیریت تغییرات خودکار و امنیت یکپارچه، سازمان‌ها را از همتایان خود متمایز می‌کند.

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

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

یک پلتفرم توسعه‌دهنده داخلی دارای دو گروه کاربر اصلی است که هر کدام دیدگاه خاص خود را دارند: تیم پلتفرم/عملیات/devops و تیم توسعه‌دهنده.

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

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

جیمز وین، مدیر ارشد فناوری Expert Thinking، یک شرکت مشاوره ابری، گفت: «این طرز فکر محصول کلید موفقیت یک پلتفرم داخلی است. “بدون آن، تیم ها روی چیزهایی تمرکز می کنند، زیرا جالب است و لزوما چیزی نیست که ارزش کسب و کار را فراهم کند.”

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

کاسپار فون گرونبرگ، مدیر عامل Humanitec، استارت آپی که در سال ۲۰۱۸ برای کمک به شرکت ها در ایجاد یک پلتفرم داخلی تاسیس شد، گفت: “این باید برای تیم devops انعطاف پذیر باشد اما برای توسعه دهندگان غیر قابل انعطاف باشد.” “تمام قابلیت های سفارشی سازی باید در اختیار تیم devops باشد و مسیرهای طلایی را برای توسعه دهندگانی ایجاد کند که نمی خواهند به زیرساخت های اساسی فکر کنند.”

اما آیا با انجام این کار، برنامه‌نویس و عملیات‌ها را دوباره از هم جدا نمی‌کنیم؟

نایجل کرستن، CTO میدانی در Puppet می‌گوید که ضروری است تیم‌های مسئول سلامت عملیاتی پلتفرم باید با افرادی که در بالای آن راه‌حل‌ها را می‌سازند و در حالت ایده‌آل، همان گروه هستند، در هم تنیده شوند. او گفت: «اگر آنها را از هم جدا کنید، در نهایت به دنیای قدیمی توسعه‌دهندگان در مقابل عملیات‌ها خواهید رسید.

IDP در مقابل PaaS

برخلاف یک پلتفرم به عنوان یک سرویس (PaaS)، که در آن فروشنده معمولاً نحوه کار یک برنامه‌نویس را دیکته می‌کند، یک پلتفرم توسعه‌دهنده داخلی بر اساس ابزارها و فرآیندهایی ساخته شده است که تیم‌های توسعه‌دهنده قبلاً با آن‌ها آشنا هستند، اما با سطح بیشتری از انتزاع و سازگاری.

همانطور که کلسی هایتاور، فن‌شناس Google در سال ۲۰۱۷ توییت کرد، “من متقاعد شده‌ام که اکثریت افرادی که زیرساخت را مدیریت می کنند فقط یک PaaS می خواهند. تنها مورد نیاز: باید توسط آنها ساخته شود.”

بسیاری از سازمان‌های کوچک‌تر به PaaS روی می‌آورند تا تیم مهندسی خود را سریع راه‌اندازی کنند – با انتخاب‌های محبوب از جمله Heroku که توسط Salesforce در سال ۲۰۱۰ خریداری شد، یا OpenShift ، Cloud Foundry، یا ابزارهای خود فروشندگان بزرگ ابر عمومی — اما اغلب متوجه می شوند که این ابزارها فاقد انعطاف پذیری برای گسترش واقعی هستند.

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

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

Kersten از Puppet که خود یک Google SRE سابق است، همه چیز را در منظر مشابهی می بیند: «ما سازمان های بزرگ متعددی را دیده ایم که سعی می کنند از مدل تیم های کوچک مستقل استفاده کنند، که در آمازون کار می کند زیرا آنها توسعه دهندگان بسیار ماهری دارند، اما همه چیز دارند. به عنوان یک سرویس ساخته شده است. آنها به اندازه نرم افزارهای قدیمی تنظیم یا محدود نشده اند. [اما برای سایر سازمان ها] هرج و مرج و بدهی سازمانی ایجاد می کند.»

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

حرکت از یک فرآیند استقرار یکپارچه به تحویل مداوم یک تغییر فرهنگی عمده است و نباید دست کم گرفت. Bottcher نوشت.

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

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

کرستن گفت: «داشتن قابلیت درک کاربران و ایجاد آن تغییرات فرهنگی مشکل بزرگ‌تری است.

توصیه او و بسیاری دیگر از کارشناسان: از کوچک شروع کنید. Expert Thinking’s Whinn توصیه کرد: “یک مرکز برتری را برپا کنید و موارد استفاده را شناسایی کنید که در آن پلتفرم می تواند برای ایجاد تفاوت واقعی توسعه یابد.” حتی ایجاد یک محیط آزمایشی برای یک برنامه واحد و ایجاد API های مورد نیاز از آنجا می تواند به تیم پلت فرم کمک کند تا در مسیر درست قرار گیرد.

«متیو اسکلتون»، یکی از نویسندگان <، گفت: «یکی از راه‌های فکر کردن به این موضوع این است که باریک‌ترین پلت‌فرم قابل دوام باشد، یا «صریح بودن در مورد پلت‌فرم مهم است و اطمینان حاصل شود که بزرگ‌تر از حد لازم نیست». a href="https://www.amazon.co.uk/Team-Topologies-Organizing-Business-Technology/dp/1942788819" rel="nofollow">Team Topologies، در طول < یک href="https://www.youtube.com/watch?v=haejb5rzKsM" rel="nofollow">اجلاس سازمانی Devops در سال ۲۰۱۹. “ما باید مطمئن شویم که هر چیزی که می سازیم برای استفاده قانع کننده است، دارای تجربه توسعه دهنده قوی است و با کاربران به عنوان مشتریانی رفتار می کنیم که باید با آنها صحبت کنیم تا بتوانیم نیازهای آنها را درک کنیم و آنها را برآورده کنیم.”

فون گرونبرگ از Humanitec گفت: “اگر بسازید یا بخرید همینطور است: باید از سطح پایه شروع کنید… ما معمولاً می بینیم که سازمان ها گروه کوچکی از بهترین مهندسان خود را انتخاب می کنند و از آنها می خواهند که چسبنده همه جدا شده باشند. زنجیر ابزار سپس شروع به متمرکز کردن این موضوع حول یک API مشترک می‌کنید که تیم‌ها می‌توانند با آن کار کنند و ساختار را به آن دریایی از ابزارهای بدون ساختار بیاورند.”