1. 应用的交付形态与发展（云原生应用交付的过去、现在与未来）
什么是应用交付？
在互联网领域，我认为应用交付是将需求转化成某种介质提供给需求方，以达到提供服务能力和创造价值的目的。这里的介质目前主流的方案是基于编码实现的程序，也可以是基于编码实现的函数，或基于可视化实现的功能等。
在互联网发展的过程中，技术的不断演进使得应用的交付形态不断的发生着变化。从需求接纳后，就开始考虑该如何实现和交付该需求，主流的方式是基于编码的方式来实现需求，编译运行提供服务让需求产生价值。
1.1. 传统应用交付(过去)
传统的应用交付是应用交付的基础方式，比如常用的 RPM 软件包或者直接二进制的方式安装运行，比较适合场景相对固定的基础设施。如果有较多的软件包依赖，一般还会搭建一些 YUM 的软件源来快速安装依赖。这类服务的运行一般也可以通过 systemd 或者 supervisor 的方式来管理。
1.1.1. 可执行文件直接交付
基于可执行文件交付的应用一般运行方式比较直接，直接在 shell 中运行程序。比如/opt/myapp.sh 。如果在终端中运行影响使用，一般还会在命令最后添加 & 符号使其在后台运行，如 java -jar myapp.jar &。
直接使用可执行文件交付没有固定的规范约束，每个研发或运维人员的习惯的不一样，文件放置的位置和启动的命令等都会有差异，就导致在运维管理上有较大的困难，因此规范这些文件成为了一个趋势。将可执行文件和配置按照一定的规范要求封装，就是大家常用的软件安装包。
1.1.2. 封装成软件包交付
软件包具有特定的格式，这些格式就是对软件安装的规范过程。由于识别和管理软件包的工具不同，出现了大量的同类型的软件封装方式，如 CentOS 使用 RPM 包，Debian 使用 DEB 包，Java Web 使用 WAR 包，Windows 使用 exe 包等等。这些不同格式的软件由不同的工具来管理和运行，如 WAR 一般使用 tomcat 运行管理，RPM 和 DEB 包使用 systemd 管理服务等。
虽然软件包能够规范文件的管理，但是由于程序的运行处自身可执行文件和配置外，还会有其他例如系统库文件的依赖才能正常运行，这就是程序的运行环境。由于操作系统的种类不同，版本不同，安装的基础库软件不同都会导致无法满足程序正常运行的需要，管理这些运行环境成为新的痛点。Docker 的出现完美的解决了这个问题。
1.2. 云原生应用交付(现在)
1.2.1. 基于 Docker 的应用交付
Docker 的镜像将程序以及依赖的软件或库文件一起打包成 Docker 镜像，在这个镜像中有着程序运行所有的依赖，这样无论这个镜像运行在任何支持 Docker 的操作系统的任何版本，都可以将程序运行起来。由于这种特性确实解决了很多应用交付的痛点问题，因此 Docker 一经出现就立马风靡全球。
Docker 镜像将一个应用的交付难度大大降低，但是在多个应用一起交付和管理时就不那么便捷了，而且程序运行还会有依赖和配置的需求，因此多容器服务的管理 docker-compose 被提出。
1.3. 基于 docker-compose 的应用交付
docker-compose 将多个应用使用 yaml 的方式管理，可以单个或多个服务的批量安装部署和服务起停。docker-compose 给多应用的交付提供了很好的参考思路。
由于 docker-compose 仍然是一个单机工具，可以很好的管理单台机器上的服务，但是在多台机器上部署和管理服务却显得力不从心。这时，基于容器的编排调度服务出现了。
1.3.1. 基于 Kubernetes 的应用交付
在早期，基于容器的服务编排调度系统有三大产品，分别是 Swarm、Mesos 和 Kuberentes。在激烈的市场竞争中，Kuberentes 由于其优秀的设计与强大的能力等原因脱颖而出。在 Kuberentes 中，用户只需要定义自己想要的服务运行副本数量和运行方式即可（deployment），在结合 Service 和 Ingress 等资源就可以完成应用的交付，完全不需要关注服务调度的节点。Kuberentes 是云原生的操作系统，目前已经成为容器编排事实上的标准。有些企业为了便于操作，使用了基于 Web 的容器云平台来管理，比如开源的 Rancher 容器云平台。
基于 Kuberentes 的应用交付已经很简单了，但是在 Kubernetes 中部署应用时还是会涉及较多类型资源管理问题。在 Kubernetes 集群中部署服务并不是简单的将 Image 镜像运行起来就可以了，实际上还会涉及一些其他相关的 Kubernetes 的资源，例如常见的资源有 Deployment、Service、Ingress、Secret、ConfigMap、PV/PVC、ServiceAccount、RBAC等等以及其他扩展服务的相关资源，如 Prometheus-operator 的 ServiceMonitor。这么多类型的文件该如何维护管理才能高效且不出错呢？
1.3.2. 基于 Helm Chart 的应用交付
Helm Chart 能够将 Kuberentes 的各种资源进行打包管理，也可以添加自定义的安装或升级逻辑。Helm 是 Kubernetes 应用查找、分享和使用的最佳方式.
Helm 已经是 Kuberentes 应用的常规推荐交付方式了，只是在一些特有的场景下还可以有更加高效的交付方式，如 CICD。
1.3.3. 基于 CICD 的应用交付
CICD 是持续集成和持续交付的简称，通过流水线可以将应用的交付流程串联起来，触发流水线自动将源代码拉取、编译、测试、打包、构建、部署和运行测试等过程执行起来。这在开发和测试过程中能极大的提升应用交付效率，将更多的时间留给研发编写功能和测试验证异常。
任何一种交付方式都有其历史背景与应用场景，基于 CICD 的应用交付同样不是绝对完美的。因为自动 CD（交付）的过程在当今这个时期并不符合大多数企业的要求，无论是在交付质量、上线流程、安全合规等方面都可能无法满足企业的需求。
因此，应用的交付应该选择应该符合实际的时代背景与技术体系。就目前，推荐在测试开发阶段使用 CICD 高效交付应用，在生产环境使用 Helm 稳定交付应用，以及在某些特殊情况下依然可以使用早期的几种交付方式来满足业务交付的需求。
1.4. 新型应用交付(未来)
以上的应用交付形态都是在考虑将应用的以程序的方式在环境中运行起来提供服务，追溯问题的本源，交付是在交付什么？交付是在交付需求，核心并不是代码，代码只是当前技术体系下可选的最佳介质而已。
今天大多数公司在开发应用程序并将其部署在服务器上的时候，无论是选择公有云还是私有的数据中心，都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。假设我们不想在这些细节上花费精力，是否有一种简单的架构模型能够满足我们这种想法？
1.4.1. 基于 OAM 的应用交付
OAM 是一个专注于描述应用的标准规范。有了这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。这种关注点分离（Seperation of Conerns）的设计好处是非常明显的。 举个例子，在实际生产环境中，无论是 Ingress ，CNI，还是 Service Mesh，这些表面看起来一致的运维概念，在不同的 Kubernetes 集群中可谓千差万别。 通过将应用定义与集群的运维能力分离，我们就可以让应用开发者更专注于应用本身的价值点，而不是”应用部署在哪“这样的运维细节。
此外，关注点的分离让平台架构师可以轻松地把平台的运维能力封装成可被复用的组件，从而让应用开发者能够专注于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。 Open Application Model 的目标是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。
1.4.2. 基于 Serverless 的应用交付
Serverless 架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。
最开始，“无服务器”架构试图帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作。这项技术的目标并不是为了实现真正意义上的“无服务器”，而是指由第三方云计算供应商负责后端基础结构的维护，以服务的方式为开发者提供所需功能，例如数据库、消息，以及身份验证等。简单地说，这个架构的就是要让开发人员关注代码的运行而不需要管理任何的基础设施。程序代码被部署在诸如AWS Lambda这样的平台之上，通过事件驱动的方法去触发对函数的调用。
很明显，这是一种完全针对程序员的架构技术。其技术特点包括了事件驱动的调用方式，以及有一定限制的程序运行方式，例如AWS Lambda的函数的运行时间默认为3秒到5分钟。从这种架构技术出现的两年多时间来看，这个技术已经有了非常广泛的应用，例如移动应用的后端和物联网应用等。简而言之，无服务器架构的出现不是为了取代传统的应用。然而，从具有高度灵活性的使用模式及事件驱动的特点出发，开发人员／架构师应该重视这个新的计算范例，它可以帮助我们达到减少部署、提高扩展性并减少代码后面的基础设施的维护负担。
1.4.3. 基于低代码或无代码的应用交付
低代码开发是一种可视化应用开发方法。通过低代码开发，不同经验水平的开发人员能够通过图形用户界面，使用拖放式组件和模型驱动逻辑来创建 Web 和移动应用。低代码开发平台减轻了非技术开发人员的压力，帮其免去了代码编写工作，同时也为专业开发人员提供了支持，帮助他们提取应用开发过程中的繁琐底层架构与基础设施任务。
无代码是完全不需要编写代码，基于视觉的拖放式无代码平台允许您创建基本但实用的应用程序。
低代码和无代码开发平台都提供了无需编写代码即可构建软件应用程序的方法。它们不要求开发人员具备任何传统编程语言的知识，而是提供了一种可视化的应用程序开发方法。这使得更多的人可以使用应用程序开发，特别是在业务领域工作的精通技术的人。
低代码和无代码开发平台有望帮助专业和非专业开发人员以更高的效率创建应用程序，从而提高生产力。由于几乎总是以平台即服务 (PaaS) 形式提供，两者都消除了建立环境和维护基础设施的开销。但这几乎是相似之处的结束。
使用低代码平台，开发人员可以使用自己编码的增强功能扩展应用。无代码平台在开发环境中添加了约束，限制了用户在供应商提供的解决方案之外扩展其应用的能力。
1.5. 总结
可以确定的是以上的应用交付形态将会同时存在，并且会长期存在。但不同的交付形态的采纳比重会有侧重，目前主流的应用交付形态会是云原生的应用交付模式，即基于容器、Kubernetes的应交付。
传统应用交付将作为无奈的兜底选择。在企业没有新型的基础设施和人才资源时，还需要继续使用传统的应用交付模式，虽然不那么高效和先进，但是他足够的成熟和稳定。
云原生应用的交付是当前的主流。其优秀的设计理念与高效交付效率是让各大厂商最求的理想技术，努力的学习和储备云原生的技术人才，让其业务在新时代的数字化背景下大放异彩。
新型应用交付是未来发展方向，是当前的前沿的技术形态。更多的还是在早期阶段，只有一些大型互联网厂商在投入研究，在真正的普及和产生实际的效益的路上还是在摸着石头过河。