Apache Mesos因与K8s竞争失败而将被Apache基金束之高阁，黑客新闻网友总结几个失败教训：
1. k8s是吸取了Google十多年来在建立此类系统的所有经验和知识。Mesos由研究学生发起，后来他入职Twitter，但负责该项目的工程师（包括我本人）没有建立集群管理系统的经验。（banq注：开源的大坑就是学生用它来学习的）
2. 大多数用户只想运行服务，作业和Cron作业，但这不是Mesos的一部分，您必须从一系列的生态系统调度程序（例如Aurora，Marathon，Chronos，Singularity等）中进行选择，或者自己创建一些东西。
3. Mesosphere是一家由VC支持的创业公司，在Twitter之后推动了该项目的发展。作为风险投资支持的初创企业，您需要一种可以产生收入的业务模型。这导致与用户和其他供应商的紧张关系和不信任感。与此相比，Google / k8s不需要直接从k8s产生收入，而是可以投入大量资金和强大的工程师，以提高谷歌的云计算业务。
4.如果您查看原始论文，Mesos的两级资源分配最初是为运行批处理工作负载（例如，spark，mpi等）而设计的。用它来运行长期运行的服务实际上是事后的想法。最终我们发现，鉴于第二级调度程序没有群集的完整视图并且第一级调度程序没有足够的信息来做出正确的决策，我们必须对第一级调度算法进行大量调整以确保公平性。k8s的调度模型是，调度程序能够看到集群的整个状态，因此可以乐观地制定最佳的调度决策，尤其是对于那些在实践中非常挑剔的长期运行的作业。尽管默认情况下k8s仅运行默认的调度程序，但理论上您可以并行运行多个调度程序（omega模型）。
5.k8s成功的另一个原因可能是因为golang生态系统。在Mesos中，由于Mesos独特的线程模型，我们花费了大量精力在C ++中构建基本的HTTP层。我希望我们可以将那些时间花在开发实际有用的功能上。
6.这不是关于Apache，而是关于Mesosphere的商业开源失败的开放治理。Apache Spark，Apache Beam，HBase等并非如此。Mesos（以及伯克利AMPLab的许多其他工作）背后都有令人生畏的想法，并且它的实现优雅，其实现远远超出了Kubernetes的目标。Kubernetes应该是Mesos的调度程序，而Google对此进行了投资。虽然我不知道Kubernetes成为调度程序和资源管理器的确切原因，但我认为这也与Mesos项目的管理密切相关。
7.在体验Kubernetes之前，我曾使用Mesos数年，我与许多Mesos项目成员和提交者一起工作，并与他们互动，尽管他们通常都是聪明的人，但他们的行业经验令人惊讶地肤浅。根据我的经验，Mesos经常更改，并且在生态系统边缘存在足够多的未知TBD成分，使其有些不稳定。在一年之内，Kubernetes处于领先地位，Mesos开始考虑转向支持k8s。
8.我不认为它从一开始就注定要失败。Mesos甚至在k8s发行之前的4年就已在Twitter上部署。Mesos的“问题”在于，它专注于从未成功的未来。Mesos的“杀手级应用”是Spark，他们专注于解决的问题是批处理作业的资源分配。Mesos被认为是YARN的替代品。甚至事实上的应用程序启动程序Marathon也被认为是“元框架”。Marathon不是用于启动服务，而是用于启动自定义框架。当Mesosphere决定使Marathon尽可能具有专有性并将其完全集成到他们的商业解决方案中时，就停滞不前了。
9.我们一直在生产中使用Mesos，直到2020年（从2018年开始过渡到Kubernetes），此评论的准确性令人难以置信。Mesos是一个有趣的项目，但是默认值对于生产环境而言太幼稚了。
10.我更喜欢Mesos，而不是k8s。我认为它的核心体系结构（2级调度程序）是更好的基础。在最长的时间里，我觉得k8s实际上是一个杂草丛生的业余爱好项目。
当Rails出现时，它也是一个业余项目。当来自更成熟的企业Web框架时，Rails感觉像一个玩具。它不具备“适当”框架的功能，健壮性，安全性和可伸缩性。
Rails做了什么？它很容易上手，并且隐藏了许多Web框架的无聊和痛苦的工作。
通过庞大的社区的意志力，Rails成长了起来，变得更像是最初的玩具。起初，我对Rails社区的看法非常傲慢，但是后来我多年来从事了多个Rails项目。
它仍然隐藏着很多东西，可以说仍然有更好的技术框架，很多人在不需要的时候不正确地使用它，并且没有真正地了解基本原理，这意味着当他们遇到麻烦时，他们往往会陷入困境。突破极限或走出发展的黄金之路。
我对k8s也有同样的感觉。我认为它开始时几乎没有类似框架的功能。它的伸缩性不好，模型过于简单，实现起来过于复杂。但这比Mesos之类的方法要容易得多，并回答了“我为什么要对所有内容进行容器化？”的问题，这为那些开始使用Docker的人们提供了一个目的。现在，它拥有巨大的支持者和支持者。
至此，我了解到流行的不一定是“正确”或“正确”的体系结构。编程趋势（和流行趋势）还远远不止这些。整个行业似乎都想每十年重新发明轮子，几乎就像某种计划过时的方法来证明我们的工作是合理的。然而，与潮流抗争并不明智，而且当您有足够的行业方向发展时，我们甚至可以将玩具变成真正的工具。
11.Mesos为分布式资源管理做出了许多新的贡献。资源提供和应用程序集成可以提高群集利用率和效率。为应用程序提供参与资源分配和调度的机会类似于Exokernel设计，并导致了许多有趣的中间件体系结构。
Mesos还引入了“主导资源公平性”（Dominant Resource Fairness），用于将资源分配给竞争应用程序，这已成为CS中的一个重要概念，尤其是计算经济学本身。
Mesos实现了将CS研究用于广泛部署的操作系统的罕见组合。它的C ++代码很容易理解和破解，并且似乎是您可以/希望“在几天之内”重新实现的那些项目之一。
令人遗憾的是它很快过时了。
12.公平地说，Kubernetes现在仅调度相对较小的集群。但是事实证明，世界上大多数地区都不是Facebook或Google，而只需要相对较小的集群。
13.我们使用Mesos作为我们的第一个容器编排堆栈。它可以正常工作，但是Kubernetes出现了，并为所有问题提供了一站式解决方案。在Mesos中，您必须将单独的项目用于容器管理（Marathon），可发现性（Consul / HAPROXY）。它似乎更适合希望为此类任务运行自己的堆栈的人。对于中小型操作，很难解决这些问题，而实际上这是每个运行一堆容器的人都遇到的问题。这是在2014年，所以还早，但k8满足我们需要的一切。
14.一个时代的结束...
除了Kubernetes和Nomad，还有其他可行的选择吗？
15.Mesospehere已重命名，并已转移到支持Kubernetes。https://d2iq.com/blog/mesosphere-is-now-d2iq