Avaliações e Detalhes do Produto de Apache Mesos

Eu amo a abstração que o Mesos fornece em termos de gerenciamento de recursos para o cluster. É integrado perfeitamente com o Apache Spark. Isso permite lançar tarefas do Spark em um cluster Mesos apenas especificando o URL do cluster Mesos. De computação local para computação em cluster com apenas um parâmetro.

Sua base de código em C++ é bastante limpa, frequentemente usando padrões de programação funcional. Análise coletada por e hospedada no G2.com.

Se você tem um aplicativo distribuído que deseja implantar no Mesos, você precisa usar um framework para lidar com ofertas de recursos para ele. Esse framework é ad-hoc para esse aplicativo e ou alguém o escreveu ou você precisa escrevê-lo por conta própria. No entanto, graças ao Marathon, que atua como um framework genérico para aplicativos containerizados, você pode implantar qualquer aplicativo que possa encapsular em um contêiner, como o Docker. Análise coletada por e hospedada no G2.com.

Os recursos de alocação são a melhor coisa que o Mesos tem. Eu gosto da maneira como fazemos a configuração, é muito simples executar o processo de mestre e escravo. A ideia de estendê-lo com frameworks foi realmente ótima, agora temos muitos frameworks para executar muitas tarefas diferentes. Análise coletada por e hospedada no G2.com.

Eu não gosto de ter que usar o zookeeper para fazer a eleição do mestre. Seria melhor se eu pudesse escolher o melhor serviço de descoberta de serviços para mim.

Às vezes é difícil depurar uma tarefa com erros.

A interface do usuário não é tão boa. Poderia ser melhor, mas funciona como está. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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 Análise coletada por e hospedada no G2.com.

1. Very good support for docker containers.

2. Easy setup

3. Logging and debug information Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no 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. Análise coletada por e hospedada no G2.com.