共计 2354 个字符，预计需要花费 6 分钟才能阅读完成。
作为多云定义系列的第三篇，本文将持续从工作负载可移植性的角度进行解析。
1、工作负载可移植性
多云工作负载可移植性意味着企业能够将工作负载从一个云或本地数据中心挪动到另一个。核心思想相似于“编写一次，随处运行。”不过，咱们很难做到为一个云编写一次应用程序之后，依然可能在不批改代码的状况下在其余云上运行该应用程序。
不同的供应商具备不同的 API、语义、性能、语法和其余细微差别，这使得工作负载的可移植性在事实中成为最具挑战性的多云可移植性模式之一。
实现工作负载的可移植性并不像一次写入到处运行那么简略，但它是可行的。就其本质而言，它更简单，因为它是数据和工作流可移植性的超集，这意味着要使这种类型的可移植性发挥作用，这两者都是必须的。出于合规和监管起因，公司须要施行工作负载可移植性，以实现多个云供应商之间的故障转移。
工作负载可移植性分为三种类型：
- 残缺的工作负载可移植性
- 局部工作负载可移植性
- 无数据工作负载可移植性
2、启用残缺的工作负载可移植性
齐全工作负载可移植性是最难实现的类型。绝大多数应用程序都须要它们的数据和其余上游依赖项。如果企业的数据库不附带它，那么挪动其 Web 服务器是没有帮忙的。
齐全工作负载可移植性意味着将应用程序及其所有依赖项和数据从一个环境齐全迁徙到另一个环境。
这些依赖项包含作为解决和申请一部分的上游 API。如果企业必须回调工作负载来到的环境，出于带宽老本和提早的思考，通常会使迁徙它的目标落空。
如果在应用程序和平台的设计阶段就内置了残缺的工作负载可移植性，这种状况是最好的。为了实现齐全的工作负载可移植性，外部服务架构必须具备雷同要求。如果应用程序能够挪动但上游依赖项无奈挪动，也将杯水车薪。
企业还须要确定要应用哪种类型的数据可移植性，并进行衡量：
继续复制：定期跨环境复制数据，这会继续减少额定的经营老本。
Break-Glass 的可移植性：须要迁徙时跨环境传输数据，每次须要领取大笔费用。
对频率的决定须要与打算迁徙工作负载的频率的决定雷同，这取决于企业是打算频繁移植工作负载（在这种状况下，应用间断复制）还是在极少数状况下移植（在这种状况下，Break-Glass 可能会起作用）。
企业也应尽量避免云专有服务，因为它会将企业锁定在本身的环境中。尽管某些服务在正确的形象下是可行的，但波及的专有服务越多，可移植性就越难。
3、启用局部工作负载可移植性
在某些应用程序不肯定须要将其数据放在同一环境中的状况下，工作负载可移植性会更加正当。无状态或前端服务就是一个很好的例子。对于这些类型的服务，企业能够将数据留在原始环境中，但应用程序依然能够工作。
然而，就像在这个场景中一样，当企业为每个申请通过网络挪动数据时，通常会有老本和性能损失，这包含：
低廉的带宽：一个地位内的带宽很便宜，但在该地位之外连贯的带宽很低廉。
高提早：光速是固定的，因而网络上的流量总是比同一地位内的流量慢。
在思考这种模式的工作负载可移植性之前，企业也须要思考其潜在的计算成本节俭是否会被更高的带宽老本和性能降落所对消。
另一个须要思考的因素是，具备简单缓存和数据管理的专用架构将冀望低提早，因而，局部工作负载迁徙将导致用户体验降落。
为了实现局部工作负载的可移植性，企业应用程序必须是专门构建的，以便晓得它正在通过网络进行继续的申请。多层缓存和应用局部或“热”数据子集能够缓解一些挑战。经营和应用程序团队必须在架构和流程上进行深度协调，这是另一个须要思考的重要挑战。
4、启用无数据工作负载可移植性
如果企业的应用程序没有数据能够挪动怎么办？该示例是无状态应用程序或具备大部分静态数据集的应用程序。这种状况可能是工作负载可移植性最简略、最具老本效益的用例。
对于无状态应用程序，简直没有老本，而对于动态或很少更改的数据集，企业须要付出老本来挪动它一次，如果不是大量数据的话，也会很便宜。
以下是一些无数据工作负载可移植性的例子：
1）金融建模应用程序：这些应用程序通常应用各种市场的历史数据集。如果企业在许多地位复制了该数据集，并且数据更新得足够频繁，那么挪动应用程序工作负载和集成该数据集难度不高。
2）计算密集型、大规模模仿：迷信高性能计算 (HPC) 工作（如蛋白质折叠模仿）通常依赖于绝对较小的数据集，这也使得工作负载的可移植性更简略。
3）测试和登台环境：只管这些环境可能有数据库，但因为它们有模仿数据或动态正本，所以企业不用放心这些数据是否不同步。
这些例子也是老本套利的绝佳抉择，特地是在现货定价方面。例如大型对冲基金就通过这种形式在其财务模仿中节俭了资金。
这种类型的工作负载可移植性不须要太多的数据可移植性，而是使企业专一于工作流可移植性，这能够通过跨多个云和混合云部署的自动化工具来实现。
5、对冲锁定是无害的
当企业从工作负载可移植性的角度对多云产生需要时，其次要目标是对冲锁定，但这可能并不值得。
次要挑战是：
数据和工作流的可移植性都是必须的：应用程序受其数据和上游依赖项的束缚。如果他们不能轻松地与其应用程序同步挪动，那么企业的工作负载也不能轻松地挪动。
企业的应用程序是无限的：为了构建工作负载的可移植性，应用程序须要设计为对云服务的无限拜访，这可能会将其锁定在一个云中。尽管这能够避免锁定，但企业会失去许多高级服务，例如本机日志记录或特定的无服务器平台。
在有些状况下，更好的策略是为工作负载锁定和目标 – 在最适宜的平台上建设应用程序。建设全或局部工作负载可移植性能够将所选平台的实用性降到最低。大多数用例和企业来说，这是不切实际的，并且在许多状况下难以实现。
无数据工作负载可移植性是三种工作负载可移植性类型中最事实的抉择。当企业的应用程序只须要一些根本的计算能力而不须要任何云供应商的独特性能时，它能够在更大规模的云应用中节俭一些费用。
