Hang

失败博物馆 - Mesos/Marathon

2019-08-23

Mesos/Marathon 的失败,怎么说,太过典型了。如教科书一般,清晰的不能再清晰。

首先,它流行的时候,是因为大家没得选。一个还在蹒跚学步阶段的 Kubernetes 就开始将它打的节节败退。到了现在,连Mesosphere 已经转向了 Kubernetes。

从一开始,这就是一个学术界的产品。由一堆并不擅长编写工业化软件的研究室的学生和老师写出。这导致了 Mesos / Marathon 的致命缺陷

首先,用 C++ 写 Mesos, C++可以说是学术界和工业界态度差别最大的编程语言了。对学术界来说,这是一个可以用来探究编程语言极限的编程语言,数不清的高级设计,数不清的语言学设计,你再任何其他语言里都见不到这么博大精深的体系。但对工业界来说,这是一种灾难级的编程语言。Linux 都在天天骂它,难学难用难调试,市场占有率也一直不断下滑。Mesos 选择了 C++之后,极大地减少了开源社区去贡献代码的可能性,彻底沦为了创世的开发团队自己的作品。

更灾难的是,Marathon 用了 Scala,一个除了 C++之外第二复杂的语言。其同样程度的撕裂性,对研发人员的折磨,让人都开始怀疑为什么当初要选择编程这份工作。语言设计者一旦觉得自己过于聪明,会趋向出设计出来大众难以理解的东西。这并不怪大众,而是怪语言设计者。两个世界上最复杂的语言,组合起来,成了一个大部分研发人员都不愿意碰的黑盒子。然而,它又不是稳定到不出什么问题,总会有出故障需要排查的时候。这便是让所有人都痛苦的时刻。所以即使今天大家发现 Kubernetes 已经非常复杂难以理解了,但没有人会抱怨太多,因为只要你肯花点时间,分析分析代码,总能慢慢理解。而对于 Mesos/Marathon,如果你发现了一个问题,想去阅读代码,大部分时间你都在纠结:这个语法什么意思?这个语法又是什么意思?

另外一种研究室出来的代码的问题在于,很少有人会考虑到架构的可扩展性。有了一个 idea,实现出来,发个 paper,大部分就完了。等到真正开始用户多的时候已经来不及了。而工业界的产品不一样,从一开始可扩展性就是所有系统在设计之初必须考虑的一个问题。所以我们看到,Mesos/Marathon 自发布之后,后续的功能扩充是极其微弱的,难以有任何实质性的功能增强。而 Kubernetes 在发布之后,新功能如井喷一般。当然这里面也有编程语言本身的功能。Golang 问题再多,简单易用本身就足够让很多人开始使用了。

Tags: 架构