7.3 以应用为中心进行封装
容器技术因彻底改变了软件打包和分发方式而被迅速普及，不过软件打包与分发方式的革新并没有使软件本身的定义与描述发生本质性的变化，典型的例子是 Kubernetes 至今没有应用的概念，基于 Kubernetes 的应用管理也没能让业务开发人员与运维人员的工作变得更为简单。
举一个具体的例子，用 Kubernetes 部署一套基础 Spring Cloud 的分布式应用，你需要分别部署一到多个配置中心、注册中心、服务网关，为每一个微服务配置好相应的 Kubernetes 工作负载和服务访问，为每一个微服务的 Deployment、ConfigMap、StatefulSet、HPA、Service、Ingress 等资源编写好元数据配置。这个过程最难的不仅在于繁琐，还在于写出合适的元数据描述文件，既需要懂开发，又要懂运维，甚至还需要懂平台。
但以上的复杂性并不能说是 Kubernetes 带来的，而是分布式架构本身的特点导致，对于大规模的分布式集群，无论是最终用户部署应用，还是软件公司管理应用都存在诸多痛点，这些困难源于 Docker 通过容器镜像封装单个应用，Kubernetes 通过资源封装服务集群，却没有一个载体真正封装整个应用，将原本属于应用内部的各类技术细节封禁起来，不暴露给最终用户。
既然微服务时代应用的形式已经不再局限于单个进程，那也该到了重新定义“以应用为中心的封装”这句话了。经过人们不断地探索，虽然就怎么的封装还未有权威的定义，但已经窥见未来容器应用的一些雏形，这其中 Kustomize 和 Helm 是 “无状态应用” 封装的典型代表，而 Operator 和 OAM 则是有状态应用的封装代表。
总字数:525字