واژهنامه
تجربهی توسعهدهنده developer experience
کاربرمحوری user centricity
پلتفرمِ توسعهدهندهِ داخلی internal developer platform
تحویل delivery
دورا DORA
ادغامِ مستمر continuous integration
مهندسیِ پلتفرم platform engineering
فراهمسازی provisioning
قابلیت capability
روند trend
پیشگفتار
مهندسیِ پلتفرم تنها یک روندِ زودگذر نیست؛ بلکه آیندهی تحویلِ نرمافزار است.
تا همین چند سالِ پیش، چنین ادعایی چیزی جز یک حرفِ عجیب به نظر نمیرسید. درست است که برخی سازمانها شروع به کنارِ هم گذاشتنِ فناوریها و ابزارهای پیچیدهی خود کرده بودند تا آنها را بدونِ نیازِ مستقیم به تیمِ عملیات (Ops) به شکلی سادهتر در اختیارِ توسعهدهندگان قرار دهند، اما “مهندسیِ پلتفرم” بهعنوان یک حوزهی تخصصی هنوز وجود نداشت.
این وضعیت در سال ۲۰۱۹ تغییر کرد، زمانی که اولین گردهماییِ مهندسیِ پلتفرم در برلین برگزار شد. در آن زمان، این رویداد یک جمعِ کوچک از مهندسانی بود که از چالشهای پذیرشِ روشهای DevOps در سازمانهایشان خسته شده بودند. هرچند رویکردِ DevOps با شعار “تو میسازی، خودت هم اجرا میکنی” (you build it, you run it) برای برخی تیمهای نرمافزاری باعثِ افزایشِ بهرهوری و کارایی شد، اما برای بسیاری دیگر فرایندی بسیار دردناک بود.
برای اکثریتِ سازمانهای مهندسی، پیچیدگیِ روزافزونِ فناوریها و معماریهای مبتنی بر فضای ابری، همراه با این انتظار که توسعهدهندگان مسئولیتِ همه چیز را بر عهده بگیرند، ترکیبی طاقتفرسا ایجاد کرده بود. توسعهدهندگان تحتِ فشارِ شدیدِ ذهنی در تلاش بودند کدهای خود را سریع ارائه دهند و دچار فرسودگی شغلی میشدند. تیمهای عملیات نیز زیر سیل درخواستهایی از توسعهدهندگانی که از پیچیدگی تنظیمات DevOps سردرگم بودند، گرفتار میشدند. همه ناامید بودند و بهرهوری کاهش یافته بود. تغییرات جدی مورد نیاز بود.
آغازِ مهندسی پلتفرم
در دهه ۲۰۱۰، غولهای فناوری مانند گوگل، فیسبوک، ایربیانبی و نتفلیکس شروع به ساخت پلتفرمهایی کردند که هدفشان کمک به توسعهدهندگان و تیم عملیات (Ops) برای انجام کارها به شکلی مؤثرتر و کارآمدتر بود. برخی سازمانهای کوچکتر نیز با مشکلات مشابهی مواجه شدند و تلاش کردند از این غولهای فناوری الگو بگیرند، اما کمبود تخصص، منابع و راهنماییهای لازم، آنها را از تحقق رؤیای ساخت پلتفرمهایشان بازداشت.
در سال ۲۰۱۸، اوان باتچر نامی برای چیزی که بسیاری از این سازمانها در حال ساخت آن بودند، انتخاب کرد. او یک پلتفرم دیجیتال (آنچه امروز به آن پلتفرم داخلی توسعهدهنده یا IDP میگوییم) را اینگونه تعریف کرد:
«یک زیربنای متشکل از APIهای سلفسرویس، ابزارها، سرویسها، دانش و پشتیبانی که بهعنوان یک محصول داخلی جذاب سازماندهی شدهاند.»
این ایده که پلتفرمها باید بهعنوان یک محصول در نظر گرفته شوند، به یکی از اصول بنیادین مهندسی پلتفرم تبدیل شد.
سپس، در سال ۲۰۱۹، متیو اسکلتون و مانوئل پایس کتاب Team Topologies (که به انجیل مهندسی پلتفرم نیز معروف است) را منتشر کردند. این کتاب برای اولین بار به موضوع تیمهای پلتفرم و رابطه آنها با سایر بخشهای سازمان مهندسی پرداخت. اسکلتون و پایس الگوهای نامناسب DevOps را شناسایی کردند، جایی که ساختارهای تیمی باعث میشد مالکیت بین توسعهدهندگان و تیم عملیات مبهم شود. آنها Team Topologies را نوشتند تا تفکیک وظایف واضحتری ارائه دهند.
هنوز به یاد دارم که چقدر مدیر ارشد فناوری ما، کریس استیونسون، هیجانزده بود پس از اولین ملاقات با پایس در کنفرانس O’Reilly Velocity سال ۲۰۱۹ در برلین.
کتاب Team Topologies یکی از اولین و مهمترین نقاط عطف مهندسی پلتفرم بود و راه را برای بسیاری از پیشرفتهای آینده در این حوزه هموار کرد.
جامعه مهندسی پلتفرم
در این مرحله، ما درک بهتری از اینکه پلتفرمها و تیمهای موفق پلتفرم چگونه میتوانند به نظر برسند، پیدا کرده بودیم. اما همچنان نمونههایی که در اختیار داشتیم، مربوط به غولهایی مانند گوگل و نتفلیکس بود؛ مدلهایی که برای اکثر سازمانها دستنیافتنی بودند. اینجاست که گروه کوچک ما وارد میدان شد. ما فضایی میخواستیم تا تجربیات خود را به اشتراک بگذاریم و از متخصصانی که در سازمانهای مشابه ما پلتفرم ساخته بودند، مشاوره بگیریم.
این جامعه کوچک اما در حال رشد سریع به این نتیجه رسید که ساخت پلتفرمها یک حوزه تخصصی مستقل است؛ مکمل DevOps، اما متفاوت از آن. مهندسی پلتفرم بهعنوان «حوزه طراحی و ساخت زنجیره ابزارها و گردشکارهایی که قابلیتهای سلفسرویس را در عصر فناوریهای بومی ابری ممکن میسازند» تعریف شد. مهندسان پلتفرم، پلتفرمهای داخلی توسعهدهنده (IDP) را میسازند، که از «تکنولوژیها و ابزارهای متعدد تشکیل شدهاند و به شکلی کنار هم قرار میگیرند که بار ذهنی توسعهدهندگان را کاهش دهد، بدون اینکه زمینه و فناوریهای زیربنایی پنهان شوند.»
پلتفرمهای داخلی توسعهدهنده توانستند بزرگترین چالشهای سازمانهای مهندسی نرمافزار را حل کنند، آن هم با استفاده از رویکرد «پلتفرم بهعنوان یک محصول.»
مهندسی پلتفرم برای بسیاری از افراد قابلدرک و جذاب بود. این مفهوم به چیزی که قبلاً وجود داشت، نام و درک مشترک داد. وقتی گردهمایی برلین در دوران همهگیری به فضای آنلاین منتقل شد، مهندسان پلتفرم در شهرهای مختلف جهان شعبههای خود را ایجاد کردند.
اعضای جدید از یافتن جامعهای از افراد همفکر هیجانزده بودند. آنها توسعهدهندگان بکاند، مهندسان زیرساخت، Ops و DevOps بودند که احساس میکردند ساخت پلتفرمهای داخلی توسعهدهنده، کاری معنادارتر از کارهایی است که قبلاً انجام میدادند. بسیاری مشتاق بودند تا بیشتر درباره رویکرد «پلتفرم بهعنوان یک محصول» یاد بگیرند و به سازمانهایشان ارزش ارائه دهند. سایر اعضای جامعه متوجه شدند که آنچه همواره انجام میدادند، همان مهندسی پلتفرم بوده است، فقط برایش نامی نداشتند. این جامعه فضایی فراهم کرد تا متخصصان بهتر به منابع دسترسی پیدا کنند و آموختههایشان را به اشتراک بگذارند.
کانال Slack مهندسی پلتفرم در سال ۲۰۲۱ راهاندازی شد تا افراد از بخشها و شهرهای مختلف جهان بتوانند تعامل مستقیمتری داشته باشند. یک سال بعد، وبسایت platformengineering.org برای نمایش بینشها، بحثها و منابع اعضای جامعه ایجاد شد.
کمکم ایده برگزاری یک کنفرانس مهندسی پلتفرم مطرح شد و به همین ترتیب PlatformCon متولد شد. کنفرانسی توسط و برای مهندسان پلتفرم، که تا آن زمان نظیر نداشت. با توجه به پراکندگی جامعه در کشورهای مختلف، ما تصمیم گرفتیم قالبی مجازی و نوآورانه را امتحان کنیم.
یک چیز کاملاً روشن است: موفقیت PlatformCon 2022 بدون اشتیاق جامعه برای به اشتراک گذاشتن دیدگاهها و تجربیاتشان ممکن نبود. ما ۷۸ سخنرانی از متخصصانی دریافت کردیم، از جمله نایجل کرستن (مدیر ارشد فناوری وقت در Puppet)، گرگور هوپه (نویسنده کتاب Cloud Strategy)، مانوئل پایس (یکی از نویسندگان Team Topologies)، و نیکی وات از OpenCredo.
سخنرانیهای PlatformCon موضوعات بنیادی مهندسی پلتفرم را پوشش دادند. بهعنوان مثال، پائولا کندی از Syntasso توضیح داد که چرا بار شناختی یکی از مشکلات کلیدی برای تیمهای پلتفرم است و چگونه میتوان با پیروی از رویکرد «پلتفرم بهعنوان یک محصول» و یافتن سطح مناسبی از انتزاع، این بار را کاهش داد.
سخنرانان با دیدگاهها و تجربیات منحصربهفرد خود، بیش از ۷۰۰۰ شرکتکننده را تحت تأثیر قرار دادند. آنها در کانال Slack جامعه داستانها و منابع خود را به اشتراک گذاشتند و دستاوردهای کلیدی خود از کنفرانس را در شبکههای اجتماعی منتشر کردند.