| > [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. |
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?