OpenStack的八年之痒
2010年10月，OpenStack发布了第一个版本；上个月，发布了它的第18个版本Rocky。几年前气氛火爆，如今却有些冷清。到底是为什么才短短几年却出现如此大的转折呢？作为一个用户，在这篇文章里，我会尝试从用户视角，反思在过去的八年里，OpenStack到底走了一条怎样的路；我也会试着展望从现在起的八年之后，它会过得好不好，甚至还在不在。
我们是怎样的一个用户？
我们作为某大型集团基础云平台团队的一部分，在集团内搭建了一个面向集团内部用户的企业基础云平台：
其主要特征如下：
计算：支持KVM、ESXi 和裸金属服务器等三个资源池。
网络：采用 Neutron + VLAN + OVS 实现了虚拟网络。
存储：采用 Ceph 和 SAN 实现了块存储，采用Ceph实现了对象存储。
区：在两个城市三个机房部署了3个区域，每个区域内划分资源池，资源池内再按机架划分可用区。三个层级都用户都可见，可按需选择。另外，我们还尝试搞过一个小型公有云区域。
功能：利用了Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等组件。
管理：采用自研云管理平台管理多个区域。
容器云平台：基于Kubernetes的容器云平台运行在自己管理的物理机上。
团队：最多时候8个人的OpenStack研发团队，3个人的运维团队。
我作为团队负责人，在做完这项目后，有如下几点感受：
这个云平台运行的还蛮好，我们在规划、技术和产品选型、研发、运维等方面都做得不错，团队非常给力，研发周期较短，迭代快速。现在它支撑着集团大大小小几百套系统，而且很稳定，运维压力已经比较小了。
也出现过若干稳定性问题：比如Neutron VR 偶尔会自动切换（我们还有一个小型公有云环境，采用Neutron +VR + OVS 架构）；KVM虚拟机偶尔自动重启甚至宕机等；KVM对windows的支持比较差，偶尔出现莫名其妙的问题，比如磁盘脱机、蓝屏、无法启动等。
监控组件、日志组件很不健全，都需要我们自己大改或者从零搭建。
除了核心模块，其它模块的产品化程度都不太高。以Trove为例，我们花了不少时间，几乎重写了一半的代码，也就实现了最基本的数据库实例的创建和管理功能。
OpenStack 离公有云需求的差距还比较远，比如在网络和规模性上。
OpenStack 的定位和对标到底该是什么？
OpenStack社区在2010年提出的原始使命是『提供一个满足公有云和私有云需求的开源的云计算平台』。那个时候，其实私有云还没什么参照物，因此可以认为最早的时候OpenStack的使命就是做开源的AWS。然而，从2014年起每年的用户调查结果看，公有云不是OpenStack的主战场，而私有云才是，因为本地部署的（On-Premise）和外部部署的（off-premise）这两种私有云环境加起来超过了80%，而公有云的比率在2017年才12%，而且是逐年不断萎缩。因此，说OpenStack的实际定位是在私有云，这个我相信是毋庸置疑的。
企业私有云环境中，VMware是真正的老大。因此，OpenStack既然要做私有云，其目标就是要替代掉VMware。而 VMware vSphere提供的只是虚拟化环境，因此OpenStack的对标对象我认为应该是 『VMware的虚拟化功能部分』+『AWS的Cloud功能部分，主要是云API』。但是，因为一开始OpenStack对标的是 AWS，而AWS是公有云不是私有云，这就导致了后来很多问题的出现，下文会仔细道来。
『VMware 虚拟化』+『AWS Cloud 功能』这两部分中，因为一开始OpenStack 就是对标AWS的，因此 『Cloud』部分应该说做得还是很不错的。这从用户调查中的『为什么组织会选择OpenStack？』部分的答案中也能看出来，即开放平台和API的标准化是第一业务驱动力。
那『VMware 虚拟化』对标部分的情况又如何呢？来看一下VMware vSphere 和OpenStack基础功能的对比：
| VMware 功能 | 描述 | 相应的OpenStack功能 |
| vMotion | 可以使运行中的虚拟机从一台物理服务器实时迁移到另一台物理服务器，它实现了零停机时间和连续可用的服务。vSphere 6.0 支持跨数据中心的vMotion。 | 可以利用 KVM live migration 功能实现虚拟的实时迁移，但是需要结合第三方工具。 |
| DRS（分布式资源调度） | 跨资源池不间断地监控利用率，并根据反映业务需要和不断变化的优先级的预定义规则，在多台虚拟机之间智能地分配可用资源。 | 不支持。 |
| 分布式电源管理（DPM） | DPM提供了通过动态调整群集容量来匹配虚拟机资源需求，以达到节省电力的目的，DPM自动整合虚拟机到较少的ESXi主机上，并对一定周期内资源利用率低的多于ESXi主机执行断电，如果资源需求增加，ESXi主机重新通电回到群集，虚拟机重新分配到群集内所有可用的ESXI主机上。 | 不支持。 |
| HA | 持续监控资源池中的所有物理服务器，并重启受服务器故障影响的虚拟机。还可以监控和检测虚拟机的“客户操作系统”故障，并在用户指定的间隔后自动启动虚拟机 | 不支持。 |
| FT | 通过创建和维护等同于主虚拟机并可在发生故障切换时替换主虚拟机的辅助虚拟机来为虚拟机提供连续可用性 | 不支持。 |
| vShield | VMware 安全虚拟设备套件 | Neutron 的安全组和防火墙实现了 vShield 的部分功能 |
| vDS（分布式虚拟交换机） | 让用户可以从一个集中界面为整个数据中心设置虚拟机访问交换，从而简化虚拟机网络连接。 | Neutron 利用 OVS 实现了部分功能 |
| Storage API | 存储 | Cinder |
| SRM | 站点灾难恢复 | 有Freezer 项目，但尚不足以进入生产环境。 |
从上表可以看出，很多vSphere 的功能OpenStack都没有实现，或者只实现了一点。那结果只能是，OpenStack 不具备对 VMware 的替代能力，也就无法驱动用户去放弃VMware 转向OpenStack了。当然，你可能会说，把OpenStack和VMware做对比，一个是云另一个是虚拟化，那这是不是牛头不对马嘴呢？我认为不是，因为，一来，用户已经习惯了使用VMware，他们很自然地就会用VMware的标准来要求后来的OpenStack；二来，我是把OpenStack的部分功能，主要是计算功能，和VMware的虚拟化部分做对比。因为对OpenStack来说，计算应该是其最核心的部分。
大帐篷模式的问题到底在哪？
2015年，OpenStack 社区开始使用『大帐篷』模式。该模式把OpenStack项目分成两大类：核心项目和非核心项目。核心项目只有六个，其余都是非核心项目。下面，我简单地对这个模式的一些问题做下说明：
1. 六个核心服务发展得确实不错，但是问题依然不少。
一方面，如下面2017年4月的用户调查结果，前几个核心项目的使用率都超过了90%。另一方面，用户对核心项目的吐槽一直没停止过，每年的用户调查报告中都有好几页记录着用户的槽点。
2. 不管是对比VMware还是对比AWS，我认为OpenStack核心服务的范围都太小了，导致它缺乏了一些必要的功能。我认为至少以下几个服务需要进入核心服务列表：
编排服务Heat：编排服务是云的基础性服务之一。一来用户可以通过编排服务自行创建和销毁云资源，二来很多二级服务可以通过提供编排模版的方式来提供给用户，三来可以与第三方云管平台和工具对接，从而培育生态。
监控服务Ceilometer：一个云生产环境离不开一个强壮的监控服务。到目前为止，Ceilometer 项目都还问题重重，比如规模性问题、性能问题、功能覆盖问题等。
裸机服务Ironic：裸机在私有云中有很多的应用场景，比如运行数据库、大数据平台、容器平台等。如果OpenStack把Ironic做好了，那这就会成为与VMware相比的一大优势，同时还能成为一些需要利用裸机的应用的支撑平台。现在的Ironic项目，实在太重太复杂。
日志服务：同监控服务一样，日志服务也是云平台的一个基础性服务，如同AWS 的CloudWatch和所有项目都打通了一样。遗憾的是，到现在为止，OpenStack都没有一个原生的日志服务项目。
部署服务：部署对私有云很重要。OpenStack需要一个提供象 Mirantis Fuel 这样的图形化一键部署工具的核心服务。
3. OpenStack社区把过多精力耗费在了一些看起来很有前途，但实际上却比较鸡肋的项目中，比如容器服务Magnum、大数据服务 Sahara、数据库服务 Trove、容器化部署服务Kolla。
一方面，用户对这些项目确实很感兴趣。我认为至少有三个原因，一来是人们对新事物都有的好奇心，二来是OpenStack社区的大力宣扬，三是殷切期望。
另一方面，这些服务在实际的生产环境中部署的案例却非常少，而且是越来越少。Trove和Sahara，2015年部署比率都是18%，2016年骤然下降到3%；Magnum，2015年部署比率是4%，而2016和2017年分别是1%和3%。
（备注：图中的数字是百分比）
那到底是什么原因导致这些新服务叫好不叫座呢？我认为一个很重要的原因是私有云和公有云对云平台需求存在很大的差异。一个典型的私有云环境中，往往包括多个平台，比如基于OpenStack的基础云平台、采用物理服务器的大型数据库平台、采用物理服务器的大数据集群，以及采用带GPU的物理服务器的机器学习集群。下图是一个我认为比较典型的私有云环境：
这种环境具有如下几个特点：
只有底层的物理机管理系统是统一的，而上面的多个平台是分离的。而公有云上，云平台是统一的。
平台是分离的。这可能有几个原因，一是管理因素，每个平台往往由不同部门在管理和使用；二是运维因素，把平台都放在一起，运维团队搞不定这个单体平台的运维，必须分而治之；三是技术因素，私有云领域还没出现象AWS和阿里云这种能把这几个平台纳管在一起的统一云平台；四是在某些企业里限于等保和安全的需要，某个大业务需要独占资源池。
除了基础云平台是在虚拟机级别实现多租户外，其它平台往往只是在管理平台层面实现了多租户，或者业务层面自己实现了多租户，而下面是一个或几个大的资源池。
两种云环境中，这些服务（其实应该称为应用服务，与基础服务分开来）的创建和管理方式迥然不同。在公有云环境中，因为多租户需求，云供应商需要提供这些服务的创建和管理服务，使得用户自行创建、管理和销毁这些环境。但是，私有云中，并没有那么多需要反复创建和销毁这些服务的运行环境的需求。因此，在OpenStack 中实现容器、大数据运行环境的自动化创建和销毁服务这种需求不那么强烈。针对这些新应用，OpenStack的使命首先应该是让它们在自身平台上『运行好』，而不是『把运行环境创建好』。
究其原因，我认为这和早期OpenStack的使命有关，因为一开始OpenStack是想做成开源的AWS，自然AWS的服务长什么样子，OpenStack的服务就长成什么样子。问题是，对于私有云和公有云的区别，OpenStack一直没有重视。而且，参照AWS的各个服务在OpenStack中再实现一套，相对来说是比较容易的。
那为什么不应该在发展的关键阶段在这些非关键项目上花费大量的精力和资源呢？
主要原因之一，是OpenStack的定位没有明确和及时纠正。面对这些不断出现的新应用，OpenStack到底该做些什么这一点一直没想明白。是一门心思搞好自己的一亩三分地，同时满足它们对自己的需求，实现对它们的良好支撑，还是不管如何都要去插一腿呢？我认为本来应该选择的是前者，但社区实际上选择的是后者。
OpenStack上的对应项目，从一开始就做不太好。新项目的发展速度往往很快，随着这些应用的新版本发布，差距只会越来越大，到最后只留下一些既没人维护也没有用户的半拉子项目。而且，很可能前期实现的很多功能后面就不需要了，这会导致浪费。
再者，实际上，这些应用的原生部署工具往往更好。我认为专业的事情就应该交给专业的人去做。
OpenStack对 AWS 的学习只停留在『形』的表面，而没有学到『神』。尽管AWS 上有一百多个服务，但是，我们看到的是AWS 扎扎实实地把基础服务做好。举几个例子吧。区块链现在很火是吧，AWS目前却只提供了CloudFormation 模板让用户自己去编排运行区块链的云资源；Kubernetes现在也很火是吧，但AWS 却连管理K8S集群的界面都不提供。
那OpenStack 对这些新型应用到底该有什么样的态度和做法呢？我认为应该是两点：
以不变应万变，做好这些新应用的运行基础架构环境，使得这些服务可以良好地运行在由OpenStack管理的虚拟机/物理机、网络和存储中。
做好Heat服务，象AWS一样提供好模版，在用户需要的时候，管理员使用这些模版把这些环境编排出来，然后交给普通用户使用即可。
为什么OpenStack在青年时期就出现了中年危机呢？
我认为有如下几个原因（当然这些肯定不是全部原因）。
（1）容器的出现，对OpenStack的冲击很大。但是，我们也要看到，容器的出现，并没有使得VMware 和以AWS 为代表的IaaS云服务商叫苦连天。OpenStack该做的不是去抱怨『既生瑜，何生亮』，而应该是反思为什么OpenStack没能做好容器的底层架构。
以 AWS 为例，它有两个容器相关项目，一个是它自研的ECS，这是一个Docker 容器管理服务，容器运行在EC2主机上。另一个是EKS，是一个Kubernetes 运行环境的创建和管理服务。AWS 为了支撑容器，主要做了几件事情：1. 创造了 amazon-ecs-cni-plugin 项目，使得容器可以很好地运行在VPC 中。2. 打通了用户权限，用户可以使用 AWS 的账号登录到 Kubernetes 环境中。3. 实现了一套Docker 容器管理服务，以及K8S管理节点。
反观 OpenStack 对容器的支持，它主要做了几件事情，一是花很大力气搞 Magnum 项目，做Kubernetes等容器环境的编排。另一个是有几个网络相关的项目，但是好像也没什么人在用。
结果就是，在OpenStack 环境中，Kubernetes环境的编排也没做好，Kubernetes在其中也运行不好（因为针对Kubernetes的网络、存储都没怎么搞好）。所以，我认为，是OpenStack 没有及时为Kubernetes做好支撑，才导致 Kubernetes和 OpenStack 的分离之势的。
（2）社区没规划和控制好OpenStack的发展方向，在关键的发展阶段浪费了宝贵的时间和资源。前面讲过，OpenStack社区没能做好自己的定位，并聚焦于基础性的核心服务，把底部做扎实。
（3）部分OpenStack创业公司太浮躁，没能做好非常关键的产品研发和服务。在高峰时，一些创业公司们追求的是社区的贡献量，而不管贡献质量，甚至是刷贡献量；追求的是用户数量，不惜以低于成本价的方式，而不管项目能不能做成，用户会不会满意；追求的是PR文章和各种炒作，而没能认真地去做用户案例。总之，既没有把产品和服务做好，用户对OpenStack的口碑和信心也没有树立起来。相对地，一些认认真真做产品的公司，其OpenStack云业务也发展得很好，这说明OpenStack其实是可以做好的，用户也是愿意用的。
（4）很多客户，特别是大部分传统企业，实际上用VMware虚拟化就够了，不一定需要用云。公司的运维体系、资源交付体系，以及应用的研发、运行和设计架构，都还是虚拟化时代的那一套，因此VMware支撑现有应用也够了。这从VMware 财报上其收入继续增长也能看出来。因此，让这些客户从VMware转到一个能用但不那么好用的OpenStack云上来的动力能有多大，其实是个很大的问题。
OpenStack的未来到底会如何呢？
个人认为OpenStack的未来会有两条路：
第一条路，如果OpenStack 只作为KVM虚拟机和Ceph存储卷的编排器，那么这条路走下去，它会免不了走到和CloudStack这样的开源云平台同样的结局，那就是还未真正兴起就开始真正凋零。
另一条路，如果OpenStack走AWS甚至VMware的道路，成为基础云（虚机和裸金属）、原生云（容器）和未来无服务器云（函数）的共同底层支撑平台，那么它的路会很长。
但是，遗憾的是，从现在的情况看，OpenStack应该是走在第一条路上，也许这就是很多人认为OpenStack快死掉了甚至已经死掉了的原因吧。
我对OpenStack的感情
我个人对OpenStack有着很深的感情。是它，让我认识了什么是云，云是怎么构建、运行和维护的等等。是从研究它开始，我开始从传统软件领域进入了云领域，我也开始了写技术博客的漫漫历程，也通过它结识了很多朋友。其实，我觉得，不光是我，整个IT领域都应该感谢OpenStack，它的出现大大加速了IT架构演进，以及云的普及和落地进程。
从实际情况来看，如果企业有一个OpenStack研发团队，或者找了一个靠谱的外部供应商，云环境规模不是特别大，业务不是非常复杂，还有几个给力的运维，OpenStack私有云还是可以跑得挺好的。至少在国内，OpenStack已经成为了自主可控的私有云云平台的主要代表之一，在各行各业发光发热。
不管结局如何，OpenStack都将在IT发展史上留下了浓墨重彩的一笔。在此，我谨代表我个人，感谢OpenStack项目，感谢OpenStack每一行代码和每一个文档，感谢OpenStack社区，感谢所有给OpenStack做过贡献的公司和人们。
后记
这篇文章首先发表在我个人的微信公众号『世民谈云计算』内。让我在发文前没有想到的是，在文章发表后的不到两天时间里，它居然能有一万两千多的阅读量，收到一百五十多个赞。很多朋友通过微信跟我交流他们的想法和感慨，以及正在或曾经为OpenStack奋战的时光。还有很多朋友发表了很多的评论和讨论，里面很多真知灼见。短短两天里这么多人在阅读、转发、评论、讨论着这篇文章，而在过去八年多时间里，有更多更多的人在贡献着、使用着、推广着、思考着、学习着、关心着、讨论着甚至争论着它。我想，这正是OpenStack的魅力，这是开源的魅力，这是云的魅力。祝福OpenStack有更好的发展！OpenStack加油！
＞ ＞ 关于作者：
刘世民（Sammy Liu），现在某公司担任云服务技术总监，云计算技术爱好者和从业者，『世民谈云计算』微信公众号和技术博客博主。
＞ ＞ 关于『 Linux宝库 』：欢迎关注『Linux宝库』微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生！
- End -
- 责任编辑： ArthurGuo -
为开源爱好者和从业者点亮人生！
长按二维码关注我们