Reseñas y detalles del producto de Apache Mesos

Me encanta la abstracción que Mesos proporciona en términos de gestión de recursos para el clúster. Está perfectamente integrado con Apache Spark. Eso permite lanzar tareas de Spark en un clúster de Mesos simplemente especificando la URL del clúster de Mesos. De la computación local a la computación en clúster con solo un parámetro.

Su base de código en C++ es bastante limpia, a menudo utilizando patrones de programación funcional. Reseña recopilada por y alojada en G2.com.

Si tienes una aplicación distribuida que deseas desplegar en Mesos, necesitas usar un framework para manejar las ofertas de recursos para ella. Ese framework es ad-hoc para esa aplicación y o bien alguien más lo escribió o necesitas escribirlo tú mismo. Sin embargo, gracias a Marathon, que actúa como un framework genérico para aplicaciones en contenedores, puedes desplegar cualquier aplicación que puedas envolver en un contenedor como Docker. Reseña recopilada por y alojada en G2.com.

Fue fácil de configurar y poner en marcha en un clúster en hardware estándar. También funciona bien en un entorno virtual. Reseña recopilada por y alojada en G2.com.

Configurarlo adecuadamente para el uso de memoria y CPU es complicado. Tampoco hay mucho software para la gestión y orquestación de clústeres. Fue difícil obtener visibilidad de tus aplicaciones en ejecución. Reseña recopilada por y alojada en G2.com.

Las características de asignación de recursos son lo mejor que tiene Mesos. Me gusta la forma en que hacemos la configuración, es muy simple ejecutar el proceso de maestro y esclavo. La idea de extenderlo con frameworks fue realmente genial, ahora tenemos muchos frameworks para ejecutar una gran variedad de tareas diferentes. Reseña recopilada por y alojada en G2.com.

No me gusta tener que usar zookeeper para hacer la elección del maestro. Sería mejor si pudiera elegir el mejor servicio de descubrimiento de servicios para mí.

A veces es difícil depurar una tarea con errores. La interfaz de usuario no es tan buena. Podría ser mejor, pero funciona tal como está. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en G2.com.

Mesos is a good tool and I have found it to scale quite well without being in the way. There is also a community around it, and Google's encouragement helps. I can't speak to Mesosphere DCOS because I haven't used it. Reseña recopilada por y alojada en G2.com.

Some aspects of the design can be problematic. Particularly, the way the resource allocation is designed makes it harder to build "intelligent" allocator modules into the mesos master that can decide who to offer resources to. On one hand, fairly simple to write an allocator, but on the other, a custom alllocator can't (last I checked) easily access any data it wants about the current state of the mesos agents and frameworks. Progress is being done in this area, though. Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en 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 Reseña recopilada por y alojada en G2.com.

1. Very good support for docker containers.

2. Easy setup

3. Logging and debug information Reseña recopilada por y alojada en 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. Reseña recopilada por y alojada en G2.com.