This is great guys, good to see more people bringing PaaS-like workflow without the baggage. We've been working in this space with Juju (http://juju.ubuntu.com) but we're using standard LXC for containers.
Using LXC allows us to support applications that run on multiple processes, and since Juju is also written in Go, It seems like it might be possible for us to work together in some interesting ways.
We already have charms for Rack, node.js, Django, etc. already working and we can replicate the example in the video, just on raw LXC, EC2, and OpenStack. And we’ve put a lot of time and energy into managing the relationships between services, which is the big complicated part of a PaaS So, there seems to be pretty good overlap.
Have you looked at Juju? Perhaps there are places where you can leverage the heavy lifting that the juju team has already done in creating a “bring your own” kind of PaaS.
Do you mind explaining that? Would the fact that they use AGPL for Juju matter if you're not hacking on Juju itself? I don't see how it would be an issue, it wouldn't extend to the proprietary software you run on a Juju-setup service, would it?
Yea, it's exactly like MongoDB which is also AGPL.
Using the database doesn't impose any restrictions on your software.
Even hacking on juju to add API'S you for your client software doesn't impose restrictions on the client -- it just means you are subject to the AGPL licence source distribution rules on the patched version of Juju.
Mongo is a different beast, because the mongo client has a GPL exception which allows your code, that is linked to the mongo client, to use a different license. This is a friendly exception, that the mongo developers allowed. Without that exception everything using mongo even over the Internet would automatically also be AGPL licensed.
IADNAL, but its a matter of risk. If one uses juju in operations scripts to implement proprietary services, do you have to make those scripts available to end users? At what point does your software become "derivative" of juju? This interpretation definitely borders on FUD, buts its easier not to take the risk when other options are available.
GPL is viral and imposes restriction which you can't foresee. A recent example is the AppStore fiasco VLC had. It required a complete rewrite and additional development years to get it in the store just because the original code was GPL. Please think twice before using (A)GPL and make sure you have checked all consequences.
I agree, we have very much approached the problem from that of service administration/management rather than the "build a PaaS"approach. But, I think the "big problem" behind building a heroku style PaaS, is not getting simple scripted deployment to a container -- it is managing relationships between applications, databases, message queues, and other connected services, and I think that is where Juju could be useful to your project.
I'd also be happy to talk more about this any time.
OK, thanks. This was a deal break for us a year ago. The issue was even partly solved and with a few hacks juju did survive reboots, but it was later on removed.
Using LXC allows us to support applications that run on multiple processes, and since Juju is also written in Go, It seems like it might be possible for us to work together in some interesting ways.
We already have charms for Rack, node.js, Django, etc. already working and we can replicate the example in the video, just on raw LXC, EC2, and OpenStack. And we’ve put a lot of time and energy into managing the relationships between services, which is the big complicated part of a PaaS So, there seems to be pretty good overlap.
Have you looked at Juju? Perhaps there are places where you can leverage the heavy lifting that the juju team has already done in creating a “bring your own” kind of PaaS.