Tsuru - open source platform as a service (written in Go) | Hacker News Reader

Tsuru - open source platform as a service (written in Go)

globocom.github.com

185 pointsgoodwink57 comments

This is a good occasion to read the source code of a non-trivial piece of Go code. The documentation of the project seems rather sparse, but at least, the app has readable tests.

That said, if you are looking for an open-source platform as a service, OpenShift, or as others mentioned, CloudFoundry are more mature options.

I had the same impression. I have been working on a very early prototype of something very similar to this and was curious the know the general architecture of the system but there doesn't seem to be any documentation covering that.

I wish that more of these projects were more general like Mesos as opposed to just replicating a service across machines.

When using the work-in-progress lxc provisioner, tsuru will behave like Mesos, but it's no that stable yet. First we worked on getting it working with EC2 instances, and now we are working on lxc and frontend integration.

Hey guys, want to collaborate with http://docker.io on the lxc provisionner? There are a bunch of "heroku-in-box" building on top of it already.

Hi, I'm fsouza on github. I already have access to it, and I will try to help tomorrow in getting docker launched :)

Could you elaborate on the other heroku in a box offerings building on docker? Sounds pretty interesting!

Hi, I'm andrewsmedina on github. I want to help. When docker will be opensourced?

Today :P

Can someone explain how this (or other tools like this?) work? How do they install services, ensure they start up, handle upgrades, etc? I am utterly confused by all these PaaSaaS apps.

I think the basic concept to understand is that of the 'dyno'. Although a term from the Heroku platform, I believe it applies to most of the other platforms too. A dyno is a container (sort of like a VM but without hardware virtualisation, see LXC or OpenVZ) that isolates system resources. You can have multiple dynos on any given server and you can have lots of servers. Each dyno contains the entire environment needed by any given app, so it'll contain the specific binary version of ruby or node for example and it'll also have unique copies of all the dependencies, managed via bundler or npm for example.

Scaling your app simply means having more running dynos that are load balanced by a centralised load balancer used across the entire platform. So yes, interestingly there is a lot of duplication of the code base.

Services, like databases, are managed on their own separate servers/clusters and allow multiple connections and can be scaled/sharded separately from the dyno farms. Therefore they can be monitored, maintained, upgraded, etc, separately as well.

I'm a small-time contributor to http://github.com/openruko, an opensource Heroku clone.

I'd personally prefer to not adopt Heroku's nonsensical superhero terms, since we already have common terms for these things that make sense -- application containers, applications.

PaaS is "platform as a service". A way of automatically deploying, updating, and managing applications inside of application containers running on a cluster of machines, using either processes, virtualization, or OS-level process containers.

Amazon BeanStalk does this for Java by using Tomcat running in a EC2 VM, and exposing the servlet interface such that one can deploy Java webapps directly to BeanStalk.

Google App Engine did the same thing for Java, and with some custom packaging for Python.

The whole idea is to get rid of all the textual OS configuration files and vestigal limbs of UNIX and get down to the simple bare metal fact that we tend to treat the OS as a hardware abstraction layer for a single application.

Oh, that makes sense, thanks. I was under the impression this managed everything (including DBs and other services), so I was wondering how this was possible.

I guess this ties in with another post I saw the other day, which was a lightweight container format you could add your environment to and deploy (and sounds like a game-changing idea). If we have a functional, standardized, self-contained container format that provides reasonable security and that you can install an environment to and just deploy to a server, it would pretty much mean that you can pick your app up and copy it to another host and be running in five minutes.

That is correct :) Are you thinking of the post about http://docker.io? If so, I concur: Tsuru + Docker seem like they would be an awesome match.

Yep, that's the one! Man, I'm so excited about docker, even if I have to deploy it manually.

I definitely want to try tsuru + docker, yet this week :)

This is really interesting. It appears to be a lot easier to get started with than CloudFoundry, but it is difficult to tell at this point how well it compares. Very cool none-the-less!

Confused me with Tsuru Capital [1][2], a trading company that uses Haskell as their main programming language.

[1] http://www.tsurucapital.com/en/jobs.html [2] http://tomschrijvers.blogspot.ca/2012/12/haskell-tsuru-capit...

I don't get it. I'd understand more if there was a service being sold or if they said you could use it to set up your own. Can anyone from the project explain the what, why, and where of it all?

You can use it to set up your own, see http://docs.tsuru.io/en/latest/

EDIT: I'm not from the project, I just found it interesting and posted it...there probably isn't anyone from the project watching this thread.

We're here! Preparing responses ;)

We have also created some docs issues[1][2] on our repository based on some questions posted here.

[1] https://github.com/globocom/tsuru/issues/367 [2] https://github.com/globocom/tsuru/issues/366

Sorry for our absense. This HN entry surprised us. We're aware that we need better docs explaining what tsuru is and it compares to alternatives like OpenShift and Cloud Foundry.

Currently, we're not running tsuru in any public cloud. We _hope_ that will change in the future :-)

Sorry for the surprise HN post! ;)

I'm wondering if there's any docs for deployment beyond the python example I saw. I'd like to deploy nodejs and go apps in particular.

Thanks for the interesting project!

Loving all this Go news lately.

Based on juju, so i assume you can use all the various charms that juju allows for.. http://jujucharms.com/charms/precise

You can, but in order to deploy applications you should use our own charms, it's explained in our chams repository[1].

Tsuru is based on Provisioners, our default provisioner is juju, we also have a on going development of a lxc provisioner[2].

You can also build your own provisioner (docs coming).

[1] http://github.com/globocom/charms [2] https://tsuru.readthedocs.org/en/latest/lxc.html

Unfortunately not. Our charms contains some custom hooks, but we want to remove them in the future. Here are the examples: https://github.com/globocom/charms/tree/master/precise (centos charms are outdate).

I always like seeing people use beanstalkd. It's a great bit of software which seems to have been largely overshadowed by redis these days, which is a shame.

I'd be interested in seeing an automatic deploy script for this service to teraform a new dedicated server instance.

This is on tsuru's roadmap. We want to make it easier to install and manage. Thanks!

In Japanese, "tsuru" can refer to a type of crane, which is likely related to the origami crane on the page.

Depending on the kanji, it might also be a few different verbs:

吊る: to hang; to suspend (something from something); to be hanged (by the neck)

釣る: to fish; to angle; to catch;

攣る: to cramp; to be cramped; to contract

Another interesting project, Appscale (https://github.com/AppScale) from UCSB, is a GoogleAppEngine PaaS clone

why does every such service forces you to use git?

git is not a deploy tool!!

git works as a deployment tool, but not in all cases. It's useful to deploy code, but when writing Java or Go, you usually don't deploy the code, you deploy compiled binaries. Currently, tsuru forces you to deploy your code (you can create a git repository versioning the binaries, and do some local magic to compile your source, put it in the repository and push it - like creating a "deploy" target in your Makefile, but that's an ugly workaround).

In the future, tsuru will probably support other ways of deployment.

git absolutely is a deploy tool.

And when they force you to use git they always forget to also support mercurial...

Git can be a deployment tool by using the post-update hook in a server-side repo. In my setups it also runs tests in a "test" repo before deciding to push into a "production" one.

How does this compare to CloudFoundry or OpenShift? I guess they all try to solve the same problem, but I'm really interested..

Will that include addons, for instance a mobile backend-as-a-service, Parse style?

Yes, tsuru calls that services. They're behind an API. Enabling the deployment of services without API's is already in our roadmap, but we don't know when we will get it done.

You can already use those addons outside of Parse, Heroku etc. Maybe what you want is like a library of all available addons for all services?

Is this a parody?

What actual platform is it?

It looks like an alternative to Heroku and VMware's CloudFoundry (http://www.cloudfoundry.org, which is also opensource)

I just checked the docs - http://docs.tsuru.io and the git repo - https://github.com/globocom/tsuru

Would have been nice to see screenshots of the command line tool. Would have made things simpler for commoners.

I'd also like to see at least some kind of quick explanation of why this is being created. How does it differ than CloudFoundry, for example? What issues does it try to solve that don't work well with the existing platforms? Just a few minutes to explain the "why" question, and I might actually want to sit down and read through the installation documentation.

I hope that the "why" is that it's much simpler to use on a small scale. What I'd really like is a standardized engine to deploy apps of many flavors on rather than having to create new chef scripts to deploy everything I write.

I essentially want something that works like heroku as far as ease of use for deployment/scaling, accommodates many different application types, and is easy for me to spin up in a 2-4 node cluster on my own VPSes. Every time I have a new app to deploy I just push it to the cluster and I'm done, adding additional VPSes as it starts to get full. I'm hoping this is such a thing, but I haven't tried it just yet, so I can't say for sure.

CloudFoundry, OpenShift, etc. seem pretty heavyweight and more meant for service providers or large corporate private clouds. If they can be used like I describe too could anyone provide some links to docs/blogs about it? I haven't found it so far.

The original motivation wasn't exactly that, but we changed it. At the first moment, we started an open source platform as a service based on Globo.com needs. That's why tsuru first supported EC2 instances. But that's pretty expensive: having 10 virtual machines for an app is not cheap, and does not fit in most company's budgets.

That's why we started implementing support for application containers, and we need to work on documentation and facilitate the life of people willing to deploy tsuru.

Thank you for your feedback!

"written in Go" in the title was the trick to gain your attention?

Globo is the media monopolist of Brazil, in case you don't know...

it runs most major print and music publishers, dominates the TV space and, for good or bad, is picking the best technologists in Brazil and dominating news, sports and some vanity entertainment of the web here.

While other corps are slacking they're doubling down on hiring the Agile, Ruby, Python, Go and etc guys most `traditional` techie companies here ignore and are probably making the other players eat dust in doing so..

Why the hate? at least they are doing something..

They are hiring people and allowing them to share their work in the opensource space, whats bad about it?

PS: i'm a Brazillian too

I don't think I was hateful, I actually gave them credit on the tech culture it's building..

Some of the comments were from people who didn't understand where this was coming from, if it was legit or not.. Obviously, people don't pick Open Source PAAS without getting a bit of context and that was what the comment was about.

That account is not factually correct. Media in general and television in particular is not a monopoly in Brazil. Globo is the largest player in the market and the one the viewers favor the most, but it's not a monopoly.

It could be argued both ways, don't you agree? every antitrust case starts with "ok, let's define what would constitute monopoly and let's see if we can agree this is or not one" but we both know we'll probably never see this case being opened around here, right? ;)

But yes, my affirmation is not factually correct.

> we both know we'll probably never see this case being opened around here

This, by itself, does not prove it is a monopoly.

A pile of buzzwords, a funny sounding name that's fun to say, and "written in go" to get some HN love.

Yawn. Wake me up when they do something Heroku/CloudFoundry/Appfog/Ironfoundry etc aren't doing.

Why people downvote a comment just because it express criticism. While not very gentle, it was neither off-topic or irrelevant and it was a perfectly valid opinion.

The criticism is skin-deep and isn't expressing any insight into the project, the "yawn" is a trite way of showing contempt.

All in all, a shitty comment, if I could downvote it two times I would.

This is just awesome. This is what the web needed. Globo.com will be the next Google, keep an eye on it.

spam.

Reply on news.ycombinator.com