Для того чтобы перенос ИТ-ландшафта компании в облачную среду был успешным, нужно отталкиваться от разработанной заранее стратегии миграции (Deployment Strategy). Этот документ должен досконально описывать весь процесс: перечень сервисов, которые подлежат миграции; порядок и методы переноса данных; обеспечение безопасности; процедуры тестирования и поддержки после миграции.

 

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

 

 

Неудачный выбор стратегии миграции в облако грозит компании целым рядом неприятностей:

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

 

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

 

Один из наиболее распространенных вариантов – стратегия Big Bang Deployment, или «взрывная миграция». Все приложения компании переносятся в облако одномоментно и полностью. Это рискованный вариант из-за возможных проблем совместимости и утечек данных. Подходит компаниям, которые экономят время при «переезде».

 

Постепенная миграция (Phased Deployment) проводится этапами, начиная с менее критичных для бизнеса приложений и заканчивая самыми важными. Позволяет снизить риски и сбалансировать нагрузку на команду DevOps. Подходит компаниям, которые стремятся уменьшить риски в процессе миграции. Требует больше времени, чем Big Bang Deployment.

 

Например, крупная компания, которая использует много приложений и сервисов, может прибегнуть к этой стратегии: сначала перенести небольшие приложения или сервисы, а затем, постепенно, более критичные и сложные системы.

Параллельная, или беспрерывная миграция (Parallel Deployment) предусматривает одновременную работу приложений и данных в течение определенного времени как на локальных серверах, так и в облачной среде. Особенно полезна для компаний, желающих исключить простой системы и любые риски сбоя. 

 

Может подойти СМБ-игроку для быстрой и безопасной миграции приложений в облако. Во время миграции новая инфраструктура работает параллельно со старой, и, если возникнут проблемы, то можно быстро вернуться к прежней версии.

 

Гибридная миграция (Hybrid Deployment) позволяет использовать преимущества облачных и локальных вычислительных систем одновременно. Приложения и данные функционируют как в облаке, так и на локальных серверах. Подходит компаниям, которые по каким-либо причинам не могут полностью перенести ИТ-инфраструктуру в облако.

 

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

 

Blue/green-развертывание (Blue/Green Deployment). В рамках стратегии новая версия приложения (green) загружается в облако и проходит тестирование. После успешного тестирования работа переключается на green-версию вместо текущей версии (blue). Если возникают какие-либо проблемы, переключение может быть отменено, и работа приложения продолжится с версией blue.

 

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

 

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

 

Rolling-развертывание (Rolling Deployment) – последовательное обновление приложения на одном или нескольких серверах. Если в процессе обновления возникают проблемы, их можно быстро устранить, а процесс обновления продолжится. Этот метод обеспечивает плавный переход к новой версии приложения в облаке, минимизируя риски и не прерывая работу приложения. Rolling Deployment очень похож на параллельную миграцию.

 

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

 

A/B-тестирование (A/B Testing) – метод, при котором компания развертывает несколько версий приложения и тестирует их на разных группах пользователей. Данные о поведении пользователей собираются и анализируются, чтобы определить наиболее эффективную версию приложения. Этот метод позволяет проверить новую версию приложения в реальных условиях и сравнить ее с предыдущей.

 

 

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

 

Далее важно выбрать облачную платформу, которая соответствует требованиям приложения и бизнес-процессов. Раньше в пуле возможных вариантов функционального публичного облака традиционно фигурировали западные гиперскейлеры – Amazon Web Services, Microsoft Azure и Google Cloud Platform. Однако в настоящее время рекомендуется использовать российские платформы, поскольку западные поставщики могут приостановить работу приложения без объяснения причин.

 

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

 

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

 

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

 

 

Разработка эффективной стратегии миграции в современных условиях – коллективная работа ИТ-департамента компании, специалистов облачного провайдера и внешних консультантов. Переменных в этом уравнении достаточно много, поэтому для выбора оптимального решения целесообразно провести коллективную экспертную оценку – бизнес лучше понимает задачу и цель, но не располагает необходимыми компетенциями в практике миграции (которые есть у консультантов) и знанием технических тонкостей (которыми обладает команда облачного провайдера).

 

Автор: Михаил Сергеев, ведущий инженер, CorpSoft24
Источник: Иксмедиа