Flynn: 为什么不tsuru？

在golang-nuts上对此进行了讨论。 我的印象是，尽管某些功能相似，但核心目标却不同。

/ cc @fsouza

@titanous我看到了这个线程。 如果tsuru和flynn之间的最大区别是tsuru是Web特有的，则可以毫不费力地对其进行修改。

我相信，如果将这两个项目结合在一起，将对这些项目更好，并且将更容易建立一个更强大的社区来制作和维护这个新项目（tsuru + flynn），就像发生在rails + merb上一样。

我们目前正在制定更完整的规范，以详细说明我们正在计划的组件和目标。 我认为将讨论推迟到我们推动该文档之前是有建设性的。

结束语，我认为现在更加清楚之间的区别是什么。

有什么区别？ 对我来说还不清楚，您是否可以推荐一些可以理解所有正在执行的PaaS工作的资源？

我一直在尝试通过研究找出答案，但是我一直在学习越来越多的使用Docker制作的PaaS系统，事情真的很分散。 这些系统中的每个系统都需要时间和精力来设置和尝试，然后才能真正了解它是什么—是否有一种更简单的方法来了解此过程中发生的所有项目，真的很难。没有那么长时间的空间，它是一个永无止境的兔子洞吗？

从目前为止我所看到的，弗林看起来很甜美-我很高兴能很快尝试它。

PS我是通过谷歌搜索“ tsuru flynn”来到这里的

@keyvanfatehi感谢您的关注。

很难及时了解所有PaaS项目，特别是因为许多PaaS项目遵循私有或不一致的路线图。 总的来说，这就是我们认为Flynn与大多数其他PaaS项目之间的差异（不是与tsuru的直接比较，只是总体上的空间）：

弗林更有野心。 Flynn可以运行在Linux上运行的任何东西，包括有状态服务。 我们利用此功能将常规数据库与Flynn打包在一起，因此大多数用户和项目都不会再手动管理数据库。 Flynn的组件是模块化的，因此可以轻松地重用，修改和替换它们，以创建适合您需求的解决方案。 我们真的希望Flynn是一个可以为每个项目和组织“解决”操作问题的单一工具包。 还有更多的功能，包括日志聚合，指标，持续集成以及用于网络和开发工作流程的下一代解决方案。

大多数其他PaaS项目至少是以下

随着Flynn达到生产稳定性和功能完善性，我们将尝试按每个项目记录差异。

@danielsiders谢谢！ 我期待着看到你们在这个领域进行创新。 我绝对忍受太多的操作困扰（这就是为什么我要研究Docker及其周围的工具）。 我想相信操作可以解决，因为它曾经是...

到目前为止，我的经验是（成功地）使用了看起来像deis的flynn-demo（我没有直接尝试过，但是他们有一个很好的循环视频，显示了类似heroku的行为）。 因此，在这个浅层次上，deis，flynn和heroku看起来是相同的。

那是关于私有路线图的一个好点-我认为对于我来说，将所有想法都包起来可能还为时过早。 做出一项或多项努力似乎比跟踪，辨别两者之间的差异并尝试判断每种努力要容易得多……每种努力都具有创新性和趣味性！

无论如何，都是激动人心的时刻-感谢您为使这一切成为现实而努力，即使我还不能完全理解它：)

@keyvanfatehi是大多数PaaS支持Heroku样式（git push）部署的应用程序。 真正不同的是可以部署的应用程序类型以及部署应用程序后会发生什么。

（nb：Flynn还支持许多其他部署范例，例如docker pull和git pull以及您想要构建的其他任何东西。即使FTP也不难）

@Truru的@keyvanfatehi我们认为，要求进行一些小的应用程序更改（例如按环境进行配置以及使用静态文件的对象存储）会更有效，因为不可避免地，您将需要设计应用程序以适合云范例（例如：它需要水平缩放而没有问题）。 但是我们做得很好，以至于我们的用户可以非常快地获得它，我们已经在这里生产了产品（在Globo.com）。
关于服务，它们过于具体而无法用单个应用程序很好地处理（想象一下处理数据库，nosql，redis，memcached，elasticsearch，对象存储等将有多难。 我们更愿意指定一个服务api（将放置用于处理该服务的业务逻辑），并且tsuru对任何服务都将以相同的方式处理，无论它们之间有什么不同。

我们非常友好，并且完全欢迎贡献和新想法。 我们仍然认为在单个解决方案中与flynn一起工作会很棒（我们可以扩展tsuru以满足将来的flynn理想），但是我们完全尊重他们的见解和远见，因为他们像我们一样雄心勃勃：-)

TL; 博士
我们知道服务的重要性，因此我们开发了一种优雅的方式来满足该要求。 Tsuru可以使用定义良好的服务api（带有一些简单的入口点，如创建，删除，绑定，计划）来处理任何服务。 因此，特定服务的所有复杂性将由其自己的service-api处理。 让我们以Redis API为例：运行＃tsuru service-add redis（servicename）redis_blognews（serviceinstancename）plus（plan）时，它将创建一个redis实例，其名称为redis_blognews和plan plus（提供2个实例）高可用性的Redis）。 Tsuru不知道如何创建（即使它具有高可用性），也将完全由service-api处理。 它也可以使用外部（甚至专有）服务来创建服务API，而无需触摸tsuru代码。 因此，处理服务将更加灵活，并避免增加Tsuru中的复杂性。 之后，您可以使用＃tsuru bind redis_blognews --app yourblognewsapp，而tsuru会将服务凭证注入到您的应用程序中

我是PaaSes的新手，这很令人困惑。 我选了鹤（Tsru），并且一直在弄乱它。 在我看来，这与弗林的目标并没有什么不同。 您可以使用其服务API运行有状态的东西，并且它是非常模块化的，其中包含tsuru-api，docker-cluster，gandalf等。

我仍然想知道是否可以通过共同努力带来更好的产品。

我必须在这里同意@msabramo的观点，我仍然看不出为什么要构建具有Tsuru所有功能的新PaaS。 我也同意，共同努力将产生出令人敬畏的产品。