I'll stick to shmux for these tasks thanks. It doesn't require me to hand you my SSH keys, runs on the command line, already supports parallell SSH execution, and is free both in terms of speech and beer.

I'm not trying to knock your product - I really do hope you get Kickstarter funding! But I just wanted to say that, to me, as a systems engineer, I only see a pretty interface, but not much value add over the other two products mentioned above

I also feel that comparing Commando.io to Puppet, Chef, or even Capistrano is disingenuous - Puppet and Chef are configuration management systems that are meant to keep your systems 'in policy', and Capistrano is meant for repeated tasks over SSH (mainly for deploying software, but it can be used for other things too.)

There are cases where I do prefer web interfaces to command line. The AWS web console is an example of this, but for me this is a case of balancing control vs convenience. Installing the AWS libraries to use the command line is a greater PITA than the need to use the command line.

With Git, I prefer the power of the command line over a graphical client. However, in this case there is little or no convenience in the difference because I have to install Git either way.

The only usage I would be able to get out of this would be to give my non technical managers, clients, co-developers, etc a way to do deployments if I'm not available. One scenario would be for contractors to be able to setup their own dev servers. So, I can see a situation where I could use it, but it's a bit of an edge case.

This is my sticking point: if the power comes from the recipes, how does having a web interface help any of that? I think this is a great piece of work, but I just can't see what the advantages are over any of its competitors given that all the actual work is still being done in the same way (e.g. shell scripts).

I would add that you bring up GitHub a number of times as a comparable service, but I think that the key difference is that a number of core git features are actually implemented by GitHub (e.g. fork, log, pull) and although this all looks great it isn't the reason (IMO) why it's successful, it's because it makes a common operation easier (i.e. git repository management). I think that you would need to make common dev-op "recipes" easy to generate before the GitHub comparison is correct.

I would give it a run through if you offered it as software though.

Two phase commit.

Admin enters commands, another had to enter same commands on another console and only then are they executed or passed to a third admin to approve actioning.

No more rm -f in root or other slip ups. No more silly mistakes. Added accountability and in that added security.

You would also get x10 the amount of backing from alot of institutions alone for that feature and even if you don't have it now, factor it in down the line as the quality of admins has gone down hill over the years and in that more mistakes get made. This will reduce that and the impact as well as protecting jobs as well as the machines from human shortcommings.

Logging aspect you have outlinesd is good. Get it robust by design and cater for remote logging servers and with all that you could go far.

Good luck

Currently we use csshX for this sort of thing, and it does the job. It's an open source tool that opens a bunch of ssh sessions and sends each character you type to each session. You can launch it with command line args that specify the hosts you'd like to connect to and optionally the commands to run, so it's pretty easy to set up scripts that mimic the recipes in this video. If you're working with less that 20 servers at a time (about the limit of what you can read on screen at once) it's a great tool.

http://code.google.com/p/csshx/

It also looks like (not sure if i am right) but your worker/server has to have direct ssh access to the server. This means you basically have root access as most configuration management tools need root to administrate the server.

Your UI should integrate monitoring and control using an actually visual interface detached from any underlying model used for state collection or implementation of state changes (because this stuff changes constantly, regardless of how much myopic VC money is thrown at it). This means instead of talking about "recipes" and suchlike, you talk explicitly about the objects being managed: services, servers, racks, PDUs, switches, routers, coolers, links, and so on.

Make it visual, like actually beautifully visual. Let me specify a floor diagram that colours each rack according to the mean health of the machines it contains. Clicking the rack should show an exploded view of each machine coloured by the mean health of each service they contain, and those services' dependencies. Provide instantly selectable overlays showing different kinds of topological relations (application/network/power/trust/routing/OAM/TCP connection state(!)) existing within the view (complete with colouring).

I want a tool that lets me study a floor diagram and instantly notice a set of racks are down because they are in a row supplied by a single PDU. I want to correlate crashes visually due to cooling hotspots, preferably even by relative colouring due to temperature sensors in the machines. I want to batch shutdown a set of machines connected to the NFS share I just found 0day on.

I want a generic visualization of a service that displays a set of vital metrics (error count, load, cpu usage) and a set of generic actions (restart, stop). I want a simple editor that allows me to assemble widgets ("CPU load gauage", "requests/sec gauge", "dependency health indicator") into some meaningful representation of a service using nothing but a mouse.

Don't bake any topology into it: make it useful for systems as small as 2 cores, or as large as having presence in every country. Racks aren't first class objects, they aren't containers, they're relations with some useful attributes. Don't bake implementation or buzz technologies into it: your codebase could be less than 10,000 lines JS+high level language backend.

Don't freeze out keyboard cowboys: there's no reason a highly visual UI need require a mouse. An idiom involving a handful of standard shortcuts ("object select", "object query", "object manipulate", "back", "bookmark", "assign shortcut") are all that's needed. I imagined a system involving keys 0-9 being redefinable (think Command & Conquer, not Emacs) with a few letters preassigned (think Gmail/Google Reader)

I want a UI no less visually beautiful than Google's search globe ( http://data-arts.appspot.com/globe-search ) for monitoring the state of my service. I want to notice the bandwidth spike occurring on the dark side of the earth.

Prior to a system like this that can be assembled with a minimum of fuss, and can be integrated with existing data sources and systems (most medium sized companies already have an asset database, etc.), I'm not going to be impressed by some crappy Ruby on Rails jammed together with a bit of JS as a fancy editor for some DSL.

Give us something with wow factor, not just another bland excuse of crap offering zero benefits over a command line, that'll end up lying dead in a Github repo in a few years.

[Footnote: for anyone with cash interested in systems like these, feel free to get in touch. I can barely enunciate correctly when talking about this stuff, my vision for what devops should look like is so far removed from the current popular state that it pains me to pay it much attention]

God, its Matriu AS (http://www.kickstarter.com/projects/naterockhold/matriu-as-l...) all over again.

I wrote a little monitoring tool like this for our servers. instead of the monitor using ssh command "recipes", it just hits API endpoints that return JSON. The monitor doesn't really care what the API is checking, it just expects that service to "neutralize" whatever metric it is checking into something that can be graphed. I think the same could be done if you have a specific data format that recipes are required to output. Those recipes that returned a common data format could then be graphed. Of course it takes a minor amount of programming to parse the output from "uptime" (for example) into formatted data, but once one person did it that could be available as a pre-buit recipe for all of your customers.

Our tool is pretty much hard-coded to our system but I had always thought it would be a cool thing to have. I've looked at other monitoring systems that seem to do that already but many of them are so complicated and none of us have the motivation to learn them. We're a typical team of programmers who have to be admins by default.

It looks like it runs very similarly to our current server management systems, but the web UI is a huge plus.

I agree that open sourcing it to run on your own infrastructure would be a big benefit - people tend to be a bit protective of where they put their root ssh keys :)

A nice ui over pluggable backends is a great idea. Building (another) sub par orchestration tool seems like a waste of everyone's time. Mcollective has had the prototype REST bridge for what, 2.5 years?

I think most features (and more) you mentioned in the video are already covered by the chef-server (recipes, role, ohai, search, provisioning etc), and they have large community and more thoroughly tested.

However, their webui is too simple, and in particularly not extensible - no plugin mechanism so it is difficult to add some minor feature on the top of their webui.

So I think there is a huge market for providing a better UI for chef-server, especially they are one of the leaders in the field?

Good lord.

Anyone who gives these people money is a fool.

Monitoring is a market that already has some amazing companies (ServerDensity, NewRelic). The missing piece is management, provisioning, automation of servers within a web-interface.