swarm - kubernetes mesos

Maratón vs Aurora y sus propósitos

Question

Tanto Marathon como Aurora están construidas en Mesos y, supuestamente, están diseñadas para ejecutar servicios de larga duración. Mis preguntas son:

1. ¿Cuáles son sus diferencias? Me ha costado encontrar buenas explicaciones sobre sus diferencias clave
2. ¿Estos frameworks ejecutan algo que se ejecuta en Linux? Para Marathon, afirman que puede ejecutar cualquier cosa que "sea ejecutable en una shell" pero esto es algo vago :)

¡Gracias!

Answer 1

Así que he estado evaluando ambos y este es mi resumen.

Aurora

[+] 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)

Maratón

[+] 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

Aunque Aurora tiene mejores capacidades, prefiero Marathon debido a la complejidad / sobrecarga de los Auroras y la falta de UI (para control) y API

Answer 2

Tengo más experiencia con Marathon.

Ideológico:

• Marathon es un producto relativamente probado que se utiliza en la producción en AirBnB. Aurora es un proyecto temprano de Apache (entonces YMMV).
• Ambos son de código abierto y activos. Siéntase libre de contribuir solicitudes de extracción o problemas de archivos!

Técnico:

• Marathon no programa tareas por lotes o trabajos cron
• Marathon tiene una interfaz de usuario amigable y mejores indicadores de salud (en 0.8.x)

En lo que respecta a su segunda pregunta, puede ejecutar cualquier comando o contenedor de ventana acoplable, y Mesos hará el aislamiento de recursos por usted. Si tiene un 50% de nodos CentOS y un 50% de nodos de Ubuntu y ejecuta una tarea que ejecuta apt-get , la tarea tendrá un 50% de probabilidad de fracaso. Mesos y Marathon no tienen conocimiento de las máquinas reales.

Answer 3

Descargo de responsabilidad: no tengo experiencia práctica con Aurora, solo con Marathon.

anuncio P1: en pocas palabras, Apache Aurora es capaz de hacer lo que Marathon + Chronos puede proporcionar, es decir, programar servicios de larga duración y trabajos recurrentes (por lotes); Consulte también la guía del usuario de Aurora .

anuncio Q2: Sí, cualquier cosa. Actualmente se basa en cgroups y Docker, pero bueno, puedes hacer tu propio rollo .

Answer 4

Descargo de responsabilidad: soy el vicepresidente de Apache Aurora, y he sido el líder tecnológico del equipo de Aurora en Twitter durante ~ 5 años. Mis opiniones probablemente sesgadas son mías y no representan necesariamente las de Twitter o ASF.

¿Estos frameworks ejecutan algo que se ejecute en Linux? Para Marathon, afirman que puede ejecutar cualquier cosa que "sea ejecutable en una shell" pero esto es algo vago :)

Esencialmente, sí. En última instancia, estos sistemas son maquinaria sofisticada para ejecutar código de shell en algún lugar de un clúster :-)

¿Cuáles son sus diferencias? Me ha costado encontrar buenas explicaciones sobre sus diferencias clave

De hecho, Aurora y Marathon ofrecen conjuntos de características similares, ambos clasificados como "programadores de servicios". En otras palabras, nos da instrucciones sobre cómo ejecutar sus servidores de aplicaciones y hacemos todo lo posible para mantenerlos.

Voy a ofrecer algunas diferencias a grandes rasgos. Cuando se trata de las deficiencias mencionadas en cada una, creo que es seguro decir que las comunidades están conscientes y tienen la intención de solucionarlas.

Facilidad de uso

Aurora no es fácil de instalar. Es probable que sientas que eres pionero al configurarlo. Expone una API de ahorro, lo que significa que necesitará un cliente de ahorro para interactuar con ella mediante programación (se acerca una API similar a REST, pero es un software de vapor en este momento), o use nuestro cliente de línea de comandos. Aurora tiene un DSL para la configuration que puede ser desalentador, pero le permite compartir fácilmente plantillas y patrones comunes a medida que usa más el sistema.

Marathon, por otro lado, te ayuda a ejecutar "Hello World" lo más rápido posible. Tiene excelentes docs para hacer esto en muchos entornos y hay pocos gastos generales para ponerse en marcha. Tiene una API REST, lo que facilita su adaptación a las herramientas personalizadas. Utiliza JSON para la configuration , que es fácil de comenzar pero más propenso al cultivo de carga.

Casos de uso dirigidos

Aurora siempre ha sido diseñada para manejar una gran organización de ingeniería. Los clusters en Twitter tienen decenas de miles de máquinas y cientos de ingenieros que las usan. Es crítico para el negocio de Twitter. Como resultado, nos tomamos muy en serio nuestros requisitos de escala, estabilidad y seguridad. Nos aseguramos de aprobar solo las características que creemos que son confiables a escala en producción (por ejemplo, tenemos nuestro soporte Docker etiquetado como beta debido a problemas conocidos con Docker y la integración Mesos-Docker). También tenemos características como la preferencia que hacen que nuestros grupos sean adecuados para mezclar servicios críticos para el negocio con prototipos y experimentos.

No puedo reclamar a favor o en contra de la escalabilidad de Marathon. En el frente de funciones, Marathon ha desarrollado funciones rápidamente, pero esto puede ser una ventaja en la práctica (el soporte Docker es un buen ejemplo). Esto no siempre se debe a Marathon en sí, sino también a las capas de la pila. Maratón no proporciona preferencia.

Propiedad

Para algunos, la propiedad y el gobierno de un proyecto es importante. Siente que en la práctica no define la apertura de un proyecto, pero para algunas personas / empresas, la letra pequeña legal puede ser un factor decisivo.

• Marathon es propiedad de una empresa (Mesosphere)

Para algunos, esto es beneficioso, para otros es no. Esto significa que puedes pagar por el soporte y las funciones. También significa que hay algo que vender, y la dirección del proyecto se decide en última instancia por los intereses de Mesosphere.

• Aurora es propiedad de Apache Software Foundation

Esto significa que está sujeto al modelo de gobernanza del ASF, impulsado por la comunidad. Aurora no tiene clientes que pagan, y actualmente no hay una tienda de software que pueda pagar por el desarrollo.

tl; dr Si solo se está mojando los pies con los servicios para correr en Mesos, sugeriría Marathon como su primer puerto de escala. Le será más fácil correr y hurgar en el ecosistema. Si está formando la ''estrategia de nube privada'' para una empresa, sugiero considerar seriamente a Aurora, ya que está probado y específicamente diseñado para eso.