专访 Pivotal 刘伟光:怀开源之初心,迈向云原生时代

  • 木环

2016 年 8 月 16 日

话题:语言 & 开发架构运维

大部分的软件工作者都对 Redis、RabbitMQ、Greenplum、Spring 等开源项目有所了解,其实这些技术都源自一家公司——Pivotal。Pivotal 于 2013 年正式成立,专注于第三方 PaaS 平台和大数据技术,技术积累可以追溯到两家联合创始公司 EMC 和 VMware 的部分项目。InfoQ 就 Pivotal 的本地化经验、开源策略、云原生对 Pivotal 大中华区总经理刘伟光进行了采访。

InfoQ:作为一家美国公司,Pivotal 能否分享下在中国市场的本地化经验?

刘伟光:“本地化”在我看来有三个层级:首先就是产品的本地化。其次,Pivotal 的产品都按照开源基金会的模式运作,国内已有企业加入像 Cloud Foundry、GreenPlum 的开源基金会。代码都是公开的,国内要求软件的自主可控,因此代码公开也是本地化策略之一;最后一种最为严格,就是要求软件归属于国产品牌。不同行业对本地化程度的要求不一样,国内电信和金融两大行业对技术的开放度比较高,与此同时这两大行业的业务压力也很大,对技术的要求也很高。

我个人认为,外国软件虽然在国外积累了很多最佳实践,但是照搬这些经验往往很难在中国发挥作用。中国的软件行业有一个特点,是市场推动 IT 的发展,一个想法往往是在市场中诞生,然后才有对应的软件开发出来。外国企业首先不容易紧密贴合中国的市场需求,其次很难适应中国市场的快速变化。

Pivotal 在中国的本地化大致分为“三步走”的策略。我们公司做的是平台软件,直接与底层打交道,对于第一类的产品层面的本地化,需要做的部分不像应用软件那样多。其次,我们采用的是开源策略,产品代码是可以开放共享给客户的;我们与客户共同在现场开发的部分的知识产权可以交给客户,因此,第二类的代码公开的本地化也实现了。此外,我们已经和中国最大的软件公司之一——浪潮达成了 OEM 战略合作协议,可以解释为,通过使用国产化品牌享受 Pivotal 的技术,这是第三个层级的品牌本地化。

InfoQ:能解释下为什么你们会选择开源众多项目吗,如 Redis、RabbitMQ、Greenplum、Spring Boot、Spring Batch、Cloud Foundary 等?

刘伟光:技术开源是全球软件行业的一个大趋势,也与国内自主可控的要求不谋而合。我们想想,传统上两大不开源的公司是谁呢?微软和甲骨文,他们是纯商业化的公司。但是,今天我们已经可以看到两家公司的开源策略,他们都投资或者收购了一些开源性的公司,并且与开源公司合作。最不开源的两大公司都在走向这种趋势,由此我们可以推断出来开源是一种不可逆转的潮流和趋势。

十几年前我在甲骨文工作的时候,很多公司和个人,包括我自己,都认为开源不会成势。但是现在开源已经发展得如此火热。为什么开源发展得怎么块?因为如果一个数据库软件只有一个公司来开发,公司投入一百人、一千人、一万人,即使再多难免会形成一个思维定式,囿于自己一家的情况和想法。但是放在社区的话,很多人本身就是用户,将用户的意见反馈到社区,就会有不同的思想和不同的应用需求。社区相当于数不胜数的开发者和公司,他们在帮助你在实践中避过无数个可能遇到的坑,这个力量是无穷的。以前,互联网技术还没有发展迅猛的时候,带宽有限,网上交流不频繁,也缺少通信和协同工作的工具,一定程度上限制了开源社区的互联。原来一个开源技术可能需要花费十年时间才能变得成熟、被人熟知;但是现在有可能两年就被推动起来,比 YARN、Spark、Docker 这些项目,前两年还没有听说过,今年就特别火。

但是光有项目的开源还不足够,我们可以好好想想历史上最成功的两个开源项目是什么?这里我所说的成功不是说拥有最多的人去开发,而是说真正被企业接受并且应用到商业环境里进行大规模地部署。我认为,到目前为止,最成功的两个开源软件,一个是 MySQL,一个是 RedHat Linux。而这两个软件有个共同的特点,就是它们的背后都有个非常强有力的公司支撑。一个开源软件想要成功,成熟的社区火是毫无疑问的必要条件,但是大公司专门的投入、商业的支持才是真正的王道。

选择 Redis、RabbitMQ、Greenplum、Spring Boot、Spring Batch、Cloud Foundary 可以看到,这些不仅仅是热度最高的开源软件产品。而且也是因为 Pivotal 认为基于云计算、分布式技术、DevOps 的云原生平台,这些产品是实现 Cloud Native 最佳的组合。他们涵盖了下一代企业应用技术架构转型的全部能力,从基础的 PaaS 云平台,到分布式微服务、大数据的开发技术框架,全部能找到解决方案,并且 Pivotal 将它们很好的进行了整合,降低了企业开发、使用的难度。当然 Pivotal 的软件宝库里还远远不止这些,其他包括 CICD、协同开发等等都有非常流行强大的软件和工具。

InfoQ:相比过去,在云计算和大数据环境下,您认为开源技术世界接下来又会有怎样发展呢?

刘伟光:在过去,我们常常会认为某种技术是不可替代的,比如关系数据库、某些中间件,但是这种情况在今天已经不存在了。举例说明,随着数据库的发展,没有哪一种数据库可以满足一个大型企业所有的数据要求。打个比方,基础的数据库就好比物质文明,过去人们满足于物质文明;但是现在精神文明也是必要条件,仅仅依靠原有的数据库技术已经难以胜任各种要求了。

一个科研机构历史沉淀的研究数据、一个制造厂商的生产线或者某些日志,每天都会产生很多数据。在过去,这些数据体量很大,系统不具备存储和处理能力;因此是每天删掉的。现在,系统具备了这样的能力,企业就可以思考怎么利用数据产生价值,怎么样形成一个数据库打通内部所有数据的模式;但是在十年前的那种情况下,我们会认为,删除数据就是唯一一种做法。

也就是说拥有变化的思维是很重要的。第一,要对开源技术不断深化认识,第二,要对市场不断深化认识,第三,要对企业经营发展不断深化认识。现在的技术有了长足的发展,系统可以承受的并发量与以前相比不可同日耳语,这是大数据技术兴起的重要前提。大数据追根究底是要对企业的决策链产生决策性的影响。大数据不是简简单单地做报表,不是仅仅是事后诸葛亮;大数据要产生反馈,形成生产闭环:这是大数据和数据仓库的主要区别。我认为,任何企业、任何行业最后一定会发展到大数据的阶段。

InfoQ:您说 Cloud Foundary 在最初设计的时候就是基于容器的,那么为什么 PaaS 平台还支持了很多其他方的开源容器项目,比如 Docker 和 Kubernete?

刘伟光:Cloud Foundary 从第一天起就是基于容器去做的,但是我们没有将对应能力作为一个单独的产品在市场上宣传。我认为 CaaS 不能取替 PaaS,因为 PaaS 做得更完整。

容器技术本身并不是新的技术,它可以追溯到 Linux 出现的时期。容器的最大价值在于各类应用可以从一个环境漂移到另外一个环境。开发者不需要关心使用者在什么环境,开发对应的环境可以自动漂移到对方。那么为什么容器技术需要编排呢?因为在企业的应用层面来看,如果容器特别多,虽然简化了开发工作但是加大了管理的复杂度。

这两年 Docker 快速发展,领跑容器界也是不争的事实。但是还有一个事实需要强调, Docker 也是 Cloud Foundary 基金会公司的之一,也就是说 Docker 也是 Cloud Foundary 的贡献者。

首先,我们融合了很多 Docker 的先进技术;其次,最重要的改变是Open Container 成立。Docker 技术还没有成熟,时常有一些版本变化,于是,我们一些公司站出来说,需要统一容器的标准。规范标准的书写由两家企业在积极地推动着:Pivotal 和 Docker。

InfoQ:您说“云原生是 Pivotal 提出来的”,那能谈谈这个想法的产生过程吗?为什么会有这样的先见?

刘伟光:这个问题我想先从 DevOps 和 PaaS 谈起。DevOps 的提出者现在已经加入 Pivotal 工作。DevOps 和云原生是现在比较火的两个概念,这两个概念提出来有一段时间了,为什么这两年变得特别火呢?因为谈云原生必须谈 PaaS 平台。

IaaS 平台专注于底层的硬件资源,与上层的应用实现,其关注点还是不大相同的 。PaaS 需要关注所有应用的运行时、中间件、高可用、路由分发、横线扩展、监控管理、日志分析、自愈等等。如果不采用 PaaS 平台,那就需要自行考虑实现这些内容,最后对接 IaaS。而 PaaS 平台代替大家把这些繁琐复杂的工作做了,PaaS 对下可以对接 IaaS 平台并通过容器化的方式更加高效地实现资源使用,对上可以提供企业级软件所需的平台服务内容、监控管理功能并支持企业应用的高效安全运行。通过我们研发的 PaaS 平台,用户可以通过统一的管理界面了解当前所有应用的运行状态、应用的并行度、哪些服务绑定了哪些应用、服务的资源使用状况等,并最终实现企业应用的全生命周期管理。这是实现 DevOps 非常关键的部分。DevOps 的精髓就是打破开发、测试和生产组织和 IT 环境的壁垒,使得使得开发人员和运维人员统一使命,有效消除无意义的工作时间消耗,能够更加高效地协同工作实现更加快捷高效的 IT 组织,而 PaaS 平台是重要的支撑,以帮助最终实现 DevOps。

回到问题上来,这世界上没有什么先知,只能说所有的东西都是经过不断积累、不断地总结教训才发展出来。 PaaS 作为承载应用的平台,应用的类型是可以完全不一样的,有大的、小的、新的、老的。我们在给客户往我们的 PaaS 平台上迁移应用时,发现老的应用部署上去后虽然可以正常运行,但是平台提供的很多云平台的特性,如应用弹性伸缩带来的性能线性扩展、应用微服务化等等,是不能充分利用的,因为老的应用软件还是按照传统的应用架构实现思路来构建的 。这样就导致客户抱怨说,虽然上云了,但是云平台的好处却不能全部享受,于是接下来就需要帮助客户一点点去地解耦和整合。

我们就反向地想,能不能设计出一个 Cloud Native 的原型,让客户新开发的应用可以自然而然地全面享受云平台的服务?Pivotal 总结了一些设计原则和编码原则,如果遵循这些原则,就可以完全发挥 PaaS 云的价值。Pivotal 将这些理论化的东西称为云原生。顾名思义,你的应用是为云而生长的,特别适合在云上进行部署。我们也形成我们的整个云原生的成熟度的这个模型,评估你的成熟度,这个也包括:开发的流程是否是采用敏捷开发的方式?是否能够达到在上 PaaS 之后最佳的运行效果?现代化的微服务应用架构有没有实践?以及应该使用什么样的持续交付工具等等。

InfoQ:怎么看待 PaaS 的使用者,需要作出一定的改变才能实现云原生应用?比如要使用敏捷开发,而敏捷开发目前在国内发展受到阻碍。

刘伟光:客户改变的好处是运维可以得到很大的效率提升。如果站在 CIO 的角度来看,如果公司选择云作为既定战略,那么团队组织、开发流程和方法都应该对应地做出改变,最后整体效率是会得到巨大的提升的。

关于敏捷开发受阻的情况我认为这很正常,任何一种技术都需要一个发展过程,不能说让所有人都统一地接受。目前国内的 IT 发展势头迅猛,十年前,金融和电信两大行业是技术的先行者;现在互联网行业成为技术开拓者。在国外,新技术都是产生于制造行业,比如德国的奔驰和宝马。所以不同行业会有一个技术采用的时间顺序问题。中国的互联网乐于试错去改变自己是一个好现象,我们在软件开发中碰到很多坑,但同时我们也在不断地进行技术迭代,抛去冗余的东西,而这是敏捷开发的基本思想。如果你不能实现软件版本的快速迭代,你在市场上就会失去竞争力;需要跟进客户体验,进行功能迭代,防止软件同质化,这就是软件公司的生命力。

敏捷开发这个词十年前就有了,但没有和云结合在一起。在过去就是个独立的技术体系,而今天,敏捷开发与跟持续开发、持续集成、云的理念是相通的;可以通过工具将敏捷开发理论和云结合在一起,令二者一脉相承。逐渐的,很多企业在重新审视敏捷开发的理念,我们期待着敏捷开发的改变与新生。


感谢徐川对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

语言 & 开发架构运维