why not tsuru?

[andrewsmedina]

Tsuru (https://github.com/globocom/tsuru) is another opensource paas implemented in go, and share the most features defined by flynn-spec.

Why not join these project instead create another?

[titanous]

This was discussed on golang-nuts. My impression is that while some of the features are similar, the core goals are different.

/cc @fsouza

[andrewsmedina]

@titanous I saw this thread. If the biggest diference betwen tsuru and flynn is tsuru be specific to web, with little effort it can be modified.

I believe that if the two projects come together will be better for these project and will make more easier to build a stronger community to make and maintain this new project (tsuru + flynn) like what happened with rails + merb.

[titanous]

We're currently working on a more complete spec that will detail the components and goals we're planning. I think it'd be constructive postpone this discussion until we push that document.

[titanous]

Closing, as I think it's more clear what the differences are now.

[kfatehi]

What are the differences? It's not clear to me, is there some source out there that you can recommend that makes sense of all the PaaS work that's being done?

I've been trying to figure it out through researching but I just keep learning about more and more PaaS systems being made with Docker, things feel really fragmented; it's really hard to keep up with it ... Each one of these systems requires time and dedication to setup and try before one can really know what it is -- is there an easier way to get acquainted with the all the projects happening in this space without it taking so long and being a never-ending rabbit hole?

From what I've seen so far, Flynn looks pretty sweet -- I am excited to try it soon.

P.S. I got here by Googling "tsuru flynn"

[danielsiders]

@keyvanfatehi Thanks for your interest.

It's hard to keep up to date with all the PaaS projects out there, especially since many follow private or inconsistent roadmaps. In general, here's what we think the differences between Flynn and most other PaaS projects are (not a direct comparison with tsuru, just the space in general):

Flynn is more ambitious. Flynn can run anything that runs on Linux including stateful services. We take advantage of this capability to package common databases along with Flynn, so most users and projects won't ever manually manage databases again. Flynn's components are modular which makes it easy to reuse, modify, and replace them to create the right solution for your needs. We really want Flynn to be a single toolkit that "solves" ops for every project and organization. There's much more to come including log aggregation, metrics, continuous integration along with next generation solutions for networking and development workflows.

Most other PaaS projects are at least one of the following: hard/slow to set up and deploy, only useful for specific kinds of apps, require developers to re-architect their applications, and monolithic. In short, we believe Flynn tries to solve the hard problems and most other projects don't, because of their age, existing user-bases, and design motivations.

As Flynn reaches production stability and feature completion we'll try to document the differences on a per-project basis.

[kfatehi]

@danielsiders thank you! I am looking forward to watching you guys innovate in this space. I definitely suffer from having too much ops falling on my shoulders (Which is why I am looking at Docker and the tools around it). I would like to believe that ops can be solved, as it were...

So far my experience has been using the flynn-demo (sucessfully) which seemed to be like deis (which I haven't tried directly, but they have a nice looping video showing heroku-like behavior). So on this shallow level, deis, flynn and heroku seem identical.

That's a good point about private roadmaps -- I think maybe it's just a bit early for me to expect to wrap my head around all of it. It seems much easier to just commit to one effort or another than try to keep track of, discern the differences between, and try to judge each effort... each one being innovative and interesting!

anyway, exciting times -- thanks for being part of making this all happen, even if I can't fully understand it yet :)

[danielsiders]

@keyvanfatehi most PaaS's support Heroku-style (git push) deployment of applications. Where things really differ is the type of applications that can be deployed and what happens after an app is deployed.

(nb: Flynn also supports many other deployment paradigms like docker pull and git pull and anything else you want to build. Even FTP wouldn't be hard)

[magnotorres]

@keyvanfatehi, at Tsuru we believe that would be more efficient to require some small application changes (like configuration by environment and use of an object storage for static files), because inevitably you will need to design your application to fits in a cloud paradigm(e.g: it needs to scale horizontally without problems). But we did it so well that our users get it in a very fast pace, we already have products running in production here(at Globo.com).
About services, they are too specific to be well handled with a single application(imagine how hard would be to deal with databases, nosql, redis, memcached, elasticsearch, object storage, etc). We preferred to specify a service api(where the business logic to handle the service will be placed) and tsuru will deal the same way with any service, doesn't matter how different they are.

We are very friendly, and totally open to contributions and new ideas. We still think that would be great to work with flynn in a single solution(we could extend tsuru to meet with the flynn ideal in the future), but we totally respect their opinion and vision, as they are so ambitions as ours :-)

TL; DR
We know how services are important, so we develop a elegant way to deal with that requirement. Tsuru can handle any service with a well defined service api(with some simple entry points like create, remove, bind, plan). So, all the complexity of a specific service will be handled by its own service-api. Lets give you an example over our Redis API: when you run # tsuru service-add redis(servicename) redis_blognews(serviceinstancename) plus(plan), it will create a redis instance with the name redis_blognews and the plan plus(that provides 2 instances of redis with high availability). Tsuru don't know how it will be created(even if it will have high availability), it will be entirely handled by the service-api. It also make possible to use external(even proprietary) services just creating a service-api for that without touch in tsuru code. So, it will be much more flexible to deal with services, and avoid increase that complexity in Tsuru. After that you can use # tsuru bind redis_blognews --app yourblognewsapp and tsuru will inject the service credentials into your application

[msabramo]

I'm new to PaaSes and it is confusing. I picked Tsuru and I've been messing with it a bit. It seems to me that it's not all that different from the goals of Flynn. You can run stateful things using their service API and it is very modular, where you have tsuru-api, docker-cluster, gandalf, etc.

I still wonder if combining efforts would bring a better product.

[flavianmissi]

I must agree with @msabramo here, I still don't see any good point on why building a new PaaS that has all of Tsuru's features. I also agree that combining efforts would make an awesome product.