Flynn: pourquoi pas tsuru?

Cela a été discuté sur les noix de golang . J'ai l'impression que si certaines fonctionnalités sont similaires, les objectifs principaux sont différents.

/ cc @fsouza

@titanous j'ai vu ce fil. Si la plus grande différence entre tsuru et flynn est tsuru, soyez spécifique au web, avec peu d'effort il peut être modifié.

Je crois que si les deux projets se rejoignent, ce sera mieux pour ces projets et cela facilitera la construction d'une communauté plus forte pour créer et maintenir ce nouveau projet (tsuru + flynn) comme ce qui s'est passé avec rails + merb.

Nous travaillons actuellement sur une spécification plus complète qui détaillera les composants et les objectifs que nous prévoyons. Je pense qu'il serait constructif de reporter cette discussion jusqu'à ce que nous poussions ce document.

Clôture, car je pense que les différences sont plus claires maintenant.

Quelles sont les différences? Ce n'est pas clair pour moi, y a-t-il une source que vous pouvez recommander qui donne un sens à tout le travail PaaS qui est en cours?

J'ai essayé de le comprendre grâce à des recherches, mais je n'arrête pas d'apprendre que de plus en plus de systèmes PaaS sont créés avec Docker, les choses semblent vraiment fragmentées; il est vraiment difficile de suivre le rythme ... Chacun de ces systèmes nécessite du temps et du dévouement à configurer et à essayer avant de pouvoir vraiment savoir de quoi il s'agit - existe-t-il un moyen plus simple de se familiariser avec tous les projets qui se déroulent dans ce domaine? l'espace sans que cela prenne si longtemps et ne soit un terrier de lapin sans fin?

D'après ce que j'ai vu jusqu'à présent, Flynn a l'air plutôt gentil - je suis ravi de l'essayer bientôt.

PS je suis arrivé ici en googlant "tsuru flynn"

@keyvanfatehi Merci de votre intérêt.

Il est difficile de se tenir au courant de tous les projets PaaS, d'autant plus que beaucoup suivent des feuilles de route privées ou incohérentes. En général, voici ce que nous pensons que les différences entre Flynn et la plupart des autres projets PaaS sont (pas une comparaison directe avec tsuru, juste l'espace en général):

Flynn est plus ambitieux. Flynn peut exécuter tout ce qui fonctionne sous Linux, y compris les services avec état. Nous profitons de cette capacité pour empaqueter des bases de données communes avec Flynn, de sorte que la plupart des utilisateurs et des projets ne gèrent plus jamais manuellement les bases de données. Les composants de Flynn sont modulaires, ce qui facilite leur réutilisation, leur modification et leur remplacement pour créer la solution adaptée à vos besoins. Nous voulons vraiment que Flynn soit une boîte à outils unique qui «résout» les opérations pour chaque projet et organisation. Il y a beaucoup plus à venir, y compris l'agrégation de journaux, les métriques, l'intégration continue ainsi que les solutions de nouvelle génération pour les flux de travail de mise en réseau et de développement.

La plupart des autres projets PaaS sont au moins l'un des suivants: difficile / lent à mettre en place et à déployer, utile uniquement pour des types d'applications spécifiques, oblige les développeurs à restructurer leurs applications et monolithique. En bref, nous pensons que Flynn essaie de résoudre les problèmes difficiles et la plupart des autres projets ne le font pas, en raison de leur âge, de leurs bases d'utilisateurs existantes et de leurs motivations de conception.

Au fur et à mesure que Flynn atteint la stabilité de la production et l'achèvement des fonctionnalités, nous essaierons de documenter les différences par projet.

@danielsiders merci! J'ai hâte de vous voir innover dans cet espace. Je souffre vraiment d'avoir trop d'opérations qui tombent sur mes épaules (c'est pourquoi je regarde Docker et les outils qui l'entourent). J'aimerais croire que les opérations peuvent être résolues, pour ainsi dire ...

Jusqu'à présent, mon expérience a utilisé la démo flynn (avec succès) qui semblait être comme deis (que je n'ai pas essayé directement, mais ils ont une belle vidéo en boucle montrant un comportement de type heroku). Donc, à ce niveau peu profond, deis, flynn et heroku semblent identiques.

C'est un bon point à propos des feuilles de route privées - je pense qu'il est peut-être un peu tôt pour moi de m'attendre à comprendre tout cela. Il semble beaucoup plus facile de simplement s'engager dans un effort ou un autre que d'essayer de suivre, de discerner les différences et d'essayer de juger chaque effort ... chacun étant innovant et intéressant!

de toute façon, des moments passionnants - merci de faire partie de tout cela, même si je ne peux pas encore le comprendre pleinement :)

@keyvanfatehi la plupart des PaaS prennent en charge le déploiement d'applications de type Heroku (git push). Là où les choses diffèrent vraiment, c'est le type d'applications qui peuvent être déployées et ce qui se passe après le déploiement d'une application.

(nb: Flynn prend également en charge de nombreux autres paradigmes de déploiement comme docker pull et git pull et tout ce que vous voulez construire. Même FTP ne serait pas difficile)

@keyvanfatehi , chez Tsuru, nous pensons qu'il serait plus efficace d'exiger de petits changements d'application (comme la configuration par environnement et l'utilisation d'un stockage d'objets pour les fichiers statiques), car vous devrez inévitablement concevoir votre application pour qu'elle s'intègre dans un paradigme cloud ( par exemple: il doit être mis à l'échelle horizontalement sans problème). Mais nous l'avons si bien fait que nos utilisateurs l'obtiennent à un rythme très rapide, nous avons déjà des produits en production ici (sur Globo.com).
Concernant les services, ils sont trop spécifiques pour être bien gérés avec une seule application (imaginez à quel point il serait difficile de gérer les bases de données, nosql, redis, memcached, elasticsearch, le stockage d'objets, etc.). Nous avons préféré spécifier une API de service (où la logique métier pour gérer le service sera placée) et tsuru traitera de la même manière avec n'importe quel service, peu importe leur différence.

Nous sommes très sympathiques et totalement ouverts aux contributions et aux nouvelles idées. Nous pensons toujours que ce serait formidable de travailler avec flynn dans une solution unique (nous pourrions étendre tsuru pour rencontrer l'idéal de flynn dans le futur), mais nous respectons totalement leur opinion et leur vision, car ce sont des ambitions comme les nôtres :-)

TL; DR
Nous savons à quel point les services sont importants, c'est pourquoi nous développons une manière élégante de répondre à cette exigence. Tsuru peut gérer n'importe quel service avec une API de service bien définie (avec quelques points d'entrée simples comme créer, supprimer, lier, planifier). Ainsi, toute la complexité d'un service spécifique sera gérée par son propre service-api. Permettez-vous de vous donner un exemple sur notre API Redis: lorsque vous exécutez # tsuru service-add redis (servicename) redis_blognews (serviceinstancename) plus (plan), il créera une instance redis avec le nom redis_blognews et le plan plus (qui fournit 2 instances de redis avec haute disponibilité). Tsuru ne sait pas comment il sera créé (même s'il aura une haute disponibilité), il sera entièrement géré par le service-api. Il permet également d'utiliser des services externes (même propriétaires) en créant simplement une API de service pour cela sans toucher au code tsuru. Ainsi, il sera beaucoup plus flexible de traiter les services et d'éviter d'augmenter cette complexité à Tsuru. Après cela, vous pouvez utiliser # tsuru bind redis_blognews --app yourblognewsapp et tsuru injectera les informations d'identification du service dans votre application

Je suis nouveau sur PaaSes et c'est déroutant. J'ai choisi Tsuru et je me suis un peu dérangé. Il me semble que ce n'est pas si différent des objectifs de Flynn. Vous pouvez exécuter des choses avec état à l'aide de leur API de service et elle est très modulaire, où vous avez tsuru-api, docker-cluster, gandalf, etc.

Je me demande encore si la combinaison des efforts apporterait un meilleur produit.

Je dois être d'accord avec @msabramo ici, je ne vois toujours pas pourquoi créer un nouveau PaaS qui a toutes les fonctionnalités de Tsuru. Je conviens également que combiner les efforts ferait un produit génial.