2023年Gartner云终端用户行为调研发现，88%的受访者选择将工作负载现代化作为云迁移的首选。同样地，在中国市场，云原生架构是工作负载迁移地热门选择。
中国的许多企业都是用云原生工作负载比例即容器化比例来衡量数字化转型的进展，导致现象是容器化迁移比例越高，云原生工作越成功。但是，这种鼓励把尽可能多的工作负载转变为云原生工作负载的工作方式，将更多的注意力放在技术实施路线的落地层面而不是业务结果层面，从而产生了需要耗费大量资源的基于分布式架构的系统孤岛，反而限制了业务的敏捷性、推向市场的速度和可扩展性。
中国基础设施与运营（I&O）领导者可以通过以下三大策略确定合适的云原生工作负载，从而以业务成果驱动的方式推动数字化转型。
使用工作负载论证框架，为应用部署设定明确原则
敏捷团队通过云原生实践方法快速完成交付，但敏捷交付保留了传统交付的大部分特性，包括线性、循序渐进和紧密耦合的一体化方法。因此，仅仅将尽可能多的工作负载转变为云原生，并不能缓解由于各自为政的技术环境所造成的问题。事实上，敏捷交付的快节奏导致系统面临可用性变差，这主要是由于容器化交付模糊了I&O和应用团队对于可用性的责任界限。
因此，仅仅以容器使用比例为标准跟踪转变为云原生的工作负载，并不能体现技术转型对业务的直接价值结果（而只是展现了IT的工作量），更无法据此衡量有说服力的数字化转型的成效。I&O领导者不应专注于跟踪转变为云原生的工作负载数量，而应明确云原生工作负载可量化的业务价值，从而专注于改善业务成果。
I&O领导者可以根据交付要求，确定工作负载与云原生的适配性。传统架构适用于稳定且可控的工作负载，通常不需要云原生。云原生架构适用于敏捷工作负载，快速迭代的业务场景，尤其是创新系统层。
图1：确定最适合使用云原生和容器化的工作负载论证框架
鼓励改变文化，从新的角度考虑工作负载
大多数企业多年来一直使用双模式IT。传统的项目管理交付方法依赖瀑布式架构，将信息技术基础设施库（ITIL）管理作为模式1；敏捷产品管理交付则依赖敏捷实践，如Scrum或看板，将DevOps作为模式2。
对于传统交付方式，应用团队和I&O团队都依赖于面向项目的管理方法。I&O团队与应用团队合作，构建一个大型单体架构，并每隔几个月对该系统进行测试与升级。
传统架构系统（通过硬件容错）可规避应用出错风险，但检查点较多，有着严格的层级结构。对各个特定领域（包括安全、服务器、网络和数据库），采用传统交付方法的I&O领导者倾向于使用专门团队分别对这些领域进行专业的系统管理。架构师需要了解整个解决方案，包括其所有组件的互连情况和复杂设计，而I&O团队相关领域负责人只需要了解其具体负责的部分。
敏捷和传统交付都需要跨团队协调，以便集成各个独立组件并交付。二者的主要区别在于部署的频率——敏捷交付的频率要高得多。这意味着，与传统交付相比，敏捷团队需要应对的复杂性可能要放大5到10倍，但在此过程中，敏捷团队因自身能力不足，为了快速部署达到结果，会妥协构建“分布式单体架构”以提供服务。
由于交付效率的提高带来了更多的韧性和可用性挑战，在使用图2所述的交付模式时，I&O团队和应用团队之间的界限并不清晰。此模式的运营极富挑战性，需要高可用性甚至危机管理。
图2：未用到云原生的敏捷交付流程示例
避免一味追求高容器化率，重点关注工作负载的敏捷性和快速推入市场
虚拟化是云计算的基础。借助虚拟化，物理平台的功能细节可以与平台托管的应用和数据解耦。容器通过将应用和服务使用资源的抽象层级进一步上移，提升计算功能的效率和敏捷性。
图3：虚拟化方法及其基础设施抽象层的演进
不同的抽象层带来不同的基础设施控制效果。基于物理服务器的单体架构推动提高了稳定性和控制能力，而基于容器的云原生架构则促进了敏捷性和灵活性的提升。
然而，如果I&O领导者将高比例的云原生部署覆盖率作为判断成功的要素，就很容易在容器采用方面遇到挑战。容器部署覆盖率并非良好指标，无法反映不同类型工作负载的业务需求。I&O领导者应重点关注可推动业务成果的云原生指标。具体指标体系可以参考Gartner的相关报告。
