分析OpenStack 的商业模式

　　从业经历，在电信、企业软件、存储以及云计算等领域做过研发、管理和架构设计等工作。从 2012 年开始学习 OpenStack，对其核心模块有较深入的了解；带领过团队开发OpenStack模块。

　　谨以此文作为《OpenStack企业私有云的若干需求》系列文章的阶段性收尾之作。继前几篇文章讨论了企业用户对 OpenStack 的各种需求之后，本文将讨论 OpenStack 的商业模式，并以 Mirantis 的商业模式为例，与 Red Hat 的商业模式做对比。本文中的观点谨代表作者的个人观点。

　　OpenStack 的价值在于其开放性和标准化的API

　　OpenStack 到目前为止的主要成果，是借助社区的力量，实现了类似于 AWS 和 VMware 这样的的云管理系统，当前它主要是部署在私有云或者小规模公有云环境中。就像我在 OpenStack Austin 峰会观察：OpenStack as IaaS 已是过去，Solutions on OpenStack 才是未来 一文中所述，这种云操作系统本身没有什么太多的新意，毕竟 OpenStack 作为该领域内的后来者，它在过去的这一阶段中主要还是扮演追赶者甚至模仿者的角色。因此，它所实现的功能基本上都能在 AWS 和 VMware 中找到类似的或者相同的功能，甚至还没它们实现得好。

　　那有人就会问，OpenStack 的价值到底在哪里？个人认为，OpenStack 的价值主要在于其开放性和标准化的 API，原因主要包括：

　　（1）开放性带来了如下几样东西，它们都是OpenStack 在过去和将来发展所离不开的基石。

　　庞大的开发者社区：它提供了足够的开发资源，使得他们能很快实现私有云所需要的最基本功能，使得它能快速赶上 VMware 和 AWS，而不至于被它们甩开。

　　庞大的从业群体：一个开源项目，提供的只是由开源社区中的开发者开发的代码，它离进入企业的生产环境还有相当长的距离，这个差距的弥补要依靠从事OpenStack 产品化的大量企业，包括传统企业新设立的 OpenStack 部门，以及广大 OpenStack 创业公司等。这些公司需要大量的从业人员，包括产品、研发和市场等。而 OpenStack 的开放性也使得快速培养大量人才成为可能，因为除了公司自己培训外，人才们还可以通过自我学习和互相交流来快速成长，同时还保证了人才的充分流动性。

　　健全的生态环境：OpenStack 只是作为 IaaS 层面，它本身除了虚机和存储以外，不向用户提供能使用的其它东西。这些东西必须依赖围绕 OpenStack 所形成的生态提供。OpenStack 的开放性，使得这个生态能主动地选择 OpenStack 作为其载体。这个生态圈可以分为上层和下层，下层主要包括硬件，即服务器网络存储之类；上层主要是各种行业应用。与其对比的是， VMware 和 AWS 则需要自己开发和培养生态群，因此其过程是被动的。

　　低成本并且减少厂商锁定的产品：客观地说，消除厂商锁定是不可能的，但是 OpenStack 的开放性有利于减少厂商锁定。特别是全部由社区代码组成的产品，其厂商锁定力度更小，成本更低。

　　（2）标准化的 API 带来了与 OpenStack 集成的便捷性和低成本。

　　OpenStack 作为云解决方案，它区别于虚机化方案比如 VMware 的一个显著特征是它有方便易用全面的 API；区别于公有云的一些显著特征是它的 API 是标准开放的。只要是基于 OpenStack 的厂商，那么它所提供的 API 都是一样的。这会带来几个好处：

　　应用与 OpenStack 集成的便捷性：这些应用厂商再也不需要一个一个地与不同的云提供商的云做集成，他们只需要和 OpenStack API 做集成即可。

　　应用与 OpenStack 集成的低成本，这会带来集成厂商的积极性，从而使生态更加繁荣。

　　有利于搭建混合云。

　　OpenStack 目前所具有的一些问题恰恰也是来源于它的开放性

　　OpenStack 目前这种松散的社区组织形式，也给其带来了一些困扰甚至阻碍，主要有：

　　社区做出的是项目，是代码，而不是产品。去年 Gartner 就曾经 “在现场认为 OpenStack 是一个科学项目”。

　　社区中的绝大多数人是架构师和开发者，对产品层面专注不够，因此，许多功能只是可用，但是不好用，不经用。

　　社区缺乏产品经理角色，尤其是企业级产品的产品经理角色，因此，社区对许多企业级需求投入有限。目前项目总数非常庞大，但是可用的其实也就那么几个。企业级产品需要的一些特性，比如RAS、扩展性、用户操作性、可维护性等，都比较缺乏。

　　组件之间缺乏统一性，以 PTL 为 Project leader 这种组织形式，缺乏更高层面的协调性和统一性。

　　很多组件的设计其实是一种妥协。部分原因是因为各大厂商都参与其中，每个公司的需求不同，目的不同，导致设计出的产品只能是一种妥协的产物，而不是给客户提供的最佳实现。

　　核心模块的成熟度依然不高。以 Nova 和 Neutron 为例，它们都是 IaaS 的核心模块，尽管经历了13个版本，但是bug依然为数众多，高级特性依然缺乏。

　　作为IaaS，还不能一统底层IT环境，许多厂家的参与度还不高。以Neutron FWaaS 和 VPNaaS 为例，相关厂家的参与度依然较低，导致其覆盖面依然有所缺乏。

　　生态中的外部社区和 OpenStack 打交道可能面临找不到人的局面。模块之间组织松散，缺乏核心的看全局的人，导致这些外部社区在与 OpenStack 社区打交道时有困惑不知道该找谁。