容器云平台在传统企业落地的一些思考和探索

 

本文内容是我今天在一个云原生论坛上演讲的材料,加上一些备注,现在分享给大家。 

 

 

从应用的承载和部署方式这一角度看,一共经历了传统的物理机架构、虚拟化架构、和现在的容器化三种架构。但是,容器并不是一种虚拟化技术,它与虚拟机有实质性区别。

 

虽然把云分为IaaS、PaaS 和 SaaS 已经好多年了,但是,它们只有的差别,一直是想得出但摸不到。对我个人来说,只有在搞了OpenStack 后才算了解了一些IaaS,只有在用了 OpenShift 后才算了解了一些PaaS。这两个产品,对我都有云启蒙性的帮助。

容器云平台 CaaS 到底在左边还是在右边,这是一个问题,而且讨论了不少年。至少对我来说,我之前是习惯性地把它归到左边,因为把容器类比为虚拟机。但是现在,我认为它更应该归到右边,成为企业PaaS平台的支撑平台。

过去的两三年,容器相关的东西非常火热。和所有新生事物一样,一开始也是杂乱无章。

开源项目上,从 Docker,Swarm,Mesos,到 Kubernetes,再到 OpenShift,各种以容器为基础的技术和产品层出不穷。

技术使用选型上,大家对于怎么用容器也是各有千秋。以阿里为例,他们主推的是富容器Pounch Container,而大家普遍采用的是 Docker 容器,还有 OpenStack 社区力推的 Kata。关于阿里的 Pounch Container,我个人很是疑问,他们是想成为主流呢,还是会被主流淹没呢?会不会重走一遍用KVM 替代 Xen 的路子呢?

而对传统企业来说,虽然越来越多的企业对它在感兴趣,但是容器云落地更是问题多多,我这里列出的只是我接触过的一些比较典型的问题。

我认为人们在为新事物做选择题的时候,往往会用老的思维模式。以容器云平台为例,就比较自然地把它归类到已经熟悉了的虚拟化和IaaS这一类的资源型平台。这种做法就会产生很多问题。我认为这是一种错位。

要解决这些问题,我认为需要将容器云平台提升到 PaaS 层面。这里面有两点需要提一下:

一是企业CIO在这里面的关键作用。当然了,在有些企业是别的类似的角色。只有这个角色,才能统一地将企业的开发和运维统一纳入考虑范围。

二是咨询方案供应商。现在,随着新的技术的层出不穷,有些企业已经有了一些无所适从,既想用,又不知道怎么用。这时候,咨询公司就有了用武之地。

对企业用户来说,他们更看重的是 PaaS 部分的功能,因为这些功能能直接对软件开发和公司业务产生价值;对基于 Kubernetes 或 OpenShift 做产品化的公司来说,他们也应该更加聚焦 PaaS 部分。而 CaaS 部分,我认为,应该由相应的社区来主导。

找到了问题症结和解决方法,那回答问题就相对容易了。

我之前看过一份麦肯锡关于企业数字化转型的一个报告。报告里面提到,科技公司的两个关键所在,就是流程标准化和工具赋能。那结合 PaaS 平台能给用户带来的优势,其实正好,PaaS 平台给企业所带来的,正好就是流程标准化,包括开发流程、软件架构、应用管理等,以及充分利用各种工具和平台所带来的工具赋能。

普遍认为,传统企业数字化转型需要经历三个阶段,分别是 云IT,云 DT,和云 DI 三个阶段。 这和将云分为 IaaS、PaaS 和 SaaS 三个层面有些巧合。
而在云IT阶段,可以大概地认为是IaaS 阶段,它的任务是向企业提供弹性云资源。
云DT阶段,是 PaaS 在企业中起关键作用的阶段。PaaS 能带来IT基础设施、应用架构、开发流程、组织结构的互联网化。
云DI阶段,是SaaS服务发挥关键作用的阶段。AI 作为这一阶段的主要驱动力之一,将以SaaS的形式,被嵌入到各种业务系统之中,来驱动业务创新。

现在和过去的混合云,我想把他们称为混合云1.0,因为主要是网络和存储打通,但是在应用层面没有打通。没打通是有原因的,那是因为没法打通,有很多原因,其中一条是因为格式不同。现在有了容器云PaaS 之后,以容器为应用的统一载体,那打通就相对容易了。

另外,随着混合云和多云概念的火热,云管理平台(CMP)的热度似乎一下子上来了。我认为,在当前存在多种不同IT环境的时期,CMP 的价值是明显的。但是,随着容器云部署在各种IT环境之上,它自己就会承担起部分CMP的功能,到那个时候,CMP 主要就会是PaaS平台的CMP了。

阶段1:孤岛式 IT 环境。问题是资源浪费;不能满足有快速需求的业务。

阶段2:能解决阶段1 的问题,但产生了新的问题,那就是无法满足互联网业务要求。当传统行业不再满足于在本行业的领先地位,希望能够对接到互联网业务的时候,上面的模式就会出现新的痛点。对接互联网所面临的最大的问题,就是巨大的用户量所带来的请求量和数据量,会是原来的N倍,能不能撑得住,大家都心里没底。例如有的客户推出互联网理财秒杀抢购,原来的架构无法承载近百倍的瞬间流量。
阶段3:解决之道

落地是一个非常复杂的问题,甚至都不完全是技术问题。它牵扯到IT架构、应用架构、组织架构多个方面。这不单单是一个技术问题,更是一个组织问题。在推动过程中,更加能够感觉到康威定律的作用,需要更高层次管理者的介入,方能够推动这些在企业的落地。

微服务和容器化的改造,更加容易发生在一个扁平化的组织里面,由一个能够体会到基层技术细节的痛的CIO,高瞻远瞩地推动这件事情。这也是为什么微服务的落地一般率先落地在互联网公司,因为互联网公司的组织架构很平台,哪怕是高层,也离一线非常的近,了解一线的痛。另一个原因是互联网业务强大的驱动力。

在一些相对先进的企业,会在运维组和开发组之间,有个中间件组,或者叫做架构组,来负责推动微服务化改造的事情,架构组就既需要负责劝说业务开发实施微服务化,也要劝说运维组实施容器化,如果架构组的权威性不足,推动往往也会比较困难。

备注:这里有采纳网易云刘超的一些观点,特此感谢。

目标很明确,也有有价值,但是道路的困难大家都知道,那么还是从第一步做起吧。

一、OpenShift 作为 PaaS 平台为红帽带来了很高的溢价。其实,从功能而论,OpenShift 相比 Kubernetes 并没有新增多少新的功能。但是,它第一次打造了面向DevOps的PaaS平台的产品,这是具有开创性的。就像新打开一扇大门一样,门并没有多少价值,但是门后的风景才是真正的价值。

二、根据前面的分析,PaaS 平台在企业的落地需要有咨询商这一角色的存在,而无疑IBM深谙这个领域。因此我对红帽的PaaS产品和IBM的咨询服务能力会怎么结合充满期待。

三、IBM发的公告里面特意提到了混合云,不知道IBM 会不会利用 OpenShift 来实现我前面画的那种混合云2.0。

另外,有时候我会想,为什么只有红帽能推出OpenShift 这种PaaS平台呢?我认为这和只有 Google 能推出 Kubernetes 是一样的,那就是公司的基因。正是因为他们自己长期使用容器,长期实践DevOps,才能比较自然地做出大家普遍能接受的产品。