A couple of months ago we, at Container Solutions, released something that we thought was quite exciting, Mesos-starter. A library that will help us drastically reduce code repetition in our Mesos frameworks. To write a fully fledged Mesos framework you don't need to do much more than adding the spring-boot-starter-mesos Maven dependency, a Spring Application with a Main method and a small configuration file. Mesos-starter has a UniversalScheduler that fits most application cases for running a number of longrunning tasks. Tasks can either be shell command or Docker containers. And of course it's all open sourced on GitHub.

Since we released version 0.1 it has been a little bit quiet, but a few very good things have happened that will also secure the future of Mesos-starter.

First of all, two official Apache Mesos frameworks has been converted to use Mesos-starter: Logstash and Kibana. And even more are on the way. Internally at Container Solutions we’ve had a few independent developers write completely new frameworks from scratch in just a matter of days.

Also, the library has been picked up by the Infraloop project and is now a part of the recommended tool suite.

The current state

Recently we’ve been supporting the development of other frameworks that needed specific features in Mesos-starter. Next to that we’ve also been experimenting with new features, like running multiple different tasks. Currently the conclusion is that it doesn't make much sense as the scheduler will become very complex and not very microservices-ish, and by the end of the day it can be managed by building multiple Mesos-starter frameworks and putting them together with an ApplicationGroup in Marathon.

Also, we have a few known bugs, that are very high on our priority list. Testing is also something that needs improvement. For that, we will develop a specific minimesos module that will ease setting up Mesos-starter in a minimesos cluster.

Now’s probably a good time to clarify what Mesos-starter most likely will be, and what it won’t be. Mesos-starter will not be a replacement for Marathon. First of all, because it will be very difficult to remove the dependency on Marathon, as it is still the de facto method for running schedulers and the fact that Marathon is very well tested and maintained by Mesosphere.
So why even bother using Mesos-starter when Marathon is such a great tool? Because sometimes using configuration files isn’t enough to describe a business case. Sometimes you need code to describe some complex scenarios. Say for instance that you want a task to run on all agents, like we do in the Logstash Framework. Currently that’s not possible with Marathon. Or if you have some arbitrary requirements for the offers that isn’t supported in the Marathon configuration file.

The roadmap

At the time of writing it doesn’t really make sense to use Mesos-Starter without Spring Boot. I would like to change that. The goal is to boil down the current codebase into a few smaller modules, where one of them will be consisting of some very plain Java classes that you can run in almost any setup. Next to that we’ll like to keep the spring-boot-starter-mesos module that works so great with Spring Boots Autoconfiguration.

On the more low-level side of things we’re planning on releasing Mesos-starter (and all of it’s modules) to Maven Central. And we want to add support for many more Mesos features, like Unified Containerizer.

As always, if you have an comments or suggestions, please reach out to us.

We're Hiring

We are currently looking for application and systems developers to work on tools like Mesos-Starter. Take a look at the careers page and get in touch.