Облачное решение - проблемы миграции данных?
У меня вопрос по облачным системам. Основополагающим принципом является "Оплата за использование", "Программное обеспечение как услуга" или "Инфраструктура как услуга". Это несколько предложений поставщиков услуг.
Предположим, у меня есть система на основе Microsoft Cloud с SQL Azure в качестве базы данных. Завтра я хотел бы перенести его на другого провайдера облачных вычислений, бывшего Amazon.
Находимся ли мы в состоянии, когда у нас есть плавный подход к переносу данных приложения от одного поставщика облачных услуг к другому.
Мой вопрос был более сфокусирован на долгосрочной основе, как управлять приложениями в облаке.
4 ответа
Все следующее должно быть решено с надлежащим поставщиком. Прежде всего, основной риск в облачной миграции - это повреждение данных - аномалии или избыточные или дублированные данные, или отсутствие ранее существующих данных - происходит из-за возможного отсутствия максимальной синхронизации между исходным и целевым облаком. Во-вторых, существует семантический риск - потеря или повреждение данных не выполняется, миграция считается успешной, но иногда значение устаревшего столбца и целевого столбца имеет одно и то же значение, но их измерение отличается, а значение данных совершенно другое. для меня это две основные проблемы, так как я сталкивался с ними в прошлом у неудачного продавца. услуга облачной миграции не является дешевой, поэтому я настоятельно рекомендую сделать правильный выбор для вас. я перешел на облачность и доволен ими как поставщиком облачных услуг. опять же, не дешевый сервис - но я верю, что если вы вложите в него деньги, вы заслуживаете того, чтобы получить лучшее.
Нашел статью, которая отвечает на мой вопрос
5 дорогостоящих ошибок миграции облака - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY
Я прочитал ваш вопрос как переносимость решений, основанных на данных, размещенных в облаке. Это сложная проблема на сегодняшний день. Нет стандартов, которые определяют требования к переносимости, но есть инструменты / услуги, которые помогут вам преодолеть отсутствие стандартов переносимости.
Несколько моментов (проблем, на которые стоит обратить внимание), которые я рассмотрел в таких миграциях:
Сопротивление предложения услуг - Предложение услуг между облачными провайдерами определяется конкуренцией и направляется стандартами. например, 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, вам потребуется написать логику для загрузки объекта, добавить нужные данные, а затем загрузить новый объект вместе с удалением существующего объекта. Такие изменения могут иногда иметь последствия архитектурных изменений.
Импеданс SLA - Услуги измеряются на определенных базовых единицах, которые являются общими для поставщиков облачных услуг. Однако существуют небольшие различия в единицах измерения и параметрах, используемых для выставления счетов. Например, AWS будет взимать плату за неструктурированное хранилище в зависимости от региона, размера, объема запросов, объема передачи (выхода) инфраструктуры AWS в единицах ГБ. Принимая во внимание, что Azure будет взимать плату за то же неструктурированное хранилище в зависимости от региона, размера, объема запросов, объема исходящих данных из инфраструктуры Azure и выбранной опции избыточности данных. Таким образом, во время миграции вам нужно будет измерить такие различия SLA и выбрать правильный тарифный план на целевой платформе. Если вы переходите с Azure на AWS и имеете SLA на основе избыточности, вам, возможно, придется платить больше или приносить другие услуги в AWS, чтобы обеспечить непрерывность своих предложений услуг.
Инструменты и импеданс API - у поставщика облачных услуг очень разнообразная поддержка программируемых интерфейсов. Но они не должны быть похожими между двумя из них. Протокол связи REST, стандарты JSON / XML могут спасти нас. Очень вероятно, что те, кто был в облаке в течение некоторого времени, создали бы инструменты, которые помогают управлять жизненным циклом сервисов в облаке. Миграция такого клиента с его набором инструментов потребует рассмотрения усилий, которые вам понадобятся для замены инструментов, предлагаемых поставщиком услуг, и усилий, направленных на изменение любого проприетарного инструмента, который был бы создан с использованием API поставщика услуг.
В заданиях по миграции я использую аналогию с операционной системой, чтобы объяснить (мне и клиенту) проблемы. то есть в начале была ОС, в которой у каждой были особые возможности, но им не хватало совместимости друг с другом, а также для обмена и обмена данными друг с другом. Это повлияло на бизнес, который начал понимать эту проблему. Постепенно стандарты развивались, и теперь мы могли обмениваться данными и заставлять ОС общаться друг с другом (виртуализация). Рассматривайте облачную платформу как ОС, а затем дайте ей некоторое время (не знаю, сколько), чтобы она преодолела такой импеданс. До этого момента мы столкнулись бы с трудностями (которые, безусловно, можно было бы преодолеть в значительной степени) при переходе от одного поставщика услуг к другому с использованием инструментов, подобных тому, который вы перечислили, и еще немногих, а также услуг консультантов для решения весьма специфических проблем миграции в бизнес-контексте.
TL;DR: построить для наименьшего общего знаменателя среди поставщиков IaaS.
Простым ответом на это является использование поставщика IaaS строго только для его инфраструктуры, а не для их "услуг".
Хороший способ сделать это может состоять в том, чтобы делать в облачном приложении только те вещи, которые позволяет вам terraform. Интересно, что такие инструменты, как Docker, Kubernetes, значительно упрощают приложения, не зависящие от инфраструктуры, и наблюдается феноменальный рост числа решений, которые помогут вам в этом. Приложения, основанные на Openshift, https://www.cloudfoundry.org/ и т. Д., Помогают нормализовать работу поставщиков облачных вычислений. Появляются и более мелкие, более удобные для разработчиков инструменты, использующие k8s/docker для создания приложений, независимых от поставщиков: deis, dokku, hasura. Отказ от ответственности: я работаю в Хасуре.
Чтобы ответить на ваши вопросы конкретно:
Предположим, у меня есть система на основе Microsoft Cloud с SQL Azure в качестве базы данных. Завтра я хотел бы перенести его на другого провайдера облачных вычислений, бывшего Amazon.
Нет, если вы сделаете это, вы не сможете быть "мультиоблаком".
Находимся ли мы в состоянии, когда у нас есть плавный подход к переносу данных приложения от одного поставщика облачных услуг к другому.
Мы еще не совсем там. Но мы определенно движемся к этому. Смотрите подробности, которыми я поделился выше.