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

توییتر، دو سیگما، Yelp و Zalando توضیح می‌دهند که چرا پلتفرم‌های توسعه نرم‌افزار خود را ساخته‌اند و درس‌هایی را که در این راه آموخته‌اند به اشتراک می‌گذارند.

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

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

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

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

تغییر فرهنگی لازم برای انتقال به یک IDP – که با تیم پلتفرم داخلی خود کامل است – نباید دست کم گرفته شود. شفافیت، ارتباطات منظم و اتخاذ یک طرز فکر محصول اول همه برای اطمینان از دستیابی پلت فرم به اهداف مورد نظر خود لازم است. حتی نیروگاه های مهندسی مانند نتفلیکس به شما می گویند که چقدر می تواند سخت باشد.

فرانک سان میگل، مهندس نرم‌افزار ارشد در نتفلیکس، در مقاله‌ای نوشت: «لحظه‌هایی وجود داشت که توسعه‌دهندگان برنامه احساس می‌کردند که تیم پلتفرم به‌طور مناسبی بر روی نیازهایشان تمرکز نمی‌کند، و زمان‌های دیگری که تیم‌های پلتفرم احساس می‌کردند بیش از حد از خواسته‌های کاربران تحت فشار هستند.» یک href=”https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad” rel=”nofollow”>پست وبلاگ. “ما با باز بودن و صادق بودن با یکدیگر از این نقاط سخت عبور کردیم.”

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

زالاندو: رشد سریع و سیستم‌های زیاد باعث ایجاد درد و رنجی شد که منجر به IDP شد

غول تجارت الکترونیک آلمان Zalando هزاران توسعه دهنده در سراسر جهان دارد که همه آنها از نوعی پلت فرم داخلی برای استقرار کد خود استفاده می کنند. اما همیشه اینطور نبود.

در سال ۲۰۱۴، شرکت با سرعتی خارق‌العاده در حال رشد بود و هفته‌ای ۷۰ مهندس به آن اضافه می‌کرد تا تقاضای رو به رشد را برآورده کند. این رشد به سرعت منجر به گلوگاه های داخلی شد و یک تیم عملیات فناوری اطلاعات شروع به غرق شدن در درخواست ها کرد. صرف استخدام افراد بیشتر مشکل را در دراز مدت حل نمی کند.

یان لوفلر، مدیر ارشد فناوری Plesk و رئیس سابق پلتفرم در Zalando، گفت: «اگر نیاز دارید سریع‌تر آزاد شوید، این بازی رفع انسداد و رفع تنگناها را انجام می‌دهید و استراتژی برای حل این علت اصلی ایجاد می‌کنید. “این کار با امتحان کردن چیزها و کوتاه کردن زمان تحویل شما برای ارسال نرم افزار و دریافت سریع بازخورد شروع می شود.”

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

اولین رویکرد برای حل این مشکل، یک شرط بندی بزرگ بر روی ابر عمومی، کانتینرهای Docker و یک خط لوله مرکزی CI/CD بود. در طول سال‌ها تکرار، این در نهایت به چیزی تبدیل شد که ما اکنون به عنوان یک IDP می‌دانیم.

لوفلر گفت: “تغییرات فرهنگی در نحوه توسعه نرم افزار Zalando و اینکه چگونه شرکت می تواند از یک دنبال کننده سریع به رهبر بازار تبدیل شود، مورد نیاز بود.” “تغییرات زیادی در نحوه استخدام و راه اندازی افراد و پرورش فرهنگ نوآوری لازم بود، و این نیازمند بستری است که مقیاس و نوآوری را امکان پذیر کند.”

خوشبختانه، درد و رنج روش موجود برای انجام کارها انگیزه کافی برای کسب و کار برای خرید ایده یک IDP بود.

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

نتایج چشمگیر بوده است. زمانی که لوفلر در سال ۲۰۱۶ شرکت را ترک کرد، تیمی متشکل از ۷۰ نفر بود که پلتفرم مرکزی را مدیریت می‌کردند که روزانه ۱۷۰ نسخه تولیدی را در بین هزاران توسعه‌دهنده داخلی تامین می‌کرد.

دو سیگما: رویکردهای گسترده ای نیاز به ذهنیت محصول برای ایجاد یک IDP دارد

شرکت خدمات مالی و صندوق های تامینی مستقر در نیویورک Two Sigma دارای ۵۸ میلیارد دلار دارایی تحت مدیریت است و بیشتر به دلیل استفاده از فناوری در راهبرد استراتژی های معاملاتی شناخته شده است.

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

Camille Fournier، رئیس مهندسی پلتفرم در Two Sigma، گفت: «زمانی که شما نیاز به ساخت پلتفرم خود دارید، این امر آشکار می شود. «اگر از چیزی مانند Heroku استفاده می‌کنید، به محدودیت‌های مقیاس‌پذیری می‌رسید و تیم‌ها را می‌بینید که جدا می‌شوند و کار خود را انجام می‌دهند. اگر قرار است تیمی از این پلتفرم پشتیبانی کند و دیدید که آنها مسیرهای هموار پیشنهاد فعلی شما را ترک می‌کنند، می‌دانید که فرصتی دارید که باید آن را حل کنید.”

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

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

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

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

تویتر: انتظار افزایش بهره وری توسعه دهندگان با استفاده از یک IDP

شبکه اجتماعی توییتر از سال ۲۰۱۱ شروع به متمرکز کردن تیم سازنده خود کرد، قبل از اینکه در سال ۲۰۱۴ تیم داخلی مهندسی اثربخشی خود را برای بهبود بهره وری و شادی توسعه دهندگان تشکیل دهد.

نیک تورنو، رهبر پلتفرم در توییتر، گفت: «امروز، ما با جستجوی سرعت شروع می کنیم. “ما این را به عنوان تعداد ویژگی هایی که یک مهندس می تواند در یک واحد زمان ارائه دهد تعریف می کنیم، و می خواهیم تا پایان سال ۲۰۲۳ آن را دو برابر کنیم.”

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

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

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

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

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

Yelp: تکامل یک IDP

پلتفورم توسعه‌دهنده داخلی سایت بررسی محبوب Yelp به قدری تثبیت شده است که حتی نام خوشمزه خود را نیز دارد: PaaSTA.

در ابتدا در سال ۲۰۱۴ توسعه یافت، IDP Yelp به عنوان راهی برای مهندسان به وجود آمد تا از فرآیندهای استقرار عمدتا دستی که توسط یک تیم عملیاتی اختصاصی انجام می‌شد دور شوند.

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

همانطور که از نام پیداست، PaaSTA برداشت خود Yelp است در یک پلتفرم به عنوان یک سرویس. کایل اندرسون، مهندس سابق قابلیت اطمینان سایت در Yelp که اکنون در نتفلیکس کار می کند، می نویسد: “این به توسعه دهندگان اجازه می دهد تا در فایل های پیکربندی دقیقاً نحوه ساخت، استقرار، مسیریابی و نظارت بر کد موجود در مخزن Git خود را اعلام کنند.” در نوامبر ۲۰۱۵ پست وبلاگ< /a>.

پلتفرم حاصل ترکیبی از Docker برای تحویل کد و مهار، Apache Mesos برای اجرای کد و زمان‌بندی، Mesosphere Marathon برای مدیریت خدمات طولانی‌مدت، Chronos برای کارهای دسته‌ای، SmartStack برای ثبت و کشف سرویس، Sensu برای نظارت و هشدار، و Jenkins (اختیاری) برای استقرار مداوم.

باشی گفت: از آن زمان، این پلتفرم “بسیار تکامل یافته است، به طوری که ما تک تک اجزا را جایگزین کرده ایم.” Mesos اکنون Kubernetes است، Spark اکنون Flink است، SmartStack اکنون Envoy است. این یکی از دلایلی است که ما این چیزها را می‌سازیم، زیرا به تیم زیرساخت اجازه می‌دهد بال‌های هواپیما را در حین پرواز جایگزین کند و توسعه‌دهندگان ویژگی فقط می‌توانند چیزهایی بسازند.”

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

بسیاری از اینها به “مدیریت محصول اولیه” مربوط می شود. “با کاربران خود در تماس باشید و برج عاج نسازید.”