云可移植性是构建可扩展、有弹性、云原生应用程序的一种策略。谈到云原生，通常也会暗含地考虑到云的可移植性。云原生是一种应用程序开发和部署架构方法，可最大限度利用云计算资源的弹性和敏捷性。然而，当团队开始使用单一云平台，并围绕这个平台的供应商所提供的专用工具和托管服务进行构建时，很快就会面临供应商锁定的局面。
延伸阅读，了解 Akamai cloud-computing
可移植的工作负载能在不同计算环境和基础设施平台上轻松迁移、部署和管理。借此，企业能够避免被供应商锁定，并保持云战略的灵活性。
如果从一开始就选择“云中立”的方法，并使用能与任何云平台相兼容的工具，我们就可以根据需求的变化灵活做出改变。可移植性战略还能让我们更深入地了解资源的使用方式和原因，并根据应用和业务需求选择不同的云平台，甚至在不同平台间转移。
设计云可移植性策略
如果你正在考虑云应用架构，那么可以通过以下五方面考虑着手，设计成功的可移植工作负载。
确定需求
实现可移植工作负载的第一步是客观地确定工作负载需求。我们可能经常会看到这样的情况：在进行最开始的这一步工作之前，主观臆断就已经污染了整个过程，因为人们的目光会被云提供商的诱人服务所吸引。因此，这里的重点是：在考虑云平台之前，就先确定需求范围。
这就好比采取一种简单的方法来了解满足最终成果所需的全部功能和特性，进而确定软件栈和依赖项，以及满足这些需求的其他组件。有了这样一个客观、简洁的视角，就好比通过广角镜头去观察云。这种方式才能更好地凸显能在任何云平台的核心云基础设施上运行的各种功能。
确定锁定点
无论应用程序仍处于构建或规划阶段，还是已经在云平台上开发和部署，都要对当前架构设计进行评估，以发现当前平台上使用的独有组件和服务。
如果已经确定了可能被供应商锁定的点，请花时间评估具体原因。首先请回答以下问题：
- 为了更快速地推出或缩短上市时间，是否选择，或至少考虑过某种解决方案？
- 解决方案是根据咨询结果确定的，还是基于与该平台上其他服务的支持/互操作性来决定的？
- 当时选择这个解决方案时的成本，和现在的成本相比有何变化？
回答完这些问题后，我们就可以开始规划理想的开源解决方案或其他可提供相同或类似功能的替代解决方案，评估实施所需的工作，并制定执行计划。如果在所有评估后，仍然决定坚持使用特定平台的服务，请确保自己还有退出策略。云计算供应商锁定有两种形式：架构锁定和运营锁定。围绕专有云服务深思熟虑制定的退出策略可以减轻这两种担忧。
可扩展、可持续运行的构建
利用负载均衡技术，结合容器化、计算实例映像、配置管理以及有状态和无状态组件的分离，可顺利实现横向扩展和分发。在可能的情况下，状态应该是声明性的，由单一的“事实来源”进行维护和管理，并自动复制和同步。
模块化设计
单体架构可能会变得繁琐、难以管理，从而降低以可移植方式进行更改所需的灵活性。因此，工作负载应采用模块化设计，明确定义不同组件，并作为一个松散耦合的系统协同工作。云原生设计提供了一种更新或替换单个组件而不影响整个工作负载的高效流程，最终提高了可维护性、适应性和可移植性！
一切皆代码
如果要开发云原生应用程序，那么我们应该熟悉声明式部署方法：将工作负载的每一部分（应用程序、基础架构和配置管理）都编成代码。采用这种方法，我们可以自动部署新环境（如开发、暂存、测试环境）或复制现有环境。这将简化蓝/绿部署流程，并在发生灾难时快速恢复。
GitOps方法为我们提供了实现可移植性的单一途径，能通过自动化管道的可靠性优势来规范部署，提高合规性/审计的可视性，并将策略的实施以代码方式来执行。
通过上述五方面的思考，我们就可以结合自身需求，制定出适合的云可移植性战略，从而在云原生应用中获得真正的灵活性，真正让工作负载能在任何云平台上流畅运行和迁移，从方方面面享受到云原生所应提供的价值。
如您所在的企业也在考虑采购云服务或进行云迁移，
点击链接了解Akamai Linode的解决方案