۳ اشتباه در نوسازی برنامه که باید از آنها اجتناب کرد

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

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

در اینجا سه ​​اشتباه اصلی من در نوسازی برنامه‌ها از نظر برنامه‌هایی که به ابر مهاجرت می‌کنند یا یک بار در آنجا مدرن‌سازی می‌شوند، آمده است:

به اندازه کافی انجام نمی شود. اکثر برنامه ها تنها با بلند کردن و جابجایی به ابر منتقل می شوند. شرکت‌ها یک آنالوگ برای پلتفرم قدیمی موجود خود «همانطور که هست» در یک ابر عمومی پیدا می‌کنند و کد و داده‌ها را به آنجا منتقل می‌کنند. آسان peasy.

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

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

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

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

بسیاری پنج برابر بیشتر از نیاز خود برای نوسازی برنامه هزینه می کنند. باید بین انجام زیاد و کم کاری تعادلی پیدا کنید.

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

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

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

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

من گمان می‌کنم که در حال حاضر حدود ۵۰ درصد بیشتر از آنچه در حال حاضر نیاز داریم برای نوسازی برنامه‌ها هزینه می‌کنیم. وقت آن است که کمی هوشمندانه کار کنیم. به من اعتماد کنید.