Самой сложной задачей при выполнении миграции в облако является не перенос данных, а перенос кода обработки данных для работы на новой облачной инфраструктуре, пишет на портале eWeek Шевек, технический директор софтверной компании Compilerworks.

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

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

С философской точки зрения существует три различных подхода к миграции, перечисленных в порядке возрастания риска:

  1. «Взять и перенести» (Lift and shift). Перенести существующую функциональность кода в облако;
  2. «Взять, настроить и перенести» (Lift, adjust and shift). Выполнить некоторые изменения в коде во время миграции;
  3. Полный редизайн. Перестроить все с нуля.

Какой бы подход вы ни выбрали, помните о пяти скрытых издержках миграции кода.

1. Недооценка масштаба задачи

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

Необходимо ответить на следующие вопросы.

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

Все ли необходимо перенести? Не выполняется ли какой-то код без всякой пользы? В результате исторического развития и роста часто значительная часть кода обработки данных работает без всякой причины.

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

2. Квалификация целевой платформы

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

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

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

3. Нестандартизированный SQL

«Стандартный SQL» — это миф. Заманчиво представить, что синтаксис SQL означает одно и то же и возвращает одно и то же значение, поскольку он легален в любом из двух диалектов SQL. Ручной перевод кода, особенно инженером, который не является экспертом в обоих диалектах, как правило, фокусируется на успешном выполнении и полагается на длинный «хвост» тестирования и проверок, чтобы подтвердить, что вычисления на новой платформе выполняются правильно. Это требует времени и чревато ошибками.

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

4. Качество и согласованность

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

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

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

5. Избежать остановки мира

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

Чтобы избежать остановки мира, исходную и целевую платформы можно запускать параллельно, чтобы подтверждать правильность результатов. Это упрощает тестирование и повышает уверенность в правильности выполнения на новой платформе. Обычно это делается поэтапно на сегментах инфраструктуры обработки данных. Задача состоит в том, чтобы правильно «определить размеры сегментов», чтобы избежать резкого увеличения сроков проекта: если сегменты слишком малы, то циклы тестирования займут слишком много времени; если они слишком большие, то выявление проблем займет слишком много времени.

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