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

تغییر از devops به مهندسی پلت فرم می تواند تحول آفرین باشد. در اینجا دلیل و آنچه در ایجاد جهش دخیل است.

• IT با پذیرش گسترده devops مشکل دارد
• مهندسی پلتفرم توسعه می‌یابد
• بهبود تجربه و بهره‌وری برنامه‌نویس
• ایجاد اجزای سلف سرویس قابل استفاده مجدد، قابل تنظیم
• مزایای مهندسی پلت فرم
• مسیر پذیرش

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

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

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

IT با پذیرش گسترده devops مشکل دارد

بلوغ توسعه و قابلیت‌های SRE نیازمند سرمایه‌گذاری قابل توجهی در توسعه مهارت‌ها، شیوه‌ها و تغییر فرهنگ است. برای مدیران ارشد فناوری اطلاعات و مدیران ارشد فناوری اطلاعات، دو مشکل اساسی ظاهر می شود.

اول، بسیاری از سازمان‌ها با بدهی‌های فنی و شکاف‌های مهارتی دست و پنجه نرم می‌کنند، بنابراین در حالی که شیوه‌های توسعه و SRE آنها پیشرفته است، پذیرش گسترده آن چالش‌برانگیزتر است. این سازمان‌ها ممکن است با موفقیت CI/CD و IaC را برای برنامه‌های کاربردی ابری و مدرن خود بسازند، اما تلاش می‌کنند تا از این قابلیت‌ها در شیوه‌های استاندارد شده استفاده کنند.

برای سازمان‌های پیشرفته‌تر، موضوع متفاوت است. این سازمان‌ها به احتمال زیاد شیوه‌های خودسازمان‌دهی را اتخاذ می‌کنند و تیم‌ها را برای پیکربندی ابزارهای توسعه‌دهنده خاص برای الزامات معماری برنامه و ارزش‌های پیاده‌سازی خود توانمند می‌سازند. آنها ممکن است پلتفرم های استانداردی داشته باشند، اما هر تیم به طور متفاوتی از ابزارها استفاده می کند. بنابراین، آنها خطوط لوله CI/CD سفارشی، اتوماسیون های IaC، معماری های ابری و پیکربندی های نظارت را مستقر می کنند.

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

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

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

مارکو آناستاسوف، یکی از بنیانگذاران Semaphore CI/CD می‌گوید: «مهندسی پلتفرم یک گام رو به جلو در توسعه است. “مهندسی پلتفرم به توسعه دهندگان این امکان را می دهد تا با ایجاد یک “مسیر طلایی” که توسعه دهندگان می توانند برای توسعه سریع برنامه از آن استفاده کنند، شیوه های devops را راحت تر دنبال کنند.”

برای سازمان‌های بزرگ، مهندسی پلتفرم ممکن است نیازمند تفکیک وظایف از توسعه‌دهندگانی باشد که برنامه‌های کاربردی را می‌سازند و مهندسین پلتفرم که devops-as-a-product ایجاد می‌کنند. آناستاسوف می‌گوید: «یک مهندس پلتفرم بر ایجاد ابزاری برای توسعه‌دهندگان تمرکز می‌کند تا ابزارها، کتابخانه‌ها و زیرساخت‌هایی را که برای نوشتن برنامه‌ها نیاز دارند، خودسرویس کنند.

بهبود تجربه و بهره وری توسعه دهنده

مهندسی پلتفرم اگرچه از نظر مفهومی ساده است، اجرای آن بی اهمیت نیست زیرا به ذهنیت توسعه محصول نیاز دارد. مهندسان پلتفرم باید محصولی را توسعه دهند که تیم های توسعه چابک بخواهند آن را مصرف کنند، و توسعه دهندگان باید تمایلات خود را برای DIY (خودت انجامش بده) رویکردهای توسعه را کنار بگذارند.

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

Donnie Berkholz، معاون ارشد مدیریت محصول در Percona، می‌گوید: «مهندسی پلتفرم نحوه انجام تیم‌ها را پوشش می‌دهد. با استفاده از اتوماسیون و سلف‌سرویس، نوع مناسبی از تجربه توسعه‌دهنده را ارائه می‌دهد، بنابراین توسعه‌دهندگان می‌توانند به جای اینکه منتظر بمانند تا زیرساخت‌ها براساس درخواست بلیط راه‌اندازی شود، به نوشتن کد و پیاده‌سازی برنامه‌ها بپردازند.»

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

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

ایجاد مؤلفه‌های قابل استفاده مجدد، قابل تنظیم، سلف سرویس

یکی از راه‌های در نظر گرفتن مهندسی پلتفرم این است که از توسعه‌دهندگان بخواهیم عبارت زیر را پر کنند: «تیم من نمی‌تواند زمان کافی را برای رسیدگی به نگرانی‌های فنی> سرمایه‌گذاری کند، زیرا ما در حال صرف زمان برای توسعه هستیم. حفظ یا بهبود <اتوماسیون‌های فنی> و پیکربندی‌های زیرساخت>.”

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

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

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

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

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

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

کریس کونی، مدافع توسعه‌دهنده در Coralogix. “مهندسی پلت فرم در حل برخی از مشکلات کلیدی که در مقیاس رخ می دهند عالی است.”

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

• افزایش ثبات بین تیم ها و کاهش ذهنیت تک راه حل
• به‌جای بازسازی و سفارشی‌سازی، مؤلفه‌های مشترک را کشف کرده و مجدداً از آنها استفاده کنید
• انطباق را با پلتفرم ایجاد کنید

مسیر پذیرش

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

• مهندسی پلتفرم از کجا می‌تواند ارزشی را برای تیم‌های متعدد از طریق بهبود کارایی یا انطباق ارائه دهد؟
• چگونه باید کار توسعه مهندسی پلتفرم را بدون ایجاد تنگناهای جدید سازماندهی کنیم؟
• هویج و چوب برای ایجاد انگیزه در تیم های توسعه بیشتر برای استفاده از قابلیت های ارائه شده توسط مهندسی پلت فرم چیست؟
• آیا مهندسی پلتفرم تمرکز را تغییر می‌دهد تا تیم‌های توسعه زمان بیشتری را صرف ارائه عملکرد و بهبود قابلیت‌های غیرعملکردی کنند؟

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