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

Зачем же рассматривать миграцию из облака в облако? 

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

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

Что осложняет миграцию из облака в облако?

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

Возьмем балансировщики нагрузки.  В AWS они обрабатываются с помощью процедуры завершения SSL, в то время как в Azure требуется Azure Application Gateway. Это два совершенно разных зверя. Иногда кажется, что системы похожи в оркестровке контейнеров, например, Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS) , но они могут создавать технические трудности.  В AWS управление идентификацией и доступом (IAM) в основном используется для контроля доступа, но в Azure этот момент будет покрываться с помощью  Azure Active Directory (Azure AD). Любому приложению, мигрирующему от одного облачного провайдера к другому, необходима адаптация для поддержки метода, используемого конечной средой.

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

Как решить, стоит ли это усилий? 

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

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

Зрелость существующей деятельности в облаке также имеет значение. Если был достигнут прогресс в модернизации приложений и внедрении подходов DevOps, таких, как Ci/CD, это усложнит работу.  Любая инфраструктура как код (IaC) или конфигурация как код (CaC) должны быть переписаны для новой среды.   

Итак, Вы решили пойти на это. Что теперь?  

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

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

Наконец, не забывайте, что фаза двойного облака приведет к увеличению затрат.  

Если Вы решили забыть об этом. Какие альтернативы? 

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

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

No Comments