通信世界网消息（CWW）当前，容器云技术方兴未艾，企业级应用容器化改造可以有效助推企业实现数字化转型。
容器化目标与路径
众多周知，企业的数字化转型大都以业务价值为目标，由于每个企业的独特性，通常很难找到完全匹配的经验可供借鉴，因此必然带来转型过程的碎片化，从而对原有的传统应用架构带来巨大冲击，而大量新应用的产生同样会导致原有企业架构的碎片化，
双态IT架构主要包含稳态业务和稳态业务两大部分。敏态业务往往是直接和业务盈利相关的，会随着用户需求而不断变化，因而更注重满足业务的快速多样性，
与此同时，支持业务应用的持续演进也是容器化的一大目标之一。企业的底层基础设施也从原来的网络设备加服务器，过渡到虚拟化，再进阶到容器化，其所支撑的上层业务应用形态也会随之发生变化，逐渐从传统的单体应用向虚拟化时代的RPC/SOA应用、再向云原生时代的微服务应用转化。很多企业可能在虚拟机时代就进行了微服务化改造，但可能收益并不明显。虽然应用已经是独立的个体了，但依然有着极高的弹性伸缩等能力需求，这时候就需要借助容器来实现，二者的强强联合才能够真正将微服务的优势发挥出来。再配合DevOps平台，就能够更好地实现敏态业务的扩展和生产效能的提升。
此外，容器化的另一红利在于推进由系统化向平台演进。由于云原生技术的学习成本过高，比起浪费大量研发资源在自研云原生平台的调研、架构设计、技术选型、建设运维上，越来越多的企业开始拥抱开箱即用、灵活可控的一站式全栈云原生平台，企业无需再关心容器、微服务技术的细枝末节，一套平台提供生产就绪的微服务基础设施、治理、运行、运维最佳实践环境。
云原生应用形态
云原生应用形态主要包含以下几类：
中间件应用
MySQL、Redis、RabbitMQ、MongoDB、Kafka。这类应用是云原生平台内的一种应用形态，可能在容器平台内，也可能在原来的虚拟机、其他公有云等传统基础设施资源上，我们称之为数据服务，用于为应用提供持久化支撑。
工作负载
工作负载指的是在K8s下的workload，包括Deployment、StatefulSet、DaemonSet、CronJob等。
抽象模型
通常来说，在部署应用时需要进行抽象封装或定义。具体来讲，一个应用通常是指一个应用系统，应用系统又有各自的前端、后端、中间件、配置文件、网络等等。当然在不同的客户环境下，也可能有不同的定义，比如微服务团队下定义的应用就是微服务应用，涵盖workload、治理能力等等。因为有上述抽象模型的定义，就衍生出了OAM应用、微服务应用、原生应用。
管理分区及组织架构
由一个平台支撑多个应用，一个应用支持多个集群，集群又划分成不同的管分区，比如生产集群、测试集群、灾备集群等等。组织架构层的业务系统可以跨多个集群，设置分配不同项目的资源配额，在不同项目下独立开发运维。
应用上云关键路径
企业上云路径应该根据不同的应用资产形态、上云后的预期目标进行综合分析评估，确定合适的转型模式，再去采用对应的解决方案和环境。应用上云的转型模式主要分为以下6种：
Encapsulate：直接暴露API供创新应用调用，也是所有应用都适用的一种模式，相当于应用不迁移，只开放旧应用的API给新应用使用。
Rehost：不做任何修改迁移到云。这里分为两种情况，第一种是原有应用不需要修改，比如原有应用为容器化应用，就可以直接迁移到云上；第二种是没有时间修改，很多企业项目改造时间周期紧张，来不及做架构改造、微服务拆分，那么就可以直接把容器当成虚拟机来用，更方便利用容器平台来做DevOps，加速企业敏捷化运营，也便于后续进行单体应用改造。只不过成果收益不太显著，很难充分享受到云的便利。
