Миграция в облако

В последние годы облачные услуги пользуются большим спросом. По данным iKS-Consulting, к 2028 году около 78% крупных компаний будут использовать облачную инфраструктуру. Этому способствуют несколько факторов, в том числе простота работы, скорость развертывания проектов, экономия средств на оборудовании и многие другие.

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

Миграция в облако: что это и зачем это нужно

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

Что касается облака, существует множество сервисов на выбор. Например, в Рег.ру можно подобрать облачные решения под системные требования вашего проекта.

Переезд в облако будет иметь следующие преимущества:

1. Повышение доступности. Серверы облаков размещены в дата-центре провайдера и подключены к источнику бесперебойного питания. Кроме того, если оборудование вышло из строя, поставщик услуг оперативно меняет его на новое. Всё это минимизирует перебои в работе вашего проекта.
2. Экономия средств. Так как часто облака размещены на территории провайдера, это позволяет снизить затраты на электричество, охлаждение и обслуживание серверов.
3. Гибкость и масштабируемость. Облака позволяют гибко управлять ресурсами. Это значит, что вы можете добавить мощности на время пиковых нагрузок, а после — снизить тариф. Всё это можно сделать в пару кликов.
4. Простота управления. Обычно провайдеры предоставляют единую панель управления облаком. Через нее вы получаете доступ ко всем заказанными ресурсам облака.

При переносе данных важно подготовиться: это поможет переехать с минимальными рисками.

Как подготовиться к переносу данных в облако

1. Определение цели переноса. Важно выяснить, для чего вам нужен перенос. Целью может стать удобство управления инфраструктурой или экономия средств.
2. Анализ текущей инфраструктуры. Не каждую инфраструктуру можно перенести в облако, и не для каждой это требуется. Эти моменты важно прояснить до начала переноса данных.
3. Выбор сценария. После анализа инфраструктуры выберите один из семи возможных сценариев (7 Rs) переноса. Выбор будет зависеть от многих факторов: например, актуальности приложения, уровня приватности данных и других. Подробнее о стратегиях 7 Rs мы расскажем далее.
4. Подготовка плана защиты данных. Для хранения данных в облаке важно заранее продумать, как будет реализована защита сервисов и данных от несанкционированного доступа.
5. Выбор поставщика облачных услуг. IT-рынок предлагает множество облачных решений от разных провайдеров: в любом случае вы сможете найти подходящее. При подборе рекомендуем учитывать требования вашего проекта, предлагаемый уровень безопасности, а также репутацию поставщика услуг.
6. Тестирование. После заказа облака проверьте, какой функционал будет поддерживаться и какую нагрузку выдержит услуга. Например, вы можете загрузить резервную копию вашего проекта в облако и протестировать его работу.
7. Миграция. Если тесты прошли корректно, можно приступить к миграции. Когда перенос будет завершен, проверьте работу проекта.
8. Мониторинг. По завершении всех этапов переноса установите систему мониторинга: так вы сможете быстро выявлять проблемы и оперативно их устранять.

В зависимости от задач вашей компании, перенос инфраструктуры будет происходить по одному из семи сценариев. Подробнее о каждом из них — ниже.

Сценарии миграции в облако

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

7 Rs — это набор методов, который помогает организациям при переносе данных в облако. Стратегии 7 Rs позволяют планировать, реализовывать и оптимизировать процесс миграции. Как можно предположить из названия, этих сценариев семь:

1. Rehost.
2. Relocate.
3. Replatform.
4. Refactor.
5. Repurchase.
6. Retire.
7. Retain.

Rehost

Rehost (Lift and Shift) — это стратегия, согласно которой проект можно перенести в облако без изменений инфраструктуры. В рамках этого сценария рабочее приложение переносится на облачный сервис вида IaaS (Infrastructure as a Service или инфраструктура как услуга) — на нем можно перераспределить нагрузку на проект. Все данные и рабочие нагрузки также переносятся в облако.

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

Relocate

Relocate (Hypervisor-Level Lift and Shift) — это стратегия для переноса виртуальных машин. По принципу она схожа с Lift and Shift, однако всё-таки имеет два отличия:

1. Это узкоспециализированный сценарий, который предназначен только для виртуальных машин.
2. При переносе могут потребоваться изменения в проекте, пусть и минимальные.

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

Replatform

Replatform (Lift and Reshape) — это стратегия, в рамках которой переносимое приложение требует небольшой оптимизации. В проект вносятся минимальные изменения, однако большая часть кода и основная архитектура остаются прежними.

Для чего подойдет этот сценарий миграции:

• повышение уровня безопасности (например, путем обновления операционной системы до последней версии),
• перенос виртуальных машин в контейнеры,
• смена операционной системы (например, переход с Windows на Linux) и во многих других случаях.

Refactor

Refactor (Re-architect) — это одна из наиболее сложных стратегий миграции. В этом случае код и архитектура проекта полностью перерабатываются: например, монолитное приложение делится на микросервисы.

Сценарий миграции Refactor будет полезен в следующих случаях:

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

Repurchase

Repurchase (Drop and Shop) — это стратегия миграции, которая подразумевает замену текущего приложения новой версией. Также возможна замена локального приложения другим продуктом.

Такой сценарий применим в следующих случаях:

• переход со стандартной лицензии ПО на SaaS (Software as a Service),
• необходимость обновления существующего приложения,
• замена локального приложения на равноценный аналог.

Retire

Retire — это сценарий миграции, в рамках которого рабочее приложение постепенно выводится из эксплуатации. Это может пригодиться:

• если нужно отключить зомби-приложение или бездействующее приложение;
• когда сохранение текущего приложения и его перенос в облако не имеет смысла;
• если приложение совместимо только с устаревшими версиями операционных систем и в других подобных случаях.

Retain

Retain (Revisit) — это стратегия миграции, при которой приложение остается в локальной среде или перенос откладывается на более поздний срок. Чаще всего это связано с требованиями безопасности: например, если организация хранит конфиденциальные данные и работает с ними.

Также Retain применима:

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

Возможные ошибки при миграции в облако

При миграции на облачную платформу возможны ошибки, которые в будущем скажутся на скорости и качестве работы приложения. Чаще всего проблемы возникают по следующим причинам:

1. Неполное понимание устройства инфраструктуры. Например, анализ мог быть проведен не полностью: состояние приложения проверено, однако необходимый набор инструментов и функционал облака подобран неверно. Из-за этого после миграции может произойти деградация работы сервисов.
2. Неподходящий тип облака. Выбор типа облака зависит от того, с какими данными работает ваша компания. Например, для общедоступных данных подходящим вариантом станет публичное облако, а для конфиденциальной информации — частное.
3. Пропуск этапа тестирования. Иногда подходящий облачный сервис можно выбрать не сразу: для этого требуется протестировать заказанную услугу. Если же этого не сделать, приложение может работать значительно медленнее или отдавать ошибку.

Как избежать подобных проблем:

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

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

Галина Ашмарина