Облачное решение - проблемы миграции данных?

Question

У меня вопрос по облачным системам.Основополагающим принципом является «Оплата за использование», «Программное обеспечение как услуга» или «Инфраструктура как услуга».Это несколько предложений от поставщиков услуг.

Предположим, у меня есть система на основе Microsoft Cloud с SQL Azure в качестве базы данных.Завтра я хотел бы перенести его на другого облачного провайдера, бывшего Amazon.

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

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

Answer 1

TL; DR: построение для наименьшего общего знаменателя среди провайдеров IaaS.

---

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

Хороший способ сделать это может состоять только в том, чтобы выполнять в облачном приложении только те действия, которые позволяет выполнять terraform.Интересно, что такие инструменты, как Docker, Kubernetes, значительно упрощают приложения, не зависящие от инфраструктуры, и наблюдается феноменальный рост числа решений, которые помогут вам в этом.Приложения, построенные на Openshift , cloudfoundry и т. Д., Помогают нормализовать работу облачных поставщиков.Появляются и более мелкие, более удобные для разработчиков инструменты, использующие k8s / docker для создания приложений, независимых от поставщиков: deis , dokku , hasura .Отказ от ответственности: я работаю в Hasura.

---

Чтобы конкретно ответить на ваши вопросы:

Предположим, у меня есть система на основе Microsoft Cloud с SQL Azure в качестве базы данных.Завтра я хотел бы перенести его на другого провайдера облачных вычислений, бывшего Amazon.

Нет, если вы сделаете это, вы не сможете быть «мультиоблаком».

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

Мы еще не полностью там.Но мы определенно движемся к этому.См. Подробности, которыми я поделился выше.

Answer 2

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

Несколько моментов (проблем, на которые следует обратить внимание), которые я рассматривал в таких миграциях, -

1. Импеданс сервисного предложения - Сервисное предложение между облакамиПоставщики руководствуются конкуренцией и руководствуются стандартами.например, AWS IAM не имеет прямого сопоставления с Azure Active Directory.Хотя вы можете объединить их, используя стандарт SAML.Если вы работаете с заказчиком, который хочет перейти с AWS на Azure (просто для разговора), решения «из коробки» не существует, для этого вам нужно будет создать специальный инструмент.Тогда как обратное (Azure AD -> AWS) было бы возможно, если бы не как PaaS, по крайней мере, как IaaS.Степень защиты (объект может быть защищен в AWS с использованием политик, Azure имеет SAS и потребует, чтобы пользовательский поставщик SAS предоставил вам аналогичную функциональность) между поставщиками облачных услуг представляет собой наибольшую проблему безопасности.Сопротивление службы также может проявляться в форме, скажем, в Azure, вы можете иметь Blob, которые бывают разных типов - Page, Append, Block.Однако в AWS нет таких категорий для объекта корзины S3.Теперь, если вы построили логику своего приложения на идее использования BLOB-объекта Append в Azure, а теперь переносите приложение на AWS, вам потребуется написать логику для загрузки объекта, добавить нужные данные, а затем загрузить новыйобъект вместе с удалением существующего объекта.Такие изменения могут иногда иметь последствия архитектурных изменений.

2. Сопротивление SLA - Услуги измеряются на определенных базовых единицах, которые являются общими для поставщиков облачных услуг.Однако существуют небольшие различия в единицах измерения и параметрах, используемых для выставления счетов.Например, AWS будет взимать плату за неструктурированное хранилище в зависимости от региона, размера, объема запросов, объема передачи (выхода) инфраструктуры AWS в единицах ГБ.Принимая во внимание, что Azure будет взимать плату за то же неструктурированное хранилище в зависимости от региона, размера, объема запросов, объема исходящих данных из инфраструктуры Azure и выбранного варианта резервирования данных.Таким образом, во время миграции вам нужно будет измерить такие различия SLA и выбрать правильный тарифный план на целевой платформе.Если вы переходите с Azure на AWS и имеете SLA на основе избыточности, вам, возможно, придется платить больше или приносить другую услугу в AWS, чтобы обеспечить непрерывность своих предложений.

3. Инструменты& API-импеданс - у поставщика облачных услуг очень разнообразная поддержка программируемых интерфейсов.Но они не должны быть похожими между двумя из них.Протокол связи REST, стандарты JSON / XML могут нас спасти.Очень вероятно, что те, кто был в облаке в течение некоторого времени, создали бы инструменты, которые помогают управлять жизненным циклом сервисов в облаке.Миграция такого клиента с его набором инструментов потребует рассмотрения усилий, которые вам понадобятся для замены инструментов, предлагаемых поставщиком услуг, и усилий, направленных на изменение любого проприетарного инструмента, который был бы создан с использованием API поставщика услуг.

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

Answer 3

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

Answer 4

Нашел статью, которая отвечает на мой вопрос

5 дорогостоящих ошибок миграции облака - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY