Автор: Алексей Ковальчук, Solution Architect в DataArt

Возможность переноса инфраструктуры в облако сейчас рассматривает едва ли не каждая компания. Однако прежде всего любому, кто подходит к ее практической реализации, необходимо определиться со стратегией. В статье я расскажу, как выбрать подход к миграции платформы данных в зависимости от характера бизнеса и потребностей в аналитике.

ЖИЗНЕННЫЙ ЦИКЛ СОФТА

Жизненный цикл цифровой системы удивительно напоминает человеческий. Она рождается (проектируется и создается), проходит через детство, постепенно совершенствуясь в соответствии с желаемыми бизнес-сценариями. Затем вступает в период молодости, когда пользователи начинают извлекать из нее пользу. Но постепенно система устаревает: она не может справляться с рабочей нагрузкой, вмещать новые источники данных и сценарии использования; становится слишком громоздка для добавления новых функций, а нанимать и готовить людей для ее поддержки оказывается все сложнее.

Некоторое время рефакторинг и патчи могут поддерживать платформу в рабочем состоянии, но в конце концов это становится невыгодным, т. к. требует слишком больших ресурсов. Любые меры по техническому обслуживанию едва ли позволят платформе не устареть.

Но есть и хорошая новость: некоторые платформы данных реинкарнируют в облачные нативные приложения.

ЗАЧЕМ ПЛАТФОРМЫ МИГРИРУЮТ В ОБЛАКО?

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

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

«Несколько лет назад слова „облако“ и „безопасность“ можно было услышать в одном вопросительном предложении: “Можем ли мы позволить себе быть в облаке с точки зрения безопасности?”. Сейчас вопрос кардинально изменился: „Можем ли мы с точки зрения безопасности позволить себе не быть в облаке?“».

И все же миграция сама по себе неспособна изменить структуру рабочих нагрузок или сократить затраты. Более того, расходы на хостинг могут оказаться заметно выше суммы, которую компания привыкла платить за поддержку локальной инфраструктуры. Возможная экономия напрямую зависит от того, насколько подходящую стратегию переноса вы выбрали.

ВЫБОР ПОДХОДА

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

Мы сосредоточимся на трех из шести общих стратегий миграции приложений, определенных Gartner и Amazon — по-английски их называют«шестью R»:

1) рехостинг (или lift-and-shift — «взять и перенести»);

2) смена платформы (re-platform);

3) рефакторинг (или смена архитектуры).

Давайте разберемся, какой подход к миграции скорее подойдет компании, в зависимости от сочетания атрибутов платформы данных, которую она использует.

РЕХОСТИНГ

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

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

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

Однако применение рехостинга имеет ограничения. Он целесообразен для платформ данных, обусловленных определенными бизнес-требованиями, не зависящими от облака. Некоторые организации, например, в банковской, финансовой, страховой или медицинской сферах, которые соблюдают строгие правила хранения конфиденциальных данных, могут использовать частное облако. При необходимости они могут быстро перенести данные обратно в локальную систему или другое облако.

СМЕНА ПЛАТФОРМЫ

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

Каким компаниям подойдет смена платформы?

В первую очередь, тем, которые переносят относительно современные платформы данных и хотят оптимизировать определенный компонент, например, хранилище данных, ETL/ELT, аналитику. Прежде чем выбрать такой подход к миграции, компания должна оценить готовность к работе в облаке: провести инвентаризацию всех существующих инструментов и используемых компонентов инфраструктуры, проверить, совместим ли каждый из них с облаком или требует модификации, затем оценить доступные облачные и/или нативные облачные технологии как услугу. Это позволит оценить сроки миграции и ее бюджет. Кроме того, компания получит четкое представление, нужна ли ей смена платформы в обозримом будущем.

РЕФАКТОРИНГ ИЛИ СМЕНА АРХИТЕКТУРЫ ПОСЛЕ МИГРАЦИИ

Рефакторинг — более продвинутый подход, который предполагает полное преобразование платформы данных в облачную, реорганизацию всего ландшафта данных, источников и всех компонентов системы. Конечно, он требует значительных затрат времени и ресурсов. Но этот подход наиболее выгоден с точки зрения возврата инвестиций в долгосрочной перспективе.

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

Рефакторинг лучше всего подходит компаниям с платформами данных, которые не успевают за потребностями бизнеса, не масштабируются или не обладают достаточной производительностью. Чтобы спланировать такую миграцию, заинтересованные стороны и миграционная команда должны начать с глубокого изучения бизнес-целей, процессов и потребностей с точки зрения потребления данных и аналитики. На основе полученных результатов они разрабатывают новую архитектуру, сохраняя при этом работоспособность легаси-платформы. Она не устаревает, пока не будет построена новая, и все данные не будут перенесены туда.

Итог

Универсального подхода к миграции в облако не существует, поэтому распространены гибридные варианты. Рехостинг — зачастую лишь прелюдия к более сложной облачной трансформации. Некоторые компании, действуя предельно осторожно, сначала переносят только среду разработки/тестирования.

В принципе переход в облако требует отдельной фазы исследований. Возможно, потребуется спроектировать новую архитектуру, совершенно точно придется провести анализ безопасности и работы по интеграции. Без этого стабильную работу системы гарантировать не получится.