组织希望从云原生应用程序的可移植性中获得什么？为什么它如此困难？最重要的是，如何正确实现它？
译自 Realizing the Dream of Cloud Native Application Portability 。
将应用程序从一个地方迁移到另一个地方看起来很简单：将其压缩打包，传送过去，然后解压缩。这有什么难的？
这种简单化的思维可能描述了虚拟机(VM)时代的应用程序可移植性，当时镜像整个卷可以捕获迁移应用程序所需的一切。
然而，在云原生世界里，情况并非如此简单。
组织希望从云原生应用程序的可移植性中获得什么？为什么它如此困难？最重要的是，如何正确实现它?
我们为什么需要云原生应用程序的可移植性?
有几个原因要迁移云原生应用程序:
- 热备份。组织可能希望在两个不同的云中运行云原生应用程序的实时副本，或者可能在本地和云中，以便在发生故障时能够快速在两者之间切换流量。
- 多云负载平衡。如果一个组织要运行热备份，它也可以在应用程序实例之间分割实时流量。只要应用程序实例在独立的云中运行，这种方法也可以避免“把所有鸡蛋放在一个篮子里”的问题。
- 部署到新的环境。在某些情况下，生产部署遵循 GitOps 实践，基本上以持续的、分阶段的方式对其进行更新。在其他情况下，组织可能希望作为一个单元将整个应用程序从开发环境移至临时环境或从临时环境移至生产环境(或者可能移至其他环境，如金丝雀或 A/B 测试部署)。
- 出于商业原因切换云。许多组织从一个云迁移到另一个云，以节省成本，或者可能是由于与提供商发生纠纷。当在某些时候本地更具成本效益时，其他组织会从云迁移到本地。
为什么云原生应用程序的可移植性如此困难？
仔细看看什么是云原生应用程序，很快就会遇到许多挑战:
- 在 Kubernetes 上运行的应用程序不是单体的。它们由短暂的微服务以及配置和数据组成。此外，这些元素可能不全部驻留在同一个虚拟机上。移动它们就像用叉子移动沙子。
- 微服务通常是无状态的，而 Kubernetes 以抽象的方式处理持久化数据。与数据库连接是显式的三层应用程序不同，云原生应用程序通过抽象连接的运算符访问持久化数据和其他状态信息。了解特定时间哪些数据属于哪个应用程序可能很棘手。
- 快照通常是短暂的。创建卷级快照是加速卷级迁移的常用而通用的方法。虽然 Kubernetes 支持这种快照，但它们通常是短暂的，因此不能保证应用程序一致的交付。
如何实现云原生应用程序的可移植性
幸运的是，来自 Kasten by Veeam 等供应商的现代数据保护可以解决上述挑战。Kasten 的解决方案如下:
- 自动发现和迁移所有 Kubernetes 组件、配置和数据。采用以应用程序为中心的方法，而不是以卷为中心的方法，该方法考虑了Kubernetes的分布式和短暂性质。
- 支持跨命名空间、集群、区域、云和 Kubernetes 发行版的可移植性。从理论上讲，Kubernetes在一个位置的运行方式与另一个位置相同。但是，在实践中，云提供商和Kubernetes发行版之间存在许多细微差异。抽象和解决这些差异是必不可少的。
- 强调大规模的数据可移植性。 对于应用程序一致的云原生可移植性，必不可少的是恢复、克隆和升级数据以及将数据从一个位置迁移到另一个位置。 此外，重要的是大规模处理这些复杂问题。
- 云原生应用程序的可移植性功能应该是其数据保护专业知识的延伸。 应用程序和数据的备份与恢复是数据保护的核心。 因此，有可能将计划中的应用程序移动视为突然且意外故障后应用程序恢复的更难的问题的特例。
Intellyx 的看法
业务连续性是成功的应用程序可移植性的关键，就像它对应用程序备份和恢复一样。 在某些情况下，确实有必要在移动应用程序之前将其关闭。 在其他情况下，在迁移完成之前，应用程序不会接收实时流量。
但在更常见的情况下，组织需要能够在应用程序运行时移动它，而活动工作负载当前正在处理事务，并且基础数据正处于流动状态。
这种情况下的应用程序可移植性就像在通电时重新布线房屋 - 一个错误的举动你就死定了。
市场上大多数云原生应用程序可移植性方法本质上是 Day Zero 技术 — 在任何应用程序上线之前完成应用程序迁移。
另一方面，Kasten 通过构建其技术来处理正在运行的应用程序的备份和恢复，在这种情况下，跟踪进行中事务的状态非常重要。
反过来，这种功能对于大多数云原生应用程序可移植性场景至关重要，因为组织希望他们的云原生应用程序能够持续运行——不仅在一个虚拟机上，而且跨虚拟机和云，根据需要扩展。
换句话说，云原生应用程序的可移植性可以在没有触电风险的情况下成为 Day 2(全面生产) 的努力。
