我对基于云的系统有疑问。基本指导原则是“按使用付费”，“软件即服务”或“基础架构即服务”。这些是服务提供商提供的多种产品。基于云的解决方案 - 数据迁移面临的挑战？
假设我有一个以SQL Azure作为数据库的基于Microsoft云的系统。明天，我想将它移植到另一个前亚马逊云供应商。
我们是否处于一种无缝迁移方法，用于将应用程序数据从一个基于云的服务提供商转移到另一个。
从长远的角度来看，我的问题更侧重于如何在云中管理应用程序。
发现了回答我的问题
5个昂贵的云迁移错误的文章 - http://www.privatecloud.com/blog/?fbid=xEEiydK0SQY
我看了你的问题，因为便携性在云中托管的数据构建的解决方案的。迄今为止，这是一个具有挑战性的问题。没有指导可移植性要求的标准，但确定有工具/服务可帮助您克服缺乏可移植性的标准。
几个点（挑战注意），我在这样的迁移已经考虑的是 -
服务提供阻抗 - 云供应商之间的服务产品是通过竞争带动，由标准。例如AWS IAM没有直接映射到Azure Active Directory。尽管您可以使用SAML标准联合他们。如果您正在为想从AWS迁移到Azure的客户工作（仅用于交谈），没有Out of Box解决方案，您需要为此构建一个定制工具。而反过来（Azure AD - > AWS）如果不是PaaS，至少可以作为IaaS。云服务提供商之间的安全粒度（使用策略在AWS中受保护的对象，Azure具有SAS并且需要定制构建的SAS提供商为您提供类似的功能）会带来最大的安全挑战。服务阻抗也可以以Azure的形式表现出来，您可以拥有不同类型的Blob - Page，Append，Block。但是，在AWS中，S3存储桶对象不存在此类别。现在，如果您已经构建了适用于Azure中的Append blob的应用程序逻辑，现在您正在将应用程序迁移到AWS，则需要编写逻辑来下载对象，添加所需的数据，然后上载新的对象以及删除现有对象。这样的变化有时可能会带来架构变化的后果。
SLA阻抗 - 服务是在云服务提供商常见的某些基本单元上计量的。但是，用于计费的计量单位和参数存在细微差异。例如AWS将根据 - 区域，大小，请求数量，以GB为单位的AWS基础架构的数据传输出（出）量来收取非结构化存储。而Azure将根据 - 区域，大小，请求量，来自Azure infra的数据出口量以及您将选择的数据冗余选项收取相同的非结构化存储。因此，在您迁移时，您需要衡量此类SLA差异，并在目标平台中选择正确的服务计划。如果您正在从Azure迁移到AWS并现在拥有基于SLA的冗余，则您可能必须支付更多费用或在AWS中引入其他服务才能保持服务产品的连续性。
工具& API阻抗 - 云服务提供商对可编程接口的支持非常多样化。但他们两人之间不需要相似。 REST通信协议，JSON/XML标准可以拯救我们。那些已经在云端服务一段时间的人很可能会建立一些工具来帮助管理云服务的生命周期。使用他们的工具集迁移这样的客户需要考虑替换服务提供商提供的工具所需的努力，以及努力更改使用服务提供商的API构建的任何专有工具的努力。
在迁移作业中，我使用操作系统类比来解释（我和客户）面临的挑战。即在一开始就有操作系统，每个操作系统都有特殊的功能，但它们都不兼容，互相通信和交换数据。这影响了企业开始实现这一挑战。缓慢的标准发展，现在我们可以交换数据并使操作系统彼此交流（虚拟化）。考虑将云平台作为操作系统，然后给它一些时间（不知道有多少）来克服这种阻抗。到那时，我们将面临从一个服务提供商转移到另一个服务提供商所面临的挑战（当然可以克服很大程度的问题），使用类似您所列的工具和更多的咨询服务以及服务来解决业务环境中非常具体的迁移挑战。
以下所有内容均由合适的供应商解决。 首先，云迁移的主要风险是数据损坏 - 异常或冗余或重复的数据，或缺少以前存在的数据 - 发生的原因是目标云之间可能缺少最大同步。 其次，存在语义风险 - 没有数据丢失或损坏，迁移被认为是成功的，但有时遗留列和目标列的含义具有相同的含义，但是它们的测量不同并且数据的含义完全不同。 对我来说，那些是两个主要问题，因为我在过去遇到过一个不成功的供应商。云迁移适当的服务并不便宜，因此我强烈建议为您选择正确的选择。我已经变成了虚拟商品，我对他们作为云供应商感到满意。再次，不是一项便宜的服务 - 但我相信如果你投入资金，你应该得到最好的。
TL; DR：构建跨IaaS提供者的最低公共标准。
这样做的简单答案是严格地将IaaS提供程序仅用于基础架构，而不是用于其“服务”。
做到这一点的一个好方法可能只是在您的云应用程序中执行terraform允许您执行的操作。有趣的是，像Docker，Kubernetes这样的工具使基础架构不可知的应用程序变得更加容易，并且帮助您实现这一目标的解决方案数量显着增加。构建于Openshift，cloudfoundry等上的应用程序可帮助您在各个云供应商之间进行标准化。还有更多的开发人员友好型工具也在涌现，它们使用k8s/docker来构建供应商不可知的应用程序：deis,dokku,hasura。免责声明：我在Hasura工作。
具体回答你的问题：
假设我有一个SQL Azure的微软云计算为基础的系统作为其 数据库。明天我想将它移植到另一个云提供商 ex-Amazon。
不，如果你这样做，你不能成为“多云”。
我们是在我们有一个无缝的迁移方法为 从一个基于云的服务提供商的应用数据移动到另一个 的状态。
我们还没有完全存在。但我们正在朝着这个方向前进。请参阅我上面分享的细节。