شاید مهاجرت ابری به بیش از شش روپیه نیاز داشته باشد

شش Rs بخش مشترک برنامه های مهاجرت ابری هستند. با این حال، شاید زمان آن رسیده است که به آنچه که هر حجم کاری به طور خاص نیاز دارد، توجه بیشتری داشته باشید.

شش روپیه مهاجرت ابری (بازنشستگی، حفظ، جایگزینی، میزبانی مجدد، پلتفرم مجدد، و بازساز) برای سال‌های متمادی جزء اصلی بوده‌اند. من مطمئن نیستم که آنها از کجا آمده اند، اما شما آنها را به یک شکل در بسیاری از اسلایدهای پروژه مهاجرت ابری فهرست خواهید کرد.

دلیل شش Rs ساده است. ما حجم کاری داریم که معمولاً برنامه‌ها و داده‌های جفت شده هستند که روی ابر اجرا نمی‌شوند، و به دنبال این هستیم که آنها را در دسته‌هایی قرار دهیم که در آینده با آنها چه کاری انجام می‌شود، چه در فضای ابری یا نه. در اینجا توضیح کوتاه شش Rs آمده است:

• بازنشستگی: حجم کاری را به طور کامل حذف کنید یا به عمر آن پایان دهید.
• حفظ: آن را در جایی که هست نگه دارید.
• جایگزینی: سیستم‌های SaaS یا سایر آنالوگ‌های حجم کار را پیدا کنید.
• Rehost: آن را بردارید و جابجا کنید، یا فقط آن را با تغییرات اندک یا بدون تغییر به ابر منتقل کنید. به عنوان مثال، از Linux on premises به Linux در فضای ابری بروید. من این را متفاوت از بازسازی مجدد می بینم، زیرا ما فقط یک برنامه را تغییر می دهیم تا در یک پلت فرم ابری به خوبی اجرا شود و به طور خاص از خدمات بومی ابری استفاده نمی کنیم.
• پلتفرم مجدد: اگر نتوانیم آنالوگ های پلتفرم را در ابر هدف پیدا کنیم، به پلتفرم جدیدی مانند لینوکس به ویندوز می رویم. گاهی اوقات پایگاه داده های جدید و سایر سیستم عامل ها نیز تغییر می کنند. بنابراین، حجم کار باید برای سازگاری با پلتفرم جدید اصلاح شود، اما ما از خدمات بومی ابری استفاده نمی‌کنیم.
• Refactor: بارهای کاری را به شدت تغییر دهید (دوباره کدگذاری کنید) تا از ویژگی های بومی ابر مانند امنیت ابری، حاکمیت، نظارت، ممیزی و غیره استفاده کنید.

البته، فقط برای اشتباه گرفتن چیزها، من شش Rs را با عبارات مختلف (مانند «خرید مجدد» به جای «جایگزین») یا حتی تعاریف متفاوتی از Rs دیده‌ام. بنابراین، اگر چیزی که استفاده می‌کنید دقیقاً با موارد بالا مطابقت ندارد، به من سرزنش نکنید. برای اهداف ما واقعاً مهم نیست.

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

مشکل من با شش Rs این است که آنها می توانند مسیرهایی را که معماران ابر می توانند طی کنند محدود کنند و در نهایت حجم کاری را به یک دسته بندی خاص وادار کنند که واقعاً تعریف نمی کند که برای انتقال به ابر چه کاری باید انجام شود. ممکن است تصمیم بگیریم یک برنامه را مجددا میزبانی کنیم، اما اگر هزینه آن ۱۰۰ هزار دلار باشد، در حالی که اکثر روش‌های دیگر به ازای هر بار کاری یک هزار دلار هزینه دارند. چه چیزی متفاوت است؟

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

• میزبانی مجدد بدون تغییر کد
• میزبانی مجدد با برخی تغییرات کد
• میزبانی مجدد با بسیاری از تغییرات کد (اما نه استفاده از خدمات بومی ابری به طوری که بازسازی نمی شود، یا به یک پلتفرم یا سیستم عامل جدید منتقل نمی شود، بنابراین دوباره پلتفرم نمی شود)

این مسیر دقیق تری را ارائه می دهد. من می‌دانم که بسیاری از تیم‌هایی که برنامه‌های کاربردی مهاجرت می‌کنند این کار را انجام می‌دهند. من معمولاً معیارهایی مانند تعداد خطوط کدی که نیاز به تغییر دارند و/یا چرخه‌های آزمایشی ارائه می‌کنم. شکستن این موارد درک سطح تلاش و در نتیجه هزینه و زمان را آسان تر می کند.

می توانید همین کار را با re-platform و refactor انجام دهید. من آن‌ها را به چند دسته‌بندی خاص تقسیم می‌کنم که بهتر روشن می‌کند چه کاری باید برای آن حجم‌های کاری انجام شود تا مسیر مهاجرت درست را هدف‌گیری کنیم. همچنین، هزینه ها و خطرات را با دقت بیشتری برآورد می کند.

این در حال حاضر در موارد موقت و غیررسمی در حال انجام است. من برخی از پروژه‌ها را به ۲۰ روپیه مختلف تقسیم کرده‌ام، و همیشه این قانون را اجرا نمی‌کنم که دسته باید با R شروع شود. دیگران نیز همین کار را انجام می‌دهند، شاید حتی شما.

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