Преимущества:
- Централизация инфраструктуры.
- Простота обслуживания.
- Упрощенное сертифицирование.
- Повышение информационной безопасности за счет сокращения внешних каналов движения данных.
- Сокращение затрат при простоях за счет простоты обслуживания.
- Сокращение затрат на электроэнергию.
- Наличие проводимой подготовки (аудит, планирование, проектирование).
- Наличие апробированных методологий и методик проведения миграции.
- Простота написания сопутствующей документации.
Основные этапы миграции в облако
Каждая стадия миграции подразумевает решение как технических, так и нетехнических вопросов.
1. Проверка и выбор облачной модели
Инвентаризация. Вам нужно иметь полную картину вашей ИТ-инфраструктуры, знать, из каких компонентов она состоит (важны и приложения, и аппаратная часть), как эти компоненты взаимодействуют друг с другом и т. п. В идеале все эти моменты должны быть четко задокументированы. Подробная, полная и точная документация облегчает миграцию в целом, а также тестирование всех систем, в частности.
Модель. Выбор подходящей именно вам модели облака (публичное, частное или гибридное) — это важный момент. Малому и среднему бизнесу зачастую более выгодна гибридная модель.
2. Тестовая миграция и проверка облака
Оценка поставщика. Каждый провайдер предлагает уникальный спектр услуг в дополнение к базовой функциональности. Вы должны быть уверены, что можете достичь ваших целей с выбранным провайдером, прежде чем подписаться на сотрудничество с ним. Особенно важными являются вопросы безопасности. Если вы выбираете гибридное или публичное облако, необходимо позаботиться о резервных каналах связи и убедиться, что зависимость от сетевых подключений не влияет на функциональность. Выберите частную модель, если вы не уверены в качестве вашего интернета-соединения.
Тестовая миграция. Поэтапный переход в облако является оптимальным способом, независимо от выбранной модели. Проведите частичную миграцию, убедитесь, что все системы функционируют стабильно, и только потом окончательно переключайтесь на облако. Плавный переход избавит от различных неприятных сюрпризов, даст возможность присмотреться к выбранному поставщику облачных услуг и докупить необходимые мощности облачных систем при необходимости.
Перенося инфраструктуру в облако небольшими частями и тестируя систему после каждой мини-миграции, вы сможете оперативно выявлять ошибки и тут же их исправлять. Важно также проверить, насколько и как облако масштабируется. Есть два базовых варианта масштабируемости: горизонтальная (например, если не хватает мощности одной виртуальной машины, вы добавляете вторую) и вертикальная (в нашем случае с виртуальными машинами — это увеличение мощности уже имеющейся виртуалки).
Горизонтальное масштабирование в облаке не так удобно, как может показаться, поэтому рекомендую рассматривать вертикальную версию. Однако каждая миграция — это уникальный случай, поэтому возможны индивидуальные нюансы.
3. Дорожная карта миграции
В любом деле план позволяет контролировать все этапы и избегать хаотичных импульсивных действий. Миграция не исключение. Стратегия миграции включает полную информацию обо всех системах на всех этапах перехода с возможностью проверки каждого совершенного шага.
Выбор правильного времени для миграции часто может гарантировать успех всей деятельности. Если вы счастливый обладатель большой и сложной инфраструктуры, миграция будет «всегда не вовремя». Поэтому важно выделить особо критические элементы, понять, в какой период времени они менее всего используются (или — в идеале — не используются) и запланировать миграцию именно на этот период. Если у вас есть свой собственный дата-центр (и соответственно частное облако), полный единовременный переход может быть слишком рискованным, учитывая вероятность полного отказа системы. Стоит двигаться поэтапно. Например, при переносе почтовой системы в облако имеет смысл оставить локальным хранилище данных, а также заранее уточнить у поставщика облачных услуг, какие конкретно меры и в какие сроки будут им предприняты для восстановления работоспособности системы в случае форс-мажора.
Некоторые приложения невозможно разделить на части, и полный переход является единственным вариантом. В таких приложениях в процессе миграции лучше ничего не менять. Если изменения неизбежны (например, необходимо установить свежее обновление), то лучше осуществить их после миграции. Если начать вносить изменения в систему в процессе миграции, потом довольно сложно понять, что же вызвало проблемы — миграция в облако или внесение корректив в систему.