在接受不同采访时我经常会被问到这么一个问题： OpenStack到底发生了什么？就像人们认为OpenStack已经死了一样。而每次面对这个问题，我都会在回 答之前做出害羞无辜的表情。这里我要给大家一个提示： OpenStack并没有死，只是经历了风雨。

这个项目目前运作仍十分健康，依旧遵循发展曲线推进：OpenStack发展至今已足够成熟，这一点已经不足以引起人们的兴趣来引发讨论了，所以大家随之在想OpenStack是不是发生了什么，这种情况是可以理解的。

问我这个问题的人通常好奇又善意，我认为我的回答跟我的专业背景有很大的关系，所以即使是在采访时，我会偏向于采用闲聊的方式。 我决定今天重新讨论这个话题。下次要是再有人问同样问题，我就会让他来读一读这篇文章。

要知道，为了实现生态系统长期持久的成功，我们需要一个超规模的 OpenStack公有云，还需要在我们已有的Iaas/Paas层上构建一套健康的SaaS应用程序， 除此之外，我们还需要在多个 hyperscale来避免引力问题（在早期，这就是RackSpace）。

很多人都在公开场合谈论到的一点是，常见的头条新闻将 OpenStack与AWS进行比较，每个风险投资机构和分析师都想知道OpenStack是否已经为企业提供服务做好了准备。我甚至还曾在一个小组讨论里探讨过这个问题！（网上有链接记录，但我不会在这里分享，因为我不想回忆当年自己的形象）但随着时间的推移， 我们成功的关键部分从未实现。为什么会这样呢？

早在2014年时，我在惠普云工作，那时候资金正源源不断地流入OpenStack，我们也正为此得意洋洋，那是OpenStack发展达到顶峰的一年，巴黎峰会上嘉年华的场景对于现在的我来说依然记忆犹新。这一现象实则出于电信公司和硬件供应商试图影响OpenStack方向的原因，但对于局外人却是雾里看花。更具体地来说，这些公司希望为他们能够迅速上市的集成私有云解决方案创造技术基础。

而在私底下，我们可以看到，这些市场势力与 hyperscale实际实现是背道而驰的。大帐篷项目（The Big Tent ）是一个试图解决当中一些问题的大胆之举。我们（即技术委员会）使劲自己最大的力气，但最终还是无法解决这些问题，因为钱包控制权并不掌握在我们手中。

正如大家所看到的，当时几乎所有为 OpenStack做出重大贡献的公司都依赖于企业客户，这其实是业内知名公司每年花费巨资在彼此合作的公司之上的另一种较为好听的说法。与 hyper-scalers 不同，企业客户通常对构建自己的服务器或编写自己的交换机固件并不感兴趣，他们会选择从这些产品服务提供商那里购买（以及给他们的支持合同），并且希望继续从这些交易中赚钱。

与此同时，发行商和运营商正努力实现OpenStack可安装，以便能够展开和维护部署来满足市场需求。而且企业对新的私有云领域的需求非常高。OpenStack开发团队面临（来自于发行商、电信公司、硬件供应商）巨大的内部压力，他们要在具有地理弹性的少部分地区大约的1000-10000个核心中创建企业客户所需并运行良好的软件。

但是，为10000个和为10000000个核心构建分布式系统存在根本性的差异。除了要改变代码之外，增加三个数量级还需要对任何业务的运行方式进行根本性的改变。利润率会越来越小。第三方支持合同、B2B交易、增值软件这些被视为销售团队“车轮的润滑油”已经不复存在了。企业硬件和软件巨头不愿意重组那么多业务，而像OVH这样的公司其自然增长速度太慢了，尽管我认为他们仍然走在正确的轨道上。

创建一个可行的、开源的、超大规模的云软件解决方案与对OpenStack开发投资最多的公司的最大利益。

有一天，我以我一贯的方式试图在餐巾纸画出以下的图。原来的版本已经遗失很久了，所以我把它从下面的记忆中重新画出来。

影响来自错误的方向。电信公司、硬件供应商和发行商的产品管理（如ATT、思科、戴尔和红帽等）投入大量资金来施加影响力、雇佣程序员编写代码、为奢华派对提供资金并推高工资水平（毫不掩饰地说，我确实很喜欢这些派对活动，同时我的薪酬待遇也很好）。与此同时，运营商越来越落后于发布进程，几乎没有发声（毕竟他们正忙着云的运行），云的最终用户（应用程序开发人员）也几乎没有发声。

到最后，营收需要从云端上受支持业务的增长（即APP程序开发人员的成功）中获得，但我们却没能实现这个目标，因为运营商无法充分扩大规模，或无法保持和维护一个健康市场在云端上蓬勃发展所需的跨云兼容性。图表左侧的每个人都忙于寻找自己的差异性优势，从而无法促成彼此间的交易。

在这个情况下，作为可以看到问题所在的上游技术团队领导正向我们每个公司内部进行游说，希望能够改变优先事项。我们说服了一些管理者和执行者在代码和基础设施方面进行战术投资，但我们无法获得足够的支持来应对所需的更大变化。

只要金融影响者专注于中型客户（MSP和企业市场）的商业模式，对于让OpenStack在超大规模市场上具有竞争力所需的大量战略方面，他们并无投资意愿。因此，绝大多数开发人员在面对自己所属的项目目标由项目经理和他们雇主内部的管理人员决定时，都忙于将一切为利用“增值集成”所设计的特性（也就是企业销售周期中的润滑油）驱动到代码库中，没有人能够解决对于正忙于扩大云规模的部署人员来说很明显的核心问题。

成功的 hyperscalers 已经消除了中间件的边际成本。谷歌、 AWS，甚至Facebook都在制造自己的服务器、交换机、存储设备等。他们提供开源项目，然后付钱给开发人员进行维护和私有云版本的改进，这样他们就可以保持领先，而一些项目现在正尝试阻止这一趋势。这些公司通过削减基础设施的成本来扩大规模，但这些效率驱动举措并没能让它们回到企业级市场中。他们在很大程度上成为了如今的巨头，通过构建流程、打造团队和搭建硬件来打破对第三方软件和硬件的依赖和支持。

所以你可以看到，创建一个可行的、开放源码的、超大规模的云软件解决方案是违背了对OpenStack开发投资最多的公司的最大利益的。

当你在看其他云产品的时候，思考下当下可能会对你最喜爱的代言人产生影响的的相似利益冲突（Kubernetes，我正在看着你呢）

对于我们中那些早早加入OpenStack并梦想成为大人物的人，我想说：好吧，我们没有机会在OpenStack中构建这些梦想了。OpenStack已经变成一种没有梦想光环但或许更实用的可扩展工具，用于中等规模的基础设施自动化，助力世界各地数千家企业，这包括许多非营利性和公益性机构。

而且，我想阐明的是，我很高兴能够通过采用我的方式帮助构建成了一个被广泛使用的工具。

我现在发表这篇文章，是希望它能对所有在 Kubernetes. 投资的人起到警示作用。你将永远无法像 GKE那样以同样的规模并有效地运行它——除非你也一样在组织全面变革方面进行投资。

即便如此，如果你使用Kubernetes，你可能也不会成功，因为让其他人真正与GKE竞争是与谷歌的最大利益相悖的。

也许这也没关系。事实上，OpenStack+Kubernetes是对于你正在构建的合适的模式，而且这两个项目也不会在短期内实现无处不在的模式。

如果另一家公司想在 hyperscale 的空间中立于不败之地，它需要从整体上审视自身的业务机构，并重复 Google/Facebook/Amazon的开放源代码私有化模式，把资金投资在自己的服务器制造中，或者与其他垂直聚焦的开放源代码企业联合才得以在市场上与对手竞争。