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.
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'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.
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!
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?
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 :-)
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.
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 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.
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.
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.
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..
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? ;)
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.
That said, if you are looking for an open-source platform as a service, OpenShift, or as others mentioned, CloudFoundry are more mature options.