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

Question

我有一个关于基于云的系统的问题。基本的指导原则是“按使用付费”、“软件即服务”或“基础设施即服务”。这些是由服务提供商提供的多个产品。

假设我有一个基于Microsoft Cloud的系统，使用SQL Azure作为其数据库。明天我想把它移植到除亚马逊之外的另一家云提供商。

我们是否处于这样一种状态，即我们拥有一种无缝迁移方法，可以将应用程序数据从一个基于云的服务提供商移动到另一个云服务提供商。

我的问题更多地集中在如何在云中管理应用程序的长期基础上。

Answer 1

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

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

Answer 2

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

我在这样的迁移中考虑的几个要点(需要注意的挑战)是-

1. Service提供阻抗-云提供商之间的服务提供由竞争驱动，并由标准指导。例如，AWS IAM没有直接映射到Azure Active Directory。尽管您可以使用SAML标准将它们联合起来。如果您正在为想要从AWS迁移到Azure的客户工作(只是为了交谈)，没有现成的解决方案，您将需要为此构建一个定制的工具。而相反的(Azure AD -> AWS)如果不是PaaS，至少是IaaS，也是可能的。云服务提供商之间的安全粒度(使用策略可以在AWS中保护对象，Azure具有SAS，并且需要定制的SAS提供商为您提供类似的功能)提供了最大的安全挑战。服务阻抗也可以表现为，比如说在Azure中，你可以有不同类型的Blob - Page，Append，Block。然而，在亚马逊网络服务中，S3存储桶对象没有这样的类别。现在，如果你已经围绕在Azure中假设一个Append blob的想法构建了你的应用程序逻辑，现在你正在将应用程序迁移到AWS，你将需要编写逻辑来下载对象，添加你想要的数据，然后在删除现有对象的同时上传新对象。这样的变化有时可能会承担架构changes.
2. SLA阻抗的后果-服务是在云服务提供商之间常见的某些基本单位上计量的。但是，用于向您计费的度量单位和参数存在细微的差异。例如，AWS将根据AWS基础设施的区域、大小、请求量、数据传出(传出)量(以GB为单位)对非结构化存储收费。然而，Azure将根据区域、大小、请求量、从Azure基础设施传出的数据量以及您将选择的数据冗余选项对相同的非结构化存储收费。因此，在迁移时，您需要衡量此类SLA差异，并在目标平台中选择正确的服务计划。如果你正在从Azure迁移到亚马逊网络服务，并且现在有了基于冗余的服务水平协议，你可能不得不支付更多的费用或者在亚马逊网络服务中引入其他服务来保持你的服务的连续性，offerings.
3. Tooling & API阻抗-云服务提供商对可编程接口有非常多样化的支持。但它们中的两个之间不必相似。REST通信协议、JSON / XML标准可以拯救我们。对于那些已经在云中工作了一段时间的人来说，很可能已经建立了帮助管理云中服务生命周期的工具。使用这些客户的工具集迁移这些客户需要考虑更换服务提供商提供的工具所需的工作量，以及更改使用服务提供商的API构建的任何专有工具的工作量。

在迁移任务中，我使用操作系统类比来解释(我自己和客户)面临的挑战。也就是说，在一开始，每个操作系统都有特殊的功能，但它们都缺乏相互兼容和相互通信和交换数据的能力。这影响了开始意识到这一挑战的企业。慢慢地，标准发展起来了，现在我们可以交换数据，让操作系统相互对话(虚拟化)。考虑云平台作为操作系统，然后给它一些时间(不知道多少)，让它克服这种阻力。在此之前，我们将面临从一个服务提供商转移到另一个服务提供商的挑战(这些挑战肯定可以在很大程度上克服)，需要使用您列出的工具和更多的咨询服务来解决业务环境中非常具体的迁移挑战。

Answer 3

以下所有问题都需要通过合适的供应商来解决。首先，云迁移中的主要风险是由于源云和目标云之间可能缺乏最大同步而发生的数据损坏-异常或冗余或重复数据，或先前存在的数据缺失。其次，存在语义风险-没有数据丢失或损坏，迁移被认为是成功的，但有时遗留列和目标列的含义相同，但它们的度量不同，数据的含义完全不同。对我来说，这是两个主要的问题，就像我过去在一个不成功的供应商那里经历过的那样。云迁移正确的服务并不便宜，因此我强烈建议您选择正确的选择。我已经改用cloudendure了，作为一个云供应商，我对他们很满意。再说一次，这不是一项廉价的服务--但我相信，如果你投入资金，你理应获得最好的服务。