基于云的解决方案 - 数据迁移挑战？

Question

我对基于云的系统有疑问。基本指导原则是“按使用付费”，“作为服务的软件”或“基础设施作为服务”。这些是服务提供商的多种产品。

假设我有一个基于Microsoft Cloud的系统，其中SQL Azure作为其数据库。明天我想将它移植到前亚马逊的另一个云提供商。

我们是否处于一种状态，我们采用无缝迁移方法将应用程序数据从一个基于云的服务提供商转移到另一个服务提供商。

我的问题更侧重于长期如何在云中管理应用程序。

Answer 1

找到一篇回答我的问题的文章

5次代价高昂的云迁移错误 - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY

Answer 2

我将您的问题视为基于云托管的数据构建的解决方案的可移植性。这是迄今为止的一个具有挑战性的问题。没有标准指导可移植性要求，但确定有工具/服务可以帮助您克服缺乏可移植性标准。

我在这种迁移中考虑过的几点（需要注意的挑战）是 -

1. 服务提供阻抗 - 云提供商之间的服务提供由竞争驱动，并由标准指导。例如AWS IAM没有直接映射到Azure Active Directory。虽然您可以使用SAML标准联合它们。如果您正在为想要从AWS迁移到Azure的客户（仅为了对话）工作，那么没有Out of Box解决方案，您需要为此构建一个定制工具。反过来（Azure AD - > AWS），如果不是像Paa那样至少可以作为IaaS。安全的粒度（使用策略可以在AWS中保护对象，Azure具有SAS并且需要定制的SAS提供商为您提供类似的功能），云服务提供商之间提供了最大的安全挑战。服务阻抗也可能以Azure的形式表现出来，你可以拥有不同类型的Blob - Page，Append，Block。但是，在AWS中，S3存储桶对象没有这样的类别。现在，如果您构建应用程序逻辑的想法是在Azure中假设一个Append blob，现在您要将应用程序迁移到AWS，则需要编写逻辑来下载对象，添加所需的数据然后上传新的对象以及删除现有对象。这样的变化有时可能会带来架构变化的后果。

2. SLA阻抗 - 在云服务提供商之间通用的某些基本单位上计量服务。但是，用于向您收费的测量单位和参数存在细微差别。例如AWS将根据 - 区域，大小，请求量，AWS基础架构的数据传输量（出口）以GB为单位对非结构化存储进行收费。然而，Azure将根据 - 区域，大小，请求量，Azure基础上的数据出口量以及您选择的数据冗余选项对相同的非结构化存储收费。因此，在迁移时，您需要测量此类SLA差异并在目标平台中选择正确的服务计划。如果您要从Azure迁移到AWS并且现在具有基于冗余的SLA，您可能需要支付更多费用或在AWS中提供其他服务以保持服务产品的连续性。

3. 工具＆amp; API阻抗 - 云服务提供商对可编程接口提供了非常多样化的支持。但他们两个之间不一定相似。 REST通信协议，JSON / XML标准可以拯救我们。对于那些已经在云中工作一段时间的人来说，很可能已经建立了有助于管理云服务生命周期的工具。使用他们的工具集迁移此类客户需要考虑更换服务提供商提供的工具所需的工作量以及更改使用API​​服务提供商构建的任何专有工具的工作量。

在迁移任务中，我使用操作系统类比来解释（我自己和客户）的挑战。即在开始时OS中每个都具有特殊功能，但它们都缺乏相互兼容并相互通信和交换数据。受此影响的业务开始实现这一挑战。缓慢的标准演变，现在我们可以交换数据并使操作系统相互通信（虚拟化）。将云平台视为操作系统，然后给它一些时间（不知道多少）来克服这种阻抗。到那时，我们将面临挑战（当然可以在很大程度上克服这些挑战），从一个服务提供商转移到另一个服务提供商，使用您列出的工具和更少的工具以及顾问服务来解决业务环境中非常具体的迁移挑战。

Answer 3

以下所有内容均由合适的供应商解决。 首先，云迁移的主要风险是数据损坏 - 异常或冗余或重复数据，或缺少先前存在的数据 - 因为源和源之间可能缺乏最大同步而发生。目标云。 其次，存在语义风险 - 没有数据丢失或损坏，迁移被认为是成功的，但有时遗留列和目标列的含义具有相同含义，但它们的测量不同，数据的含义完全不同。 对我来说，这是两个主要问题，因为我过去经历过一个不成功的供应商。云迁移适当的服务并不便宜，因此我强烈建议您选择正确的选择。我已经改为cloudendure，我对它们作为云供应商感到满意。再次，不是廉价的服务 - 但我相信，如果你把钱放进去，你应该得到最好的。

Answer 4

TL; DR：构建IaaS提供商的最低标准。

这样做的简单答案是严格仅将IaaS提供商用于其基础设施，而不是用于他们的“服务”。

执行此操作的一种好方法可能是只在您的云应用程序中执行terraform允许您执行的操作。有趣的是，像Docker，Kubernetes这样的工具使基础架构无关的应用程序变得非常容易，并且帮助您实现此目的的解决方案数量显着增加。基于Openshift，cloudfoundry等构建的应用程序可帮助您跨云供应商进行规范化。还有更小的开发人员友好工具，使用k8s / docker构建与供应商无关的应用程序：deis，dokku，hasura。免责声明：我在Hasura工作。

具体回答您的问题：

  

假设我有一个基于Microsoft Cloud的系统，其中包含SQL Azure   数据库。明天我想把它移植到另一个云提供商   前亚马逊。

不，如果你这样做，你就不能成为“多云”。

  

我们是否处于无缝迁移方式的状态   将应用程序数据从一个基于云的服务提供商移动到   另一个。

我们还没有完全在那里。但我们肯定会朝那个方向发展。请参阅我上面分享的详细信息。