How does this compare to other similar solutions?

[Marcelo de Moraes Serpa]

Hey guys,

I just stumbled upon Tsuru today, and I must say it really caught my attention, it does look really appealing to me.

I've been searching for a way to abstract away devops for a long time. I like Heroku, but it's expensive. I'd prefer something I could control myself (and know the architecture of, and change it if required). I've had some success by using Chef to both cook the infrastructure *and* deploy apps (sometimes to the same server), but Chef wasn't made to deploy multiple apps, and while it can work great, it's kind of clunky as it is, and I didn't have the time to look into it further.

It seems Tsuru is the tool I was waiting for. However, I'd really want to now how it compares to existing solutions (CloudFoundry, Openruko, etc). The documentation is scarce as of now, and I understand you, since guys just made it public recently; perhaps this post could also offer some additional insights to other people considering using this project :)

Cheers,

- Marcelo.

[Flavia Missi]

Hi,

It seems Tsuru is the tool I was waiting for. However, I'd really want to now how it compares to existing solutions (CloudFoundry, Openruko, etc). The documentation is scarce as of now, and I understand you, since guys just made it public recently; perhaps this post could also offer some additional insights to other people considering using this project :)

Tsuru has everything all those PaaS you quoted have. The differences lays mostly on its components. Our architecture is highly plugable and extensible. In other words, we're building a PaaS where you can customize everything you want, if you want to deploy your apps with a revision control tool different than git you should be able to do it. If you want Tsuru to talk with a non-OpenSource IaaS solution, you can do it. If you need to change the provisioning system, you can do it.

This is the main project goal: to fit your needs.

I hope I helped!

--
Flavia

[Alan Justino da Silva (alanjds)]

Hi.

I am wondering the same of @Marcelo. In fact, I am wondering the archtecture difference from Openruko. Looking at Tsuru code and Openruko archtecture at http://www.slideshare.net/slideshow/embed_code/18758349?rel=0&startSlide=57, I can say that: (please correct me if needed)

- Tsuru is mainly Go. Openruko is mainly Node.js
- Tsuru uses Juju or Docker. Openruko uses low-level LXC
- Tsuru usas Gandalf to "receive the push". Openruko uses Gitmouth
- Tsuru uses Hipache to route the crowd. Openruko uses Httprouting
- Tsuru uses docker or docker-related stuff. Openruko uses LXC or LXC-related stuff.
- Tsuru uses tst, tsuru-collector and tsuru-api to "manage" the stuff. Openruko uses heroku-cli, rukorun and apiserver.

What I see as positive on Tsuru:
- Hipache is considered better, even from Openruko people, that now aims to adopt Hipache
- I could expect docker-related stuff to be better supported than LXC-related stuff
- Tsuru have Globo.com sponsoring. Its a huge plus IMHO
- Aims to be a flexible PaaS
- Have a try-before-you-buy website (try.tsuru.io)

What I see as positive on Openruko:
- Have an archtecture diagram (!!!)
- Aims to be a Heroku copycat PaaS. Yet CLI-compatible!
- Bigger community (at least making more noise ;)
- Have a vagrant machine AND instructions about how to use it

Juju and Docker vs just LXC can be a good or bad thing, as Tsuru needs to support 2 technologies instead of one, both Juju and Docker are well maintained by 3rd party. So lets take this as neutral.

Do you agree? Is there some important topic that I missed??

Then I started asking myself, and now asking you:

1) Why Go ??

Lets assume that is easier to code Python or Ruby than Go. I see a need for massive usage of coroutines on Gandalf, on tsuru-api and on Hipache, but not on tsr or tsuru-collector. Lets say that Go excels on this task AND Python+Gevent is not a more maintenable and equally good option. People on Openruko is considering to replace Gitmouth for Gogit, and this maybe makes me sense, but why tsr and tsuru-collector uses Go too?

2) Why not to fork Openruko?

(Disclaimer: I am a Python fanboy)
Still as a Python fanboy, I am thinking why is better to start over instead of forking Openruko and then replacing the parts that I dont like there. Maybe I am asking this because I have no historical background of both projects, and no archtecture schema of Tsuru, but I still keep asking myself this one.

Please dont take me wrong. I liked Tsuru a lot, and want so much the value that this delivers. From a long time. Just wanting to understand the design/community decisions to help better.

Cheers,
Alan.

[Alan Justino da Silva]

> 1) Why Go ??

 

Goroutines and coroutines are different things. Goroutines can run in
parallel, and we totally take advantage of that.

Oops. I should had said "massive usage of concurrency" not coroutines. My bad.

 

BTW, tsuru-collector is the component that needs concurrency the most,
and it's also the one that takes most advantage from parallelism.
Gandalf could easily be a Python application, it's just an HTTP API,
and it doesn't need coroutines.

Hum... I am still puzzled about tsuru-collector. Can you elaborate on the tasks that tsuru-collector does, and the workload?

 

Last but not least, we _want_ to use Go. The language is great :)

If you want you want :) This is enough.

 

> 2) Why not to fork Openruko?

That would not be possible: Tsuru was born before Openruko.[...]

Got it.

Thanks very much for clarifying me.

Best, Alan.

[Andrews Medina]

Hi,

On Mon, Nov 4, 2013 at 2:36 AM, Alan Justino da Silva (alanjds)
<alan.just...@gmail.com> wrote:
> Hi.

>
> - Have an archtecture diagram (!!!)

We have an issue to do it
(https://github.com/globocom/tsuru/issues/162) and I did a sketch
diagram that is attached to explain the tsuru architecture.

> Do you agree? Is there some important topic that I missed??
>

>

> 2) Why not to fork Openruko?
>

tsuru and openruko do not share the same goals. the openruko goal is
be an open source heroku. the tsuru goal is be a flexible,
customizable, private/public paas.

the heroku was designed to be a public paas, but it is not
customizable and does not support private paas.

> Please dont take me wrong. I liked Tsuru a lot, and want so much the value
> that this delivers. From a long time. Just wanting to understand the
> design/community decisions to help better.
>

you are right in wanting to know more details about the tsuru.

we have some docs about tsuru architecture [0], [1], [2]. [3]. but
documentation is our weak point.

If you miss any more information or documentation, let us know

[0] - http://docs.tsuru.io/en/latest/provisioners/docker/architecture.html
[1] - http://docs.tsuru.io/en/latest/why.html
[2] - http://docs.tsuru.io/en/latest/overview.html
[3] - http://docs.tsuru.io/en/latest/faq.html


Best regards!

--
Andrews Medina
www.andrewsmedina.com