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

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

1. Определите цели

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

2. Оцените свою вычислительную среду

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

3. Идентифицируйте и подготовьте данные и приложения

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

4. Осуществите миграцию

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

5. Предоставьте доступ к целевой облачной инфраструктуре

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

6. Протестируйте и оптимизируйте новую среду

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

7. Перенесите задачи в новую среду

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

Сценарии миграции

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

• смена хоста или платформы. Данный подход, известный также как перемещение (lift and shift), обычно включает перенос приложений «как есть» из ЦОДа предприятия в облако. При переносе с одной облачной платформы на другую потребуется немного больше работы, чем при смене хоста. В этом случае предприятие заменяет облачные сервисы, такие как СУБД или система управления кластерами контейнеров;
• покупка нового. При переносе в другое облако предприятия могут отказаться от старого и купить новое. Они заменяют самоуправляемую систему, которая предоставляет широко используемый сервис (например, электронную почту или систему ERP) на эквивалентный продукт SaaS;
• рефакторинг и смена архитектуры. Это может быть небольшой операцией вроде упаковки приложений в контейнеры перед передачей их сервису управляемых контейнеров или весьма обширной при перепроектировании приложения для облачного сервиса, контейнеров или бессерверных функций;
• сохранение или вывод из эксплуатации. На этапах постановки целей и оценки делается вывод, что некоторые ИТ-системы излишни, недостаточно активно используются или что их лучше не переносить.

Независимые от облаков и гибридные стеки инфраструктуры

Иногда смена платформы заставляет организации произвести стратегическую оценку архитектуры своей инфраструктуры. Обычно предприятия хотят иметь набор ПО, который может развертываться на множестве облачных платформ после минимальной модификации или вовсе без нее. Некоторые крупные ИТ-производители учли, что такая цель становится все более популярной, и выпустили продукты и сервисы, которые могут служить фундаментом гибридных или многооблачных корпоративных сред. Вот наиболее важные из них: Microsoft Azure Stack, Google Cloud Anthos, AWS Outposts, VMware Cloud on AWS, многооблачный PaaS на базе контейнеров типа Cloud Foundry или Red Hat OpenShift.

Проблемы и ограничения многооблачности

Если перенос приложений из собственного ЦОДа в облако одного из провайдеров открывает доступ в мир весьма полезных сервисов, то миграция между облачными провайдерами (будь то из опасения быть привязанным к одному из них или для обеспечения высокой доступности) часто оказывается ошибкой. Перенос из одного облака в другое требует наименьшего общего знаменателя инфраструктурных сервисов и принесения жертву специфических для облаков возможностей. Он также порождает новую форму зависимости — от производителей многооблачных систем, таких как VMware или Cloud Foundry.

По материалам: ITWeek