۷ روپیه نوسازی اپلیکیشن ابری

چگونه می‌دانید که چه زمانی یک برنامه را به سادگی جابه‌جا کنید و چه زمانی باید از ابتدا آن را بازسازی کنید؟ در اینجا نکاتی در مورد ارزیابی جنبه فنی و مورد تجاری آورده شده است.

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

برای مثال، یک برنامه گردش کار که توسط ده‌ها کاربر که در آخرین نسخه‌های جاوا و MySQL نوشته شده‌اند، استفاده می‌شود، ممکن است به راحتی به یک ابر عمومی منتقل شود. این رویکرد به بازنویسی کد کمی نیاز دارد، اما احتمالاً به تغییرات پیکربندی، به‌روزرسانی CI/CD و اجرای مجدد اتوماسیون‌های آزمایشی نیاز دارد. از سوی دیگر، اگر همان برنامه در Cobol نوشته شده باشد و بر روی یک پردازنده مرکزی اجرا شود، به احتمال زیاد قبل از اجرا در فضای ابری نیاز به تعمیرات اساسی دارد.

هنوز چندین گزینه فنی بین بالابر و تعویض و تعمیرات اساسی وجود دارد. اینها به عنوان ۷ Rs نوسازی اپلیکیشن ابری شناخته می شوند. تفاوت های جزئی از یک منبع به منبع دیگر وجود دارد، اما آنها گزینه های مدرن سازی سطح بالا را به خوبی نشان می دهند.

عواملی که باید در نظر گرفته شوند

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

اولین مسائلی که باید در نظر گرفته شود، تأثیرات آن بر عملیات تجاری و کاربران است. برنامه های ماموریت حیاتی و پرکاربرد به رویکردهای فنی متفاوتی نسبت به برنامه هایی که به صورت اپیزودیک استفاده می شوند نیاز دارند. هر نوسازی نیازمند ارتباط با کاربران، آزمایش و آموزش افراد در مورد تغییرات گردش کار است.

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

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

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

برنامه هایی را که دیگر ارزشمند نیستند بازنشسته کنید

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

گاهی اوقات تصمیم برای بازنشستگی یک برنامه واضح است: کاربران تجاری با بستن آن برنامه را امضا کرده اند یا بازنشستگی برنامه تأثیری بر عملیات تجاری ندارد. اما حتی زمانی که برنامه‌ها کاربرد کمی دارند یا عملکرد تجاری را انجام می‌دهند، ارزش تجاری آن‌ها باید در مقابل نوسازی و هزینه‌های پشتیبانی مداوم سنجیده شود.

آمیت پاتل، معاون ارشد در Consulting Solutions، می‌گوید: «برای بهبود تجربه کاربر، شرکت‌ها باید استراتژی بازنشستگی را در نظر بگیرند. خروج از برنامه‌های قدیمی قدیمی، کارایی بهتری ایجاد می‌کند که منجر به تجربه کاربری بهتری برای مشتریان شما می‌شود. کاهش سطح حمله همچنین منجر به امنیت قوی‌تر می‌شود.”

برنامه‌ها را با گزینه‌های SaaS، تجاری یا منبع باز جایگزین کنید      

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

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

برنامه را به فضای ابری منتقل کنید

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

اما باب کویلین، مدیر ارشد اکوسیستم در vFunction می‌گوید: «مهاجرت مساوی با مدرن‌سازی نیست». او توضیح می‌دهد، «مزایای توسعه‌ای وجود دارد که می‌توان با روش مهاجرت با افزایش و جابجایی به‌دست آورد. تقریباً همه شرکت‌ها به برخی دستاوردهای کوتاه‌مدت دست می‌یابند، اما اشتباهی که بسیاری از رهبران فناوری مرتکب می‌شوند این است که معتقدند کار در همین جا متوقف می‌شود.»

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

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

مؤلفه هایی که مزایای عملیاتی دارند را مجدداً ایجاد کنید

بسیاری «lift and shift» را به‌عنوان یک گزینه انتقال تفسیر می‌کنند که به حداقل مشارکت تیم توسعه نیاز دارد و نیازی به ارتقاء کد یا تغییرات عمده در پیکربندی ندارد. امید این است که بدون کار اضافی و هزینه های مهندسی مجدد کد، از مزایای مهاجرت بهره مند شوید.

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

تومر شیران، یکی از بنیانگذاران و مدیر ارشد محصولات Dremio، یک مثال را به اشتراک می گذارد. “به جای انتقال و انتقال یک انبار داده قدیمی یا دریاچه داده به فضای ابری، مهاجرت ابر فرصت هایی را برای اتخاذ معماری های خانه دریاچه باز و رویکردهای شبکه داده برای مدیریت داده ها ارائه می دهد.”

معماران ابر ممکن است انبارهای داده و دریاچه های داده را مدرنیزه کنند تا آنها را به عنوان خدمات ابری عمومی با مزایای عملیاتی و هزینه ای به کار گیرند. سایر گزینه‌های Replatform عبارتند از انتقال اتوبوس‌های خدمات، انتقال به ابزار استاندارد CI/CD سازمان، یا تغییر شبکه‌های تحویل محتوا.

استفاده مجدد، بازسازی، یا بازسازی برنامه‌هایی که تاثیرات بلندمدت کسب و کار ارائه می‌دهند

وقتی معماران و تیم‌های توسعه‌دهنده تصمیم می‌گیرند کد را به‌عنوان بخشی از مدرن‌سازی برنامه ارتقا دهند، چندین گزینه در اختیار دارند:

• از مدل‌های داده، سرویس‌ها و APIهای موجود برنامه استفاده مجدد کنید اما تجربه کاربر را دوباره طراحی کنید.
• کد Refactor برای بهبود عملکرد، امنیت، قابلیت نگهداری و سایر ارتقاءهای غیر کاربردی.
• بازسازی ماژول‌ها و قابلیت‌ها برای بهبود عملکرد، رفع نقص‌ها یا کاهش بدهی‌های فنی. برخی از برنامه های کاربردی یکپارچه را به میکروسرویس ها تغییر می دهند.

کدام رویکرد برای برنامه شما بهترین است؟ پاتل دیدگاه خود را به اشتراک می‌گذارد: «استراتژی Refactor و Rearchitect، اگرچه گران‌ترین رویکرد است، اما زمانی که شرکت‌ها می‌خواهند به سمت یک مدل توسعه چابک‌تر حرکت کنند، باید در نظر گرفته شود. این استراتژی همچنین به نوآوری مستمر کمک می کند و در نهایت به افزایش عملکرد کمک می کند.”

تیم‌های Devops می‌توانند رویکردهای مرحله‌ای را نیز در نظر بگیرند. برای مثال، ممکن است ابتدا برنامه‌هایی را که روی پلتفرم‌های قابل پشتیبانی اجرا می‌شوند، مجددا میزبانی کنند تا از مزایای عملیاتی اجرای آن‌ها در فضای ابری خصوصی یا عمومی بهره ببرند. سپس می‌توانند استفاده مجدد از برنامه‌های کم مصرف که مرتباً ارتقاء نمی‌یابند را در نظر بگیرند و برنامه‌های دیگر را در جایی که نیاز تجاری به بهبودهای مکرر وجود دارد، بازسازی کنند.

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