5 ms·
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
by jcastro 13y ago
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 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.
- progrium 13y agoI really liked Juju. I think we operate on slightly different paradigms / abstractions. Would love to talk more though.
- markramm 13y agoI 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.
- stevvooe 13y agoJuju is a great project and you guys are way ahead of the game but the AGPL licensing is problematic for proprietary services built on that platform.
- girvo 13y agoDo 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? I could be completely wrong, mind you.
- markramm 13y agoYea, 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.
- js4all 13y agoMongo 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.
- stevvooe 13y agoIADNAL, 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.
- js4all 13y agoGPL 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.
- lfauve 13y agoHas the issue with juju on LXC not surviving reboots been fixed?
- markramm 13y agoLXC support in the latest Go juju landed earlier this week, and reboot persistence landed yesterday. So, yes, but it's still very new.
- lfauve 13y agoOK, 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.