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