Flynn: ¿por qué no tsuru?

Esto se discutió en golang-nuts . Mi impresión es que, si bien algunas de las funciones son similares, los objetivos principales son diferentes.

/ cc @fsouza

@titanous Vi este hilo. Si la mayor diferencia entre tsuru y flynn es tsuru, sea específico para web, con poco esfuerzo se puede modificar.

Creo que si los dos proyectos se unen será mejor para estos proyectos y hará más fácil construir una comunidad más fuerte para hacer y mantener este nuevo proyecto (tsuru + flynn) como lo que pasó con rails + merb.

Actualmente estamos trabajando en una especificación más completa que detallará los componentes y los objetivos que estamos planeando. Creo que sería constructivo posponer esta discusión hasta que impulsemos ese documento.

Cerrando, ya que creo que está más claro cuáles son las diferencias ahora.

¿Cuáles son las diferencias? No me queda claro, ¿hay alguna fuente que pueda recomendar que tenga sentido para todo el trabajo de PaaS que se está haciendo?

He estado tratando de resolverlo a través de la investigación, pero sigo aprendiendo acerca de más y más sistemas PaaS que se crean con Docker, las cosas se sienten realmente fragmentadas; es realmente difícil mantenerse al día ... Cada uno de estos sistemas requiere tiempo y dedicación para configurar y probar antes de que uno realmente pueda saber qué es: ¿hay una manera más fácil de familiarizarse con todos los proyectos que ocurren en este espacio sin que tome tanto tiempo y sea una madriguera de conejo sin fin?

Por lo que he visto hasta ahora, Flynn se ve bastante dulce, estoy emocionado de probarlo pronto.

PD: llegué aquí buscando en Google "tsuru flynn"

@keyvanfatehi Gracias por su interés.

Es difícil mantenerse actualizado con todos los proyectos de PaaS que existen, especialmente porque muchos siguen hojas de ruta privadas o inconsistentes. En general, esto es lo que creemos que son las diferencias entre Flynn y la mayoría de los otros proyectos de PaaS (no una comparación directa con tsuru, solo el espacio en general):

Flynn es más ambicioso. Flynn puede ejecutar cualquier cosa que se ejecute en Linux, incluidos los servicios con estado. Aprovechamos esta capacidad para empaquetar bases de datos comunes junto con Flynn, por lo que la mayoría de los usuarios y proyectos nunca volverán a administrar manualmente las bases de datos. Los componentes de Flynn son modulares, lo que facilita su reutilización, modificación y sustitución para crear la solución adecuada para sus necesidades. Realmente queremos que Flynn sea un conjunto de herramientas único que "resuelva" operaciones para cada proyecto y organización. Hay mucho más por venir, incluida la agregación de registros, métricas, integración continua junto con soluciones de próxima generación para flujos de trabajo de desarrollo y redes.

La mayoría de los otros proyectos de PaaS son al menos uno de los siguientes: difíciles / lentos de configurar e implementar, solo útiles para tipos específicos de aplicaciones, requieren que los desarrolladores rediseñen sus aplicaciones y monolíticos. En resumen, creemos que Flynn intenta resolver los problemas difíciles y la mayoría de los otros proyectos no lo hacen, debido a su antigüedad, bases de usuarios existentes y motivaciones de diseño.

A medida que Flynn alcance la estabilidad de producción y la finalización de funciones, intentaremos documentar las diferencias por proyecto.

@danielsiders ¡ gracias! Espero verlos innovar en este espacio. Definitivamente sufro por tener demasiadas operaciones cayendo sobre mis hombros (por eso estoy mirando a Docker y las herramientas a su alrededor). Me gustaría creer que las operaciones se pueden resolver, por así decirlo ...

Hasta ahora, mi experiencia ha sido usar flynn-demo (con éxito) que parecía ser como deis (que no he probado directamente, pero tienen un buen video en bucle que muestra un comportamiento similar al heroku). Entonces, en este nivel superficial, deis, flynn y heroku parecen idénticos.

Ese es un buen punto acerca de las hojas de ruta privadas: creo que tal vez sea un poco temprano para esperar entenderlo todo. Parece mucho más fácil comprometerse con un esfuerzo u otro que tratar de hacer un seguimiento, discernir las diferencias y tratar de juzgar cada esfuerzo ... ¡cada uno es innovador e interesante!

de todos modos, tiempos emocionantes, gracias por ser parte de hacer que todo esto suceda, incluso si aún no puedo entenderlo completamente :)

@keyvanfatehi la mayoría de las PaaS admiten la implementación de aplicaciones al estilo Heroku (git push). Donde las cosas realmente difieren es en el tipo de aplicaciones que se pueden implementar y lo que sucede después de que se implementa una aplicación.

(Nota: Flynn también admite muchos otros paradigmas de implementación como docker pull y git pull y cualquier otra cosa que desee construir. Incluso FTP no sería difícil)

@keyvanfatehi , en Tsuru creemos que sería más eficiente requerir algunos pequeños cambios en la aplicación (como la configuración por entorno y el uso de un almacenamiento de objetos para archivos estáticos), porque inevitablemente necesitará diseñar su aplicación para que se ajuste a un paradigma de la nube ( ej .: necesita escalar horizontalmente sin problemas). Pero lo hicimos tan bien que nuestros usuarios lo obtienen a un ritmo muy rápido, ya tenemos productos en producción aquí (en Globo.com).
En cuanto a los servicios, son demasiado específicos para manejarlos bien con una sola aplicación (imagínese lo difícil que sería tratar con bases de datos, nosql, redis, memcached, elasticsearch, almacenamiento de objetos, etc.). Preferimos especificar una API de servicio (donde se ubicará la lógica comercial para manejar el servicio) y tsuru tratará de la misma manera con cualquier servicio, sin importar cuán diferentes sean.

Somos muy amables y estamos totalmente abiertos a contribuciones y nuevas ideas. Seguimos pensando que sería genial trabajar con flynn en una única solución (podríamos extender tsuru para cumplir con el ideal de flynn en el futuro), pero respetamos totalmente su opinión y visión, ya que son tan ambiciones como las nuestras :-)

TL; DR
Sabemos que los servicios son importantes, por eso desarrollamos una forma elegante de abordar ese requisito. Tsuru puede manejar cualquier servicio con una API de servicio bien definida (con algunos puntos de entrada simples como crear, eliminar, vincular, planificar). Entonces, toda la complejidad de un servicio específico será manejada por su propio service-api. Le damos un ejemplo sobre nuestra API de Redis: cuando ejecuta # tsuru service-add redis (servicename) redis_blognews (serviceinstancename) plus (plan), creará una instancia de redis con el nombre redis_blognews y el plan plus (que proporciona 2 instancias de redis con alta disponibilidad). Tsuru no sabe cómo se creará (incluso si tendrá alta disponibilidad), será completamente manejado por service-api. También hace posible el uso de servicios externos (incluso propietarios) simplemente creando una API de servicio para eso sin tocar el código tsuru. Por lo tanto, será mucho más flexible tratar con los servicios y evitar aumentar esa complejidad en Tsuru. Después de eso, puede usar # tsuru bind redis_blognews --app yourblognewsapp y tsuru inyectará las credenciales del servicio en su aplicación

Soy nuevo en PaaSes y es confuso. Elegí a Tsuru y he estado jugando un poco con eso. Me parece que no es tan diferente de los objetivos de Flynn. Puede ejecutar cosas con estado utilizando su API de servicio y es muy modular, donde tiene tsuru-api, docker-cluster, gandalf, etc.

Todavía me pregunto si la combinación de esfuerzos traerá un mejor producto.

Debo estar de acuerdo con @msabramo aquí, todavía no veo ningún buen punto de por qué construir una nueva PaaS que tenga todas las características de Tsuru. También estoy de acuerdo en que combinar esfuerzos haría un producto asombroso.