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

发布于: 2020 年 05 月 17 日
浅谈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等云服务,则要比基础产品综合,有些类似解决方案模式。

 

用户头像

韩超

关注

还未添加个人签名 2017.10.20 加入

还未添加个人简介

评论 (1 条评论)

发布
用户头像
非常详细、用心的一篇文章。 云原生对整个软件开发模式带来了非常大的影响。整个infra 层架构变复杂了。因为应用以前需要自己考虑的问题被转移到了infra 层。
2020 年 05 月 20 日 16:00
回复
加油,云原生时代要考虑的问题比之前多了
2020 年 05 月 21 日 13:47
回复
北风 回复 韩超
对,架构复杂性升高了很多很多
2020 年 05 月 21 日 23:33
回复
没有更多了
浅谈Cloud Native技术对云上产品的影响