4 ms·

This is much more the real story but I doubt most folks will ever hear it. Totally agree. Mesos project always had a trouble with governance and didn't build o

by jaaron 6y ago

This is much more the real story but I doubt most folks will ever hear it. Totally agree. Mesos project always had a trouble with governance and didn't build out the larger community the way other projects did. If they had built that coalition, made the project more accessible to others, who knows, maybe it would have gone differently. Then again, k8s succeeded in part due to the Google reputation (even if undeserved) and it's use of GoLang. I always found Mesos' use of C++ meant many of the users (often developing in Java, Go, or Node) just wouldn't contribute.

aabhay 6y ago
I think the problem went deeper than that actually. Mesos required that applications use a distributed system API to interface with the executors. This meant it was very challenging to write a distributed system upon Mesos, even though that was ostensibly the very thing that Mesos was meant to solve. When K8s came along and made everything manifest and YAML-based, we sort of knew that we were screwed because of how much simpler that was.
- jaaron 6y ago
  Eh, maybe. I see your point. The thing is, Mesos on it's own isn't k8s. Mesos is a scheduler. k8s is a full stack. So it's always been a bit off to fully compare the two. If your system fit clearly within what k8s did well, then you were fine and the stack worked. If you had a more complicated architecture with parts that didn't play well with containers or k8s' scheduling model, life became pretty difficult. That's one reason I liked Mesos is you could build the stack you needed for _your_ infrastructure. Granted, I don't think most shops had the kind of problems that warranted Mesos, let alone k8s (that's still true today). But k8s is "good enough" for lots of problems and understandably that's where the community went.

4 ms·

This is much more the real story but I doubt most folks will ever hear it. Totally agree. Mesos project always had a trouble with governance and didn't build o

by jaaron 6y ago

aabhay 6y ago
I think the problem went deeper than that actually. Mesos required that applications use a distributed system API to interface with the executors. This meant it was very challenging to write a distributed system upon Mesos, even though that was ostensibly the very thing that Mesos was meant to solve. When K8s came along and made everything manifest and YAML-based, we sort of knew that we were screwed because of how much simpler that was.
- jaaron 6y ago
  Eh, maybe. I see your point. The thing is, Mesos on it's own isn't k8s. Mesos is a scheduler. k8s is a full stack. So it's always been a bit off to fully compare the two. If your system fit clearly within what k8s did well, then you were fine and the stack worked. If you had a more complicated architecture with parts that didn't play well with containers or k8s' scheduling model, life became pretty difficult. That's one reason I liked Mesos is you could build the stack you needed for _your_ infrastructure. Granted, I don't think most shops had the kind of problems that warranted Mesos, let alone k8s (that's still true today). But k8s is "good enough" for lots of problems and understandably that's where the community went.