IaaS（Infrastructure as a service – 基础设施即服务）：用户可以在云服务提供商提供的基础设施上部署和运行任何软件，包括操作系统和应用软件。用户没有权限管理和访问底层的基础设施，如服务器、交换机、硬盘等，但是有权管理操作系统、存储内容，可以安装管理应用程序，甚至是有权管理网络组件。简单的说用户使用IaaS，有权管理操作系统之上的一切功能。我们常见的IaaS服务有虚拟机、虚拟网络、以及存储。
PaaS（Platform as a service – 平台即服务）：PaaS给用户提供的能力是使用由云服务提供商支持的编程语言、库、服务以及开发工具来创建、开发应用程序并部署在相关的基础设施上。用户无需管理底层的基础设施，包括网络、服务器，操作系统或者存储。他们只能控制部署在基础设施中操作系统上的应用程序，配置应用程序所托管的环境的可配置参数。常见的PaaS服务有数据库服务、web应用以及容器服务。成熟的PaaS服务会简化开发人员，提供完备的PC端和移动端软件开发套件（SDK），拥有丰富的开发环境（Inteli、Eclipse、VS等），完全可托管的数据库服务，可配置式的应用程序构建，支持多语言的开发，面向应用市场。
SaaS（Software as a Service – 软件即服务）：SaaS给用户提供的能力是使用在云基础架构上运行的云服务提供商的应用程序。可以通过轻量的客户端接口（诸如web浏览器（例如，基于web的电子邮件））或程序接口从各种客户端设备访问应用程序。 用户无需管理或控制底层云基础架构，包括网络，服务器，操作系统，存储甚至单独的应用程序功能，可能的例外是有限的用户特定应用程序配置设置。类似的服务有：各类的网盘(Dropbox、百度网盘等)，JIRA，GitLab等服务。而这些应用的提供者不仅仅是云服务提供商，还有众多的第三方提供商（ISV: independent software provider）。
通俗的讲：
云服务提供基础设施，经常听有人说：“某某企业或某某斜杆青年租了什么什么云服务器，准备自己搞个软件或者搞个网站…..”，其实就是IasS，就是租了个云服务器（裸机）而已。
云服务提供一个平台，企业自己设计应用，数据也由自己保管，这就是PaaS。就是租了个带有开发环境、IDE等开发集成环境的云服务器，但是应用程序或者软件需要自己开发、部署，数据也自己保存。
云服务提供现成的软件，数据也是全部上云，这就是SaaS。
云计算目前主流的部署模式分为三类：
私有云（Private Cloud / On Premise）: 私有云是专为单个组织运营的云基础架构，管理的模式有内部管理，第三方管理，亦或是内部或外部托管。简单的讲，私有云就是通过自建或者租用场地的形式建立服务器机房或者数据中心。服务是面向私有网络或者VPN专有网络。企业拥有对服务器、数据硬盘的完全控制。因此安全性很高。
公有云（Public Cloud）：公有云服务面向公开网络暴露，服务可能也是免费的。由于网络对外公布，因此从安全层面上也是大不相同的。常见的公有云有AWS，Microsoft Azure，阿里云等。
混合云（Hybrid Cloud）：混合云是两个或多个云（私有云，社区云或公共云）的组合，它们保持不同的实体但绑定在一起，提供多个部署模型的好处。 混合云还意味着能够使用云资源连接搭配，托管和/或专用服务。比较常见的例子如数据公司，可能拥有很多数据，而这些数据因为合规性等原因只能放在私有环境，当需要大规模机器学习，对数据进行脱敏后使用公有云进行大规模学习。
IPaaS和APaaS 的产生，是因为企业在使用软件过程中，又遇到了难以解决的问题：
1、对于很多企业来说，SaaS都是固定功能的软件，对于自己需要个性化的需求难以满足，虽然软件开发能灵活满足自己的需求，但是无论是自研还是托管，开发和运维费用都极其高昂
2、一个软件解决不了所有问题，那就多堆几个软件，导致一个企业可能用了五六个软件，但都互相独立，无论是功能还是数据，都不能连起来
本来想通过信息化提高效率、解决数据难题的，却使得数据壁垒越来越厚、事情越做越多。
这可不行。
所以IPaaS和APaaS 产生了。
首先，是企业的个性化问题。
堵死一大批企业的，其实就是软件开发的门槛过高。要找到懂开发又懂业务的IT太难了，业务人员为了开发去学编程也不是朝夕就能实现。
怎么才能提供一种框架，让业务人员不需要学代码就能自己设计出一个管理软件呢？这种模式就是APaaS ，从应用和数据层面入手，设计搭建工具与逻辑，实现零代码开发。
举个典型的APaaS 设计逻辑——通过【表单】上传数据并实现堆叠搭建，利用【流程工具】将业务点串联起来，借助【仪表盘】进行数据展现与分析。如图：
而APaaS 从应用和数据层面入手，就足以看出，它趋向于PaaS和SaaS之间。
其次，就是打通企业内部的各个软件问题。
由于企业堆叠的各种SaaS软件，用着不同的主机和数据库，怎么将这些软件集成起来？这就需要一种技术，也就是iPaaS。
它从虚拟主机和数据库层面入手，创建一个中心生态系统来查看、管理和修改所有数据、基础设施和操作。从而轻松打通各个系统的数据与功能。
可以看出，iPaaS则趋向于IaaS和PaaS之间。
云原生计算基金会（CNCF）给出的云原生的定义：
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”
这个定义还是比较靠谱的，尽管它并不严谨，也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同，看问题的角度不同，CNCF的主要目的是培育云原生工具市场，因此它的定义带有很重的实用色彩，偏重工具方面。若是从这个角度看，这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去，其他的都没什么问题。
让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石，也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器（Container）、服务网格（Service Mesh）、微服务（Microservice）、不可变基础设施（immutable infrastructure）和声明式API（declarative APIs）。其中容器（Container）是k8s的底层引擎，服务网格（Service Mesh）是建立在k8s上的针对请求的扩展功能，不可变基础设施（immutable infrastructure）是现代运维的基石，声明式API（declarative APIs）是k8s的编码方式，这些无一不是和k8s紧密相关的。但微服务（Microservice）就不同了，它其实跟云原生没什么关系，它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配，它们现在的演进轨道交织在一起密不可分。
但实际上没有容器技术，微服务也可以部署在虚机上，只不过资源的利用率可能不够高。没有微服务，容器技术虽然不能大展宏图，但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼，但把微服务划归到云原生里实在是有点扩大外延，跑马圈地的意味。因为云原生的重点还是在基础设施，运维和运行环境以及软件的开发环境，而微服务是一个软件的架构，两者之间有明显的不同。
云原生的表层含义
那么到底什么是“云原生（Cloud Native）”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。
云环境与本地环境的差异
那么部署到云环境和部署到本地服务器有什么不同？这个才是问题的本质。
你可能会说“是容器技术”，这个是现代云计算的不可或缺的支撑，但云计算开始的时候是基于虚拟化的，并没有容器技术，是在发展的过程中才有了容器技术。
是“自动伸缩（auto-scaling）”吗?这是云环境的一个主要优点和特性，但它只是结果，不是本质。
云技术的三大基石：
基础设施即代码 (Infrastructure As Code）
基础设施即代码是指把创建基础设施（包括服务器和网络环境）的命令像应用程序一样储存在源码库中，并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境，出了问题就在原来的基础之上进行修修补补，一旦需要把整个环境重新建立，很难保证与原来的一样。 当使用基础设施即代码之后，再也没有了这个担心。
不可变基础设施（immutable infrastructure）
说道这里，我们不得不提“不可变基础设施（immutable infrastructure）“，它是基础设施即代码的升级版。有了基础设施即代码之后，随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备，并且还能预装应用程序，创建的时间还是秒级的。这时当服务器出现问题时，就没有必要去花时间查找原因了并修复了，而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的，只有创建和删除，而没有修改操作。这彻底改变了运维的方式。
声明式API（declarative APIs）
声明式API也是基础设施即代码的升级版。最开始时，当用软件定义基础设施时是用的过程式描述，也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态，而由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。
上面讲了云计算环境和传统基础设施的不同，其实随着云计算的发展，传统基础设施也在不断地采纳云计算的先进技术和理念，例如虚拟化和容器技术，而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大，而通常本地私有云的版本是公有云的一个简化版。
云原生应用程序的不同
上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？
它主要有两个部分:
第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。
第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。
云原生的深层含义
不过云原生还有一层引申含义。当你的最终生产环境是云环境时，你的本地开发环境最好也是云环境，这虽然不是必须的，但它能保证本地环境和生产环境的一致性，减少部署时的意外，是一个很自然的选择。而要在本地使用云环境来进行开发，你需要一系列的工具来保证开发的顺利和高效。
