یکی از بهترین روش‌های بهبود فرایندهای توسعه نرم‌افزار و افزایش سرعت تحویل و ارائه محصول، استفاده از پلتفرم‌های دواپس یا دیجیتال است. پلتفرم‌ها در دواپس از اهمیت زیادی برخوردارند و کمک شایانی به تیم‌ها می‌کنند. اما پلتفرم دقیقا چیست و چه کار می‌کند؟ یک پلتفرم خوب چه ویژگی‌هایی دارد و برای ساخت آن چه پیش‌نیازهایی وجود دارد؟ در این مقاله قصد داریم درباره پلتفرم‌های دیجیتال و تاثیر آن‌ها در فرایند توسعه نرم‌افزار، ویژگی‌هایی که پلتفرم باید داشته باشد و چگونگی راه‌اندازی و استفاده از پلتفرم صحبت کنیم. با ما همراه باشید.
پلتفرم چیست؟
معمولا پیدا کردن کلمه مناسب برای تعریف مفاهیم مختلف سخت است و در اینجا هم، «پلتفرم» کلمه‌ای مبهم برای توصیف رویکردی بسیار مهم در افزایش سرعت انتشار و کارایی نرم‌افزار است. اما همانطور که عنوان مقاله مطرح می‌کند، قصد داریم این تعریف را شفاف کنیم و بگوییم که پلتفرم دقیقا چیست و از چه حرف می‌زنیم.
تعاریفی که برای پلتفرم‌های سخت‌افزاری و نرم‌افزاری وجود دارند عموما مشابه هستند؛ این تعاریف معمولا یک محیط توسعه را توصیف می‌کنند که می‌توانید در آن‌ها اپلیکیشن توسعه دهید و منابع و ابزارهای دواپس را برای راحتی بیشتر کار در اختیارتان قرار می‌دهند. اگر با دید وسیع‌تر و در سطح سازمان به موضوع «پلتفرم‌های دیجیتال» نگاه کنیم، باز هم تعریفی مشابه می‌بینیم؛ یعنی محیطی عملیاتی که تیم‌ها می‌توانند در آن نرم‌افزاری با ویژگی‌های مختلف را توسعه دهند و با کمک منابع قابل استفاده مجدد، توسعه‌های بعدی را سریع‌تر به کاربر ارائه دهند.
پلتفرم دیجیتال چیست؟
پلتفرم دیجیتال، پایه و زیربنای APIهای سلف‌سرویس، ابزارها، خدمات، دانش و پشتیبانی است که به عنوان یک محصول داخلی کامل و جامع در کنار هم قرار گرفته‌اند. تیم‌های انتشار مستقل، می‌توانند با استفاده از پلتفرم فیچرهای جدید محصول را با سرعت بیشتر و نیاز به هماهنگی کمتر منتشر کنند.
تجربه‌های جهانی نشان داده است که اگر بخواهید تبدیل به یک شرکت دیجیتال شوید، باید روی مهم‌ترین توانمندی‌های مشترک در پلتفرم‌ها سرمایه‌گذاری کنید. این توانمندی‌های عبارتند از:
- زیرساخت تحویل و انتشار
- APIها و اصلاح معماری
- داده سلف‌سرویس
- زیرساخت تجربی
- تکنولوژی‌های نقطه تماس با مشتری (customer touchpoint)
در این مقاله ما قصد داریم با تمرکز بیشتر روی زیرساخت تحویل، که شامل میزبانی ابری و کاربردهای پلتفرم در دواپس می‌شود، پیش برویم.
بررسی یک سیستم غیرپلتفرمی
ابتدا با بررسی یک شرکت بزرگ خدمات مالی استرالیایی، که در اینجا به آن بیگ‌کو (BigCo) می‌گوییم، شروع می‌کنیم. اولین هدفی که در بدو شروع کار باید دنبال کنیم، بررسی و شناخت ساز‌وکار زیرساخت اپلیکیشن، فضای میزبانی و فضاهای عملیاتی است. برای درک بهتر چالش‌ها در زیرساخت، باید ابتدا یک تغییر واقعی در سیستم ایجاد و تاثیر آن روی فرایندها را بررسی می‌کردیم.
با وجود اینکه شرکت مورد نظر سرمایه‌گذاری کلانی روی فضای ابری و اتوماسیون انجام داده بود، اما همچنان از ساختار سنتی برای تیم‌های زیرساخت و عملیات استفاده می‌کرد و تیم‌ها براساس توانایی‌های فنی تقسیم شده بودند. به همین خاطر هر کدام از تغییرات کوچک و ساده‌ای که ایجاد کردیم، تعدادی از تیم‌ها را درگیر کردند.
اثر پروانه‌ای یک تغییر کوچک
برای مثال تغییری که در پیکربندی سرور اپلیکیشن ایجاد کردیم، تیم «میان‌افزار» (middleware) را درگیر کرد؛ اما این تیم به پیکربندی سیستم عامل پایه دسترسی نداشت و باید این دسترسی را از تیم «مید رنج» (midrange) می‌گرفت. تغییرات در پایگاه داده هم باید توسط تیم DBA انجام می‌شدند. به همین ترتیب تغییرات شبکه توسط تیم شبکه، بالانس بار شبکه توسط سرویس‌دهنده و تغییرات در فایروال هم توسط تیم دیگری انجام می‌شدند.
حتی تیم اتوماسیون هم یک تیم جدا بود که توانایی‌ها و دسترسی‌های آن بیشتر به ارکستراسیون محدود میشد. تعجبی ندارد اگر بگوییم که تیم‌های مانیتورینگ، امنیت، مدیریت انتشار و به‌روزرسانی هم هر کدام جداگانه فعالیت می‌کردند.
هر کدام از این تیم‌ها در BigCo ساختار مدیریتی و فرایندهای کاری مجزای خود را داشتند. هر تیم به تنهایی در تلاش برای رسیدن به بالاترین سطح بهره‌وری در بخش‌های فنی، تمرکز تخصص‌ها، برون‌سپاری فرایندهای تکراری، پیاده‌سازی چارچوب و کاهش هزینه‌ها بود. اما هیچ‌کس در این شرکت تاثیر و کارایی ویژگی‌هایی که به کاربر نهایی ارائه می‌شدند را اندازه‌گیری نمی‌کرد.
صرف زمان زیاد برای هر تغییر
تغییراتی که زیرساخت را درگیر می‌کردند، بین چند هفته تا چند ماه زمان می‌بردند و روی خروجی سیستم و تجربه کاربران هم تاثیر منفی می‌گذاشتند. هرچه این تغییرات سخت‌تر و کندتر بودند، خطاهای فرایند تغییر بیشتر می‌شدند و همین موضوع باعث طولانی‌تر شدن این فرایند میشد.
این اتفاقات و تاخیرهای فراوان ناشی از تغییر، باعث شده بودند تا مهندسان و مدیران به دنبال حداقل کردن تعداد تغییرها باشند و تنها تغییرات اساسی و حیاتی را در زیرساخت و اپلیکیشن ایجاد کنند.
مجموعه عوامل بالا در BigCo باعث شده بودند تا به مرور، کیفیت اپلیکیشن و زیرساخت به طور واضح کاهش پیدا کند و در سطح پیکربندی و محیط عملیاتی هم عدم یکپارچگی ایجاد شود. در نتیجه مشکلاتی که تغییر به وجود می‌آورد، تیم‌ها از بهبودهای جزئی و بازسازی‌هایی که به حفظ و بهبود کیفیت و یکپارچگی کمک می‌کردند، دست کشیده بودند.
این فرایند یک چرخه خودتقویت‌گر و تکرارشونده است؛ از آن‌جایی که بهبود کیفیت روی قابلیت پیش‌بینی تاثیر می‌گذارد و ریسک تغییر را افزایش می‌دهد، تیم‌ها در برابر ایجاد تغییر و بهبود در سیستم مقاوم و محتاط عمل می‌کنند.
در یک کلام: مدیریت زیرساخت و میزبانی در BigCo فرایندی سخت و آهسته بود.
تاثیر وابستگی بک‌لاگ‌ها (Backlog Coupling)
ساده‌ترین راه برای تحویل و توسعه نرم‌افزار چابک، استفاده از کانال‌های دیجیتال با تیم‌های کوچک مستقل است که ارتباط نزدیکی با مدیران کسب و کار دارند و نیازهای کاربران را شناسایی می‌کنند و برای این نیازها راه‌حل ارائه می‌دهند. اما هرچه تیم توسعه‌دهنده یک محصول دیجیتال سریع‌تر، چابک‌تر و منعطف‌تر شود، محدودیت‌های خارجی که با آن روبرو می‌شود بیشتر می‌شود.
تیم‌های دیجیتال به طور معمول در سه حوزه با محدودیت روبرو می‌شوند: کندی سیستم‌های معاملاتی و تراکنشی اصلی، دسترسی به داده و تحلیل‌های با کیفیت، و زیرساخت و محیط عملیاتی مشترک.
برای درک بهتر این محدودیت‌ها از عبارت بک‌لاگ کوپلینگ یا وابستگی بک‌لاگ استفاده می‌کنیم. بک لاگ در اینجا به یکی از ابزارهای مهم برنامه‌ریزی چابک اشاره دارد که در آن، تمامی کارهایی که باید در یک فرایند انجام شوند مشخص می‌شوند و سپس زمان و نحوه انجام آن‌ها مشخص می‌شود.
بک‌لاگ کوپلینگ چیست؟
این مفهوم یک تعریف ساده دارد؛ اگر تعدادی از وظایف موجود در بک‌لاگ یک تیم نیازمندی متناظری در بک‌لاگ یک تیم دیگر داشته باشند، به دلیل این وابستگی بهره‌وری و انعطاف یک سیستم و فرایند به طرز چشم‌گیری کاهش پیدا می‌کند.
در اثر وابستگی بک‌لاگ، در عین حال که تمام بک‌لاگ‌های سطح سازمان زنجیروار بهم متصل هستند، هر کدام با توجه به نیاز تیم خود الویت‌بندی می‌شوند. در این حالت کارهای مختلف در وضعیت بلوکه (Blocker) قرار می‌گیرند، فرایندها پیش نمی‌روند، ذی‌نفعان عصبانی می‌شوند و سرویس‌دهندگان مشترک بین تیم‌های مختلف، به تندترین حالت ممکن واکنش نشان می‌دهند.
وابستگی بک‌لاگ تا چه حد آسیب‌زا است؟
طی تحقیقی که روی فرایندهای تحویل و انتشار یک شرکت ارتباطات استرالیایی انجام شد، تسک‌ها و وظایف این شرکت به دو گروه مستقل و وابسته تقسیم می‌شدند. وظایفی که می‌توانستند به طور مستقل و توسط یک تیم، بدون نیاز به حضور اعضای تیم‌های دیگر انجام شوند، بین ۱۰ تا ۱۲ بار سریع‌تر از کارهایی انجام می‌شدند که به تایید یا حضور تیم‌های دیگر نیاز داشتند. پس می‌توانیم بگوییم که این وابستگی‌ها نقش بسیار پررنگی در سرعت فرایندها دارند.
این وابستگی از چندین جنبه به شرکت آسیب می‌رساند:
- توان عملیاتی و بهره‌وری را کاهش می‌دهد.
- پاسخگویی به نیاز مشتری را مختل می‌کند.
- تیم‌ها را مجبور به برنامه‌ریزی بلندمدت برای مدیریت بهینه وابستگی‌ها می‌کند.
- مسئولیت‌پذیری تیم در مقابل خروجی را کاهش می‌دهد.
از این تعریف به عنوان قاتل انگیزه تیم‌ها هم یاد می‌شود، چرا که تیم‌ها به راحتی مسئولیت و تقصیر را گردن یکدیگر می‌اندازند و دیگر به بهبود پیوسته خود اهمیتی نمی‌دهند. علاوه بر این کار کردن در تیمی که بار کاری زیادی دارد و مجبور است بدون هیچ نظمی به تیم‌های داخلی سرویس بدهد، چندان جالب نخواهد بود.
راه‌حل چیست؟
یکی از رسوم جدید در شرکت‌ها برای حل مشکل وابستگی بک‌لاگ‌ها، استفاده از «چابکی مقیاس‌پذیر» است. برای این کار معمولا جلسات برنامه‌ریزی در مقیاس بزرگ برگزار می‌شوند تا اولویت‌ها در تیم‌های مختلف مشخص شوند. هرچند این جلسات به وضوح هماهنگی را افزایش می‌دهند، اما استقلال، انعطاف و پاسخگویی تیم‌ها به تغییر را کاهش می‌دهند. به همین خاطر باید به دنبال یک راه‌حل بهتر باشیم.
با توجه به این موضوع، یک پلتفرم خوب باید وابستگی بک‌لاگ را با کم‌ترین عوارض جانبی کاهش دهد. یک پلتفرم مناسب باید بدون نیاز به ثبت درخواست و ایجاد بار کاری اضافه، مشکلات توسعه را حل کند؛ با این حساب سلف‌سرویس بودن باید یکی از ویژگی‌های اصلی این پلتفرم باشد.
یک پلتفرم باید به اعضای تیم امکان ارائه خدمات سلف‌سرویس، پیکربندی سلف‌سرویس و مدیریت سلف‌سرویس بخش‌های مختلف پلتفرم و سیستم را بدهد.
پیاده سازی اولیه پلتفرم؛ ابر اختصاصی نیم-بند سطحی
بعد از طی مراحل بالا، BigCo نیاز به یک پلتفرم سلف‌سرویس را درک کرد. اما تصور پیاده‌سازی پلتفرم با داشتن زیرساخت و محیط عملیاتی وسیعی که با تفکرات سنتی اداره می‌شود، برای این شرکت سخت و پیچیده بود. بیگ‌کو قبل از این روی ابزارهای اتوماسیون مرکزی سرمایه‌گذاری کرده بود و حالا، باید یک پلتفرم سلف‌سرویس برای تیم‌های توسعه نرم‌افزار می‌ساخت تا زیرساخت خود را روی آن ارائه دهند.
برای این کار، یک ابزار سلف‌سرویس ساختیم تا تیم‌های توسعه بتوانند طبق یک قالب مشخص، درخواست پردازش نمونه‌ها را روی آن ثبت کنند. نمونه‌های ماشین مجازی ارائه شده برای پلتفرم هم در پیکربندی ثبت و قفل کردیم تا مطمئن شویم که مدیریت پیکربندی با تیم میدرنج مرکزی باقی می‌ماند.
برای استفاده از نمونه‌ها – برای مثال نصب پکیج روی آن‌ها، اتصال آن‌ها به شبکه یا حافظه، ارائه لود بالانسر، پیکربندی ابزارهای مانیتورینگ و … – تیم توسعه باید یک درخواست ثبت می‌کرد و این درخواست‌ها باید پاسخ داده می‌شدند. به همین خاطر، با وجود پیاده‌سازی این API سلف‌سرویس اولیه، تغییر چندانی در سرعت تحویل نرم‌افزار ایجاد نشد.
ممکن است بگویید که این اتفاق در اولین تکرارها طبیعی است و حق دارید – اما نتیجه نهایی در همین مرحله مشخص شد. تیم زیرساخت و عملیات BigCo در آن زمان برای شکستن سیلوهای سازمانی خود و انتقال مسئولیت و دسترسی به تیم توسعه آماده نبودند. هر اندازه هم که هدف نهایی مثبت و مفید باشد، این میزان تلاش برای ساخت تدریجی یک API خوب، نشدنی بود.
ابر خصوصی سطحی چیست؟
به رویکردی که در آن پلتفرم‌های مجازی‌سازی موجود را به صورت محدود و بدون تغییر در نحوه مدیریت مرکزی، برای استفاده تیم توسعه تغییر شکل و نام می‌دهیم، «ابر خصوصی نیم-بند سطحی» گفته می‌شود. این رویکرد شاید در ظاهر تغییراتی را در سیستم و فرایندها ایجاد کند، اما در باطن تفاوتی در عملکرد سیستم ایجاد نمی‌کند.
همزمان با تغییراتی که در فرایندها ایجاد می‌کردیم، یکی از تیم‌های توسعه و تحویل در BigCo شروع به استفاده از آمازون وب سرویس (AWS) برای سیستم‌های توسعه کردند. به محض اینکه تسهیل فرایندهای این تیم تایید شد، تمام تیم‌های توسعه و تحویل برای استفاده از AWS پیش‌قدم شدند.
AWS یک پلتفرم جامع و مناسب برای تیم‌های تحویل است که کاملا سلف‌سرویس است و مرزهای مشخصی برای مسئولیت‌ها تعریف می‌کند. در این پلتفرم رویکرد «خودتان می‌سازید، خودتان اجرا کنید» تبدیل به یک اصل می‌شود؛ به شکلی که آمازون پلتفرم را تا API می‌سازد، اجرا می‌کند و از صحت عملکرد و در دسترس بودن آن مطمئن می‌شود. سپس تیم تحویل نرم‌افزار شرکت شما اپلیکیشن‌ها را روی این پلتفرم می‌سازد، پیکربندی می‌کند و سپس اجرا می‌کند.
اما آیا داستان پیاده‌سازی پلتفرم مناسب اینجا تمام می‌شود؟
استقلال تیم‌های محصول، سرعت عرضه به بازار و نوآوری را افزایش می‌دهند
بسیاری از شرکت‌ها به طور پیش‌فرض از تفکر و رویکرد «ساخت برای استفاده مجدد» پیروی می‌کنند؛ رویکردی که روی تمرکز توانایی‌ها و قابلیت‌ها با ترکیبی از ریسک‌گریزی و کاهش هزینه تمرکز دارد. معمولا در این روش فناوری‌ها و چگونگی استفاده از آن‌ها از قبل تعیین می‌شوند و تیم‌ها باید از این چارچوب‌های از پیش تعیین شده پیروی کنند.
برای درک بهتر بحث استقلال تیم‌ها، یک شرکت فناوری استرالیایی با نام فرضی WebBiz را بررسی می‌کنیم. این شرکت که به طور گسترده در فضای آنلاین فعالیت می‌کند تا حدودی به BigCo شباهت دارد، اما سنت‌ها و سیستم‌های قدیمی نقش پررنگی در آن ندارند و به اندازه‌ای کوچک است که بتواند به طور مرتب تغییر و بهبود پیدا کند.
در WebBiz یک هدف چند ساله را برای مهاجرت از پلتفرم‌های مجازی‌سازی در دیتاسنتر‌های اجاره‌ای، به انتشار اپلیکیشن‌ها روی AWS تعیین کردیم. علاوه بر این مسئولیت بیلد و اجرای اپلیکیشن‌ها و بخش بزرگی از زیرساخت را به تیم‌های محصول سپردیم و عملیات مرکزی سنتی را به طور کامل به دواپس (DevOps) تبدیل کردیم.
شاید ساختن یک کسب و کار جدید بر پایه ذهنیت «خودتان می‌سازید، خودتان اجرا کنید» چندان سخت نباشد، اما تغییر یک ساختار قدیمی به ساختار جدید و پیاده‌سازی این ذهنیت در تمام سازمان، جرئت و انرژی زیادی می‌خواهد که وب‌بیز، به خوبی توانست از پس این تغییر بربیاید.
به عنوان بخشی از فرایند مهاجرت از سیستم قدیمی به سیستم جدید، به تیم‌های محصول در WebBiz استقلال کامل داده شد تا اجرای فرایندهای خود را در دست بگیرند و مدیریت کنند. این روش را با عنوان «مدیریت زیرساخت توسط تیم محصول» ایجاد کردیم؛ هرچند نکاتی به صورت پیش‌فرض وجود داشتند که همه تیم‌ها باید رعایت می‌کردند، اما در نهایت این تیم‌ها بودند که تغییرات و تصمیمات لازم برای بخش‌های مختلف زیرساخت خود را می‌گرفتند و کنترل مرکزی برای این کار وجود نداشت.
شرکت وب‌بیز با این تغییر، توانست سوگیری‌های پیش‌فرض درباره سازمان‌ها را تغییر دهد؛ یعنی تنوع در تکنولوژی‌های سازمان را افزایش داد و همچنین فناوری‌های جدید اختراع کرد. این تغییرات نتایجی را به همراه داشتند:
- مشارکت کارکنان افزایش یافت.
- دانش مهندسان در بخش‌های مختلف فناوری عمیق‌تر شد.
- نوآوری افزایش یافت.
- مسئولیت تیم‌ها در قبال محصولی که منتشر میشد، بیشتر شد.
- و در نهایت حجم انبوهی از وابستگی‌های بین تیمی از بین رفت.
علاوه بر این، مهندسانی که تمایل داشتند مسئولیت آنچه ساخته‌اند را بپذیرند، مستقل و در عین حال هماهنگ عمل کنند و مشکلات پیچیده فنی و کسب و کاری را حل کنند، اشتیاق بیشتری برای پیوستن به این شرکت داشتند و جذب نیرو هم با این تغییرات، افزایش پیدا کرد.
تنوع بالا در تکنولوژی‌های استفاده شده، فاصله بین تیم‌ها را زیاد می‌کند
با وجود همه مزایایی که استقلال کامل تیم‌ها به دنبال دارد، هزینه‌هایی هم در سازمان ایجاد می‌کند. با پیاده‌سازی AWS به عنوان پلتفرم اصلی، WebBiz وابستگی بک‌لاگ را از تیم زیرساخت مرکزی حذف کرد. اما حالا تمام تیم‌ها مجبور بودند تا برای ساخت و عملیاتی کردن بخش‌های مختلف زیرساخت خود، مجموعه‌ای از تصمیم‌های مختلف را سازماندهی کنند.
در تصویر بالا می‌توانید مجموعه‌ای از برنامه‌های لازم برای ساخت یک زیرساخت و معماری ابری را ببینید که بر اساس کاربردی که دارند توسط Cloud Native دسته‌بندی شده‌اند. این نقشه شلوغ تنها شامل تعدادی از بهترین راهکارهای ابری موجود در بازار است و هر تیم، برای پیاده‌سازی زیرساخت مناسب برای هر بخش، باید بهترین راهکار را متناسب با نیازهایش از لیست بالا انتخاب کند و سپس به دنبال پیاده‌سازی و عملیاتی کردن آن باشد.
علاوه بر مشکلاتی که در نگهداری از زیرساخت‌های مشابه به وجود می‌آید، تیم‌ها باید به صورت مستمر انتخاب‌هایی را که برای زیرساخت داشتند ارزیابی کنند و این امر، باعث ایجاد بار کاری اضافه می‌شود. همچنین، تبادل دانش و حتی نیروی ماهر بین تیم‌هایی که هر کدام زیرساخت مستقل خود را دارند، تقریبا غیرممکن می‌شود.
با احتساب این مشکلات، وب‌بیز تصمیم گرفت تا یک پلتفرم شفاف‌تر و مشخص‌تر برای تحویل زیرساخت خود ایجاد کند؛ پلتفرمی که موارد محدود و قابل قبولی را در اختیار تیم‌ها قرار می‌دهد تا فاصله بین تیم‌ها کنترل شود و بهره‌وری هم افزایش پیدا کند.
با این وجود، آیا این شرکت حاضر است مزایایی که استقلال تیم‌ها در بر دارد را از دست بدهد؟
به پلتفرم به دید یک محصول داخلی نگاه کنید
پیدا کردن نقطه تعادلی بین «استقلال در تنوع بخشیدن به تکنولوژی‌ها» و «اجبار به استفاده متمرکز از تکنولوژی‌ها» کار بسیار سختی است، اما اینکه بدانیم کی به نقطه تعادل می‌رسیم سخت‌تر است. یک نکته کلیدی در رسیدن به این تعادل، این است که پلتفرم کاملی را در نظر بگیریم که تنها بر اساس یک دستور مشخص عمل نمی‌کند.
زیرساخت‌های مشترک معمولا انحصاری و با توجه به یک تیم ساخته می‌شوند و سایر تیم‌های تحویل جایگزین مناسبی برای آن‌ها ندارند. به همین خاطر، وجود کمی رقابت بین تیم‌ها باعث می‌شود تا تفکر محصولی بین آن‌ها افزایش پیدا کند و برای این کار، باید مطمئن شوید که پلتفرمی را انتخاب می‌کنید که بدون ایجاد محدودیت و وابستگی‌های اضافه، ارزش ایجاد می‌کند.
یک پلتفرم خوب چه ویژگی‌هایی دارد؟
بگذارید به ویژگی‌های یک پلتفرم خوب نگاه کنیم:
- در اکثر مواقع، امکان استفاده سلف‌سرویس از پلتفرم وجود دارد.
- سرویس‌های مختلف آن مجزا از هم عمل می‌کنند و در صورت نیاز، می‌توانند ترکیب شوند.
- انعطاف خوبی دارد و دست تیم‌های تحویل را برای ایجاد تغییرات باز می‌گذارد.
- یادگیری و استفاده از آن راحت است.
- جامعه کاربران داخلی آن وسیع است و به همین خاطر، انتقال تجربه راحت‌تر است.
- امنیت بالایی دارد.
- به روز است و در بازه‌های مختلف، به روزرسانی‌های جدید دریافت می‌کند.
یک پلتفرم زیرساخت تحویل زمانی کامل و قانع‌کننده است که استفاده از آن، ساده‌تر از ساخت و نگهداری یک زیرساخت شخصی باشد. برای مثال شرکت نتفلیکس ابزار مرکزی خود را به یک «جاده آسفالته» تشبیه می‌کند؛ به این معنی که تیم‌ها مجبور نیستند از ابزارهای پیش‌فرض استفاده کنند، ولی مسئول تمام هزینه‌های نگهداری جایگزین‌های خود هستند.
علاوه بر این یک پلتفرم بیشتر از صرفا یک نرم‌افزار یا API است؛ این ابزار باید شامل مستندات، مشاوره، پشتیبانی، قالب‌ها و راهنماهای مورد نیاز تیم‌های سازمان هم باشد.
یک دقیقه صبر کنید… آیا با یک «تیم دواپس» روبرو هستیم؟
ما کاملا در جنگ «دواپس یک نقش، ابزار یا تیم نیست» شکست خوردیم، اینطور نیست؟ ما همواره در این جنگ شکست می‌خوریم. شاید بهتر باشد به فکر یک استراتژی جدید باشیم. – فیل کالجادو
ممکن است که شما تصمیم بگیرید تا برای ساخت و اجرای پلتفرم زیرساخت تحویل خود، یک تیم تشکیل دهید؛ در بسیاری از مواقع، این روش بهترین انتخاب برای شروع یک ساختار جدید است.
هر چند هدف اصلی در پلتفرم این است که تیم‌ها مستقل عمل کنند، حق انتخاب داشته باشند و مدیریت مرکزی برای این فرایند وجود نداشته باشد، اما گاهی نیاز است مسیر را کمی متفاوت از هدف نهایی شروع کنیم. پس برای تشکیل تیم، باید به صورت کاملا شفاف محدوده وظایف تیم پلتفرم و مشتریانش را، که به آن‌ها تیم اپلیکیشن می‌گوییم، تعیین کنید.
تیم‌های اپلیکیشن، وظیفه ساخت، انتشار، مانیتورینگ و پشتیبانی از اجزا و زیرساخت اپلیکیشنی را دارند که روی پلتفرم منتشر می‌کنند. این در حالی است که تیم‌های پلتفرم، وظیفه ساخت، انتشار، مانیتور و پشتیبانی از اجزای پلتفرم و زیرساخت لازم برای اجرای آن را دارند.
در ایده‌آل‌ترین حالت، تیم پلتفرم حتی از اپلیکیشن‌هایی که روی پلتفرم اجرا می‌شوند خبر ندارند و تنها وظیفه ایجاد دسترسی روی سرویس‌های پلتفرم را دارند. در این حالت، هر دو تیم‌های پلتفرم و اپلیکیشن، وظیفه ساخت و اجرای محصولات خودشان را دارند و رویکرد «خودتان می‌سازید، خودتان اجرا کنید» در این فرایند جریان دارد.
برای داشتن یک پلتفرم خوب، از کجا شروع کنیم؟
برای اجرای موفق یک پلتفرم تحویل نرم‌افزار پیش‌نیازهایی وجود دارد.
در قدم اول، شما احتمالا باید «پروژه» را به عنوان مکانیزم اولیه تامین مالی و نیروی انسانی فرایند تحویل تکنولوژی، کنار بگذارید. پلتفرم یک محصول است و به یک تیم محصول پایدار نیاز دارد تا وظایف ساخت و اجرای آن را بر عهده بگیرد.
در قدم دوم، باید تمایل داشته باشید تا تمام یا بخشی از وظایف اجرای اپلیکیشن را به تیم‌های اپلیکیشن منتقل کنید و از ساختار عملیات و پشتیبانی مرکزی خارج شوید. پلتفرم تمام ابزارها و سرویس‌های لازم را برای تیم‌های اپلیکیشن فراهم می‌کند و آن‌ها می‌توانند مسئولیت آنچه ساخته‌اند را برعهده بگیرند؛ در حالی که در ساختار مرکزی چنین چیزی ممکن نیست.
در قدم سوم هم، باید تمایل داشته باشید تا ساختار یکپارچه و دقیق پیاده‌سازی مرکزی را، با خروجی ناشی از آزادی و مسئولیت‌هایی که به تیم‌های مستقل اپلیکیشن می‌دهید جایگزین کنید.
سخن پایانی؛ استفاده از پلتفرم‌های دواپس
در این مقاله سعی کردیم که با پلتفرم‌های دواپس و کاربردی که در فرایند تحویل و توسعه نرم‌افزار دارند آشنا شویم. در انتها می‌خواهیم به نکاتی اشاره کنیم که رعایت آن‌ها می‌تواند به شما در پیاده‌سازی موفق پلتفرم کمک کند:
- پلتفرم شما تنها زیرساخت، ابزار و API نیست. برای تاثیرگذاری بیشتر، باید چگونگی تعامل تیم‌ها با پلتفرم را مشخص کنید و نیازمندی‌هایی که دارند و بهبود‌هایی که لازم دارند را در نظر بگیرید.
- از آن‌جایی که از ابتدا تمام نیازمندی‌ها را نمی‌دانید، با یک پلتفرم کوچک و حداقل ویژگی‌ها شروع کنید و سپس مرحله به مرحله پلتفرم را گسترش دهید.
- حواستان باشد که صرفا به ابزار محدود و مرکزی که در حال حاضر دارید، لقب پلتفرم را ندهید و در عوض به دنبال ساخت یک پلتفرم واقعی باشید.
منبع:
نوشته ایوان بوچر و مارتین فاولر
دیدگاهتان را بنویسید