Стратегії міграції: як правильно вибрати хмарну платформу для роботи з даними

10 червня
Олексій Ковальчук, Solution Architect у DataArt
Стратегії міграції: як правильно вибрати хмарну платформу для роботи з даними
Можливість перенесення інфраструктури у хмару наразі розглядає майже кожна компанія. Однак перш за все будь-кому, хто підходить до її практичної реалізації, необхідно визначитися зі стратегією. У статті я розповім, як вибрати підхід до міграції платформи даних залежно від характеру бізнесу та потреб у аналітиці.

ЖИТТЄВИЙ ЦИКЛ СОФТУ

Життєвий цикл цифрової системи на подив дуже нагадує людський. Вона народжується (проектується та створюється), проходить через дитинство, поступово вдосконалюючись відповідно до бажаних бізнес-сценаріїв. Потім вступає у період молодості, коли користувачі починають отримувати від неї користь. Але поступово система застаріває: вона не може впоратися з робочим навантаженням, вміщати нові джерела даних і сценарії використання, стає занадто громіздкою для додавання нових функцій, а наймати та готувати людей для її підтримки виявляється дедалі складніше.

Протягом деякого часу рефакторинг і патчі можуть підтримувати платформу в робочому стані, але зрештою це стає невигідним, оскільки вимагає забагато ресурсів. Будь-які заходи з технічного обслуговування навряд дозволять платформі не застаріти.

Але є й хороша новина: деякі платформи даних реінкарнують у хмарні нативні застосунки.

НАВІЩО ПЛАТФОРМИ МІГРУЮТЬ У ХМАРУ?

Перенесення платформи даних у хмару — чудовий спосіб не дати їй остаточно застаріти, вийти за межі локального центру обробки даних або змінити стратегію ліцензування ПЗ. До того ж інвестувати величезні ресурси у складні локальні системи зараз дозволяють собі лише компанії, пов'язані жорсткими правилами і стандартами безпеки. Для інших більше підійде хмара з її перевагами: гнучкістю і керованістю, відмовостійкістю, масштабованістю, оптимізацією витрат тощо.

Петро Вайханський, старший віце-президент DataArt:

«Кілька років тому слова "хмара" і "безпека" можна було почути у запитанні: "Чи можемо ми дозволити собі бути у хмарі з погляду безпеки?". Зараз запитання кардинально змінилось: "Чи можемо ми з погляду безпеки дозволити собі не бути у хмарі?"».

І все ж міграція сама собою не здатна змінити структуру робочих навантажень чи скоротити витрати. До того ж витрати на хостинг можуть виявитися помітно більшими за суму, яку компанія звикла платити за підтримку локальної інфраструктури. Можлива економія безпосередньо залежить від того, наскільки правильну стратегію переносу ви вибрали.

ВИБІР ПІДХОДУ

Насамперед потрібно врахувати особливості платформи: технологічний стек, вік, джерела даних, бізнес-вимоги, дорожню карту у сфері управління даними й аналітики.

Ми зосередимось на трьох із шести загальних стратегій міграції застосунків, визначених Gartner і Amazon — англійською їх називають «the 6 R’s»:

  • рехостинг (або lift-and-shift — «взяти й перенести»);
  • зміна платформи (re-platform);
  • рефакторинг (або зміна архітектури).

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

cloud-migration-scheme

Шість поширених стратегій міграції додатків. Джерело: amazon

РЕХОСТИНГ

Рехостинг або lift-and-shift («взяти й перенести», просте перенесення) — найпростіший, порівняно швидкий та економічний підхід до переносу платформ даних у хмару. Система просто переноситься у своєму первісному вигляді чи з мінімальними змінами. Рехостинг можна автоматизувати за допомогою спеціальних інструментів, пропонованих постачальником хмарних послуг.

Яким компаніям підійде рехостинг?

Перш за все, тим, які хочуть швидко евакуювати центр обробки даних, збільшити ємність зберігання серверів або розірвати ліцензійну угоду з хостинг-провайдером. Для деяких компаній хмара служить додатковим центром обробки даних. За допомогою міграції за принципом рехостингу можна виграти час, щоб спланувати перетворення всієї системи на нативну хмарну. Інші підходи — зміну платформи і рефакторинг — легше реалізувати, коли сама платформа даних уже знаходиться у хмарі.

Однак застосування рехостингу має обмеження. Він є доцільним для платформ даних, обумовлених певними бізнес-вимогами, що не залежать від хмари. Деякі організації, наприклад, у банківській, фінансовій, страховій чи медичній сферах, які дотримуються суворих правил зберігання конфіденційних даних, можуть використовувати приватну хмару. У разі необхідності вони можуть швидко перенести дані назад у локальну систему або іншу хмару.

ЗМІНА ПЛАТФОРМИ

Зміна платформи або lift-tinker-and-shift («взяти, повозитися та перенести») — часткове оновлення платформи і всіх пов'язаних з нею даних для оптимізації хмари та часткового перетворення застосунку на нативний хмарний. Такий підхід є досить ефективним з економічного боку, оскільки не передбачає серйозних змін у бізнес-логіці чи архітектурі. Багато компаній вважають за краще розвивати хмарну середу в міру зростання платформи даних, тому вибирають саме цей варіант.

Яким компаніям підійде зміна платформи?

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

РЕФАТОРИНГ АБО ЗМІНА АРХІТЕКТУРИ ПІСЛЯ МІГРАЦІЇ

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

Яким компаніям підійде рефакторинг?

Рефакторинг найкраще підходить компаніям із платформами даних, які не встигають за потребами бізнесу, не масштабуються або не володіють достатньою продуктивністю. Щоб спланувати таку міграцію, зацікавлені сторони та міграційна команда мають почати з глибокого вивчення бізнес-цілей, процесів і потреб з погляду споживання даних і аналітики. На основі отриманих результатів вони розробляють нову архітектуру, зберігаючи при цьому працездатність легасі-платформи. Вона не застаріває, доки не буде побудовано нову та всі дані не будуть перенесені туди.

***

Універсального підходу до міграції у хмару не існує, тому поширені гібридні варіанти. Рехостинг часто є лише прелюдією до більш складної хмарної трансформації. Деякі компанії, діючи дуже обережно, спочатку переносять тільки середовище розробки/тестування.

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    19 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Дніпро; Україна, Харків; Україна, Херсон
    1 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    30 жовтня