Flynn: Warum nicht Tsuru?

Dies wurde an Golang-Nüssen diskutiert . Mein Eindruck ist, dass einige der Funktionen ähnlich sind, die Kernziele jedoch unterschiedlich sind.

/ cc @fsouza

@titanous Ich habe diesen Thread gesehen. Wenn der größte Unterschied zwischen Tsuru und Flynn darin besteht, dass Tsuru spezifisch für das Web ist, kann es mit geringem Aufwand geändert werden.

Ich glaube, wenn die beiden Projekte zusammenkommen, ist dies für dieses Projekt besser und erleichtert den Aufbau einer stärkeren Community, um dieses neue Projekt (Tsuru + Flynn) wie das, was mit Rails + Merb passiert ist, zu erstellen und zu warten.

Wir arbeiten derzeit an einer vollständigeren Spezifikation, in der die von uns geplanten Komponenten und Ziele detailliert beschrieben werden. Ich denke, es wäre konstruktiv, diese Diskussion zu verschieben, bis wir dieses Dokument veröffentlichen.

Schließen, da ich denke, es ist klarer, was die Unterschiede jetzt sind.

Was sind die Unterschiede? Mir ist nicht klar, gibt es da draußen eine Quelle, die Sie empfehlen können und die Sinn für die gesamte PaaS-Arbeit macht, die gerade ausgeführt wird?

Ich habe versucht, es durch Nachforschungen herauszufinden, aber ich lerne immer wieder, dass immer mehr PaaS-Systeme mit Docker erstellt werden. Die Dinge fühlen sich wirklich fragmentiert an. Es ist wirklich schwer, damit Schritt zu halten ... Jedes dieser Systeme benötigt Zeit und Engagement, um es einzurichten und zu testen, bevor man wirklich weiß, was es ist - gibt es eine einfachere Möglichkeit, sich mit all den Projekten vertraut zu machen, die in diesem System stattfinden Raum, ohne dass es so lange dauert und ein nie endendes Kaninchenloch ist?

Nach dem, was ich bisher gesehen habe, sieht Flynn ziemlich süß aus - ich freue mich darauf, es bald zu versuchen.

PS Ich bin hierher gekommen, indem ich "tsuru flynn" gegoogelt habe.

@keyvanfatehi Danke für dein Interesse.

Es ist schwierig, über alle PaaS-Projekte auf dem Laufenden zu bleiben, zumal viele privaten oder inkonsistenten Roadmaps folgen. Im Allgemeinen sind hier die Unterschiede zwischen Flynn und den meisten anderen PaaS-Projekten (kein direkter Vergleich mit Tsuru, nur der Raum im Allgemeinen):

Flynn ist ehrgeiziger. Flynn kann alles ausführen, was unter Linux ausgeführt wird, einschließlich Stateful Services. Wir nutzen diese Funktion, um gemeinsame Datenbanken zusammen mit Flynn zu verpacken, sodass die meisten Benutzer und Projekte Datenbanken nie wieder manuell verwalten werden. Die Komponenten von Flynn sind modular aufgebaut, sodass Sie sie problemlos wiederverwenden, ändern und ersetzen können, um die richtige Lösung für Ihre Anforderungen zu erstellen. Wir möchten wirklich, dass Flynn ein einziges Toolkit ist, das Operationen für jedes Projekt und jede Organisation "löst". Es wird noch viel mehr kommen, einschließlich Protokollaggregation, Metriken, kontinuierlicher Integration sowie Lösungen der nächsten Generation für Netzwerk- und Entwicklungsworkflows.

Die meisten anderen PaaS-Projekte sind mindestens eines der folgenden: Schwer / langsam einzurichten und bereitzustellen, nur für bestimmte Arten von Apps nützlich, Entwickler müssen ihre Anwendungen neu entwickeln und monolithisch. Kurz gesagt, wir glauben, dass Flynn versucht, die schwierigen Probleme zu lösen, und die meisten anderen Projekte tun dies aufgrund ihres Alters, der vorhandenen Benutzerbasis und der Designmotivationen nicht.

Sobald Flynn die Produktionsstabilität und die Fertigstellung der Funktionen erreicht hat, werden wir versuchen, die Unterschiede pro Projekt zu dokumentieren.

@danielsiders danke! Ich freue mich darauf, euch bei Innovationen in diesem Bereich zuzusehen. Ich leide definitiv darunter, dass zu viele Operationen auf meine Schultern fallen (weshalb ich mir Docker und die Werkzeuge um ihn herum ansehe). Ich würde gerne glauben, dass Ops sozusagen gelöst werden können ...

Bisher habe ich die Flynn-Demo (erfolgreich) verwendet, die wie Deis aussah (was ich nicht direkt ausprobiert habe, aber sie haben ein schönes Loop-Video, das Heroku-ähnliches Verhalten zeigt). Auf dieser flachen Ebene scheinen Deis, Flynn und Heroku identisch zu sein.

Das ist ein guter Punkt bei privaten Roadmaps - ich denke, es ist nur ein bisschen früh für mich, damit zu rechnen, dass ich mich um all das kümmern werde. Es scheint viel einfacher zu sein, sich nur auf die eine oder andere Anstrengung einzulassen, als zu versuchen, die Unterschiede zu verfolgen, die Unterschiede zwischen ihnen zu erkennen und jede Anstrengung zu beurteilen ... jede ist innovativ und interessant!

Trotzdem aufregende Zeiten - danke, dass du dazu beigetragen hast, dass dies alles passiert, auch wenn ich es noch nicht vollständig verstehen kann :)

@keyvanfatehi Die meisten PaaS unterstützen die Bereitstellung von Anwendungen im Heroku-Stil (Git Push). Wo sich die Dinge wirklich unterscheiden, ist die Art der Anwendungen, die bereitgestellt werden können, und was passiert, nachdem eine App bereitgestellt wurde.

(nb: Flynn unterstützt auch viele andere Bereitstellungsparadigmen wie Docker Pull und Git Pull und alles andere, was Sie erstellen möchten. Selbst FTP wäre nicht schwer.)

@keyvanfatehi , bei Tsuru glauben wir, dass es effizienter wäre, einige kleine Anwendungsänderungen (wie die Konfiguration nach Umgebung und die Verwendung eines Objektspeichers für statische Dateien) zu erfordern, da Sie Ihre Anwendung zwangsläufig so gestalten müssen, dass sie in ein Cloud-Paradigma passt ( zB: es muss problemlos horizontal skaliert werden können). Aber wir haben es so gut gemacht, dass unsere Benutzer es sehr schnell bekommen. Wir haben bereits Produkte in Produktion (hier bei Globo.com).
Die Dienste sind zu spezifisch, um mit einer einzigen Anwendung gut verarbeitet zu werden (stellen Sie sich vor, wie schwierig es wäre, mit Datenbanken, NOSQL, Redis, Memcached, Elasticsearch, Objektspeicherung usw. umzugehen). Wir haben es vorgezogen, eine Service-API anzugeben (in der die Geschäftslogik für die Abwicklung des Service platziert wird), und Tsuru wird mit jedem Service auf die gleiche Weise umgehen, unabhängig davon, wie unterschiedlich sie sind.

Wir sind sehr freundlich und offen für Beiträge und neue Ideen. Wir denken immer noch, dass es großartig wäre, mit flynn in einer einzigen Lösung zu arbeiten (wir könnten den Tsuru erweitern, um in Zukunft das Flynn-Ideal zu erreichen), aber wir respektieren ihre Meinung und Vision voll und ganz, da sie so ehrgeizig sind wie unsere :-)

TL; DR
Wir wissen, wie wichtig Dienstleistungen sind, und entwickeln daher einen eleganten Weg, um mit dieser Anforderung umzugehen. Tsuru kann jeden Service mit einer genau definierten Service-API verwalten (mit einigen einfachen Einstiegspunkten wie Erstellen, Entfernen, Binden, Planen). Die gesamte Komplexität eines bestimmten Dienstes wird also von einer eigenen Dienst-API verwaltet. Geben wir Ihnen ein Beispiel für unsere Redis-API: Wenn Sie # tsuru service-add redis (Servicename) redis_blognews (serviceinstancename) plus (plan) ausführen, wird eine redis-Instanz mit dem Namen redis_blognews und dem Plan plus (mit 2 Instanzen) erstellt von Redis mit hoher Verfügbarkeit). Tsuru weiß nicht, wie es erstellt wird (auch wenn es eine hohe Verfügbarkeit hat), es wird vollständig von der Service-API verwaltet. Es ist auch möglich, externe (sogar proprietäre) Dienste zu verwenden, die lediglich eine Service-API dafür erstellen, ohne den Tsuru-Code zu berühren. Es wird also viel flexibler sein, mit Diensten umzugehen und zu vermeiden, dass diese Komplexität in Tsuru zunimmt. Danach können Sie # tsuru bind redis_blognews --app verwenden. Yourblognewsapp und tsuru fügen die Dienstanmeldeinformationen in Ihre Anwendung ein

Ich bin neu bei PaaSes und es ist verwirrend. Ich habe Tsuru ausgewählt und ein bisschen damit rumgespielt. Es scheint mir, dass es sich nicht allzu sehr von den Zielen von Flynn unterscheidet. Sie können Stateful Things mithilfe ihrer Service-API ausführen und es ist sehr modular, wo Sie Tsuru-API, Docker-Cluster, Gandalf usw. haben.

Ich frage mich immer noch, ob eine Kombination der Bemühungen ein besseres Produkt bringen würde.

Ich muss hier @msabramo zustimmen, ich sehe immer noch keinen guten Grund, warum ein neues PaaS erstellt wird, das alle Funktionen von Tsuru bietet. Ich stimme auch zu, dass eine Kombination der Bemühungen ein großartiges Produkt ergeben würde.