1. 应用的定义

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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