Live data from Hacker News

Apache Mesos to be moved to Attic

lists.apache.org

41–50 of 139 posts

Re: Apache Mesos to be moved to Attic

#41
Most of the comments here about Mesos are exactly my experience with Kubernetes. Replacing the words and I'm just nodding my head:

"Kubernetes changed frequently and there were enough unknown TBD components at the edges of the ecosystem to make it somewhat volatile."

"Kubernetes was an interesting project but the defaults were incredibly naive about production environments."

"Kubernetes unfortunateley never got beyond being a shiny UI with a primitive application model and a hacky API."

"A challenge with Kubernetes is that Kubernetes was a piece of technology, a framework at most, instead of a product."

"In Kubernetes you had to use separate projects for container management (kubelet, kube-scheduler, kube-controller-manager, kube-proxy, cri-o), discoverability (etcd). It seemed more geared to people that wanted to run their own stacks for such tasks. For a small to medium sized operation it was difficult to solve these issues where really they are issues everyone running a stack of containers has."

Re: Apache Mesos to be moved to Attic

#42
It's sad, but expected.

This is not about Apache, but a failed open-governance for commercial open-source from Mesosphere. It's not the case with Apache Spark nor Apache Beam, HBase, etc.

Mesos (and many other Berkeley AMPLab efforts) had briliant ideas behind it and an elegant implemention that allowed for much more than what Kubernetes was desgined to.

Kubernetes was supposed to be scheduler for Mesos and Google invested in it. Let's not forget John Wilkes (Google Borg, Omega, Kubernetes) on the stage at MesosCon in 2014 https://www.youtube.com/watch?v=VQAAkO5B5Hg

While I don't know the exact reasons behind Kubernetes becoming the scheduler and resource manager, I think that has very much to do with the stewardship of the Mesos project as well.

By 2015/16 most Mesos committers were at Mesosphere. Suffice to say the open-governance was more of pain than a benefit to them. If you were at Apple, Adobe and others that relied on Mesos you didn't have much to say. Everything shifted towards DCOS and everyone was pushed towards commercial licenses.

This is said, because sadly Kubernetes didn't fix the whole problem and left us with a distributed system with a text based "API" that requires text patching to manage and borderline clueless about the lifecycle of the services running on top. Yet, it's the best we got :)

Re: Apache Mesos to be moved to Attic

#43
post #26

Mesos made a ton of new contributions to distributed resource management. Resource offers and application integration can allow high cluster utilization and efficiency. Giving applications the opportunity to take part in resource allocation and scheduling was similar to the Exokernel design, and led to many interesting middleware architectures. Mesos also introduced Dominant Resource Fairness for allocating resources…

Are there examples of high-utilization, large-scale Mesos deployments? Mesos didn't even gain over-commit until 2015, so it seems like it was generally behind the state of the art.

Twitter. From generic caches to ad serving; from stream processing to video encoding, all high utilization applications of either one or multiple schedulable resources.

Re: Apache Mesos to be moved to Attic

#44

I used Mesos for a few years before experiencing Kubernetes. As neat as Mesos was, it was doomed from the start. For one, Kubernetes was, at least to some extent, a rewrite and extraction of functionality built at Google, from their production orchestration ecosystem that is Borg. The fact that Kubernetes was heavily influenced by a successful, large solution in this space allowed it to leapfrog, at least a bit, the…

A challenge with Mesos is that Mesos was a piece of technology, a framework at most, instead of a product. When I was using Mesos, the selling point was flexible and efficient resource scheduling. Unfortunately, resource/machine efficiency alone does not sell well, as most of the companies and individuals have betters things to worry about, say, productivity.

>the selling point was flexible and efficient resource scheduling

There was a period when it wasn't clear that you didn't need both resource management and container orchestration. One of my colleagues was quite convinced at the time that we needed both Mesos and Kubernetes. If course, the market coalesced around Kubernetes which largely backfilled the missing capabilities.

Re: Apache Mesos to be moved to Attic

#45
post #42

It's sad, but expected. This is not about Apache, but a failed open-governance for commercial open-source from Mesosphere. It's not the case with Apache Spark nor Apache Beam, HBase, etc. Mesos (and many other Berkeley AMPLab efforts) had briliant ideas behind it and an elegant implemention that allowed for much more than what Kubernetes was desgined to. Kubernetes was supposed to be scheduler for Mesos and Google in…

This is much more the real story but I doubt most folks will ever hear it.

Totally agree. Mesos project always had a trouble with governance and didn't build out the larger community the way other projects did. If they had built that coalition, made the project more accessible to others, who knows, maybe it would have gone differently.

Then again, k8s succeeded in part due to the Google reputation (even if undeserved) and it's use of GoLang. I always found Mesos' use of C++ meant many of the users (often developing in Java, Go, or Node) just wouldn't contribute.

Re: Apache Mesos to be moved to Attic

#46

I used Mesos for a few years before experiencing Kubernetes. As neat as Mesos was, it was doomed from the start. For one, Kubernetes was, at least to some extent, a rewrite and extraction of functionality built at Google, from their production orchestration ecosystem that is Borg. The fact that Kubernetes was heavily influenced by a successful, large solution in this space allowed it to leapfrog, at least a bit, the…

>As neat as Mesos was, it was doomed from the start.

I don't think it was doomed from the start; Mesos was deployed at Twitter 4 years before k8s was even released. The "problem" with Mesos was that it was focused on a future that never panned out. The "killer app" for Mesos was Spark, and the problem they were focused on solving was resource allocation for batch jobs. Mesos was supposed to be a replacement for YARN. Even Marathon, which was the de facto application launcher, was pitched as a "meta-framework". Marathon wasn't for launching services, it was for launching custom frameworks. They never really pivoted from this, and the writing was on the wall when Mesosphere decided to make Marathon as proprietary as possible and fully integrate it within their commercial solution. Once Marathon was gone, Mesos didn't really compete with k8s anymore unless you wanted to write your own framework.

Re: Apache Mesos to be moved to Attic

#47
post #7

End of an era... Are there any viable alternatives to Kubernetes and Nomad?

For over 90% of workloads kubernetes is an overkill. Only when company is reaching google scale kubernetes make sense. A good alternative to kubernetes is LXD [1] or just stick with docker compose. Kubernetes except for managed services from cloud providers is more difficult than an average application to manage and a huge cost in itself to run and maintain. [1] https://www.linuxcontainers.org/

I don't know about this. I caution people against microservices architecture all the time, but at my company having a scheduler just made sense. We spin up and down queue workers by massive amounts every hour, and doing this with anything besides a scheduler would be really tricky.

Granted, we use Nomad, not k8s, but we definitely need a scheduler and definitely are not reaching Google-scale.

Re: Apache Mesos to be moved to Attic

#48
The real gem of the Mesos ecosystem was the much lesser known Singularity scheduler from HubSpot.

https://github.com/HubSpot/Singularity

I've run this at scale, in production since 2015 and it has been absolutely rock solid and does most of the production things you'd want. Unlike commercial products, it was written to run HubSpot's own infrastructure so it does what a production system needs. Really bummed to have to downgrade to something like K8s in the near future.

Re: Apache Mesos to be moved to Attic

#49
Disclaimer - I used to work for Mesosphere.

On the topic of arrogance, I wasn't in that meeting referenced, but having worked with most people there who could have been, and being a Brit who's worked for west coast startups like that for nearly 10 years, it's that American confidence, outlook and drive (along with Sand Hill road) that contributes to so much success out there. I'm a fan, but have to check myself every time i use 'super' as an adjective.

Tech vs Product is a good comparison to make. I banged my head many times on DC/OS (the commercial version of Mesos) and underlying Mesos itself. Solid tech, but I'd have liked to have seen the product develop faster, to realise its potential in the enterprise market, which was huge.

Re: Apache Mesos to be moved to Attic

#50
post #42

It's sad, but expected. This is not about Apache, but a failed open-governance for commercial open-source from Mesosphere. It's not the case with Apache Spark nor Apache Beam, HBase, etc. Mesos (and many other Berkeley AMPLab efforts) had briliant ideas behind it and an elegant implemention that allowed for much more than what Kubernetes was desgined to. Kubernetes was supposed to be scheduler for Mesos and Google in…

> Everything shifted towards DCOS and everyone was pushed towards commercial licenses.

This was then partially diluted when Microsoft decided to deploy DC/OS and, from what I've heard, pushed Mesosphere to open source large chunks of DC/OS.

Post reply on HN