چگونه روش ۱۲ عاملی، میکروسرویسهای مبتنی بر کانتینر، و رویکرد monorepo هم با مشتریان و هم توسعهدهندگان در Priceline برنده میشوند.
همانطور که معمای مبتکر به ما می گوید، امروز سازمانهای موفق بهطور فزایندهای برای پذیرش فرآیندهای جدید به منظور پیشرفت به چالش کشیده میشوند. برای سازمانهای مدرنی که برای حفظ مزیت رقابتی بر توسعه نرمافزار تکیه میکنند، این نیاز همیشه حاضر برای تغییر مستلزم بازاندیشی روشهای کار تیمهای توسعه است. اینجا در Priceline – یکی از پربازدیدترین سایتهای مسافرتی جهان با میلیونها بازدیدکننده ماهانه – این به معنای پذیرش نه تنها فنآوریهای جدید و نوآورانه است، بلکه یک طرز فکر کاملاً جدید در مورد نحوه ساخت و استقرار خدمات.
اگر میخواهیم موفقیت را در یک بازار بیش از حد رقابتی حفظ کنیم، باید از مجموعهای کاملاً جدید از استراتژیهای ارائه خدمات پشتیبانی کنیم، و این مستلزم اندیشیدن و کوشش از سوی رهبری فناوری است. تیم پر ستاره ما از فنآوران در تلاش برای رهبری تکامل فناوری در صنعت سفر، حول توسعه برنامههای ۱۲ عاملی، monorepos، توسعه مبتنی بر ترانک و مدیریت وابستگی گرد هم آمدهاند. اما هنوز کارهای زیادی باید انجام شود.
بیایید میکروسرویسهای مبتنی بر کانتینر را در نظر بگیریم. شرکتها در امتداد منحنی پذیرش با کانتینرها و Kubernetes بسیار دورتر از چند سال پیش هستند. بر اساس بررسی بنیاد محاسبات بومی ابری ۲۰۲۰، استفاده از کانتینرها در تولید از سال ۲۰۱۶ تا ۳۰۰ درصد افزایش یافته است. امروزه، ۸۰ درصد از کل پلتفرم محصول Priceline در Google Cloud روی کانتینرها و Kubernetes اجرا میشود.
بسیاری از سازمانهای فناوری بزرگ شروع به درو کردن مزایا (و کشف چالشهای جدید) این تغییر پارادایم در توسعه برنامههای کاربردی کردهاند، اما بسیاری دیگر تازه این سفر را آغاز کردهاند. و علم اقتصاد نشان می دهد که ما هرگز به اندازه کافی از متخصصان و کارشناسان SRE استفاده نخواهیم کرد تا با نیازهای شتاب دهنده توسعه نرم افزار هماهنگی داشته باشند. مدیران ارشد فناوری در همه جا باید از خود بپرسند نه تنها چگونه میتوانند برنامههای کاربردی خود را انعطافپذیرتر و مقیاسپذیرتر کنند، بلکه چگونه میتوانند مسئولیت بیشتری را به دست توسعهدهندگان بگذارند بدون اینکه آنها را با کارهای دستی و اصولی تحت فشار قرار دهند.
در Priceline، ما طرحی را برای مدرن کردن همه برنامههایمان بر اساس مجموعهای از اصول که بر بهرهوری توسعهدهنده تمرکز میکند، توسعه دادیم. در اینجا چگونگی و چرایی آن طرح آمده است.
تغییر سرعت و نوآوری به ۱۲ عامل تغییر دهید
اگرچه Priceline بیش از ۲۰ سال است که وجود دارد، هنوز هم از بسیاری جهات مانند یک استارت آپ عمل می کند. تکامل مداوم در اینجا یک تجمل نیست – ضروری است. رفتارها و خواستههای مشتریان ما مرتباً تغییر میکند و رقابت ما دائماً راههای جدیدی برای مطابقت با این نیازها پیدا میکند. در نتیجه، توسعهدهندگان ما هر روز نوآوری میکنند، چه در محصول، داده، SDLC یا زیرساخت، همگی در عین مدیریت بدهی فنی، قابلیت اطمینان نرمافزار و امنیت. این یک کار بزرگ است.
روش ۱۲ عاملی – که اصول اصلی آن حول قالبهای اعلامی، اتوماسیون و قابلیت حمل میچرخد – به ما اجازه میدهد تیمی برای حفظ فرهنگ نوآوری با جدا کردن نرمافزار ما از وابستگیهای زیرساختی و حصول اطمینان از اینکه در یک ابر، مرکز داده، نرمافزار یا ارائهدهنده خدمات قفل نشدهایم. این بدان معناست که ما میتوانیم یک محیط آربیتراژ زیرساخت را اجرا کنیم، و در طول زمان، در صورت نیاز، بارهای کاری را به هر ابر خصوصی یا عمومی منتقل کنیم.
روش ۱۲ عاملی همچنین نیازمند مدیریت وابستگی شدید در فرآیند ساخت است. این شامل مواردی است که در کانتینرهای ما در حال اجرا است و تأثیر تغییرات روی آن کانتینرها – چه تغییر در سیستم عامل یا در کد خود ما. توانایی بررسی و نمونهسازی کد خود در مراحل اولیه ساخت، به ما امکان میدهد تغییرات را زودتر در فرآیند حمل و نقل تأیید کنیم، که منجر به نوآوری بیشتر و کاهش هزینههای سربار ناشی از رفع مشکلات در استقرار تولید میشود.
جداسازی فرآیندهای ساخت و اجرا به ما امکان میدهد تا آزمایشهای عملکردی خودکار و استقرار مداوم را برای اطمینان بیشتر از سرعت تیمهایمان انجام دهیم. این نه تنها بهرهوری و رضایت توسعهدهنده را افزایش میدهد، بلکه به ما امکان میدهد تا سریعتر ویژگیهای مواجهه با مشتری را آزمایش و بهبود دهیم، که در نهایت نتایج بهتری را برای مسافران و کسبوکارمان به همراه دارد.
رویکرد اول مشتری
برنامه مدرنسازی ما را قادر ساخته است که دادهها و پلتفرم خود را تغییر دهیم و برندههایی را برای مشتریان و کسبوکارمان به ارمغان بیاوریم. با امکان پخش جریانی دادهها در زمان واقعی، میتوانیم سریعتر فعالیتها و رفتارهای مشتریان را در پلتفرم خود درک کرده و به آنها پاسخ دهیم. این به ما امکان میدهد توصیههای خود را برای مکانهایی که مسافران میخواهند بروند و بمانند شخصیسازی کنیم و به ما کمک میکند ویژگیها و عملکردهای جدید را سریع آزمایش کنیم.
استفاده از معماری monorepo در فرآیند طراحی نرم افزار به ما این امکان را می دهد که از تجربه مشتری ثابتی اطمینان حاصل کنیم. به عنوان مثال، اجزای پرداخت ما اکنون می توانند یک بار ساخته شوند و سپس توسط تیم های متعدد مورد استفاده قرار گیرند، به جای داشتن چندین مؤلفه پرداخت مختلف که منجر به تجربه ای از هم گسیخته برای کاربر نهایی می شود.
تیمها میتوانند ویژگیهای خود را به آن مؤلفههای رایج اضافه کنند، و تیمهای پلتفرم ما به طور کامل از آنچه در حال رخ دادن است، مشاهده میکنند. بنابراین، مهم نیست که چه ویژگی هایی به تجربه پرداخت اضافه می شود، پلت فرم نرم افزار یا معیارهای عملکرد ما را به خطر نمی اندازد. معماری monorepo ما همچنین ارتقاها را قابل پیشبینیتر میکند و مدیریت وابستگی را به جای یافتن مشکلات در استقرار پاییندستی به فرآیند طراحی و توسعه تغییر میدهد.
اختلال در توسعه نرم افزار
تمرکز ما بر روی روش ۱۲ عاملی، میکروسرویسهای مبتنی بر کانتینر و رویکرد monorepo، معماری نرمافزاری را که پلتفرم محصول Priceline را تقویت میکند، ارتقا داده است. مزایایی که تاکنون دیدهایم عبارتند از:
- توسعهدهندگان کنترل بیشتری بر نحوه طراحی و توسعه نرمافزار دارند، زیرا به وابستگیها یا پشتههای فنی تیم دیگر وابسته نیستند.
- ما یک ذهنیت «اول توسعهدهنده» ایجاد کردهایم، بنابراین بیشتر مسئولیتهای اصلی طراحی و توسعه را به دست توسعهدهندگان واقعی میسپاریم.
- توسعه دهندگان مسئول بهره وری خود هستند. برای مثال، من میتوانم ویژگیای را طراحی و توسعه دهم که کاملاً ایزوله است و هیچ وابستگی به سایر بخشهای زیرساخت من ندارد.
- برنامهها به گونهای طراحی شدهاند که بر اساس مزایای زیرساختهای ابری ساخته شوند، بهجای اینکه صرفاً بهصورت اولیه توسعه یابند و سپس به ابر ارسال شوند.
از اینجا به کجا می رویم
متأسفانه، تعداد کمی از ابزارهای امروزی استفاده از استراتژیهایی مانند معماری ۱۲ عاملی یا مونورپو را آسان میکنند و عرصه توسعه نرمافزار هنوز جایی که باید باشد برای دیدن شیوههای توسعه خلاقانه و بومی ابری نرسیده است. آنها باید.
امروزه، فقط پیچیدهترین سازمانهای فنآوری افراد و بودجههایی برای اختصاص دادن به این مشکل دارند. در شرکتهایی مانند Priceline، با تعداد زیادی از مهندسان ماهر، میتوانیم تیمهای DevX یا پلتفرمها را برای انجام این نوع حل مسئله در مقیاس بزرگ بچرخانیم، اما حتی این با هزینه فرصت، یعنی توسعه ویژگیهای جدید برای مشتریان همراه است. اکثر شرکتها – و مطمئناً استارتآپها، کسبوکارهای کوچک و شرکتهای قدیمی که دستخوش تحول دیجیتالی هستند – اصلاً این تجمل را ندارند.
در آینده شاهد ابزارهای نسل بعدی CI/CD خواهیم بود که به همه شرکتها امکان میدهد از این قابلیتها به نحوی استفاده کنند که نیازی به استخدام تیمهایی از افراد نداشته باشند. در پرایس لاین، ما از قبل کار با استارت آپ های نوآور در این فضا را آغاز کرده ایم. استارتآپهایی مانند Slim.AI و دیگران در حال جابجایی از مرزهای Cloud-Native هستند و احتمالاً روش ما را تغییر خواهند داد. توسعه نرم افزار مدرن در مقیاس مشارکت با این شرکتهای جدید برای هر شرکت فناوری سازمانی برای تقویت نوآوری حیاتی است.
طبق نظرسنجی CNCF 2021 که در بالا ذکر شد، «پیچیدگی» به «تغییرات فرهنگی با تیم توسعه» به عنوان چالشهای اصلی در استفاده و استقرار کانتینرها پیوسته است. در پرایس لاین، ما نه تنها پشته فناوری، بلکه ذهنیت فناوری خود را مدرنسازی کردهایم. با این حال، منحنی به حرکت به سمت بیرون ادامه میدهد و کار هرگز انجام نمیشود. تمرکز ما بر بهرهوری توسعهدهنده همچنان نقش اصلی را در بهبود تجربه مشتری و ایجاد نتایج بهتر برای کسبوکارمان ایفا میکند.
مارتی برادبک مدیر ارشد فناوری در پرایس لاین است. او قبلاً در شاتراستاک، پیرسون، دیاژو و فایزر سمتهای رهبری فناوری برتر را بر عهده داشته است و در حال حاضر به چندین استارتآپ در صنعت فناوری ابری مشاوره میدهد.
—
New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.
پست های مرتبط
ساخت و اجرای میکروسرویس ها در مقیاس: دیدگاه CTO
ساخت و اجرای میکروسرویس ها در مقیاس: دیدگاه CTO
ساخت و اجرای میکروسرویس ها در مقیاس: دیدگاه CTO