> Mesos (and many other Berkeley AMPLab efforts) had briliant ideas behind it Brilliant on paper. The idea was influenced by MR workloads on Borg. Because MR

> Mesos (and many other Berkeley AMPLab efforts) had briliant ideas behind it Brilliant on paper. The idea was influenced by MR workloads on Borg. Because MR is so large a workload pattern on Borg, that it benefits from having its own scheduler, and Borg also benefit from unnecessary meddling. The idea was only brilliant for a very small number of human users, both inside Google and in the broader industry. In terms of CPU & memory usage, mesos' approach should always take great share, because workloads that in the category of needing their own scheduler always is the big ones. But as an open source product, its adopters are far off from that group. So you can see that all early adopters of Mesos are large corps. I seldom hear any startup applaud Mesos. Precisely, I have repeated many times when Mesos was still relevant, that its model makes it costly to get started. It will never succeed unless it start to package a product that can provide the scheduler part. We all know what happened after K8s. K8s works because Borg already worked for 12+ years. > an elegant implemention that allowed for much more than what Kubernetes was desgined to. By design K8s is more capable then Mesos. Because K8s includes scheduler. And numerous other capability. Heck, excluding performance and scalability, K8s is a level a bove Borg in terms of feature and capability. Mesos is far behind Borg even, not mentioning K8s. Mesos does offer better scalability, on paper. I had no experience though. > Kubernetes was supposed to be scheduler for Mesos and Google invested in it. I never heard of such plan.