marathon

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 Twitter as the foundation for Twitter's custom PaaS which was later open sourced as Apache Aurora. Marathon's main use case was actually for running microservice application in containers, which is why it has some advanced features around managing groups of containerized apps and their dependencies. The "meta-framework" use case for launching custom frameworks was also important but basically just needs Marathon to keep a containe

Great stuff as well (but due to $reasons, I'm switching to kubernetes away from Mesos/Marathon)! https://github.com/mesosphere/marathon/issues/created_by/SEJ... :)

Have anybody works with Mesos? How does it compare to Yarn, particularly in a production perspective? Is it stable, easy to integrate? We are currently thinking to switch from a Kafka-Spark(on Yarn)-Mongo stack to a SMACK stack (Spark, Mesos, Akka, Cassandra, Kafka)[1]. It seems that there is a good integration between theses projects. Also you can run Docker on Mesos using Marathon[2] so not only our data-driven stack could be on Mesos but the full stack. [1] https://mesosphere.com/blog/2015/07/24/learn-everything-you-... [2] https://github.com/mesosphere/marathon

Just to double down on that previous point, check out the code for haproxy-marathon-bridge. https://github.com/mesosphere/marathon/blob/master/bin/hapro...

Our UI for Marathon[1], a framework on top of Apache Mesos, is written in React and uses Backbone models. It uses Require JS for modules and compiling the source into a single file for distribution. The JS root is in the assets directory[2]. There are a few guidelines we have adopted through trial and error so far: * Use React.addons.classSet[3] liberally. Class name generation becomes simpler for future developers to read. * Define propTypes[4] for every component. Debugging becomes easier because React gives you informative warnings about mismatched propTypes. [1] https://github.com/mesosphere/marathon [2] https://github.com/mesosphere/marathon/tree/master/src/main/... [3] https://facebook.github.io/react/docs/class-name-manipulatio... [4] https://facebook.github.io/react/docs/reusable-components.ht...

Mesos is exceptionally good at managing long-running service and that use case represents about 50% of the workloads I've seen on large production clusters. "Scheduling" long-running services is straightforward, as they typically only need to be run "once." It's trivial to use something like Marathon [0] to do that, and you then immediately benefit from Mesos' fault-tolerance and self-healing. Marathon also makes it easy to elastically scale the long-running processes (e.g., start more Rails servers when traffic increases). [0] - https://github.com/mesosphere/marathon

I haven't read the Omega paper yet, but plenty of people are running long-running tasks in Mesos (Marathon [0] is a framework for doing just that). [0] https://github.com/mesosphere/marathon

Yes, that's the approach I took in our Marathon project (https://github.com/mesosphere/marathon/tree/master/src/main/...). The view is React, the models are Backbone, and I intend to use Backbone's Router as well. Backbone.View is never used.

Yes. I get that. Except Marathon can do 'cron-like' things too. So can Mason. Mason manages cluster applications. So does Marathon. Mason can juggle task resources. So does Marathon. Mason is a framework. So is Marathon. Mason has a scheduler. So does Marathon. The only thing Chronos does, at all, is run jobs on a schedule, distributedly. Which Marathon and Mason can do too. So can someone please explain to me why you need all three?? -- Look, here, at the infographics in the middle of the page: https://github.com/mesosphere/marathon What they're saying is, Marathon will move your jobs to a new server when one dies. Okay, cool. But Chronos can do that too. And Mesos can do that too! -- I'm pretty sure all these tools are a giant troll by Google to get its competitors to burn R&D time on reinventing tools that already exist and aren't nece