Бізнес-обґрунтування міграції робочих навантажень з вичерпаним терміном експлуатації у AWS. Частина II

Якщо ви вирішили переходити у хмару, а не оновлювати локальне корпоративне програмне забезпечення, термін служби якого закінчився (EOL, end-of-life), вам потрібно визначити, яка стратегія міграції підходить для вашої організації. У цій другій частині блогу про хмарну міграцію ми розглянемо міркування, які допоможуть вам обрати найкращий маршрут, зокрема, як вибрати між двома опціями: рефакторинг (refactoring) або реплатформінг (replatforming).

Якщо ви все ще обмірковуєте про перехід у хмару, перевірте частину першу .

Рефакторинг і реплатформінг є двома із семи так званих стратегій 7R для міграції в хмару. Amazon Web Services (AWS) описує їх таким чином: refactor, replatform, repurchase, rehost, relocate, retain і retire.

Це вже багато опцій. Але рішення може стати набагато складнішим, якщо ви плануєте перенести декілька додатків. Тут, у SoftwareOne, у нас є перевірена методологія, яка допоможе вам успішно провести міграцію в хмару AWS, незалежно від того, наскільки комплексними є ваші ІТ-активи. І це починається з надання консультації про модернізацію додатків (AMA, Application Modernization Advisory). Це допоможе вам зрозуміти, як виглядає ваша існуюча інфраструктура, щоб потім намітити свій шлях до більш сучасного, хмарного підходу в AWS.

Але спочатку давайте розглянемо різні потенційні стратегії міграції для вирішення проблем з програмним забезпеченням, термін якого підходить до завершення (EOL).

Розуміння різних опцій 7R

Незважаючи на всі розмови про цифрову трансформацію та хмарну міграцію, більшість організацій сьогодні все ще сильно залежать від програмного та апаратного забезпечення в локальних центрах обробки даних. Останні дані Gartne показують, що більше половини корпоративних витрат на ІТ все ще йде на традиційну локальну інфраструктуру. Але модернізація робочих навантажень і переміщення робочих навантажень у хмару — це не одне й те саме. Звичайна міграція в хмару додатку як є «lift and shift» - рехостинг – може бути найпростішим способом міграції, але це не дає вам змогу максимально використати багато розширених можливостей хмари. Гірше того, це може означати, що ви заберете все своє поточне програмне забезпечення та неефективність програм із собою в хмару.

Ви можете зменшити ризик такого типу неефективності, дотримуючись іншої стратегії 7R: реплатформінг.

Це передбачає модифікацію ваших програм перед міграцією, щоб отримати більше переваг від можливостей хмари. Наприклад, ви можете розгорнути базу даних у Amazon Relational Database Service (Amazon RDS) – набір хмарних керованих сервісів, що надаються за схемою «Платформа як сервіс» (PaaS, Platform as a Service). Це усуває необхідність виправлення бази даних, що економить час на операції та підвищує доступність і продуктивність. Таким чином, ви можете швидко почати отримувати переваги від переходу до хмари.

Реплатформінг може бути простішим і рентабельнішим, ніж деякі інші стратегії 7R.

Іншим варіантом є рефакторинг, який потребує більше часу та зусиль, ніж рехостинг або реплатформінг. Реархітектуючи частину свого існуючого програмного коду, ви можете оптимізувати результат міграції та отримати значні переваги від хмарних сервісів. Наприклад, перехід до таких сервісів, як AWS Lambda, безсерверний обчислювальний сервіс, або до керованого сервісу, як-от Amazon API Gateway, може значно зменшити витрати на інфраструктуру та забезпечити більшу масштабованість і відмовостійкість. Розглядайте цей підхід лише тоді, коли необхідні інвестиції мають сенс: ви навряд чи захочете скористатися цим шляхом, наприклад, для локальної програми, яка не є критично важливою та працює ефективно та економічно вигідно.

Плануйте свій шлях вперед за допомогою сервісу Application Modernization Advisory

Отже, як все ж таки визначитися, який саме варіант підходить саме для вас – рехостинг, реплатформінг чи рефакторинг? Для початку необхідно отримати чітке уявлення про те, як виглядає ваше поточне середовище додатків, де хмара пропонує можливості для зменшення витрат і рівня складності, та яка стратегія є найкращою для вашого бізнесу, коли наближаються терміни завершення експлуатації вашого програмного забезпечення (EOL). Ми можемо допомогти вам досягти цього за допомогою AMA.

Наша методологія AMA використовує автоматизовані інструменти, проведення зустрічей та воркшопів з клієнтом з метою отримання глибокого розуміння його додатків: проблем з кодом, залежностей, ризиків, питань по ліцензуванню, витрат тощо. Це важливо перед прийняттям рішення про стратегію міграції. Багато організацій спостерігали, як їхнє середовище додатків з роками стає все більш непрозорим і складним, і жодна особа чи постачальник не має повного розуміння того, як це все працює. Дуже часто це середовище стає чорною скринькою.

Базуючись на оцінці AWS Well-Architected Review, наш місячний етап AMA дозволяє розробити декілька дорожніх карт і рекомендацій згідно найкращих практик, щоб допомогти вам отримати максимальну віддачу від переходу до хмари AWS. Незалежно від того, чи маєте ви справу з одним додатком, декількома чи сотнями додатків, ми визначимо моделі використання, щоб знайти ефективні та економічно вигідні шляхи модернізації вашого середовища.

Після того як ми завершимо AMA, ми можемо зустрітися з вами, щоб допомогти визначитися з наступними кроками. Можливо, ви прагнете зменшити капітальні витрати, перейшовши до моделі, зосередженої більше на операційних витратах. Можливо, ви прагнете збільшити інноваційність або ефективність. Або, можливо, ви прагнете зрозуміти, що означає злиття чи поглинання для майбутнього вашої організації.