我理解的云原生

　　云的实质是构建在远端的池化服务供给，云计算是其中服务的泛指。

　　通常，云计算的服务模式主要分为三类，分别代表用户对资源控制的不同程度：

　　IaaS（Infrastructure as a Service，基础设施即服务）：提供虚拟化的计算资源，包括服务器、存储、网络和操作系统等，用户可以在这个基础上部署和运行任何软件，包括操作系统和应用程序。

　　PaaS（Platform as a Service，平台即服务）：提供一个构建应用和服务的平台，允许用户开发、运行和管理应用程序，无需构建和维护底层硬件和软件基础设施。

　　SaaS（Software as a Service，软件即服务）：提供通过互联网访问的应用程序，用户无需安装或维护软件，只需使用服务提供商托管的应用程序。

　　除了这三种主要的云计算服务模式外，还有其他一些模式，例如DaaS（Desktop as a Service，桌面即服务；或Data as a Service，数据即服务）和MaaS（Model as a Service，模型即服务），Serverless也算，虽然它们可能不像前三者那样广为人知，但也在特定的应用场景中发挥着作用。总体来看，其他服务模式没有脱离基本的三个层次分类，只是更具专用性和特殊性。

　　云原生（Cloud Native）顾名思义是指天然生长在云上的东西。云原生没有什么简要的定义，它更多地是一种理念、一种文化、一种构建现代应用的方法论，旨在充分利用云计算的优势，提高应用程序的可伸缩性、弹性和可靠性。

　　脱离应用讨论云原生没什么意义，前面已经列举了很多云计算服务模式，单纯再增加概念对现实没什么帮助。那么，PaaS作为云上构建应用的平台，利用PaaS构建的应用也是生长在云上的东西，可以说这就是云原生应用吗？

　　可以说是，也可以说不是。

　　云原生和PaaS是相生互补的关系，云原生定义了PaaS的能力，扩大了PaaS的服务范围，同时，PaaS承载云原生的理念，实现云原生的架构。

　　也就是说，云原生应用是在特定的开发理念指导下，基于云原生架构构建的，而云原生架构又由云原生产品联合组成，云原生产品又需要云原生技术提供基础支持。这听起来像以云原生造句的绕口令，但确实表达了云原生自上而下的关系。

　　回到上面的问题，基于PaaS平台构建的应用是否属于云原生应用，取决于两方面的因素。一方面，云平台能提供支持云原生架构的产品，并进行应用维度的整合，这是供给的因素；另一方面，业务能适应云原生架构进行改造，以满足云原生目标下的构建、运维、扩展要求，这是使用的因素。

　　讨论了虚的东西，接下来得落到实处，要讲清楚云原生应用具体是什么，得先说清楚为什么。

　　云原生的产生可以说是社会化极致分工的一种体现。

　　为什么要用云原生架构，我的答案很简单，就是让用户只做业务相关的事情，其他都由云服务托管。

　　那什么是业务相关的事情，什么是其他的事情，又得从软件工程说起。

　　应用是软件，应用的生命周期对应软件工程的不同阶段，想来是没有疑义的。一般来说，软件工程分为需求、设计、编码、测试、交付、维护几个阶段，其中需求、设计、编码和测试的一部分是业务的事情，测试的另一部分、交付、维护是其他的事情。再简化点，编写业务逻辑并自行验证是业务的事，自动化测试、发布和保持在线，就算是其他的事，粗略地讲就是开发工作和运维工作。

　　但是，云的产生本身也来自于分工的服务化能力供应，PaaS本身也实现了一个构建和管理应用的平台，似乎和上面说的也没什么差别，是不是重复了？

　　我认为并没有，这是云原生和PaaS相生互补的一个例证，也更好地说明云原生应用的业务价值：PaaS提供了基础的“静态”功能，而云原生解决了业务“发展”和“变化”的“动态”问题。

　　激烈的商业竞争，日新月异的市场环境，业务的发展和变化是常态。

　　从后验的角度，既然云原生解决了业务发展的痛点，那么从业务的痛点，就能倒推云原生的特点：

　　到这里再看CNCF对云原生的定义。

　　Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

　　云原生实践使组织能够在计算环境（公共、私有、混合云）中开发、构建和部署工作负载，以可编程和可重复的方式满足组织的大规模需求。它的特点是松散耦合的系统以安全、有弹性、可管理、可持续和可观察的方式进行互操作。

　　Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is non-exhaustive.

　　云原生技术和架构通常由容器、服务网格、多租户、微服务、不可变基础设施、无服务器和声明性API的组合组成——未完待续。

　　诚然，现在的定义跟最初的定义已有不同，未来大概率也会跟随技术的发展再变化，关于什么是云原生的争论或许永远都不会停止。我想最重要的，是理解云原生作为指导一种行为方式的理念哲学，究其根本，凡是能提高云上资源利用率和应用交付效率的，就都是云原生的。

　　云计算的发展史是云原生化的发展史，在这个过程中，席卷了技术、业务、云厂商三方交融、制约和成长。

　　很多时候人们会用技术来定义云原生，例如概括云原生的要素为微服务、容器化、编排调度等等。而我尽量避免用具体的技术来描述云原生，因为技术总是在发展的，当下的技术适应当下的基础设施，但它不是全部，也不一定是未来。但技术的范式是可延续的，例如自包含、可移植、DevOps、持续交付等等。

　　康威定律历经快60年仍没有过时。对业务来说，技术只是支持发展的工具，但拥抱新的技术架构，实际上是采纳新的组织结构和沟通流程，很多人都忽略了这一点。每项技术都是为了被广泛应用而产生的，天然就具备智力上普惠的特性，学习和使用永远都不是门槛，也不该成为门槛，而没有合适的组织环境来承载技术，也只是削足适履。

　　最大的挑战或许在于云厂商。越深的水表面越平静，同样地，越唾手可得、开箱即用的服务，背后就需要花费更多的功夫。业务面临的组织变革，对云厂商也同样适用，云服务从工具化到平台化，再到解决方案化已经是必然的趋势，产品墙、部门墙会被需求的冲击打破。

　　云服务的价值不来自于技术的难度和整合的难度，而来自于业务的选择。这就要求云服务不能只是追赶业务，而要引领业务，“从业务中来，到业务中去”，说的是以业务的思维做产品。

　　现在是技术变革的时代，也是机会勃发的时代。