多云的定义之——工作负载可移植性

作为多云定义系列的第三篇，本文将继续从工作负载可移植性的角度进行解析。

1、工作负载可移植性

多云工作负载可移植性意味着企业可以将工作负载从一个云或本地数据中心移动到另一个。核心思想类似于“编写一次，随处运行。” 不过，我们很难做到为一个云编写一次应用程序之后，仍然能够在不修改代码的情况下在其他云上运行该应用程序。

不同的供应商具有不同的 API、语义、功能、语法和其他细微差别，这使得工作负载的可移植性在现实中成为最具挑战性的多云可移植性形式之一。

实现工作负载的可移植性并不像一次写入到处运行那么简单，但它是可行的。就其本质而言，它更复杂，因为它是数据和工作流可移植性的超集，这意味着要使这种类型的可移植性发挥作用，这两者都是必需的。出于合规和监管原因，公司需要实施工作负载可移植性，以实现多个云供应商之间的故障转移。

工作负载可移植性分为三种类型：

2、启用完整的工作负载可移植性

完全工作负载可移植性是最难实现的类型。绝大多数应用程序都需要它们的数据和其他上游依赖项。如果企业的数据库不附带它，那么移动其 Web 服务器是没有帮助的。

完全工作负载可移植性意味着将应用程序及其所有依赖项和数据从一个环境完全迁移到另一个环境。

这些依赖项包括作为处理和请求一部分的上游 API。如果企业必须回调工作负载离开的环境，出于带宽成本和延迟的考虑，通常会使迁移它的目的落空。

如果在应用程序和平台的设计阶段就内置了完整的工作负载可移植性，这种情况是最好的。为了实现完全的工作负载可移植性，内部服务架构必须具有相同要求。如果应用程序可以移动但上游依赖项无法移动，也将无济于事。

企业还需要确定要使用哪种类型的数据可移植性，并进行权衡：

持续复制：定期跨环境复制数据，这会持续增加额外的运营成本。

Break-Glass的可移植性：需要迁移时跨环境传输数据，每次需要支付大笔费用。

对频率的决定需要与打算迁移工作负载的频率的决定相同，这取决于企业是计划频繁移植工作负载（在这种情况下，使用连续复制）还是在极少数情况下移植（在这种情况下，Break-Glass可能会起作用）。

企业也应尽量避免云专有服务，因为它会将企业锁定在自身的环境中。虽然某些服务在正确的抽象下是可行的，但涉及的专有服务越多，可移植性就越难。

3、启用部分工作负载可移植性

在某些应用程序不一定需要将其数据放在同一环境中的情况下，工作负载可移植性会更加合理。无状态或前端服务就是一个很好的例子。对于这些类型的服务，企业可以将数据留在原始环境中，但应用程序仍然可以工作。

但是，就像在这个场景中一样，当企业为每个请求通过网络移动数据时，通常会有成本和性能损失，这包括：

昂贵的带宽：一个位置内的带宽很便宜，但在该位置之外连接的带宽很昂贵。

高延迟：光速是固定的，因此网络上的流量总是比同一位置内的流量慢。

在考虑这种形式的工作负载可移植性之前，企业也需要考虑其潜在的计算成本节省是否会被更高的带宽成本和性能下降所抵消。

另一个需要考虑的因素是，具有复杂缓存和数据管理的专用架构将期望低延迟，因此，部分工作负载迁移将导致用户体验下降。

为了实现部分工作负载的可移植性，企业应用程序必须是专门构建的，以便知道它正在通过网络进行持续的请求。多层缓存和使用部分或“热”数据子集可以缓解一些挑战。运营和应用程序团队必须在架构和流程上进行深度协调，这是另一个需要考虑的重要挑战。

4、启用无数据工作负载可移植性

如果企业的应用程序没有数据可以移动怎么办？该示例是无状态应用程序或具有大部分静态数据集的应用程序。这种情况可能是工作负载可移植性最简单、最具成本效益的用例。

对于无状态应用程序，几乎没有成本，而对于静态或很少更改的数据集，企业需要付出成本来移动它一次，如果不是大量数据的话，也会很便宜。

以下是一些无数据工作负载可移植性的例子：

1）金融建模应用程序：这些应用程序通常使用各种市场的历史数据集。如果企业在许多位置复制了该数据集，并且数据更新得足够频繁，那么移动应用程序工作负载和集成该数据集难度不高。

2）计算密集型、大规模模拟：科学高性能计算 (HPC) 任务（如蛋白质折叠模拟）通常依赖于相对较小的数据集，这也使得工作负载的可移植性更简单。

3）测试和登台环境：尽管这些环境可能有数据库，但由于它们有模拟数据或静态副本，所以企业不必担心这些数据是否不同步。

这些例子也是成本套利的绝佳选择，特别是在现货定价方面。例如大型对冲基金就通过这种方式在其财务模拟中节省了资金。

这种类型的工作负载可移植性不需要太多的数据可移植性，而是使企业专注于工作流可移植性，这可以通过跨多个云和混合云部署的自动化工具来实现。

5、对冲锁定是有害的

当企业从工作负载可移植性的角度对多云产生需求时，其主要目的是对冲锁定，但这可能并不值得。

主要挑战是：

数据和工作流的可移植性都是必需的：应用程序受其数据和上游依赖项的约束。如果他们不能轻松地与其应用程序同步移动，那么企业的工作负载也不能轻松地移动。

企业的应用程序是有限的：为了构建工作负载的可移植性，应用程序需要设计为对云服务的有限访问，这可能会将其锁定在一个云中。虽然这可以防止锁定，但企业会失去许多高级服务，例如本机日志记录或特定的无服务器平台。

在有些情况下，更好的策略是为工作负载锁定和目的 - 在最适合的平台上建立应用程序。建立全或部分工作负载可移植性可以将所选平台的实用性降到最低。大多数用例和企业来说，这是不切实际的，并且在许多情况下难以实现。

无数据工作负载可移植性是三种工作负载可移植性类型中最现实的选择。当企业的应用程序只需要一些基本的计算能力而不需要任何云供应商的独特功能时，它可以在更大规模的云使用中节省一些费用。