Hacker News Reader

Comment by stanley | Hacker News Reader

How does Mesosphere differ from CoreOS? I haven't worked with either one, but as a casual observer it seems like there's a bit of overlap between the two platforms. Is that a fair assessment, and can anyone comment on the maturity of one solution vs the other?

View on HN

Mesosphere is based on Apache Mesos, Marathon and other technologies. Mesos is an abstraction of the underlying hardware - exposing APIs to allow running tasks in a cluster ~ think of just launching threads on your linux box - with Mesos it's similar, you can launch processes on your servers across your datacenter or cloud. It's production software that powers Twitter, Airbnb and other companies at scale. Mesos is more than just orchestration - it's really a fabric for writing distributed systems. Apache Spark was a sample app written for Mesos. Marathon is another application that runs on top of Mesos and orchestrates containers. It can handle tens of thousands of containers and more in a single cluster. Chronos and Storm are other systems that can run on top of Mesos.

Marathon: https://mesosphere.github.io/marathon/ Chronos: https://airbnb.github.io/chronos/

In addition to what others replied, you might be interested in this presentation by Benjamin Hindman (who co-created Mesos) to see how it all fits together: https://www.youtube.com/watch?v=F1-UEIG7u5g

CoreOS is Linux distribution. It has been tuned to be lightweight, secure, and highly compatible with Docker among other things.

Mesos is a job scheduler for large distributed systems based on a quick read.

edit: and to the point, it is very natural to consider Mesos slaves as running inside of Docker containers (which may be based on CoreOS)

CoreOS contains a tool called fleet, which abstracts systemd into a cluster init system. fleet has scheduling rules such as "don't schedule more than 1 foobar on this box" or "schedule this app on a box with metadata region=foo" built in to it.

fleet doesn't aspire to do complex resource scheduling or high density bin-packing. The best way to accomplish these tasks is to use fleet to bootstrap more complex and higher-level services like Mesos, Kubernetes or Deis. fleet will make sure the components of those services are running in the cluster, even if machines die or are partitioned.

(CoreOS employee)

It'd be very interesting if you know anyone who is doing this sort of thing (fleetd for bootstrapping a more "heavyweight" scheduler) in production, and could prod them to do a write-up on their system. It might inspire some more interesting PaaS products. :)

Deis has been doing this successfully for a while now. Their work is all open source. Here's what the units look like to bootstrap all of their components: https://github.com/deis/deis/tree/master/deisctl/units

More info on the components: http://docs.deis.io/en/latest/understanding_deis/architectur...

The Kubernetes project has also documented a getting started guide for CoreOS: https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

Or, more robustly, run Kubernetes, Deis, and Marathon — along with Spark, Hadoop, Cassandra, and so on, all Mesos, all on the same cluster. Mesos is the only technology capable of doing that at any scale.

Reply on news.ycombinator.com