انتقال برنامه های کاربردی قدیمی به ابر برای استفاده از امنیت و داده های مدرن، کانتینرها، میکروسرویس ها و قابلیت حمل معمولاً اوضاع را بدتر می کند. در اینجا دلیل آن است.
از هر کسی بخواهید که نوسازی اپلیکیشن را تعریف کند، پاسخ های مختلفی خواهید شنید. در اینجا یک تعمیم از چیزی است که همه ما در مورد آن توافق داریم: نوسازی برنامهها، برنامههای کاربردی و مجموعه دادههای موجود را که کسبوکارها را اداره میکنند، میگیرد و آنها را برای کسانی که از آنها استفاده میکنند، بهویژه مشتریان، مفیدتر، سازندهتر و جذابتر میکند. توانایی ارتقاء تجربه مشتری، تجارت بیشتری را هدایت می کند.
برخی مدرنسازی اپلیکیشنها را بهعنوان «رژ لب گذاشتن روی خوک» میدانند، اما اصلاً هدف این نیست. مدرنسازی برنامهها نباید در مورد مدرن کردن برنامهها باشد. برنامه ها باید مدرن و باید به نظر برسند.
این به معنای تغییر رابط کاربر و ماشین و همچنین مدرنسازی معماری داخلی، زیرساخت پلتفرم ابر عمومی، ویژگیهای برنامه، و فعال کردن فناوری است. همچنین شامل حرکت از فرآیندهای توسعه سنتی آبشار به چابک و توسعه است.
آیا این ایده خوبی است که برنامههای قدیمی ارزشمند را برداریم، آنها را بهتر کنیم و به یک ابر عمومی منتقل کنیم؟ مطمئن. با این حال، بیشتر و بیشتر میبینم که توسعهدهندگان و معماران ابری با نوعی چک لیست بیپایان به مدرنسازی نزدیک میشوند که اغلب بیش از حد پیش میرود و کارهای زیادی انجام میدهد، بنابراین اهداف و اهداف ارزش تجاری پروژه را از دست میدهند.
اطلاعات زیادی در مورد نوسازی برنامهها، از جمله فرآیندها و متدولوژیها، وجود دارد که بسیاری از تیمها سعی میکنند با زدن علامتهایی که دیگران میگویند برنامه قدیمی آنها را واقعاً مدرن میکند، آنها را مدرنسازی کنند. آنها مفاهیم پرهیجانی مانند کانتینرسازی، میکروسرویسها، افزایش دادهها، تقویت معماری داخلی و موارد دیگری که ممکن است به جراحی بزرگ نیاز داشته باشند را دنبال میکنند. این رویکرد میتواند با معرفی پیچیدگیها، پیچیدگیها و هزینههای بیشماری، فقط برای علامت زدن کادر چک لیست، برنامه را در معرض خطر قرار دهد.
در اینجا دو موضوع عملگرایانه وجود دارد که باید در نظر گرفته شود.
اول، یک نقطه اوج وجود دارد که ممکن است منطقی تر باشد که برنامه قدیمی اصلی را حذف کنید و از نو شروع کنید. من همیشه بیشتر مایل به اصلاح چیزها هستم تا اینکه آنها را پرتاب کنم. با این حال، من اغلب مواردی را می بینم که ۲ میلیون دلار برای مدرن کردن یک برنامه کاربردی هزینه می شود، در حالی که یک توسعه خالص جدید ۱ میلیون دلار هزینه دارد.
مهندسین نرمافزار معمولاً میدانند که ساختن چیزی از ابتدا آسانتر و ارزانتر است تا اینکه یک سیستم موجود را بازسازی و دوباره کدگذاری کنید که ابتدا باید کاملاً درک شود تا بتوان آن را تغییر داد. به ندرت پیش میآید که تیمهایی که در ابتدا برنامه را توسعه دادهاند، هنوز در کارمندان باشند. پایگاه دانش ناقص یا وجود ندارد. این برنامه در طول سالها به قدری اصلاح شده است که هیچکس دامنه کامل آن را مانند امروز به طور کامل درک نمیکند.
دوم، کسانی که برنامهها را مدرنسازی میکنند، چک لیست گستردهای از کارهایی را که باید انجام شوند نوسازی برنامههای کاربردی انجام میدهند. در بسیاری از موارد، آنها بدون در نظر گرفتن نیاز واقعی، همه کارها را در لیست انجام می دهند. این به معنای کانتینریسازی، فعالسازی میکروسرویس، مهاجرت به پایگاه داده مدرنتر، قابلیت حمل و جابجایی است. این ویژگیها ضروری در نظر گرفته میشوند، زیرا در لیست هستند. چرا تعداد کمی از افراد لیست را زیر سوال می برند؟
در بیشتر موارد، جا دادن اجباری همه چیز در چک لیستهای نوسازی برنامهها به صرفه نیست. حتی کانتینرسازی که فواید زیادی دارد، برای همه کاربردها مناسب نیست. برای معماریهای مبتنی بر کانتینر و فناوری فعالسازی هزینهای وجود دارد، همانطور که در مورد میکروسرویسها و حتی مهاجرت به فضای ابری وجود دارد.
من نمیگویم که این ویژگیها وقتی بر اساس نیازهای برنامه هستند سرمایهگذاری محکمی نیستند. من می گویم که در برخی موارد آنها بیش از حد هستند و واقعاً به هدف کلی کسب و کار ارزش اضافه نمی کنند. بار دیگر، اگر می توانید سؤال نکنید، اگر باید سؤال کنید.
پست های مرتبط
مدرن سازی برنامه کاربردی و مفید باشد
مدرن سازی برنامه کاربردی و مفید باشد
مدرن سازی برنامه کاربردی و مفید باشد