根据OpenStack基金会收集到的数据，生产型云项目在规模上仍然相当有限，不过大家也不能将此视为最终结论——毕竟即使是参与到调查中的受访者也没有确切提供其项目的原始数据，甚至出于匿名性考虑而对数据有所保留——仍有不少企业拒绝公开与其项目相关的详细信息。
一般来说，主流生产云项目的节点数量一般在50个以下、计算核心数量则不超过100个，不过大家通过上图可以看到，少数生产型OpenStack云项目拥有数百甚至上千个节点、计算核心数量也在数千乃至数万之间。 如果姑且忽略那些并未使用对象存储机制或者拒绝公布相关细节的客户，那么就目前而言OpenStack生产型云项目所包含的对象数据一般低于10万个。当然，也有一些云项目拥有上亿个存储对象，但这只能算是特例。在块存储方面，这一结论也同样有效。大部分生产型云项目的块存储容量在100TB以下，少数项目则率先将其推进到了PB级别。 正如大家预期的那样，OpenStack也为超大规模数据中心运营商准备了与Puppet及Chef类似的配置管理工具，此外该项目还准备了一系更其它工具、旨在进一步帮助客户完成OpenStack云的设置工作：
再将目光转向虚拟机管理程序方面，作为目前Canonical与红帽为OpenStack选定的标准搭档、双方心目中理想Linux-OpenStack组合的构成元素，KVM在诸多选项中无疑最具吸引力。有趣的是，VMware的ESXi、LXC容器以及Docker容器在概念验证型云项目中的人气要远高于生产环境，这可能为我们带来了另一项值得关注的参考指标。 就在本次OpenStack峰会上，众多企业讨论了自身如何利用OpenStack技术对各种类型与规格下的物理及虚拟设备进行管理。举例来说，在长期运行流程中，企业用户可以保持ESXi的运作而不必使用VMware的vCloud。这能为他们回避大量虚拟机转换所带来的技术困扰，并借此实际成本节约。微软的Hyper-V也是同理，OpenStack同样可以对其加以控制。对于那些同时使用三大主流虚拟机管理程序的企业用户——例如一家需要在内部环境中分别建立Linux与Windows应用程序开发团队的大型企业——来说，OpenStack的出现能够将原本彼此孤立的业务流程转化为一整套混合环境。 为了将虚拟机管理程序与OpenStack接驳在一处，必要的网络驱动程序自然也是种类繁多、不一而足。在此之一，Open vSwitch的流行程度最高，甚至俨然有些OpenStack标准配备的意思。不过尽管如此，生产云项目中的网络方案在多样性方面还是要远远超过虚拟机管理程序。 无论大家是否相信，已经有人宣布在生产项目中成功运行了OpenStack的Austin初始版本——Lane表示他本人对此是绝不相信的。作为该版本下辖的三个子版本，代号分别为Bexar、Cactus以及Diablo的三套发行版也取得了不错的使用率。 作为第一款可用版本，Essex仍然活跃在61个云项目当中，而于2012年发布的Folsom则占据64台设备，接下来的是在一年前OpenStack真正获得市场关注时登场的Grizzly版本、它出现在84台设备之上。去年秋季面世的Havana版本占据42个云项目，而就在一个月前刚刚诞生的Icehouse版本也已经拥有五位支持者。有趣的是，有26个云项目没有等待正式版本发布而选择了自主进行技术更新。
在新近出炉的这份OpenStack调查报告中，我们还发现了另一种值得关注的现象，即仍有一部分客户在使用能够让OpenStack与Amazon Web Services中EC2计算与S3对象存储服务相兼容的API。具体来讲，目前有87个云项目使用EC2 API，另有54个云项目使用S3 API。除此之外，另有一些客户在使用开放云计算接口（简称OCCI）API，不过目前还没有将谷歌计算引擎的API引入项目的先例。 思杰公司放弃早期OpenStack研发成果、转而收购Cloud.com并将CloudStack作为Apache项目加以开源的理由之一是，Rackspace坚持认为与AWS保持兼容不应作为OpenStack项目发展过程中的主要任务。 通过调查可以看到，思杰选择的AWS兼容之路还是受到了包括Eucalyptus Systems在内的其它厂商的认同，后者推出的同名云控制器希望尽可能多地克隆AWS服务、并借此构建起一套规模较小的新兴项目。OpenStack决定寻求属于自己的发展道路，根据自己的判断处理问题，这当然有其可取之处。然而必须强调的是，对AWS的兼容性在很多企业用户眼中仍是一项不容忽略的重要优势。 |
