Live data from Hacker News

Apache Mesos to be moved to Attic

lists.apache.org

121–130 of 139 posts

Re: Apache Mesos to be moved to Attic

#121

I’m one of the long term PMC / committers on mesos. In retrospect I feel this was inevitable to a few key reasons: * k8s was a second system with all the learnings and experience of building such a system at Google for over a decade. Mesos was birthed by grad students and subsequently evolved into its position at Twitter but the engineers driving the project (myself included) did not have experience building cluster…

>"k8s was a second system with all the learnings and experience of building such a system at Google for over a decade. Mesos was birthed by grad students and subsequently evolved into its position at Twitter ..." Do you know does Twitter still run Mesos?

Yes, and at very large scale! But migrating to k8s.

Re: Apache Mesos to be moved to Attic

#122
post #53

I went to see Mesos early in their life in their San Francisco office after a joint customer put us in touch. Never in my life did I meet such an arrogant group of people. First, they left us waiting in reception for an hour. They eventually took the meeting over lunch, where we had to watch them inhaling their free food. Some guy in plastic-leather trousers spent most of the hour lecturing us about all of the multi…

I haven't seen much overt rudeness like what you're describing, but it does mystify me how often I'll meet with another company to discuss a potential integration story that benefits us both, and instead of any engineers who can discuss technical considerations, they send multiple product managers who all want to present their own slide deck about why they're so great. I know you're great - that's why we requested th…

I couldn’t stop crying-laughing at what you described.

Unfortunately at many firms, Product is supposed to be the interface to customers and engineers are supposed to interface with product. This model only works if the product person is smart and humble enough to understand when to involve engineers. Often their incentives are against it as they want the credit for “landing” a big account without the helps of others, especially engineers who often report to a different org.

Re: Apache Mesos to be moved to Attic

#123

Earlier quoted context omitted.

You're thinking of Mesosphere, a separate company building a product on top of Mesos.

True. As the major corporate sponsor though they didn’t give it the best chance. I ran one of the first Docker partners and saw first hand how both Mesos and Docker Inc had considerable mindset and interest from large enterprises for a year or so before Kubernetes matured. They both spectacularly failed to deliver through arrogance and bad execution.

I remember visiting SFBA in 2014 or so, a friend worked in PayPal said they used mesos, kubernetes was a baby project with a lot of hype. It sure seemed mesos had won back then, and the fact that kubernetes caught up, surpassed and then succeeded so wildly would have never crossed my mind.

Re: Apache Mesos to be moved to Attic

#124
post #20

Earlier quoted context omitted.

> For over 90% of workloads kubernetes is an overkill. It's not. Take any simple web app and deploy it into managed GKE with Anthos and you automatically get SLI's and the ability to define SLO's for availability and latency with a nice wizard. Takes a few minutes to setup. The amount of engineering needed to achieve good SLO monitoring dwarfs the engineering needed to run a simple app so it just never happened. That…

Your statement already support that without the blessings of engineering team of Amazon, Google, Microsoft, Digital Ocean and various managed kubernetes service it's impossible for a reasonable small team to manage and monitor k8s and all of this service comes with lock-in and additional capital outlay. Obviously for a Google Cloud Partner, more people are tied to gcp and kubernetes, higher the revenue. Its secondary…

[deleted]

Re: Apache Mesos to be moved to Attic

#125

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…

> Apache Foundation is no longer a label for solid, reliable software

ASF is just a shelter for providing governance, infra, a legal framework for donations, and credibility to projects that went unprofitable, or weren't intended to be profitable to begin with, such as complements to commercial software. It's a responsible way to dump software you can't realistically maintain going forward, to give it a chance to build up a community by those depending on it, and often accompanied by an initial contribution to ASF. While not every software project is doing well for sure, whether ASF or not, I think the above sentence really misrepresents what ASF is doing (and arguably is doing with a lot of success).

Re: Apache Mesos to be moved to Attic

#126

I’m one of the long term PMC / committers on mesos. In retrospect I feel this was inevitable to a few key reasons: * k8s was a second system with all the learnings and experience of building such a system at Google for over a decade. Mesos was birthed by grad students and subsequently evolved into its position at Twitter but the engineers driving the project (myself included) did not have experience building cluster…

When I first picked up Mesos, it WAS the easiest one out the box. Basic Java bits, 20 minutes, up and running.

Compared to the dog and pony show kubernetes docs were.

Re: Apache Mesos to be moved to Attic

#127

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

Personally think AWS ECS is a 3rd place contender. Would add sprinkles to it if only they'd allow yaml files vs json configs in the aws-cli. ecs-cli and copilot are alright. Generally prefer to stay as close as possible to aws-cli

In AWS I’d choose ECS over any k8s variation on price alone before you get to the IAM integrations.

Re: Apache Mesos to be moved to Attic

#128

Earlier quoted context omitted.

ITT: K8s is great because it frees us from the tyranny of Big Cloud providers. Also ITT: Oh, but of course k8s is totally unusable unless you buy it from a Big Cloud provider.

The K8s docs offer ways of running on-prems, you can do it with nginx ingress daemonset + DNS pointing to the IP (or CNAME) of your workers. It's all covered quite well here: https://kubernetes.github.io/ingress-nginx/deploy/baremetal/ and we use it in production.

[deleted]

Re: Apache Mesos to be moved to Attic

#129
post #65

Earlier quoted context omitted.

> 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…

Co-founder of Mesosphere/D2iQ here. Mesos started as a research project at Berkeley in 2009 and was originally focused on cluster computing frameworks like Hadoop. From the paper: "We present Mesos, a platform for sharing commodity clusters between multiple diverse cluster computing frameworks, such as Hadoop and MPI." It actually predates YARN by a few years. But, it very quickly (in 2010) saw production use at Twit…

marathon-ui was deprecated and went unsupported in favor of the proprietary DCOS UI.

Re: Apache Mesos to be moved to Attic

#130
post #9

Earlier quoted context omitted.

We used Mesos in production until 2020 (started transition to Kubernetes in 2018), and this comment is incredibly accurate. Mesos was an interesting project but the defaults were incredibly naive about production environments. Two concrete examples: Mesos maintenance mode vs Kubernetes' cordoning and eviction APIs, and Mesos's default behavior when a Node is suddenly powered off vs Kubernetes'.

>"Two concrete examples: Mesos maintenance mode vs Kubernetes' cordoning and eviction APIs, and Mesos's default behavior when a Node is suddenly powered off vs Kubernetes'." What was Mesos default behavior when a node was powered off?

It assumed that the Node had a temporary network fault and did not automatically remove the Node. Marathon also did not automatically schedule replacement containers on other Nodes.

Kubernetes will, after a period of time, garbage collect the Node and schedule replacements as dictated by the controller.

Post reply on HN