应用程序迁移、可移植性和移动性是相似但不同的概念。以下是它们之间的区别。
译自 Unleashing the Power of Kubernetes Application Mobility 。
在我之前为 The New Stack 撰写的一篇文章中，我讨论了云原生应用程序可移植性的挑战和益处。
可移植的应用程序对于热备份、多云负载均衡、将应用程序部署到新的环境以及出于商业原因从一个云切换到另一个云都很有好处。
但是，这种可移植性很难实现，因为 Kubernetes 应用程序由短暂的微服务、配置和数据组成。Kubernetes 也以一种抽象的方式处理状态信息，因为微服务通常是无状态的。
因此，理解 Kubernetes 应用程序移动性的价值非常重要。乍一看，应用程序移动性似乎与应用程序可移植性同义，尤其是在 Kubernetes 环境中。
但是，如果我们仔细看，重要的区别在于，这个区别阐明了组织如何从这个重要功能中提取最大价值。
应用程序迁移、可移植性和移动性是相似但不同的概念。以下是它们之间的区别。
- 应用程序迁移是指将源代码或应用程序二进制文件从一个环境迁移到另一个环境，例如，从虚拟机实例迁移到一个或多个容器。
- 云原生应用程序的可移植性侧重于在不同的 Kubernetes 实例上运行的基于微服务的工作负载的移动。
- 本文重点关注的云原生应用程序移动性，是指确保与微服务交互的消费应用程序可以在软件底层位置改变时继续无缝运行，即使工作负载从一个环境迁移到另一个环境。
应用程序可移植性支持应用程序移动性，但对其既不是必需的也不是足够的。
应用程序移动性的许多好处包括云服务提供商的选择、收入分析和风险管理。 对于 Kubernetes，应用程序移动性是一个进行近实时分析和性能评估的有价值的数据管理工具。
随着客户使用推动对应用程序的需求，应用程序所有者可以针对每个应用程序和风险管理系统优化云环境组合。
应用程序移动性的影响是其对短期和长期计划以及生命周期内跨 Kubernetes 应用程序组合保护所需的战略业务价值。
对于 Kubernetes 数据管理平台供应商 Kasten by Veeam，应用程序移动性满足四个重要用例：跨云可移植性、集群升级测试、多云平衡以及通过生成数据副本进行的数据管理。
Kubernetes 应用程序的跨云可移植性是一个应用程序可移植性支持应用程序移动性的明确示例，其中应用程序移动性在将应用程序移植到其他云或升级的集群时为消费应用程序提供了无缝的行为。
在 Kubernetes 中，容器化的应用程序独立于基础设施。这种独立性允许跨多种平台传输，包括本地、公有云、私有云和混合云基础设施。
Kubernetes 应用程序可移植性的关键指标是平均恢复时间(MTTR)——组织将应用程序从一个集群恢复到另一个集群的速度有多快。
集群升级测试对于希望通过可预测地将应用程序迁移到升级后的集群来管理 Kubernetes 更改的业务所有者至关重要。 在正常操作过程中捕获和解决与升级相关的问题的能力是必不可少的。
集群升级测试的关键指标是在问题扩大之前捕获重要变更的能力，以便组织可以解决这些问题，无论是通过恢复单个组件还是整个应用程序。
多云负载平衡是一个不需要调用可移植性的应用程序移动性示例，因为 API 网关指导流量并在各个云实例之间处理负载平衡。 事实上，API 网关支持跨公有云和私有云进行负载平衡，并使组织能够根据现有的业务政策管理应用程序。
多云负载平衡的关键指标集中在实时管理负载平衡过程中的成本、风险和性能。
最后，数据管理利用可移植性来支持应用程序的移动性。组织可能会使用生产数据的副本来测量应用程序性能、数据使用或其他参数。
这种活动依赖于跨实时和复制数据的无缝行为，该行为利用应用程序移动性将数据旋转到脱机副本，用于数据分析和数据保护，就像应用程序或服务开始生产时一样。
数据管理的关键指标包括测量实时应用程序和服务数据性能、数据使用情况和当前应用程序数据集的其他特征。
Kubernetes 应用程序可移植性和移动性之间的区别很细微，但很重要。
可移植性在本质上是移动性下面的一层抽象，因为它侧重于应用程序组件或工作负载的物理移动。
相比之下，应用程序移动性侧重于使应用程序资源的消费位置独立，允许其底层资源以及消费者自由移动。
鉴于 Kubernetes 是基础设施软件，这样的消费者本身就是可能直接或间接影响用户体验的应用程序。 此外，运行在该基础设施上的工作负载本身就是一组短暂和持久元素的抽象。
工作负载可以移动，或者它们可以同时在多个地方运行，或者它们可以在一个地方然后在另一个地方运行，这取决于特定的用例。 当消费应用程序对此一无所知时，组织就可以说他们已经实现了应用程序的移动性。