It’s taken about a year, and a redo, but we’re about ready to unleash Stack Hammer on an unsuspecting public. We’re just polishing up the site, and we’ll start opening it up in a few days.

We’d been feeling really good about how things came together. But then came this new Thor movie. One minute, big hammers are a completely “ownable” brand, and the next they’re on billboards everywhere you look. This is not just some *coincidence* – we’ve been, like, totally ripped off. The Hollywood suits got wind of our plans, and then rushed their film out to get “first-mover” advantage.

The good news is that this is definitely survivable. Our market is pretty different form theirs – movies, action figures and other commercial tie-ins (them) versus web apps that help you create, share and provision software stacks (us). Once things settle down, we don’t expect to be bumping into Kenneth Branagh and his “backers” at Paramount Pictures very often.

And who knows, maybe we’re partly to blame? We thought we got the hammer thing from “smiths” and “smithing.” But it does look kind of *Viking-chic*. Plus, we have all these Swedes on the team. So maybe we actually ripped them off subconsciously?

But we digress. Back to Stack Hammer.

The beta actually came out a bit different than we originally anticipated. Maybe a little less *vision* on display (in this first release), but hopefully useful and easy to understand. Plus, we’ve leveraged some really good and popular technologies Puppet, GitHub/Git and Elastic Beanstalk, rather than indulging the tendency to develop everything ourselves.

In this first version, we focused on doing something really good for existing Puppet users. We took our notion of a stack – a set of software elements you plan to deploy together – and mapped it to Puppet constructs (manifests, modules, catalogs, etc.). Then we provided a nice visual way of developing and sharing these “Puppetized” stacks. Our intention is to be 100% complementary to Puppet, which doesn’t provide much in the way of authoring and sharing support. We rely on the Puppet runtime for provisioning, deploying, monitoring, etc. Following the provisioning hand-off, we’re out of the loop until it’s time to modify the stack.

All the information relating to a user’s stacks (Puppet files, metadata, social info, etc.) is versioned and stored in a Git repo. So instead of inventing a new Git hosting service, we just used GitHub. (They provide a pretty good API for third-party apps.) This makes it really easy to work with assets you keep in Git, and also lets us leverage GitHub’s great social mechanisms.

Many users can’t keep everything at GitHub, so we’ll eventually need to support Git repos in other places. But we think GitHub is a very cool way to get started, and it makes Stack Hammer a kind of bridge between the code you develop and the code you deploy.

Something that isn’t directly visible to users, but has been really good for us, is Amazon’s Elastic Beanstalk. We’d built the first version of the beta on Google AppEngine, which seemed smart until they started to go wobbly on supporting “Internet companies” like us (their term). Then when EB came out this winter, it was exactly what we needed and we were able to take a lot of we’d created for AppEngine and just apply it to EB. So far the experience has been great….it’s the future!

We wanted to keep the first release as simple as possible, so there’s a lot we didn’t include. One area where there’s not much to see yet is the *cloud*. This is kind of  ironic, given our name, founding vision, current fashion, the architecture of our service, etc. But we’ll be doing something about that in a release later this summer. Given our recent experience with Mr. Branagh et al., we’ll be keeping the details to ourselves until a later date.

Do not be fooled by cheap imitations like this. You need the real Stack Hammer.