Apache Mesos Reviews & Product Details

I love the abstraction Mesos provides in terms of resource management for cluster. Is seamlessly integrated with Apache Spark. That allow launching Spark tasks in a Mesos cluster by just specifying the Mesos cluster URL. From local to clustered computation in just one parameter.

Its C++ code base is quite neat, often using functional programming patterns. Review collected by and hosted on G2.com.

If you have a distributed application you want to deploy on Mesos, you need to use a framework to handle resource offers for it. That framework is ad-hoc for that application and either someone else wrote it or you need to write it by yourself. However, thanks to Marathon, which acts as a generic framework for containerized applications, you can deploy whichever application you might wrap in a container such as Docker. Review collected by and hosted on G2.com.

It was easy to set up and get running in a cluster on standard hardware. It also works well in a virtual environment. Review collected by and hosted on G2.com.

Configuring it properly for memory and cpu usage is tricky. There's also not a lot of software around the cluster management and orchestration. It was hard to get visibility into your running applications. Review collected by and hosted on G2.com.

The resource allocation features are the best thing the Mesos has. I like the way we do configuration, it is very simple to run the master and slave process. The idea of extending it with frameworks was really great, now we have some many frameworks to execute a lot of different tasks. Review collected by and hosted on G2.com.

I don't like to have to use zookeeper to make the master election. It would be better if I could choose the better service discovery service for me.

Sometimes is difficult to debug a task with errors.

The UI is not so good. It could be better but it works as is. Review collected by and hosted on G2.com.

We are suppose to prepare the necessary execution environments from testing to production and everything in between. Using Docker alongside Mesos allows us to encapsulate execution environments inside the container. In coordination with Mesos it allocates a suitable machine for the service, and deploys it by pulling it from our private Docker hub onto the allocated machine.However, for external software like ElasticSearch we have no need for continuous integration and we release them directly from our local dev environment. To handle this use case we developed Shovel, which we plan to open-source shortly. It automates the process from building the Docker image containing the microservice to finally releasing them to the public. To release a microservice today we only have to prepare a Dockerfile and provide basic configuration. The rest of the release process is then completely handled by Shovel. To further simplify bootstrapping, we have a service template that contains commonly used components and allows us release a new microservice in minutes. Review collected by and hosted on G2.com.

Mesos is still in its early days, probably best exemplified by the very sub-1.0 version numbers. New Mesos releases often include important bug fixes but upgrading has been a pain point for us due to the number of moving parts that led to catch-22 situations. Review collected by and hosted on G2.com.

In Pre-Mesos we had to prepare the necessary execution environments from testing to production and everything in between. Using Docker alongside Mesos allows us to encapsulate execution environments inside the container. That frees us from the effort of provisioning the infrastructure of every new microservice we want to release.

However, for external software like ElasticSearch we have no need for continuous integration and we release them directly from our local dev environment. To handle this use case we developed Shovel, which we plan to open-source shortly. It automates the process from building the Docker image containing the microservice to finally releasing them to the public. To release a microservice today we only have to prepare a Dockerfile and provide basic configuration. The basic configuration includes settings like public URL endpoint or amount of required CPU and memory resources. The rest of the release process is then completely handled by Shovel. To further simplify bootstrapping, we have a service template that contains commonly used components and allows us release a new microservice in minutes. Review collected by and hosted on G2.com.

Mesos is still in its early days, probably best exemplified by the very sub-1.0 version numbers. New Mesos releases often include important bug fixes but upgrading has been a pain point for us due to the number of moving parts that led to catch-22 situations.

As an example, we experienced memory leaks with Docker 1.6 but were not able to upgrade for some time even though the bug got fixed in Docker 1.8. Upgrading Docker would have required upgrading to a Mesos version (0.23) that was untested with Marathon version 0.10. Review collected by and hosted on G2.com.

Stability. We rarely encounter problems that are due to Mesos itself. It is nice to be able to simply take down or add machines and have Mesos adjust accordingly.

The ability to use frameworks, such as Marathon, on top of it is also key for us. We needed long-running tasks and the ability to invoke them using REST APIs.

Support for running tasks within Docker containers is critical for us, so the Docker Containerizer is important. Review collected by and hosted on G2.com.

Documentation is good enough in most respects, but these days, it should be assumed that some people will want to run the entire Mesos framework within Docker, so officially supported Docker containers out on Docker Hub would help.

The mechanism for specifying Mesos configuration options (whether a file exists or not, the name of a file is the option name, and the content is the option value) is odd. First time I've encountered it. Review collected by and hosted on G2.com.

Pre-Mesos we had to prepare the necessary execution environments from testing to production and everything in between. Using Docker alongside Mesos allows us to encapsulate execution environments inside the container. That frees us from the effort of provisioning the infrastructure of every new microservice we want to release.

Our release process initially consisted of pushing to a service’s git release branch, which automatically triggered the continuous integration process. Marathon serves as deployment manager. In coordination with Mesos it allocates a suitable machine for the service, and deploys it by pulling it from our private Docker hub onto the allocated machine.

However, for external software like ElasticSearch we have no need for continuous integration and we release them directly from our local dev environment. To handle this use case we developed Shovel, which we plan to open-source shortly. It automates the process from building the Docker image containing the microservice to finally releasing them to the public. To release a microservice today we only have to prepare a Dockerfile and provide basic configuration. The basic configuration includes settings like public URL endpoint or amount of required CPU and memory resources. The rest of the release process is then completely handled by Shovel. To further simplify bootstrapping, we have a service template that contains commonly used components and allows us release a new microservice in minutes. Review collected by and hosted on G2.com.

Mesos is still in its early days, probably best exemplified by the very sub-1.0 version numbers. New Mesos releases often include important bug fixes but upgrading has been a pain point for us due to the number of moving parts that led to catch-22 situations.

As an example, we experienced memory leaks with Docker 1.6 but were not able to upgrade for some time even though the bug got fixed in Docker 1.8. Upgrading Docker would have required upgrading to a Mesos version (0.23) that was untested with Marathon version 0.10. Review collected by and hosted on G2.com.

Mesos is great for helping ops teams simplify and condense their infrastructure. The tools is very solid and we have had very few problems with it. There is also a large and growing community of developers creating different frameworks for mesos to suite different needs. We've created our own framework on top of mesos that runs almost the entire product. Review collected by and hosted on G2.com.

Documentation can be lacking in some cases, making it difficult to get started in certain areas. Getting started on developing a framework, or getting the mesos cluster up and running the first time can be tricky steps. However, other community members or framework developers often have information that can fill in the gaps for these cases.

Note: we operate our own mesos cluster and do not use a hosted service Review collected by and hosted on G2.com.

1. Very good support for docker containers.

2. Easy setup

3. Logging and debug information Review collected by and hosted on G2.com.

1. In few occasions mesos-slave becomes non-responsive or stuck phase, there by bunch of tasks queued to it.

2. Very tight integration to Zookeeper. Some times zookeeper is causing memory issues which leads to instability. etcd/consul integration is preferred. Review collected by and hosted on G2.com.

Apache Mesos is a cluster management framework. It actually behaves as a kernel for the data center. The best part of Apache Mesos is it's efficient tasks isolation and seamless abstraction of physical resources from VMs or machines or applications. It is going in the right direction and is best suitable for applications like Hadoop, Kafka etc. It also ensures high availability of our applications. It has an easy to use interface also. Review collected by and hosted on G2.com.

It is a bit heavy as compared to Kubernetes. Also from developer's point of view, it requires a lot of memory to build the source code. Review collected by and hosted on G2.com.