3 ms·

Having used both DC/OS (mesos & marathon) and kubernetes in production. The one thing DC/OS had absolutely nailed was the web interface and bootstrap. The DC/O

by gnur 8y ago

Having used both DC/OS (mesos & marathon) and kubernetes in production. The one thing DC/OS had absolutely nailed was the web interface and bootstrap. The DC/OS interface is brilliant as it allows you to explore all the possibilities and actually have a overview of what is happening. Also, it was a lot easier to reason about because everything is contained in a single marathon job. No need to split everything up in deployments / services / ingresses. A single JSON file is all you need for DC/OS. Less to think about. The downside of all this is that DC/OS feels like a solution for a theoretical problem, while kubernetes is the solution to practical problems.

amazingman 8y ago
It seems to me that running Kubernetes as a service on DC/OS might be a decent path to take. Mesosphere seem to be pushing this pretty hard, too. What did you think of DC/OS as a base platform? From an ops perspective, I’m finding a lot to like at least conceptually. Especially the idea of managing one “kind” of cluster that then manages many additional kinds for you. But I have yet to actually use it.
- gnur 8y ago
  It sounds great, but I've always found the DC/OS marketplace not really flexible enough. I've looked at many services, but in most cases the requirements for running a service from the marketplace were for extremely high throughput situations. I wanted to experiment with arrongoDB but it required a total of 16GB memory (IIRC). Practically, I think kubernetes with helm charts gets will get you at least 90% of what DC/OS offers. Also, running Kubernetes itself is complicated enough, running it on a different scheduler will just expose you to the pains of both schedulers.
  - chrisgaun 8y ago
    Mesos means "middle" and it was designed to handle the declarative infrastructure provisioning for different schedulers... container orchestration schedulers: Aurora (Youtube/Twitter), Titus (Netflix), Marathon and Kubernetes (DC/OS).... analytics schedulers: Spark, Tensorflow, etc. The idea was always that you should manage this infrastructure just like they are managing containers. discloser: I am the PM of Kubernetes on DC/OS.
bfrydl 8y ago
FWIW, while the resources themselves are still split up, you can combine any number of resource definitions into a single YAML file for Kubernetes. Just separate each with ---

by gnur 8y ago

amazingman 8y ago

It seems to me that running Kubernetes as a service on DC/OS might be a decent path to take. Mesosphere seem to be pushing this pretty hard, too. What did you think of DC/OS as a base platform? From an ops perspective, I’m finding a lot to like at least conceptually. Especially the idea of managing one “kind” of cluster that then manages many additional kinds for you. But I have yet to actually use it.

gnur 8y ago
It sounds great, but I've always found the DC/OS marketplace not really flexible enough. I've looked at many services, but in most cases the requirements for running a service from the marketplace were for extremely high throughput situations. I wanted to experiment with arrongoDB but it required a total of 16GB memory (IIRC). Practically, I think kubernetes with helm charts gets will get you at least 90% of what DC/OS offers. Also, running Kubernetes itself is complicated enough, running it on a different scheduler will just expose you to the pains of both schedulers.
- chrisgaun 8y ago
  Mesos means "middle" and it was designed to handle the declarative infrastructure provisioning for different schedulers... container orchestration schedulers: Aurora (Youtube/Twitter), Titus (Netflix), Marathon and Kubernetes (DC/OS).... analytics schedulers: Spark, Tensorflow, etc. The idea was always that you should manage this infrastructure just like they are managing containers. discloser: I am the PM of Kubernetes on DC/OS.

bfrydl 8y ago

FWIW, while the resources themselves are still split up, you can combine any number of resource definitions into a single YAML file for Kubernetes. Just separate each with ---