It’s official. The deal is done and Cloudsmith and Puppet Labs are now one team. (Actually, it was done a few weeks ago, except now it’s also “official.”)
What does this mean for our loyal users and customers? Things will only get better. We always had great ideas and great technology. Now we can push them forward as a market leader.
What does it mean for the team? Painting on a bigger canvas. And no more “management”. (That second part isn’t really true, but they don’t know that yet.)
It’s been a while, but we’ve been busy with our new “partner.”
Last we reported, we were off to PuppetConf in SF to see the show and score some swag.
Next thing we knew, we were in a windowless conference room with a dozen “suits” from Puppet Labs, being given the hard sell. “Stack Hammer, Geppetto…that’s nice. But you’re tiptoeing. You need to strut.”
It sounded good to us, and we bought it.
To be honest, we liked everything about the Puppet Labs crew from the start. Great people, vision, cool technology, an unbelievable market position, the right culture. We’d been working together for over a year, and taking the collaboration to the next level was the obvious next step.
So for the last six months or so, we’ve been effectively working as a team. Sharing technology, pooling resources, working from a common vision toward a common goal.
We promise to write again soon.
We’ve just dropped *a lot* of new Stack Hammer features into production. And as people who have been developing software for many many years, we can tell you that more features *always* makes a better product.
Testing support just got much more powerful. Stack Hammer now generates a complete RSpec scaffolding for you – the necessary file structures, catalog tests, a test harness that gets automatically deployed with your stack. And if you don’t want to write your own application tests, Stack Hammer generates everything you need to do full regression testing based on your Puppet catalogs.
We’ve also expanded support for Puppet Facts, which lets you do dry-run testing with 100% fidelity. Have Stack Hammer pull the facts for any Amazon machine it deploys to, or extract and upload facts from your own machines. Run your tests against the facts and you’ve tested your stack on the exact machines you’ll deploy to, without actually deploying.
Last but not least, we’ve added Puppet-lint support. When Stack Hammer parses your code, it now shows you what Puppet-lint would find, alongside Geppetto-type errors. By the way, getting the team to give a damn about the unlucky 47% who don’t use Geppetto and want to see lint results wasn’t easy, but management was a tireless advocate.
In sum, it’s a great release, and management would like to tell you more. But the team got this into production about 30 seconds before the planes took off for PuppetConf, so we haven’t had much time to reflect on it. And frankly, most of this stuff goes completely over management’s head.
By the way, while we’re out at PuppetConf, management intends to find out exactly who this “Tim Sharpe” is, and how he has gained “mind control” over our product strategy from his reported base of operations in the Southern Hemisphere.
A few more months and Geppetto has more than 5,000 users! Actually, the real number is probably much bigger, but we don’t count redistributions inside the firewall.
Geppetto is on its third full release and it’s pretty polished at this point. Geppetto 3 fixes hundreds of bugs (many reported by users), adds over a hundred enhancements compared to Gepetto 2.x and provides updated Git support.
As reported previously, management thought Geppetto was a very bad idea. One reason was it just didn’t seem “cricket” to put a full-blown Puppet IDE into competition against a bunch of little code editors and command line tools.
The Puppet community is great and we’re glad to be a part of it. But there’s a new community to jump into – Jenkins, the leading platform for continuous integration- and a new domain to address – continuous deployment.
Since we released Stack Hammer earlier this year, we’ve been getting the same two questions over and over:
- “The validation testing in Stack Hammer (and Wham!) is really powerful. Can Stack Hammer trigger our other tests the same way?”
- “We’re deploying continuously. How can we integrate Stack Hammer’s configuration testing/validation service into a continuous process?”
We’ve taken the hint, and we’ll be adding more explicit support for continuous deployment. In fact, this will be our major product priority over the rest of this year.
Our first step is a Stack Hammer plug in for Jenkins, which we’ll be previewing at a Jenkins User Conference we’re co-sponsoring this week in NYC. The plugin lets you add Stack Hammer validation and deployment steps directly to a Jenkins project.
A typical usage scenario would be to trigger these steps using a Git hook, so that your stack is revalidated and deployed, for example, each time someone makes a commit to GitHub. Kenn will be demoing this at the conference, using Stack Hammer and Jenkins to continuously deploy and test a Jenkins stack (yes, it’s very *meta*), with the code edited directly at GitHub and the Jenkins stack running at Amazon.
The plug-in needs to call out to Stack Hammer as an external service, so we’ve added support for a RESTful API. We’ve implemented this in a generalized way, so pretty much any external application can now call Stack Hammer as a service. A number of people have asked for this, and we’ll be documenting it so anyone can use it.
A key point is that in continuous deployment scenarios Stack Hammer generally will be filling a specific gap – configuration testing – rather than providing a complete, end-to-end configuration management service. This is a direction we want to take in any case, because we’re finding that many prospective users are relatively far along the Puppet investment curve and want to fit Stack Hammer into an existing workflow. So current and future Stack Hammer functionality will be applied to a more focused value prop – continuous configuration testing – where most organizations still have a hole.
Our next step will be to introduce a more general purpose capability to drive testing based on configuration changes. The necessary framework for test integration is substantially complete, and we’ll be doing some refactoring of the Stack Hammer UI to cleanly separate the validation, test and deployment domains. We plan to preview the complete story at the Dublin Puppet Camp in early July.
May and June will be very busy.
There are three secrets to being an extremely successful and charismatic leader. (1) Build a team that can make you look awesome. (2) Pretend to listen to that team even when you know they’re completely wrong, then overrule them. (3) Have the confidence to admit that although, with the full benefit of hindsight, you may not have been 100% correct on every little detail, you still totally nailed the big picture.
All three of those management principles were on display in the case of Geppetto. When Kenn and Henrik came up with the idea of an Eclipse-based IDE for Puppet early last year, Management politely heard them out before telling them it was one of the dumbest ideas of all time. Who would ever want to use something that? Eclipse is for old men! The kids today are all using command line, not IDEs!
As usual, the team ignored Management and did whatever they damn well pleased, working on Geppetto in secret through 15 long months of nights, weekends and vacations.
But the story turns out to have a happy ending: Geppetto is doing really well. Unique user downloads crossed the 3,000 mark in April, and are accelerating. Many of those users probably download Geppetto and then redistribute it internally, so more could be actually using it. These are pretty decent numbers, given the size of the Puppet user community and the fact that we’ve had very little time to promote it. It may not be for every Puppet user, but those that like it seem to really like it.
And so what if Management said that an Eclipse-based IDE for Puppet was a total waste of time, and Geppetto is an Eclipse-based IDE for Puppet? From the start, Management’s vision has been that, in the future, people were going to need a lot more stuff to make things way better. And isn’t that the the key takeaway regarding Geppetto? Doesn’t it make things *way better*? Let the team sweat the details. That’s their job, not Management’s.
Not all of us here at Cloudsmith are dry and technical. Sure, those of us working down in the trenches may be a bit “serious”. But our most creative elements, such as Kenn and Henrik, the duo behind our new Wham! service, have all the style and flair you would expect of pop stars.
They created Wham! so that you’d have no remaining excuses to not pick up your stack hammer. Just type in the name of a module from the Puppet Forge, or a GitHub repository containing some Puppet code, and click. A graph magically appears, showing you color-coded errors and dependencies!
Wham! uses the same validation and graphing services as Stack Hammer. But while the flagship service is deep, powerful and (some may say) a bit complex, Wham! is shiny, sexy and simple. But still just as useful.
So instead of wondering what’s “lurking in the bushes” (figuratively speaking) of that code you’d like to use, get it all out into the open! You’ll feel better and stack safer!
Use Wham! as a standalone service right now. And wait for us to tie it into the rest of Stack Hammer over the next few months.
Having spent most of the last eighteen months holed up in the studio working on Stack Hammer, it’s time for the band to get out on the road.
We’ll be on tour with our friends from Puppet Labs over the next six weeks, starting in Edinburgh next week, moving to various capitals (Stockholm, Amsterdam, etc.) on the continent and then landing for a final gig in NYC. Then we’re be back on the road for a few more major venues.
If you can’t make the show, we’ll be sure to bang a gong for you…
A quick report on Kenn’s trip to Puppet Camp/Atlanta last Friday. Attendance turned out to be good. His Geppetto talk went well, and some quality time was spent with Kelsey Hightower of Puppet Labs talking about the future of the Forge and module development.
Interestingly, maybe a third of the audience now had some experience with Geppetto, which showed this exponential spike in downloads last month. Kenn must have been telling people down there that Management had originally declared Geppetto a complete waste of time, because Management’s ears were burning throughout the day on Friday.
But taking off our community hat and donning the crass chapeau of commerce, what we found most interesting were the results of the early look Kenn gave at the upcoming Stack Hammer release. Granted, Kenn was only able to show it to the six or seven people he ate lunch with, but it seems they all REALLY LIKED IT and might even want to USE IT! (At least that’s what they said.) So we’re getting a good feeling.
Our next report on this topic is imminent.
First up is Atlanta, where we’re hoping to give folks an early look at our new release. Then we’re off to Edinburgh in March, followed a few days later by Stockholm, which we’re co-organizing with Puppet Labs.
New York, Chicago, D.C. and hopefully Amsterdam should follow, adding up to a year-on-year increase in our marketing activities of 250% for Puppet Camp alone.
Like any good start-up, we begin our year with a rousing offsite where we review the past year’s accomplishments and look ahead to the coming year. This year was no exception.
All in all, 2011 was a pretty good year. We pivoted to a new technology/user community (Puppet); built up credibility through a substantial open source contribution (Geppetto); worked through two betas of a new service based on that community (Stack Hammer); and generally just got our act together. We even found time to get this guy to do this. Most things took a little longer than we hoped, but that always seems to be the case for us.
2012 promises to be an even better year. That’s because we’re close to washing our hands of this whole *beta thing* and getting *out there* with a real service, as in, one people would be crazy not to use and hopefully pay us for.
Cleaning up after those contractors always takes a bit longer than expected. Since we’ve already missed our ideal release date of November 11 (Nigel Tufnel Day), we’ve decided to combine the release with all sort of capabilities we’d planned for later this year. The end result should be pretty awesome.
We’ll report back with the details when we have a date.
We’re back from PuppetConf, done reviewing the feedback we got there and back to work on Stack Hammer.
There were actually no real surprises. We hoped to put in place the foundation for a really useful product solving really important problems. That seems to have gone as planned. Stack Hammer seems able to do pretty much everything users want to do with it.
We also knew that we didn’t exactly know what really important problems people would want to solve with our really useful product. We’re relatively new to this particular user community, so we don’t have enough direct exposure to what bothers its members day-to-day and what they like and don’t like.
So we didn’t even try to include in Beta 2 much to help the user figure out how exactly to get started, because we figured it would be a waste of time. It pretty much violates every current best practice for building applications (or building buildings, where you generally put in doors and windows at the same time as the walls), but it made sense to us at the time.
So that’s what we’re working on now. We’ll be releasing features over the next month that show you how things fit together, how to get started and make it easy to navigate around. What’s underneath won’t change very much, if at all.
Another thing we’ve held off on is aggressively promoting Stack Hammer to the community at large. If we aren’t there to help you get started, we’re concerned you’d just get irritated and leave. (That’s what we’d do, after all.) So no Stack Hammer spam until next month!
Our first PuppeConf has come and gone. All in all, we declare it a success, with a number of key objectives achieved:
- Getting several hundred attendees to wear our ridiculous t-shirts or stick our ridiculous stickers on their notebooks.
- Getting a significant number of attendees to be photographed with their faces sticking through a ridiculous poster.
- Giving a slick Stack Hammer demo to everyone who walked by our station with only *one* bug encountered, which Kenn skillfully worked around in all subsequent demos.
- Verifying that that lots of people think Stack Hammer will be awesome (which we suspected but really didn’t know, because we hadn’t talked to two hundred potential users).
These were not isolated events. In fact, as our Creative Director explains to us, the site design, naming, t-shirts, stickers, cheap publicity stunts, etc. – everything plays a part in creating an edgy brand around an awesome product.
The biggest achievement was the fact that Kenn was able to give a few hundred Stack Hammer tours over three days with only one real bug discovered . What made this so amazing is that we entered testing a week late, lost almost another week due to GitHub API outages and other misfortunes and basically had three days to test and fix an almost completely new service.
Our developers write awesome product code!
John and I haven’t exactly been twiddling our thumbs while the rest of the team gets stuff working for PuppetConf. On the contrary, we’ve been spending lots of time giggling over youtube videos and coming up with clever catchphrases and double entendres.
It started innocently enough with a demo to show at PuppetConf. But somehow we ended up re-watching all the Old Spice Guy videos and decided we had to work that in. (We honestly can’t recall how it happened…Portland, Wieden+Kennedy, power tools…who knows?) And then we were inspired to try our own hands at producing edgy, offensive material that would appeal to the sort of young people we’re likely to encounter at PuppetConf.
And before we knew it, we had probably gone too far, but printers had been paid and the presses were already humming. Having recently skimmed Dick Cheney’s memoir at Barnes & Noble, however, we did remember to build plausible deniability into the most offensive material, so we should be ok.
We’ll have pictures from PuppetConf for you next week.
Remember that first beta we told you about in July? It was pretty nice, but it had a couple of gaps.
First, the product was called Stack Hammer, and you’re supposed to use it build software stacks. The problem was that there was nothing about stacks in the applications. There was plenty of really useful Puppet stuff, but you had to use your imagination to see the stacks. We’d definitely file that one under “shortcomings.”
Second, the company’s name is “Cloudsmith”, and has been since the beginning and that wasn’t an accident. Doing something with the “cloud” today is kind of like doing something on the Internet in 1999. But there was no “cloud” stuff to be seen in beta 1 either: another shortcoming.
We’re taking journalistic license, of course. Every witty blog post has “conceit” and this post’s conceit is to be dismissive of beta 1 when, as we already noted, it was actually pretty nice. So maybe we should just come out and say it: beta 1 was just fine, but beta 2 is an ELEVEN!
Pull your assets in from a GitHub repository, stack up your modules or create new ones. Put the stacks on a node. Configure a Puppet master. Validate it to make sure it’s right; graph it to visualize the dependencies and locate problems. Then deploy it all to your favorite Amazon AMI and spin it up. All from within a very slick looking Stack Hammer UI. Total eleven-ness.
We’ll be cutting over from beta 1 to beta 2 at the start of PuppetConf (this Thursday), and the next days will be kind of dicey. We’re finished development about a week late, which wasn’t bad given that the beta 2 cycle took up four three-week sprints.
But we committed to being out with beta 2 at PuppetConf, which means we have a week less for testing and tutorials etc. will have to wait until next week. We had more bugs than usual in the final sprint when we brought the front and back ends together (putting them on separate development tracks was the only way people were able to take vacations this summer). And, of course, the GitHub APIs we use became suddenly and mysteriously flaky during testing.
So this week’s beta will be an authentic beta, rather than the perfect, pseudo-beta that appeals to our sense of smugness. But….we do have t-shirts and stickers!
The list of enhancements is pretty long, and lots of them were requested by early users, many of whom have been really helpful.
We should give a special shout-out to some of the folks at Puppet Labswho have been using it every day and giving us great feedback.
At this point, Geppetto is of at least 2.0 quality. If you’re a Puppet user and like an IDE-style interaction, there’s no reason not to try it.
If you’re going to be at PuppetConf this week, we’ll be glad to give you a tour.
What is a beta without beta testers? Not much, of course.
We assume that every able-bodied Puppet user immediately started knocking out stacks when we opened the beta last week. But in case you didn’t, we’d love to have you as a beta tester.
All it takes is a willingness to (1) try out Stack Hammer and (2) complain to us about what you don’t like using the Feedback link. (If you’d like to tell us nice things as well, we certainly won’t object, but we’re expecting you to complain.)
We’re also working directly with a small number of users to identify requirements for upcoming releases. If you’d like to join this elite and highly selective group, simply email us and you’ll be promptly ushered into the inner sanctum.
We look forward to hearing from you.
Stack Hammer Beta went live today!
We think the end result looks great and is a fantastic starting point for the service. On the other hand, anyone who launches a public beta without a feeling of apprehension, if not terror, for what is about to come is probably delusional.
As with any entrepreneurial venture, such as becoming an oil baron starting with nothing but a pick ax and a few dusty acres, getting here required a ruthless and single-minded focus, particularly on the part of Kenn Hussey and the rest of our engineering team. So hats off to them! (Whereas for “the management,” the key trait required was a zen-like combination of patience and equanimity.)
FYI, if you have no idea what we’re referring to with the picture and the reference to the oil business, this should help.
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.
- No public Twitter messages.
Chris Horn Co-founder & chairman
Founder and CEO of IONA Technologies, leading middleware/platform vendors of the ‘90s. Started IONA with two of my computer science grad students at Trinity College Dublin and bootstrapped all the way to a US IPO (first for an Irish tech company). Spend lots of time on Cloudsmith, plus a few other teams of ventures in the US and EU.Dublin, IrelandCurrent Temp:55 F°
Mitch Sonies Co-founder & CEO type
Consider myself the “idea guy”, but I’m totally dependent on the rest of the team to actually implement anything. Studied math, but went to law school. Started out as a venture lawyer, became a technology analyst on Wall St. Went into the software industry. Cloudsmith is my second startup. Did the first one with Henrik and Thomas as well.New York, United StatesCurrent Temp:50 F°
Thomas Halgren Co-founder and chief architect
Like to lay a foundation that will last a long long time. Earlier in my career I concentrated on O:R mapping and modeling frameworks and languages. Drifted into the build and provisioning domain. Have done a lot of the heavy lifting for the Eclipse community for several years. Began my career working for Henrik more than 20 years ago. He is now my wingman.Stockholm, SwedenCurrent Temp:50 F°
Henrik Lindberg Co-founder and CTO
I’ve been doing this a long time at many companies, startup to public, from operating system to application. Ran JRockit (Oracle’s JVM division) before Cloudsmith. Get most excited about newest stuff and hardest problems. Would solve every one with a Turing-complete language (plus an editor) if the team let me. Thomas is (still) my wingman.Stockholm, SwedenCurrent Temp:50 F°
Karel Březina Developer & architect
Joined the team with Filip. Michal, Filip and I were all CS students together in the Czech Republic. I’m a Java type, but I like working on the user interface more than the other guys. Michal is my squash partner; he hits harder but I win with superior tactics.Pilsen, Czech RepublicCurrent Temp:64 F°
Filip Hrbek Architect & developer
I’m the anchor of Cloudsmith/East. Met the rest of the team through some open source projects. Got intrigued and joined early. Brought along former colleagues Karel and Michal. Used to focus on server-side of things; now having fun with UI development as well. (GWT is Java, after all).Pilsen, Czech RepublicCurrent Temp:64 F°
Michal Růžička Developer & devops guy
Joined the team as a developer just after Karel and Filip. Handier with machinery than the others, so I also manage all our builds and infrastructure. Spend a lot of time helping enterprise customers with provisioning problems. Spend half my time developing, half my time doing devops and third half on customer projects.Pilsen, Czech RepublicCurrent Temp:64 F°
Kenn Hussey VP Development
Modeling guy & toolsmith by background. Worked at Embarcadero and IBM/Rational before Cloudsmith. Spend half my time planning the product and managing the development cycle and other half coding. Originally from Nova Scotia, where we like to have kids early and sail. (I did/do.)Ottawa, CanadaCurrent Temp:37 F°
John Malcolmson Creative Director
Help focus the message, make everything look good. Try to add a dash of “flavor” as well. Originally from New Zealand; went to RISD and stayed here. Worked in large branding/design firms. Ran my own shop with a partner (Cloudsmith was a client.) Left after we merged with a bigger firm. Now divide my time into slices for 3-4 startups needing internal creative direction.New York, United StatesCurrent Temp:50 F°
- cloudsmith/geppetto Allow both upper- and lower case characters in owner name. thallgren2013-09-12T15:26:21+02:00
- cloudsmith/geppetto Ensure that Modulefile dependencies uses '/' as owner/name separator thallgren2013-08-30T12:44:50-07:00
- cloudsmith/geppetto Add missing call to super.dispopse() thallgren2013-08-27T09:40:43-07:00
- cloudsmith/geppetto Add bundle necessary to expose 'External Tools' menu item thallgren2013-08-26T16:34:07-07:00
- cloudsmith/geppetto Fix test assuming that publishing a release without module should fail thallgren2013-08-26T14:21:19-07:00
- cloudsmith/geppetto Fix regression causing New Manifest and New Modulefile wizards to fail thallgren2013-08-22T17:53:35+02:00
Puppet Camp/Dublin06 Jul 2012 - , Dublin, Ireland
DevOps Day/Silicon Valley28 Jun 2012 - , Mountain View, CA
PuppetCamp/DC15 Jun 2012 - , Washingon, DC
Jenkins/NYC17 May 2012 - , NY, NY