Those kind of articles are not so useful, Mesosphere is the company behind DC/OS and Mesos and they have all the interest in the world to say that Mesos is the best. Things like "... are willing to get your hands dirty integrating your solution with the underlying infrastructure" when talking about Kubernetes is unfair, especially if you compare Kubernetes to Mesos and not to Mesosphere DC/OS for which they provide paid services.
It is true that Mesos works on a different level, but, most of all, the two level scheduling is just a different take at the problem of abstracting physical/virtual resources. In the end, both Mesos/Marathon and Kubernetes aim at the same goal: allow developers to stop thinking about servers.
Kubernetes' great advantages is the community (which is unbelievable) and the extensibility it proposes: Third Party Resource or Custom Resource Definition, pluggable webhooks in the API Server and a number of other things that are simply not there in Marathon or any competitor which allow companies to make Kubernetes work best for their use cases.
The limitation of only being able to run Containers I think will be fleeting — as docker and alternatives mature, it really won't make sense to ever use anything else when trying to get the scale that Kubernetes and Mesos is going for by abstracting out the underlying hardware and providing a framework to run sophisticated apps on undifferentiated hardware.
What's described in that doc is even easier today thanks to Operators (https://coreos.com/operators), which, to quote the description page, are "application-specific controller[s] that extend[s] the Kubernetes API to create, configure and manage instances of complex stateful applications on behalf of a Kubernetes user."
Disclosure: I work on Kubernetes at Google (and wrote the doc you linked to).
Some of us love getting our hands dirty. In my honest opinion this whole article seemed very neutral in phrasing. It wasn't until I decided to check the source after having read and enjoyed the entire article, that I discovered that it was written in a Mesos domain. And even then I applaud that they were humble enough to save their own product until the end and didn't seem to exaggerate their sales pitch.
True, it is not too much of a sales pitch, but still something that really can't be seen as impartial, for natural reasons (it comes from the company behind Mesos) and it looses a bit of clarity (Java doesn't equal legacy, you can run Stateful workloads on Kubernetes) towards the end.
From my point of view, the benefits of the two level scheduling are actually quite limited with respect to how the whole story is usually told. Some Mesos framework always use all the resources from the clusters and it might get tricky to really have multiple frameworks to run at the same time on Mesos. Also, sometimes those frameworks don't really offer so many additional features to justify changing the way you are already using Spark, Cassandra and so on.
Exactly. The frameworks that the article describes know how to run say Cassandra or Spark, but you can do the same thing in Kubernetes using TPRs or CRDs with operators:
Well for something as crucial as this you want to be able to debug and patch the code. I mean: using outside of hobby, prototyping or a startup (i.e the rest of the economy were money wants to buy off risk) this stuff cant be a magic black box. That would be so irresponsible. "Why are our servers down? We are loosing 500k per day." .. "we are getting some weird error we cant debug because we dont know the codebase, or worse, the language. But we searching for random dumb stuff to try on StackOverflow". Yeah somebody is getting fired.
So for the developers responsible for the uptime it could matter a lot if they are more comfortable with one of codebase or language they use.
Off course if you are more like a consumer app type of startup, just put all energy on UX and stuff and hope for the best. But lets hope every bank that uses this sort of stuff has a developer on call that can actually dive into the codebase.
It is true that Mesos works on a different level, but, most of all, the two level scheduling is just a different take at the problem of abstracting physical/virtual resources. In the end, both Mesos/Marathon and Kubernetes aim at the same goal: allow developers to stop thinking about servers.
Kubernetes' great advantages is the community (which is unbelievable) and the extensibility it proposes: Third Party Resource or Custom Resource Definition, pluggable webhooks in the API Server and a number of other things that are simply not there in Marathon or any competitor which allow companies to make Kubernetes work best for their use cases.