Иногда перед ускорением следует затормозить. Для сосредоточения, планирования и внедрения необходимых изменений. В этой статье будем говорить о качественном шаге вперед – о миграции приложений в облачное хранилище.
По данным Synergy Research Group, в 2020 году расходы предприятий на сервисы облачной инфраструктуры увеличились на 35% и достигли почти 130 миллиардов долларов. Переход в облако совершают масштабные компании и небольшие стартапы.
Вы еще не в облаке, но собираетесь? Держите простой пошаговый план, как лучше совершить переход и получить максимум преимуществ от смены хранилища.
Спойлер – это довольно легко. Но только при четком соблюдении алгоритма осуществления процесса.
Как убедиться, что все проходит хорошо?
Давайте начнем с граблей. На которые чаще всего наступают при перемещении приложений, настроек, операционных систем виртуального дата-центра облачного провайдера.
Распространенные ошибки, возникающие в процессе миграции
- мнение, что все облачные провайдеры одинаковы,
- отсутствие схемы зависимости приложений,
- отсутствие предварительного тестирования,
- просчеты в политике безопасности,
- простого и неудобства для пользователей.
На самом деле, эти пункты тесно связаны между собой. И при наличии надежного плана действий и четкого его выполнения большинство из проблем решаются заранее, еще до того, как успеют вызвать заметный деструктив.
6 шагов, которые приведут прямо в облако
На каждом из них нужно задать вопросы и найти ответы на них. Держите список и сверяйтесь с ним:
- обследование инфраструктуры,
- разработка стратегии,
- выбор облачного провайдера,
- подготовка и планирование
- миграция данных в облако,
- проверка и подтверждение результата.
Далее подробнее о каждом из этапов.
Обследование готовности ПО размещению и использованию в облаке
Включает сбор и анализ информации о программном обеспечении предприятия, статистику пиковых нагрузок в работе инфраструктуры, оценку рисков возможных сбоев, создание перечня приложений и их схем взаимодействия. Этакая инвентаризация.
После этого станет очевидно, как лучше перенести наземную инфраструктуру в облако полностью или частично и выборочно, на постоянной основе или временно.
Если в результате обследование убедились, что вместо инвестирования в дополнительное оборудование готовы использовать преимущества масштабирования облаков, вперед! Если выводы напрашиваются другие, то, отложите этот вопрос.
Выбор и разработка стратегии
После детального обследования пора приниматься за стратегическое планирование. Удобную классификацию предлагает Amazon Web Services. Всего 6 стратегий миграции приложений в облако, «6 R’s»:
- Rehosting (рехостинг) – перенести «все как есть». Следует использовать для приложений, которые принесут значительную пользу бизнесу и не требуют изменения. Попробуйте автоматизировать процесс с помощью специальных инструментов (например, AWS Application Migration Service).
- Replatforming (изменение платформы) – перенос важных приложений, требующих оптимизации, но без изменений основной архитектуры.
- Repurchasing (повторная покупка) – переход на другой продукт (платформу).
- Refactoring/Re-architecting (изменение архитектуры) – внедряется по необходимости в новых функциях, в дополнительном масштабировании или производительности. Как правило, производится с использованием cloud-native функций. Это дорогостоящий подход, но при высоком спросе на Ваш продукт может стать самым выгодным.
- Retire (вывод из эксплуатации) – избавляемся от приложений, которые больше не приносят пользы, в которых нет нужды.
- Retain (оставление) приложений, целесообразность и архитектуру которых планируете посмотреть через некоторое время. Не сегодня.
Выбор облачного провайдера
Лучше всего посмотреть, на чем фокусируются провайдеры и сравнить их предложения с насущными и перспективными потребностями проекта. Что важнее для Вашего бизнеса: мгновенная значительная масштабируемость (например, для проектов по сезонной нагрузке) или персонализированные возможности управления приложениями?
По крайней мере, необходимо сопоставить требования к производительности приложений и систем с теми показателями, которые гарантирует облачный провайдер.
Частные облака для проектов с повышенными требованиями к безопасности
Обратите внимание на эту возможность, если вам необходима полностью изолированная виртуальная инфраструктура.
Гибридные облака как комбинация частных и публичных
Многообещающий вариант для проектов, требующих одновременно широких возможностей масштабирования и гибкости публичных хранилищ и надежности частных ресурсов. Качественное решение для работы с big data.
Учтите степень готовности персонала к выполнению работы
Спрогнозируйте, с какими провайдерами процесс пойдет быстрее и проще. Так, например, платформа Microsoft Azure обычно повышает производительность специалистов благодаря встроенным инструментам и готовым шаблонам.
Подготовка и планирование
Самое главное здесь убедиться, что frontend и backend обособлены и что они могут масштабироваться в зависимости от фактической необходимости в ресурсах. Предусмотрите изменения архитектуры, если они необходимы. Далее спланируйте очередность.
Как показала практика, лучше начать с небольших шагов
Разделите общую задачу на этапы. В первую очередь в туче следует развернуть наименее важные компоненты миграции. Выберите для начала приложения, которые наиболее подходят для облачной среды, и перенесите их. Увеличивать объем ресурсов в облаке и/или переносить можно уже в процессе тестирования облака и проверки нагрузочной устойчивости. Особенно осторожно обращайтесь с бизнес-критическими приложениями (Business Critical Applications, BCA).
Проанализируйте приложения с точки зрения автономности
Как они соединены меж собой? А с инфраструктурой в целом? Часто случается, что несколько приложений обращаются в одну базу данных. Чтобы не нарушить их слаженную работу, следует проработать процедуру скоординированного перемещения в облако. Проще всего перенести приложения, не связанные с другими системами (например, корпоративный блог).
Обязательно учтите порядок переноса, чтобы минимизировать простои. Для этого может понадобиться контактировать с технической поддержкой провайдера (которого выбрали, помните?).
Что дает такой подход:
- тестирование возможностей облака и вашей подготовки
- разгрузка части физической инфраструктуры,
- возможность действовать оперативно с наименьшими рисками.
Безопасность передачи
Учтите, что при высоких стандартах безопасности данных те же требования должны относиться ко всем этапам переноса в облако. Любые места временного хранения должны быть такими же надежными, как и конечный пункт назначения.
Учтите, что некоторые процессы могут быть непригодными для облачных приложений. У Вас может оказаться меньше инструментов мониторинга, меньше контроля безопасности и другими процедурами. Поэтому настройтесь, что, возможно, придется просмотреть свои стратегии и процедуры безопасности.
Предвидение неудобств для пользователей
Плохая новость – вероятнее всего, неудобства возникнут. Хорошая новость – их можно минимизировать, если на предыдущих этапах все рассчитано верно.
Так, по словам заместителя председателя правления Приватбанка Мариуша Качмарека, при глобальном переносе более 270 банковских приложений в облачную среду весной 2022 года клиенты в общем-то имели сложности с доступом к системам менее чем на 5% времени от всего срока проведения работ. Обнадеживающе, не правда ли?
Возможно, заранее предупредить пользователей о вероятности ограничения возможностей в пользовании приложениями с понятным объяснением причины.
Миграция данных в облако
Что ж, здесь следует просто действовать по плану. Успех этого этапа зависит от усердия проведения предыдущих.
Будьте гибки, готовы оперативно внести определенные изменения в план в соответствии с фактическим ходом событий.
Как перенести данные
Методы переноски выбирайте в зависимости от размера приложений. Небольшие объемы данных можно просто скопировать через Интернет-соединение. Но при значимых величинах данных таковой метод не подойдет. Вас вряд ли устроят бесконечное время передачи или космическая стоимость услуг облачного провайдера. Попытайтесь сжать данные перед отправкой. Отправьте провайдеру физические диски.
Проверка и подтверждение
Последняя ступень к цели. Убедитесь, что все работает:
- все ли перенесено?
- все внутренние компоненты должным образом обмениваются данными в новой среде?
- все ли доступно пользователям?
- все ли инструменты администратора могут качественно контролировать работу приложений?
- обеспечена ли защита от сбоев на уровне дата-центра и отдельных аппаратных компонентов?
В идеале нужно провести автоматизированное тестирование. Если это невозможно, выполните тщательную ручную проверку. Ошибок нет? Поздравляем, смело выводите сервисы в продакшне.
Вы волнуетесь, что нет практического опыта? Найдите того, у кого он есть
Учтите, что при отсутствии практики и уверенности в персонале лучше прибегнуть к экспертной помощи. По меньшей мере, для переноса критически важных приложений (BCA). Специалисты, многократно проходящие весь процесс, сделают его максимально комфортным и для Вашего бизнеса.
Мы предлагаем перечень решений для организации или облачной инфраструктуры. Подберем публичное или частное облако (после обследования существующей инфраструктуры расскажем, какой вариант для Вас оптимален), построим хранилище, выполним миграцию и проверим результат.
Свяжитесь с нами, опишите первоочередные требования к переносу приложений в облако. Вы получите обратную связь от одного из наших технических специалистов и мы вместе найдем пути эффективной и безопасной миграции.