[lobster_johnson]

I've looked at Mesos briefly, but it seems completely JVM-based, and that you're not prepared to build your whole stack around the current Java stack (Hadoop, Spark, Storm, Kafka, Zookeeper etc.), Mesos has zero utility. Is this accurate?

As someone working on scaling microservices, I keep being disappointed by potentially useful services that turn out to require a JVM-based language such as Java or Scala. For example, Kafka looks very decent, but the high-level client is written in Java; if you're not on the JVM, you're stuck implementing a lot of the client yourself. As far as I know (from the last time I looked at this stuff), the Zookeeper client is similar, whereas Spark and Storm both require that you write processing code on the JVM, and libhdfs is apparently still JNI-based, not native.

For someone using Docker, is there anything competing with Mesos that isn't wedded to Javaland?

[CoffeeDregs]

> [Not using Java -> ] Mesos has zero utility. Is this accurate?

Not at all. My company has a cluster with a few hundred Slaves and we're mostly a Python shop, with some C++ for machine vision.

Mesos certainly has its issues (as does everything), but its awfully nice for micro-services: if you can package your service into a Docker container, then you can launch it into the cluster and Chronos/Marathon/Mesos will take care of making sure that it's run/running.

I missed the deadline for the Mesos conference (I was unaware of the deadline), but I'm trying to squeak in a talk about "Using Mesos at [small] Scale" because we're a small company and Mesos has allowed us to do a bunch of big company stuff.

>is there anything competing with Mesos that isn't wedded to Javaland?

Yes, I can look at the source code and see that it uses te JVM (Chronos uses Scala), but, AFAICT, Mesos isn't "wedded" to anything. All of the components are API-driven. I apt-get install it, I run it, I send jobs to it, it works and it behaves well. Better I can poke at the APIs of any of the services to find out what is happening. So we use Marathon for service-discovery and run Chronos, a framework, under Marathon. Makes finding Chronos, which could be on one of 200 machines, quick and easy.

[lobster_johnson]

Thanks for the detailed reply!

I have to say I'm wary of big frameworks like this that insert themselves as a kind of monolithic control structure for everything.

My ideal setup is always one where I pick and mix the best modules for the job, and where I can write some interface glue to let my apps slot into the system, as opposed to writing my apps for a specific API (as tends to be the case with, say, Hadoop, and which of course would tie the whole platform to that API, making it hard to migrate to something else).

Sounds like Mesos is pretty modular and open in that respect?

[CoffeeDregs]

Once you get to know it, Mesos is really quite simple: slaves emit events about their capabilities and running processes; masters collect and distribute an inventory of slaves and their processes and of events that occur on slaves. The frameworks (ie. Marathon for long running jobs; Chronos for scheduled jobs) then listen to those inventories/events and ask the Mesos master to add and delete processes from slaves. So Mesos is quite modular.

[jacques_chester]

> For someone using Docker, is there anything competing with Mesos that isn't wedded to Javaland?

Lattice[0].

It's built from a few components extracted out of Cloud Foundry, all written in Go. In particular it includes Diego, an orchestrator. It can be run locally, on AWS, Google and DigitalOcean.

In terms of the key architectural difference, Onsi Fakhouri explained it to me this way: Mesos is supply-driven, Diego is demand-driven. Mesos keeps a list of pending workloads and waits for a report of available resources that fits. Diego instead receives a request for resources and then stages an auction amongst available cells.

Disclaimer: I have worked on Cloud Foundry (on the Buildpacks team here in NYC) and I am employed by Pivotal, we do the lion's share of the work on Cloud Foundry.

[0] http://lattice.cf/

[andrewjf]

Mesos itself is written in C++. Building Mesos will generate Java and Python bindings.

[senex]

There are frameworks that run on Mesos capable of running Docker containers. Check out Singularity, for example.

[CoffeeDregs]

AFAIK, the Docker capability is largely due to Mesos. Frameworks need the ability to specify a container type so that they can specify that a Docker container can run. But running a Docker container is the responsibility of Mesos. So Marathon and Chronos, both frameworks, are able to specify a job which uses a Docker container, while Mesos is able to run the job which uses a Docker container.

[SEJeff]

Mesos is written in C++ FYI.

[lobster_johnson]

Mesos itself is, but it seems every framework out there is written in Java or Scala: Chronos, Marathon, Aurora, Spark, Singularity etc. Also, it relies on Zookeeper, which is of course Java.