When Should I Use Marathon?
When you’re assembling your Mesos cluster, you need to figure out what kind of frameworks are appropriate for the workloads you’re going to run. Marathon comes up a lot in discussions and searches, but is it right for you?
You should use Marathon when you have long-running tasks (think web services, not long ETL jobs) that you want to keep alive on the cluster despite service and underlying hardware failure.
Marathon can also run other frameworks (most of which are long-running tasks
themselves.) For example, if you wanted to run
Chronos (the equivalent of cron for a
cluster) you can specify that and Marathon will keep it alive and running.
Marathon has a RESTful API and supports Dockerized workloads, so you don’t need to worry about what language your software is implemented in. If you can ship it around the cluster, Marathon can manage it.
When should I not Use Marathon?
There are four basic situations in which Marathon by itself wouldn’t be a good fit:
- When your task is a process that should be run at a set interval. (use Chronos.)
- If the task requires keeping state on disk. This is coming, but as of now persistent disk resources are not in the main builds.
- When you know the task is going to end as part of it’s normal lifecycle. For example, a data processing job would fall into this category because you know that it will finish working eventually.
- If your task has complex requirements regarding service discovery or linking (for example, running HDFS or Kafka.) In these cases, a dedicated framework would be better suited to keeping it alive. However, you can probably run that framework using Marathon. (Hint: search for “{service name} Mesos framework”.)
All Right!
You can now choose for yourself whether or not you should use Marathon in your Mesos cluster. In fact, here’s a cheat sheet to help remember the things you should be thinking about when deciding:
