一个 openstack 老兵的2018 OpenStack 温哥华峰会总结

又一届 OpenStack 峰会结束了。

现在很多人都说 OpenStack 在走下坡路或者更有甚者说 OpenStack 已死，但至少从这一届2500+的参会人数上看，还是有很多人在关注 OpenStack 或者在做 OpenStack 的生意，要知道，以前峰会所谓的5000+可是 Summit+PTG 的总人数啊。当然，得承认的是，现在关注 openstack 的人在减少，openstack 的社区参与者在减少，原因的多方面的，峰会期间跟一些朋友也一起认真讨论过，我也借此机会再陈述一下我的观点。当然我的陈述并不是为了证明什么，也不是为谁辩解，而是希望更多的人用更理性的态度去对待一个曾经如日中天的开源社区。

首先，目前的状况并不是 openstack 社区或者基金会的错。基金会一直以来都在做对 openstack 有利的事情，不管是 big tent 还是 PTG，亦或是现在的 katacontainer，边缘计算，serverless。但从技术的历史发展进程来看，没有一个技术能一直保持着青春活力，所以当 openstack 遭遇到容器技术(k8s)的潮流时，势必会受到影响，特别是，两者同属云计算技术领域。云计算从业者在一定历史时期内就那么多，无论从技术趋势还是自身职业规划的角度考虑，投入分散在所难免。这里，我仅以 k8s 代表容器技术趋势，虽然它只是容器技术领域的一个分支而已。

很多人骂 foundation，当年 big tent 的决定有多么愚蠢，PTG 有多么不靠谱。试问，如果当时 k8s 社区没有起来，再给你一次思考的机会，你还会不假思索的骂么？当年 openstack 核心项目人满为患，各个厂商利益角逐，围绕 openstack 的周边有100多个项目，争相成为 official。因为一旦成为 official，对公司和自己是个交代，也更能吸引社区开发者的注意。毕竟，那个时候，你不是官方项目，是不会有人搭理你的。项目越来越多，5天的峰会根本就没法合理安排，一些想做正事儿的开发者也觉得应该把 design summit 分开，好让他们静心搞技术，而不是搞市场宣传和被领导逼着站台。所以 foundation 不得不说，好吧，咱们单独弄个 PTG。所以，从 foundation 的角度看，这些决定有错么？没错。那到底是哪错了呢？哪也没错，大家都做了对自己有利的事情，只是历史规律告诉我们，正确的路只有一条。不能因为刘备把曹操灭了，就说曹操愚蠢至极导致决策失误，也不能因为大清国被革命而说整个清政府昏庸无能一无是处。

如果非要我挑出点毛病，那就是有些项目负责人的短视以及 TC 的不作为。在部分 openstack 的技术人员开始流向 k8s 之后，有些项目居然站出来说，我们要独立运作，我们可以不用社区的 CICD，项目文档想托管在其他地方，我们可以不依托于 openstack 而独立部署和提供服务，我们不想依赖于其他 openstack 项目因为它们不成熟，典型的过河拆桥。明眼人都知道这些项目是不想被绑定在一个走下坡路的社区里，或者想往容器方向靠一靠。但在云计算的世界里，一荣俱荣，一损俱损。对于很多 openstack 项目，在容器世界里有很多项目在做同样的事情，更轻更容易部署更本地化，用户凭什么转而去用你一个从 openstack 社区脱离出来的新东西？另一方面，一些项目说不想依赖于其他 openstack 项目而影响自己的部署率，导致一些小的项目连露脸的机会都没有，胎死腹中，进而加剧了 openstack 项目分化和畸形。不说别的，去看看 AWS，哪个服务不是跟其他服务有千丝万缕的关系？云计算服务看的不是某个服务多么的牛逼，而是服务间的无缝集成做的有多好。让用户的操作在你的服务之间转起来，才是一个成功的云计算服务平台该做的事情。话题回到 TC 的不作为，TC 是在 openstack 社区做技术决策的唯一组织，在当时的情况，还允许这些项目胡作非为，任其自由发展，这种过于民主化的方式是我不能苟同的。时至今日，我能看到的 TC 在社区做的两个事情是，制定每个 release 的 community goal 以及审核新项目的 official 申请，终于算是干点实事了。但人心已散，看看每个 goal 的完成度，看看有多少 PTL 在积极响应，TC 更多的是在自娱自乐而已。

看看河对岸 k8s 的歌舞升平吧，真应了中国那句老话：三十年河东，三十年河西。k8s 被管辖于 CNCF 社区，而 CNCF 社区的治理完全吸取了 openstack 曾经的经验教训，比如一上来就是 sig 的治理模式，再比如对于新项目申请孵化的必备条件之一就是至少有三家公司在其生产环境中部署，而且现有的孵化项目也会被定期 review。然而，同 openstack 一样，k8s 社区也不可能一直灯火辉煌下去，也许将来有一天会有一个新的革命性技术把 k8s 取代，就如同虚拟机容器，serverless 会取代传统虚拟机一样，k8s 也会经历在做正确决策的过程中慢慢的烟消云散。

那么，技术的趋势在哪里？我不知道。我只知道，用户需要的就是技术需要解决的。openstack 社区的退化并不能代表 openstack 项目本身的消亡。虽然现在参与社区的人少了，但现在能保持参与的，大部分就是对 openstack 真正有诉求的，原来为了市场宣传和基于 KPI 的社区贡献基本消停了。

现在对 openstack 的需求场景大致分几个方面：为容器应用的部署提供基础设施，所谓的容器云基于很多因素的考量敢把容器直接跑在物理机上的不多；自建公有云或私有云，或者为客户交付云基础设施；NFV，其实我一直看不上 NFV，只要牵扯到有电信公司参与的事情就要做好无穷无尽扯皮的准备，大家都是做过标准的，谁也不服谁，其实根本不适合在开源领域玩，网上看到过一群大妈在泥土地上 PK 街舞的视频，令人忍俊不禁；边缘计算，这东西应该还处于吹牛逼拉客户的阶段，反正我是没完全懂，可能是我视野层次太低。

这届峰会也是历年来我在 market place 停留时间最长的一次，当然并不是为了要 T 恤，而是想真正了解现在这些仍然肯花钱赞助的厂商，都在 openstack 干些什么。聊天的结果并没有多少惊喜，除了做硬件的，其他大致分为几类：提供 openstack 私有云或混合云的部署或托管的公司，无论是为了卖自己的发行版，操作系统还是虚拟化软件，ubuntu，suse，vmware 等都是此类；基于 openstack 提供公有云的，现在没剩几家了，来自欧洲的居多，citynetwork，vexxhost，ovh，telekom，华为也算吧，当然，我们也属于此类，只是我们没有赞助；为 openstack 提供周边服务或咨询的公司，理论上他们不依赖于 openstack，openstack 活下来对他们来说就是多一口饭吃，openstack 死了，他们还有其他的赚钱渠道，比如 datadog，他的 dashboard 给我留下了很深的印象；做插件的，比如一些网络厂商或存储厂商。而且，跟大家聊天你会发现，基本上提供 openstack 发行版或服务的厂家，都提供容器相关的服务，至少也都是 k8s 服务，还有少部分提供面向应用的服务。大家想法是雷同的，我相信会有一些共性的需求。

katacontainer 不知道会不会是 openstack 基金会自认为的最后一根救命稻草，openstack 基金会似乎是向 CNCF 社区挑衅说，少年，你的容器不是牛逼么，但安全问题你得解决吧，是不是还得跟 openstack 基金会合作你才有前途呢。结果 google 不干了，上个月在 kubecon 上发布了 gVisor，同样是为了解决容器的安全问题。我在非正式场合专门问了王旭(Xu Wang，不知道中文是不是这么写)两个问题，第一个是问他怎么看 katacontainer 跟 gVisor 的竞争关系，他的大概意思是说 gVisor 还嫩，软件模拟的系统调用延时是硬伤，第二个问题是 katacontainer 里启动一个虚拟机容器耗时有些长啊(秒级)，从现场演示也能看出来，他说这个后续是会优化到毫秒级的。我不懂容器底层的实现，但容器安全是大家普遍认可的目前容器技术的问题，我还是真心希望 katacontainer 能成，成为解决容器安全问题的推荐方案，虽然它跟 openstack 没多大关系。

因为上述我提到的部分原因，一些小的 openstack 项目现在的生存状况很糟糕，基本就是一两人在真正干事情，比如 Octavia，Magnum，Trove，Designate，Barbican，当然也包括我自己发起的 Qinling。但从我参与的这些项目的 project update 以及 project onboarding 来看，还是会有很多人在关注这些小项目，因为这些人确实在做 openstack 的生意。openstack 在 IaaS 层的服务其实相对来说已经比较稳定了，现在大家的业务需求都在往上长，所以自然就需要上层的一些服务，在 openstack 开源世界里，没有其他选择，只能依赖于这些项目的慢慢成熟。但能不能成熟，一方面是看大家是否真的抱团取暖，另一方面也看这些项目的 PTL 是否有所作为，是否会主动寻求这些真实玩家的反馈和帮助。让我比较遗憾的是 Trove，PTL 应该是国人，但却没在这次峰会的 project update 中出现而没有任何事前的提醒和通知，让现场来自不同公司的将近20人大失所望。Trove 这个项目在 Tesora 掌控时期就有所争议，去年 Tesora 被收购后，前任 PTL 一拍屁股走人，留下一个烂摊子给了一个国人，但这位朋友似乎也不是 trove 的真正玩家，在 Rocky 开发周期并没有做太多实质性的贡献。当然，能主动承担 PTL 的工作本身就需要勇气，更何况社区工作是义务劳动，我们不能谩骂，而是应该寻求途径帮助这个项目成长。Designate 项目是让我比较惊讶的，我还记得在2017年初的时候，当时的 designate PTL 专门写了一篇博客说 designate 项目的状态很差，没有贡献者，项目的持续发展受到严峻考验，以至于最后被列为社区的‘Help most needed’之一，但从这次峰会跟 designate 相关 session 的参会人数可以看到，大家对于 designate 还是很关心的，主动提出在某些方面帮忙的人挺多，而且 designate 服务的部署率应该是这些小项目中比较高的吧。

最后来说说我在 openstack 做什么事儿吧。我们(Catalyst Cloud)基于 openstack 做公有云，很小规模的公有云，以至于说出来很多国内的朋友都笑了，但这个小公司确实是以从0到1再到更多的方式玩 openstack，有问题我们必须反馈到社区并且帮社区修复，同时我们也得益于社区其他开发者的 bug 修复，这是我在华为工作时梦寐以求的玩社区的方式，也许也只有我们这种小体量的公司才能玩的很好。随着我们用户规模的扩大，以及用户自身业务向云上的转型，我们也需要越来越多的其他云服务为用户业务提供支撑。所以，除了传统的 IaaS，我们也关注并且贡献 octavia，magnum，trove，designate，barbican 等项目。同时，用户业务的容器化也是潮流，所以提供 k8s 集群服务会是公有云的标配，而基于 openstack 的 k8s 的特殊之处在于，如何做到与其他 openstack 服务的无缝集成，即如何利用其他 openstack 服务来增强或扩展 k8s 的能力。所以，我也会参与到 k8s-sig-openstack working group 的工作中。而跟 k8s 的集成也促使我参与到 k8s 社区，像以前学习 openstack 一样去学习 k8s。

也许 openstack 将来有一天会彻底消亡，但不是现在。很多刚刚进入云计算领域的新人问我，现在学 openstack 还有没有必要，其实 openstack 本身没啥可学的，一堆 python 代码而已，你需要学的是 openstack 背后的那些背景技术，比如 KVM，Ceph，OVS，容器等，因为在云计算的世界里，无论趋势怎么发展，这些基础技术始终会是构筑起高级服务的基石，所谓万变不离其宗。