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的相关报告。