Marathon vs Aurora et leurs objectives

Marathon et Aurora sont tous deux construits sur Mesos et sont supposés être conçus pour exécuter des services de longue durée. Mes questions sont:

  1. Quelles sont leurs différences? J’ai eu du mal à trouver de bonnes explications concernant leurs principales différences
  2. Ces frameworks exécutent-ils tout ce qui fonctionne sous Linux? Pour Marathon, ils déclarent qu’il peut exécuter tout ce qui est “exécutable dans un shell”, mais c’est en quelque sorte vague 🙂

Merci!

Clause de non-responsabilité: Je suis le vice-président d’Apache Aurora et je suis le responsable technique de l’équipe Aurora sur Twitter depuis environ 5 ans. Mes opinions biaisées sont les miennes et ne représentent pas nécessairement celles de Twitter ou de l’ASF.

Ces frameworks exécutent-ils tout ce qui fonctionne sous Linux? Pour Marathon, ils déclarent qu’il peut exécuter tout ce qui est “exécutable dans un shell”, mais c’est en quelque sorte vague 🙂

Essentiellement, oui. En fin de compte, ces systèmes sont des machines sophistiquées pour exécuter du code shell quelque part dans un cluster 🙂

Quelles sont leurs différences? J’ai eu du mal à trouver de bonnes explications concernant leurs principales différences

Aurora et Marathon proposent en effet des fonctionnalités similaires, toutes deux classées comme “ordonnanceurs de services”. En d’autres termes, vous nous donnez des instructions sur la manière de faire fonctionner vos serveurs d’applications et nous nous efforçons de les conserver.

Je vais offrir des différences dans les grandes lignes. En ce qui concerne les lacunes mentionnées dans chacun d’eux, je pense qu’il est prudent de dire que les communautés sont au courant et ont l’intention de les corriger.

Facilité d’utilisation

Aurora n’est pas facile à installer. Vous vous sentirez probablement comme un pionnier en le mettant en place. Il expose une API d’épargne, ce qui signifie que vous aurez besoin d’un client d’épargne pour interagir avec lui par programmation (une API de type REST arrive, mais est un vaporware pour le moment), ou utilisez notre client de ligne de commande. Aurora possède un DSL pour la configuration qui peut être intimidant, mais vous permet de partager facilement des modèles et des modèles courants lorsque vous utilisez davantage le système.

Marathon, d’autre part, vous aide à exécuter «Hello World» le plus rapidement possible. Il a d’excellents documents pour faire cela dans de nombreux environnements et il y a peu de frais pour y aller. Il possède une API REST, ce qui facilite son adaptation aux outils personnalisés. Il utilise JSON pour la configuration , qui est facile à démarrer, mais plus enclin à la culture de fret.

Cas d’utilisation ciblés

Aurora a toujours été conçu pour gérer une grande organisation d’ingénierie. Les clusters de Twitter utilisent des dizaines de milliers de machines et des centaines d’ingénieurs. C’est critique pour les affaires de Twitter. Par conséquent, nous prenons très au sérieux nos exigences en matière d’échelle, de stabilité et de sécurité. Nous veillons à ne tolérer que les fonctionnalités qui, selon nous, sont dignes de confiance à l’échelle de la production (par exemple, notre support Docker est étiqueté en version bêta en raison de problèmes connus avec Docker et l’intégration de Mesos-Docker). Nous avons également des fonctionnalités telles que la préemption qui rendent nos clusters adaptés au mélange de services critiques avec des prototypes et des expériences.

Je ne peux rien réclamer pour ou contre l’évolutivité de Marathon. Sur le front des fonctionnalités, Marathon a rapidement développé des fonctionnalités, mais cela peut sembler surprenant dans la pratique (le support Docker est un bon exemple). Ce n’est pas toujours dû à Marathon lui-même, mais à la couche. Marathon ne fournit pas de préemption.

La possession

Pour certains, la propriété et la gouvernance d’un projet sont importantes. Il estime que dans la pratique, cela ne définit pas l’ouverture d’un projet, mais pour certaines personnes / entresockets, les petits caractères juridiques peuvent être un facteur de rupture.

  • Marathon appartient à une société (Mésosphère)

Pour certains, cela est bénéfique, pour d’autres, ce n’est pas le cas. Cela signifie que vous pouvez payer pour le support et les fonctionnalités. Cela signifie également qu’il y a quelque chose à vendre, et la direction du projet est finalement décidée par les intérêts de Mesosphere.

  • Aurora appartient à Apache Software Foundation

Cela signifie qu’il est soumis au modèle de gouvernance de la FAA, piloté par la communauté. Aurora n’a pas de clients payants et il n’y a pas actuellement de boutique de logiciels que vous pouvez payer pour le développement.

tl; dr Si vous vous contentez de faire fonctionner des services sur Mesos, je vous suggérerais Marathon comme premier port d’escale. Il sera plus facile pour vous de courir et de contourner l’écosystème. Si vous créez la «stratégie de cloud privé» pour une entreprise, je suggère sérieusement d’envisager Aurora, car elle a fait ses preuves et a été spécialement conçue pour cela.

J’ai donc évalué les deux et c’est mon résumé.

Aurore

[+] also handles recurring jobs [+] finer grained, extensive file-based configuration [+] has namespaces so multiple environments can co-exist [-] read-only UI, no official API [~] file based configuration and cli based execution brings overhead (which can be justified with more extensive feature set) 

Marathon

 [+] very easy to setup and use [+] UI that provides control and extensive API (even with features missing from UI at the moment) [+] event bus to listen in on api calls [-] handles only long-running jobs [-] does not have separate deployment-run-cleanup steps, these if necessary need to be combined in a script of one-liner 

Même si Aurora a de meilleures capacités, je préfère Marathon en raison de la complexité / des frais généraux des Aurora et du manque d’interface utilisateur (pour le contrôle) et d’API

J’ai plus d’expérience avec Marathon.

Idéologique:

  • Marathon est un produit relativement éprouvé utilisé en production chez AirBnB. Aurora est un projet Apache précoce (donc YMMV).
  • Les deux sont open source et actifs. N’hésitez pas à consortingbuer aux demandes de tirage ou aux problèmes de fichiers!

Technique:

  • Marathon ne planifie pas les tâches par lots ou les tâches cron
  • Marathon a une interface conviviale et de meilleurs indicateurs de santé (en 0.8.x)

En ce qui concerne votre deuxième question, vous pouvez exécuter n’importe quelle commande ou conteneur Docker, et Mesos effectuera l’isolation des ressources pour vous. Si vous avez 50% de nœuds CentOS et 50% de nœuds Ubuntu et que vous exécutez une tâche qui exécute apt-get , la tâche aura 50% de risques d’échec. Mesos et Marathon ne sont pas au courant des machines actuelles.

Disclaimer: Je n’ai pas d’expérience pratique avec Aurora, seulement avec Marathon.

ad Q1: En résumé, Apache Aurora est capable de faire ce que Marathon + Chronos peut fournir, c’est-à-dire planifier à la fois des services de longue durée et des travaux récurrents (batch); voir aussi le guide de l’utilisateur Aurora .

annonce Q2: Oui, n’importe quoi. Actuellement basé sur les groupes de contrôle et Docker mais bon, vous pouvez lancer vos propres .