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

大部分的软件工作者都对 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 ）关注我们。