1. 云原生应用的定义与交付

随着云计算技术的发展，云原生技术成为当今时代的主流。云原生（Cloud Native）是一种理念，本质上是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

在云原生场景下如何做好应用的定义与交付也同样影响着企业的成本投入，也影响着股东的每一份利润。

1.1. 应用的交付

在进入互联网这个行业以来，很长一段时间我理解的应用交付就是程序的安装部署，把业务方给我的程序安装包运行起来就好了。但是，随着在这个行业中逐渐的摸索，我对交付有了新的理解，我认为交付就是将需求转化成某种介质提供给需求方，以达到提供服务能力并创造价值目的的过程。而应用交付的对象是应用更加具体，更侧重于软件的需求交付，但也不仅局限于程序的安装部署了。

应用的交付可以有多种形态。互联网企业或业务团队成立的初衷是实现一些想法或者目标，比如想要即时通讯 IM工具，想要使用电商平台，想要提供互联网检索功能等等。企业创始人或业务负责人给到业务团队的需求是明确的，就如需求目标就是想要一个即使通讯的工具来支撑整个集团的高效沟通，但是业务团队如何实现并交付这样的需求其实是不固定。当然，可以选择从新开发一个新的通讯IM工具来交付这个需求，更可能的情况确是提供一套解决方案采购其他厂商已有的产品，两种方式都是可以满足最初的需求交付，只是满足需求的方式或者说介质不同了罢了。交付需求的介质可能是打包的程序、代码函数、API接口、公有云产品、解决方案、设计图稿甚至是 Markdown 文档等等，只要能满足的需求方的需求即可，并不局限于固有的意识形态。

随着时代技术的演进，应用交付的载体也在不断的变化以满足不同的交付场景，通过对交付过去、现在和未来的方式进行分析，以便对应用交付有更加深入的理解。

• 在 《应用的交付形态与发展》 一文中梳理了应用交付的发展过程以及未来的可能推测。

1.2. 应用的定义

应用的定义决定了应用的交付方式，不同的交付方式也影响着如何定义应用。应用的定义可以理解为是根据特定的交付场景，对交付物（或交付介质）进行符合一定规范标准的组织方式。

这些规范标准可能涉及应用运行的平台、开发的语言、运行文件封装方式、配置及环境信息以及说明性的材料等。

1.3. 应用定义需要明确运行的平台

在定义或者封装一个应用时，需要明确其运行时的平台。在硬件层面需要考虑 CPU 类型，是 X86 架构还是 ARM 架构，甚至需要考虑兼容更多其他的 CPU 架构，不同的 CPU 架构的指令集不同，驱动及系统库不同可能导致应用无法在不兼容的硬件平台上运行。

在明确好硬件平台后，还有考虑其运行的操作系统 OS，这也决定着不同的软件运行生态的依赖，例如在 Windows 上打包的程序很可能无法在 Linux 操作系统上运行。

在目前云原生场景下，可以将 Kubernetes 理解成分布式的操作系统平台，如果应用想在 Kuberentes 平台上运行，就需要按照 Kubernetes 的标准来封装应用。

1.4. 应用定义核心是可运行的文件

应用的定义规范的核心是如何更好的打包、管理、运行可运行的文件，可运行文件由于编写语言的不同，主要分为两种。

一种是脚本化语言编写的应用，他们由解析器来解析执行，例如 Shell 脚本、Python 脚本、Nodejs 等；另一种是编译型语言，需要经过链接编译后才能正常运行，如 C/C++可执行文件、Golang 可执行文件、Java 的 jar 包等。

1.5. 运行文件的封装更便于传播和管理

虽然可执行文件是应用的核心，但是一个完整的应用一般由多个不同功能的文件组成，如可执行文件、配置文件、依赖的库文件以及帮助文档等。如果不能合理的管理相关的文件，会给交付运维人员的管理带来很多麻烦。由于运行平台不同，运行文件的封装方式也多种多样，如在 CentOS 上打包成 RPM 包，在 Debian 上打包 DEB 包，在 Windows 上打包成 EXE 包等等。在云原生场景下，会封装成容器镜像，并进一步的封装成 Helm Chart。

1.6. 配置及环境信息是应用定义的运行态说明

仅仅只是封装的软件包依旧只是程序文件，需要实际运行起来提供服务才有意义，应用运行起来的实际配置也是应用定义的一部分。例如和实际运行相关的服务配置文件 nginx.conf，服务启动时 JVM 参数，或者 Helm Chart 安装时以来的 values.yaml 配置。

1.7. 完整的应用离不开说明性的材料

说明的材料能够让使用着或者部署运维的人员对该应用有一定了解，能够更好的使用和管理该应用的服务。一般的应用可执行文件都会提供 --help 的帮忙说明，能够提供简单基础的说明。对于程序更详细的说明一般提供 man 手册详细描述，对于云原生应用的 Helm Chart 通过 README.md 或 NOTES.txt 来描述。

定义好一个应用需要考虑很多维度的信息，特别是云原生的应用和传统应用有着较大的差别，这里将云原生应用于传统应用在多个维度上进行对比，便于更好的理解云原生应用

结合传统应用的认知，一个云原生应用应该具有以下几个方面：

1.8. 总结

通过多年的经验对交付有了更深刻的认识理解，交付的目的是交付需求，而需求的交付方式是多种多样的。当需求需要使用应用来交付时，从应用交付方式的演进来分析过去、现在和未来的交付方式。由于交付方式的不同，对应用的定义也有所不同，核心主要是应用运行的平台、开发的语言、运行文件封装方式、配置及环境信息以及说明性的材料。

结合以上的内容，总结了几点建议：

• 如果业务比较早期，专业人员未就绪，可以选择 docker/docker-compose 进行基础的容器化封装运行。
• 如果团队有懂 Kubernetes 的技术人员，就使用 Kubernetes 的方式管理服务。
• 如果是在线业务或开发测试环境，可以使用 CI/CD 的方式持续集成部署，Jenkines 还是目前的主流技术选型。
• 如果是离线业务，或安全限制等，推荐使用 Helm Chart 的方式封装应用。
• 如果团队技术前沿，有平台支撑，可以使用 Serverless 的方式定义交付需求，或者使用低代码或无代码来开发产品。
• 总之，企业应该结合业务场景与技术能力来选择合适的应用定义与交付方式。