您好,欢迎来电子发烧友网! ,新用户?[免费注册]

您的位置:电子发烧友网>源码下载>数值算法/人工智能>

分析OpenStack 的商业模式

大小:0.8 MB 人气: 2017-10-10 需要积分:1

  从业经历,在电信、企业软件、存储以及云计算等领域做过研发、管理和架构设计等工作。从 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 的开放性有利于减少厂商锁定。特别是全部由社区代码组成的产品,其厂商锁定力度更小,成本更低。

  分析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 社区打交道时有困惑不知道该找谁。

非常好我支持^.^

(0) 0%

不好我反对

(1) 100%

      发表评论

      用户评论
      评价:好评中评差评

      发表评论,获取积分! 请遵守相关规定!