In spite of what Dave Rosenberg thinks, I do in fact read his blog, and after rereading his post I’m pretty sure that the first time I’d actually seen ElasticFox was over there. So when asked why, while on a call with him and his MuleSource colleagues this morning, I inquired as to whether he’d seen it yet, my response is simple: dude, that was before Christmas. Might as well have been a hundred years ago.
Anyway, if you haven’t had the opportunity to give the extension – or Amazon’s EC2 facilities – a look yet, I encourage you to do so. Especially with the barriers to entry continually lowering as a result of tools like ElasticFox. The complexity of the tools, after all, were formerly a significant obstacle to usage. In handing the Amazon crowd my award for technical innovation last year (really fighting this year’s probable choice), I was obliged to note their failings in the tool department:
Despite this award, AWS is far from perfect. I’ve criticized them in the past for the complexity of their toolset, and many if not most of those criticisms remain valid (although they do finally have an Ubuntu image).
ElasticFox, by itself, is clearly not the solution to the problem of interfacing with EC2. But it’s certainly part of it.
True, it’s excessively finicky generating key pairs and connecting to the generated instances via SSH, but it could get any easier when it comes to launching, rebooting, or terminating them. Nor could you ask for lighter footprint tooling; essentially, it’s just a bunch of CSS, JavaScript, and Mozilla packaging. A bunch of open source CSS, JavaScript and Mozilla packaging, notably. Apache licensed, for the curious.
Amazon is to be credited on multiple fronts here; first, for the underlying service that dramatically lowers the bar for hardware procurement and deployment. Second, for addressing an obvious need in improving the toolset used to interface with the underlying service. Last – and perhaps most importantly – for realizing that there’s little if any benefit for trying to exert total control over those interface mechanisms. Their economic benefit derives from the platform, not the tooling.
Why not open source the project, then? If no external contributions are forthcoming, who cares? No harm, no foul. But if someone external can substantively improve on the effort – even if it’s just a restyled skin – then they’ve made it more likely that users will chew up cycles on their platform at no or low cost. A better tool is a lower barrier, and a lower barrier means more paying users.
As simple as that logic may appear, it’s considerably less so for a great many in the software world. Trust me.
Up several levels, it’s also interesting to see an embrace of Firefox, rather than say Eclipse, as the tooling platform. The reasoning for the choice is obvious, and it would be asinine to argue that Eclipse and Firefox were directly competitive, but I do believe that we’ll see more overlap going forward than we have previously.
