2

失败博物馆 - Mesos/Marathon

 2 years ago
source link: https://yanhang.me/post/2019-08-23-mesos-marathon/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

失败博物馆 - Mesos/Marathon

2019-08-23 约 957 字 预计阅读 2 分钟

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 问题再多,简单易用本身就足够让很多人开始使用了。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK