0

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

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

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

从长远来看，我的问题更侧重于如何在云中管理应用程序。

4

4 回答 4

0

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

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

于 2011-10-08T05:51:56.877 回答
0

TL;DR：为跨 IaaS 提供商的最低公分母而构建。

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

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

具体回答您的问题：

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

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

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

我们还没有完全做到。但我们肯定会朝着那个方向前进。参考我上面分享的细节。

于 2017-03-16T12:50:17.077 回答
0

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

于 2016-11-29T11:42:46.053 回答
0

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

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

  1. 服务提供阻抗- 云供应商之间的服务提供由竞争驱动并由标准指导。例如，AWS IAM 没有直接映射到 Azure Active Directory。尽管您可以使用 SAML 标准联合它们。如果您正在为想要从 AWS 迁移到 Azure 的客户工作（只是为了交谈），那么没有现成的解决方案，您需要为此构建一个量身定制的工具。而相反的（Azure AD -> AWS）如果不是 PaaS 至少是 IaaS 也是可能的。云服务提供商之间的安全粒度（对象可以在 AWS 中使用策略进行保护，Azure 有 SAS 并且需要定制构建的 SAS 提供商为您提供类似的功能）提供了最大的安全挑战。服务阻抗也可以表现为在 Azure 中你可以有不同类型的 Blob - 页面，追加，阻止。但是，在 AWS 中，S3 存储桶对象没有此类类别。现在，如果您已经围绕假设 Azure 中的 Append blob 的想法构建了应用程序逻辑，并且现在您正在将应用程序迁移到 AWS，您将需要编写逻辑来下载对象、添加所需的数据，然后上传新的对象以及删除现有对象。这样，更改有时可能会承担架构更改的后果。

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

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

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

于 2016-11-02T07:02:29.653 回答