> Mesos has been simulated to scale to 50,000 nodes, although it is not clear how far scale has been pushed in production environments
Apple are "many thousands"[0] to provide Siri, and Twitter use it for pretty much everything, though I can't remember any numbers (15000 springs to mind? But mesoscon was all a bit of a blur now)
Twitter has 10k+ node Mesos clusters in production right now. At MesosCon, Apple's comments were that they run the biggest Mesos cluster in the world, not "one of the biggest". That would infer it is at least bigger than Twitter's 10k node cluster.
Now a bit of fact checking on the very dubious claims this post pretends are facts which are not.
Indeed, Mesos does scale, but one thing that is often important to remember is that many frameworks do not actually scale to this many nodes. Twitter has battle tested Aurora at scale and Apple's Jarvis (not open source sadly) scheduler also run at scale.
This article is clearly not written by an author that cares about writing facts. It states that Mesos uses etcd, which is simply not true. Mesos uses Zookeeper for coordination and locking / leader election although there is a ticket for making this aspect of Mesos pluggable:
Mesos can't run LXC as there are native Docker and Mesos containerizers. There is work on the AppC and Rkt containerizers, to be merged into the main Mesos Containerizer, but that is ongoing.
Also note that while Mesos has only been simulated on 50k nodes, at MesosCon 2015, Verizon did a demo of starting 50k containers running actual web services on 1k physical machines in about 70ish seconds. It was pretty impressive. That wasn't theoretical, they actually demonstrated it on stage and the demo gods showed mercy on them.
Mesos and Kubernetes are both great projects. I see both projects working together to build the platforms of tomorrow.
Check out the comments. The author isn't exactly careful with his claims.
One commenter says:
> "the Kubernetes team is looking to reimplement its JSON parser, which is also written in Go, in some other language."
> Did they say that? I was under the impression they just wanted to use an alternative parser to avoid the reflection that > the std lib json parser uses.
To which his response is:
> No, I was just speculating way beyond my pay grade. I have put in a call to ask some questions, but sometimes Google talks, and sometimes it doesn’t.
5 comments
[ 2.8 ms ] story [ 21.5 ms ] threadApple are "many thousands"[0] to provide Siri, and Twitter use it for pretty much everything, though I can't remember any numbers (15000 springs to mind? But mesoscon was all a bit of a blur now)
[0]: https://mesosphere.com/blog/2015/04/23/apple-details-j-a-r-v...
Now a bit of fact checking on the very dubious claims this post pretends are facts which are not.
Indeed, Mesos does scale, but one thing that is often important to remember is that many frameworks do not actually scale to this many nodes. Twitter has battle tested Aurora at scale and Apple's Jarvis (not open source sadly) scheduler also run at scale.
This article is clearly not written by an author that cares about writing facts. It states that Mesos uses etcd, which is simply not true. Mesos uses Zookeeper for coordination and locking / leader election although there is a ticket for making this aspect of Mesos pluggable:
https://issues.apache.org/jira/browse/MESOS-1806
Mesos can't run LXC as there are native Docker and Mesos containerizers. There is work on the AppC and Rkt containerizers, to be merged into the main Mesos Containerizer, but that is ongoing.
Also note that while Mesos has only been simulated on 50k nodes, at MesosCon 2015, Verizon did a demo of starting 50k containers running actual web services on 1k physical machines in about 70ish seconds. It was pretty impressive. That wasn't theoretical, they actually demonstrated it on stage and the demo gods showed mercy on them.
Mesos and Kubernetes are both great projects. I see both projects working together to build the platforms of tomorrow.
Uhh... what?
One commenter says:
> "the Kubernetes team is looking to reimplement its JSON parser, which is also written in Go, in some other language." > Did they say that? I was under the impression they just wanted to use an alternative parser to avoid the reflection that > the std lib json parser uses.
To which his response is: > No, I was just speculating way beyond my pay grade. I have put in a call to ask some questions, but sometimes Google talks, and sometimes it doesn’t.
Here's a quick look at some work we've been doing with 1000 node clusters of kubernetes:
https://www.youtube.com/watch?v=1bHUsBhPL20