浅谈 Cloud Native 技术对云上产品的影响



云上产品原本有着公有云、私有云的形态，有着IaaS、PaaS、SaaS三种基本模式。随着Cloud Native技术的出现，云上产品的形态逐渐丰富，甚至既有模式的边界也会被打破。本文从技术变革的角度展望传统云产品模式、技术层次的变化。



本文的一些要点：

0：云上产品的基本盘理念仍在，但会复杂化；

1：docker容器与虚拟机在目标上一致，但新模式影响了云上产品模式；

2：Kubernetes生态已是既成事实，也影响云服务提供商的产品供应形态；

3：CNCF划定了云的各个方面，云服务提供商跟从这个格局；

4：云原生时代，原本云的一些概念需要变通；

5：实际云上产品的分类



0 云上产品的基本盘：有效但将复杂化

如果从需求的角度理解云上产品的基本盘，那就是云服务供应商（Cloud Service Provider）对客户提供一些便利性的设施，目的是为了构建一个网站或者后台系统。



0.1 公有云和私有云

公有云、私有云两种形态是云的首个基本的概念，原本是比较明确的：

• 公有云（Public Cloud）：在本云服务供应商的环境中部署；

• 私有云（Private Cloud）：在企业内部的环境中部署；





从一开始，公有云+私有云就并不是云产品的模式的全集。

从一个云服务供应商的角度，只要“不在本云服务供应商的环境中部署”，就不是属于“我的公有云”；如果也不是在企业内部环境中部署，这其实它也不是私有云。但即便两种都不属于，其中依然有商业形态，例如：A云服务供应商的产品在B服务供应商的环境中部署。



混合云则带来形态上面更复杂的一面，从云服务使用者的角度，他们常常需要公有云、私有云结合使用，面对的云服务提供商也有可能是多家，可能还会引入独立软件提供商。

回归到云的基本产品上面，同样一个软件部署在自己的环境中、别人的环境中，所需要的技术有相关性，又有所差别。

在Docker、Kubernetes等技术出现之后，由于技术开始进行标准化，从大方向会减少差别、提高技术的共用性。

0.2 IaaS、PaaS和SaaS

IaaS、PaaS和SaaS原本是非常简单的概念，而且在业界也有充分的认同。

• IaaS（Infrastructure as a service ，基础设施即服务）：提供服务器等物理设备给客户，或者是虚拟机、网络、存储等；

• PaaS（Platform as a service ，平台即服务）：提供平台软件给客户，比如系统软件、中间件、开发框架等，用户在上面可以进行二次开发；

• SaaS（Software as a Service，软件即服务）：提供软件给客户；

与IaaS、PaaS、SaaS相对于的一个概念是On-premises,可以理解成各种软件属于客户的自有，云服务提供商在这里面没有行为。



对于IaaS、PaaS、SaaS，首先需要掌握一个现实来说，层次结构图仅仅是理念中的层次，在云服务提供商来说，IaaS、PaaS、SaaS仅有对客户一层是明确的，而客户不可见的部分，并非用的相同的技术，也并非是严格的如此多个层次。

例如，云服务提供商可能既有IM软件提供给用户（属于SaaS），也提供IM软件所需要的API（属于PaaS），它们二者并非只是“差了上面的软件层”，下面架构很可能也是不一样的，包括：层次结构不一样多，每个层次实现不同。

在Docker、Kubernetes等技术出现之后，理论上是可以用类似的技术支持不同层次的软件需求，但其中毕竟有差别，云服务提供商最终趋向于选择总ROI最优的方案，而不会为了统一而统一。

1 云时代的虚拟机、容器

对于云服务提供商来说，一个最基本的技术就是将一台物理资源拆成N分，提供给不同的客户使用。

例如，一台物理机可能有20多个CPU，但对大部分客户来说，需要使用不同机器上面不同CPU，其结果就是一台物理机需要提供给多个客户使用，一个客户也需要使用多台物理机。

将物理机分成N份的技术主要有两种：虚拟机（VM）、容器（Container）。

例如：OpenStack是一种虚拟机技术；而Docker则是主流的容器技术。

虚拟机提供的是OS的运行状态，如果使用了虚拟机物理机上面就有了Host OS和Guest OS两层操作系统。





简单来说，虚拟机和容器的区别在于：虚拟机的开销比较大（虚拟了操作系统），隔离更深入；容器的开销比较小（基于Linux cgroup技术），隔离比较浅。

Docker这种主流容器技术的出现，带来了一些变数。



1.1 容器平台算PaaS，还是算IaaS？

传统的IaaS、PaaS的区别在区分容器平台的时候，会有一些困难，或者说有些矛盾的地方：

1. 按照软件层次，容器平台属于系统软件，它应当是PaaS；

2. 按照客户的需求，拿容器平台分配的容器，可以自行安装除了Linux 内核的所有软件，因此又类似于当成IaaS区别。

从客户的需求出发，表示是“我需要隔离的、分布式的环境”，而非“我要IaaS”或者“我要PaaS”，从云服务提供商的角度，给它虚拟机也行，容器也行。以Docker为代表的容器平台技术之所以能崛起，就是因为它们在某些满足用户需求的场景成本更低。

这点其实很普遍，随着新技术的演进，IaaS、PaaS、SaaS的边界其实并不会一直泾渭分明，会出现一些边缘的地带。

1.2 虚拟机上面跑容器

在传统的观念中，虚拟机和容器的目标是相同的，但从二者原理、实践中也可以看出，虚拟机上面也可以跑容器，也就是讲两种技术叠加起来。

比如，让Docker+Kubernetes运行于OpenStack上面，然后让客户使用容器。

虚拟机上面跑容器一方面带来了额外的性能开销；一方面又带来了更好的隔离特性。从存在即合理的角度，它的确是一些场景的解决方案，但未必是未来最佳的方案。

2 Kubernetes带来新模式

Kubernetes作为一个容器编排引擎出现，它的下层运行时一般就是Docker。由于Kubernetes在云时代出现，因此也带来了一些新模式。



对于Kubernetes新模式，驱动力并不仅仅是技术，也有人的因素。



2.1 Kubernetes的结构

Kubernetes结构上分成Master和Node，可以视为不同的物理机：

• Master的作用是管理节点，一个集群有数个；

• Node的作用是工作节点，一个集群有很多个；

• 一个Node可以包含若干个Pod，一个Pod对于一个或者N个容器（Docker）。



从Kubernetes的角度，Node代表物理机、虚拟机层面，Pod是交付给客户的最小单元。这其实就完成了分割资源且带有隔离性的目标。

2.2 Kubernetes引起的模式变更

Kubernetes引起云上产品模式变更可从下面两个方面理解：

1. Kubernetes可以成为供应的宿主：Node、Pod都是供应的单元；

2. Kubernetes本身是IaaS上面的软件，它自己也有不同的供应模式；



从云服务提供商的角度，通过Kubernetes会有一些的新的商业模式产生：

• 供应给客户IaaS，加上自己的Kubernetes平台，客户部署之后，该Kubernetes集群都归客户管。

• 供应给客户Kubernetes的Node节点，自己管理Master，对客户来说，这通常被称之为托管Kubernetes；

• 只给客户Pod的，客户不用管它如何运行，这种模式发展下去，越来越接近Serverless。



客户使用Kubernetes的模式也比较灵活：

• 得到整个Kubernetes集群的控制权；

• 得到Node，自己去编排和管理Pod；

• 得到Pod就可以运行自己的程序，可以不负责Pod的生命周期（死生扩缩），而由Kubernetes根据变化编排和管理Pod。



对于这三种模式，按照传统的IaaS、PaaS模式，已经较难对它们进行归类。

3 云原生技术格局的演化

随着Docker、Kubernetes技术的发展，一个更大的概念出现了Cloud Native（云原生）。

CNCF（Cloud Native Computing Foundation,云原生计算基金会）在某种程度上划定了云上的格局。

3.1 CNCF的格局概述

CNCF的全景图（landscape）比较复杂，可以先了解一个它的简化结构。



CNCF的全景图的几个部分：

• Infrastructure / Provision：可以视为下面的基础层，不同时代略有区别；

• Runtime：可以理解成Kubernetes的运行依赖：容器、网络、存储；

• Orchestration & Management：主要是Kubernetes，也有配套设施；

• Application Definition & Development：更上层的应用定义、中间件设施；

• Platform：提供完整平台级别的解决方案，包括但不限有基础软件；

• Observability & Analysis：监控、日志这些跨层次的机制；

3.2 CNCF全景图2016

CNCF的全景图的0.95版本在软件格局上面已经比较稳定，



本版本包括的内容较少，龙骨却已经确定：

1.       Runtime的重点是Docker，也包括存储和网络；

2.       Orchestration & Management的重点是Kubernetes；

3.       Application Definition & Development的重点是配套软件；

与这三层软件定义与应用相关场景信息：

1.       Kubernetes等编排管理软件需要运行与不同环境（IaaS）中，即便代表运行时的Docker是确定的，存储、网络也需要移植；

2.       Kubernetes当时还有Swarm、Mesos等同类竞争者，但最终全面胜出；

3.       Kubernetes在很多时候并不适合直接提供给用户用，需要结合应用定义来使用，一个应用可以视为一个分布式程序的描述。

3.3 CNCF全景图2020

CNCF的全景图的2020版本变化并不大，可以在CNCF发展而程中的脉络非常清晰，在大的格局中，各个部分各司其职。



相比CNCF的几年前的版本，这个成熟版本的主要变化是：

• Infrastructure这一层不存在了，基础设施不是CNCF直接考虑的问题；

• 侧边的Platform逐渐变大，这其实也是软件提供商的商机所在。Kubernetes比较框架和底层，需要外围的设施来配合使用，前者一家独大、后者百家争鸣；

• Application Definition & Image Build壮大：这是所有基于Kubernetes软件的基础，也就是云原生的原教旨。

4 云原生对云上产品的影响

Cloud Native对于云上产品的影响是深远的，云原生带来的一个典型的变化就是：

很多云上产品要以Kubernetes为运行环境

4.1 云原生技术对架构层次的影响

云原生技术对架构层次的影响，可能冲击原本很简单的IaaS、PaaS、SaaS的架构层次。



A 网络和存储

网络（Network）、存储（Storage）是最基本的设施，它们有可能以特殊的硬件来提供。

在Kubernetes技术体系中，对于IaaS层的Virtualization、Servers这两层可以看不见（或者根本没有），但是会有CSI、CNI等网络层的抽象，也提供了移植能力。

B 运行时

运行时（Runtime）原本代表了应用的运行环境，至于运行的是什么应用，这是说不定的。

在较早的PaaS层定义中，Runtime常常指一个特定语言的运行环境，比如：PHP的运行环境、Java的运行环境。

在Kubernetes体系中，如果套用既有的层次结构，通常是这种情况：

• PaaS的OS是Linux、没有Virtualization、Servers；

• PaaS里面的Runtime 是Kubernetes加上它下面的Docker；

• 对于PaaS的使用者来是，Kubernetes能运行的东西就是一个Docker Image，这其实可以是各种各样的软件；

• 对于PaaS的使用者来是，Docker Image也可以是基础Image+用户Image，这其实又变成类似特定语言的运行环境。

C 中间件

在传统的概念中，中间件（Middleware）也常常包括MySql等数据库、Kakfa等消息队列。

从应用开发者的角度，这些中间件属于下层，并且常常有独立的部署环境。

在Kubernetes技术体系中，长远来看，数据库、流、消息等“中间件”与应用没有区别，它们也可以运行在Kubernetes上面。

随着技术的发展，“中间件”这个层次如果包括数据库、流、消息，它在IaaS、PaaS、SaaS的图中，并不应该算作一个单独的层次。

从实际操作的角度，一个数据库产品，其原本的运行环境可能是物理机、虚拟器，二者对于软件其实并没有实际的差别，但如果它运行在Kubernetes上面，那软件本身就需要改造了：Helm安装、Operator运维。

D 应用和数据

按照原本的定义，应用（Application）和数据（Data）原本是SaaS层才提供的东西，PaaS层只提供运行时（Runtime）。

在Kubernetes技术体系中，如果还一定要按照IaaS、PaaS区分，在Kubernetes运行的软件，可以视为PaaS的能力。

4.2 云原生技术对云上生态

Kubernetes技术体系本身的标准化特性，也云上产品和生态新模式。

独立软件开发商（Independent Software Vendors）在这个过程中有了作为的空间，它们可以与云服务提供商合作，对客户提供服务。

场景1：A云服务提供商提供Kubernetes环境，上面可以运行B独立软件开发商提供的软件，二者合起来对客户提供价值。

场景2：客户可以要求云服务提供商提供独立的Kubernetes环境，自己在上面运行各种软件、自行管理，这种模式对于云服务提供商来说仍是公有云，但对于客户，却很有私有环境的操作空间。

场景3：很多软件产品会演化成，既支持自我小PaaS在物理机、虚拟机部署，也支持Kubernetes部署，前者可能有利于公有云的深度优化，有着可能用于私有云部署更便利。

场景4：一些比较复杂的软件，原本只能自己部署好，以RestfrulAPI或者界面的方式给用户提供服务，但目前只有把它移植在Kubernetes，就可以在其他的环境部署，作为软件服务提供。

一个典型的方向就是，由于Kubernetes提供的标准化部署方式，软件的可移植、可装配的能力变迁，在不同云环境的迁移能力也变强。

5 云上一些典型基础产品

云上的一些基础产品，可谓是大同小异，由于Kubernetes云原生的出现，大格局略有变化。

腾讯云、阿里云上面的基础产品，大约分成几种类型：

1.       （红色）IaaS类服务器：某某云服务器、物理机、裸金属，对于客户来说，它们都是租来当服务器用的。

2.       （棕色）容器平台：一般是基于Kubernetes的容器平台，可能分成资源池、独立集群的模式；

3.       （绿色）存储类：对象存储、CDN等；

4.       （蓝色）网络类：网关、负载均衡等；

5.       （紫色）数据库类：关系数据流、NoSql数据库等，业界的类型比较类似；



以下是腾讯云上面的基础产品。

以下是阿里云上面的基础产品。







对于公有云上面客户的角度看：拿服务器、容器平台开发自己的应用，拿数据库作为自己应用的依赖，拿网络类、存储类当自己应用的配套设施。

这些PaaS类的产品虽然看起类似，但类不同云上面的内在实现却不同，从表现看大都包括几个方面：

• 使用场景

• 计费方式

• 使用示例

• 高可用等指标

• 分布式方案

基础类的产品大同小异，也是云上生态的基础。至于大数据、AI、IOT等云服务，则要比基础产品综合，有些类似解决方案模式。