Практически не существует инструментов, предназначенных для помощи в репатриации из облака, поэтому вы фактически предоставлены сами себе. Независимый аналитики Кристофер Тоцци рассказывает на портале ITPro Today, о чем следует подумать при планировании репатриации.

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

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

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

Почему планирование репатриации является сложной задачей

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

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

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

Что нужно учитывать при репатриации

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

Давайте рассмотрим эти требования по порядку.

Упаковка рабочей нагрузки

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

Лучший способ сделать это зависит от того, как вы управляете рабочей нагрузкой в облаке и какие варианты хостинга у вас есть онпремис. Если ваша облачная рабочая нагрузка представляет собой виртуальную машину, вы можете взять ее образ и запустить его онпремис, при условии, что вы можете поддерживать виртуальную машину того же типа в своей собственной инфраструктуре. Если это контейнер, вы можете перенести образы контейнеров обратно в локальную инфраструктуру, хотя вам, возможно, придется изменить их конфигурации, чтобы приспособиться к другой среде оркестровки. Одним из примеров, когда может потребоваться изменение конфигурации, является использование ECS (контейнерного оркестратора не на базе Kubernetes) для запуска контейнеров в облаке, но в локальной инфраструктуре вы планируете использовать Kubernetes.

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

Сети

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

Хранилище

Рабочие нагрузки, требующие огромных объемов хранения данных или разработанные для работы с определенным типом облачных сервисов хранения, также могут потребовать обновления в процессе репатриации. Вам нужно будет убедиться, что у вас есть локальная инфраструктура хранения, необходимая для поддержки объема данных, которые вы собираетесь перенести онпремис. Возможно, вам также придется преобразовать ресурсы хранения, такие как базы данных, из облачных версий (например, Amazon Aurora) в типы, которые вы можете использовать на собственной инфраструктуре (например, MySQL).

Управление операциями

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

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

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

Планирование успешной репатриации

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