And to people who know what juju is, it sounds exactly like what its intention is. You wouldn't be confused if the title was "The new Chrome UI" or something of the sort.
Having worked on node-graph UIs in the past and used software that relies on this metaphor, it's a dangerous thing to not build in undo/redo support. It's too easy to delete an edge, and spend a bunch of time trying to redo your work. That really pisses off users.
Also, not giving the edges of the graph a direction is a problem -- it's hard to quickly grasp what the 'result' node should be. Ditto for not using fixed-position plugs on the nodes: input plugs should be at the top, outputs at the bottom (or left and right).
In the end, I'm not sure who this is for: if you just want to click a button to deploy some services, it's doubtful that you'll want to muck around with wiring up nodes; and if you're putting these packages together, it'll probably be faster to just use a text editor.
So basically you search in the box for the service you want (Hadoop, haproxy, memcached, postgresql, and so on) and click deploy and then an instance launches with that service on AWS/HP Cloud/OpenStack. You then connect them and basically model your deployment via the web interface.
Then when you want to horizontally scale you just add units to the service.
Sorry that wasn't clear in the blog post, I was mostly targetting existing users and totally forgot to explain what it does: http://juju.ubuntu.com
Nice to see the relationships visualized. I think it's a bit more cloud provisioning focused than, say, general purpose orchestration -- but this is an important problem that needs to be solved too!
For my take on this, see http://ansible.cc -- though I think we've talked already. One of the goals of that was modelling rolling updates and repeated idempotent configuration management, which is something orchestration tools need to be able to do for once those nodes are up (versus say, bash scripts). It doesn't really take on provisioning so much and assumes the nodes already exist.
I'm still thinking there is a good way we could collaborate so you could provide the modeling of the provisioning layer and leverage our backend for actual actions on the nodes (we'd need to write a push_script module, which is easy), since you seem to be doing the SSH thing already, which is the right way to go :)
Founder of http://commando.io here - Really cool interface. We are doing some of the same sort of things to help with orchestration of servers. Currently we are using `libssh2` via a PHP module, but switching to a sparkling new node.js interface for the SSH and SCP connections and executions shortly.
This seems to be more like a Rundeck to me, i.e. parallel script dispatch?
Idempotent models are kind of important when managing systems in production environments as systems can be in heterogenous states and well, scripts fail. Part of the goal should be to get out of the practice of writing scripts.
Mobile isn't just 3.5" displays. And some of us DO need to log in and do things while we are on the go, we don't get to sit at a coffee shop and whip out our MacBook Air every time there is an issue.