Chef Automate: the big stack o’ stuff from Chef

Chef stack diagram

The idea behind this consolidation is to give organizations system-wide insight across all their applications and their supporting environments, be they in the cloud or within private data centers.

Also, some momentum updates:

More than 80 percent of Chef’s revenue now comes from enterprise deployments, consisting of more than 900 commercial customers.

See also Tim Anderson’s coverage at The Register.

Source: Chef Rolls all of its IT Management Ingredients into One Package, Chef Automate

Relative momentum around Chef (née Opscode)

Chef’s Sales grew 250 percent year-over-year for the third quarter. The number of new Chef Software customers grew by 350 percent for the nine-month period ending September 30, 2013, with Fortune 1000 companies accounting for nearly 60 percent of Chef’s sales.

Relative momentum around Chef (née Opscode)

I’ve been in Chef Fundamentals training this week. It’s a good course. Chef is a lot more ruby than I’d realized. It’s pretty close to what a programmer would do if they were forced to manage machines. Of course, programmers also came up with Ant and Maven, so we have that. All this will be a good baseline for chomping through the successors of Puppet and Chef, the SaltStacks and Ansibles who seem to be taking an even more simplified approach.

Sputnik Cloud Launcher – Doing More DevOps

One of the tools in Project Sputnik is the “cloud launcher.” The idea for this tool is to help instrument a DevOps life-cycle: the tool models out a simulated cloud on your desktop during development, and then deploys it to “real” clouds once you’re ready. We demonstrated one version of the cloud launcher at Dell World this week that uses juju.

In the meantime, OpsCode’s Matt Ray has been working on another approach (which he describes in the above video) that uses Chef under the covers. See the code checked into the Sputnik repo as well. I’m looking at these two versions as proofs of concept, or even “spikes” to explore how to best implement the idea. We’re eager to get feedback and engagement from the community to figure out which approach (or a third!) is most helpful.

How a BigCo actually got some innovation done – The Longer Story of Crowbar

Here’s the slides for the talk I gave this morning (at DevOpsDays Austin 2012) on lessons learned from working on a DevOps product in a large company, that is, Crowbar in Dell.

You can also see the recording of the presentation if you scrub the start time to around 17:45:00 in this recording.

The abstract:

Sometimes it seems like It’s near impossible to get anything innovative, interesting done in a large company – it’s as if BigCos are goaled to prevent just that. While you can’t type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps!

I’m amazed when I find a skunk-worked project that’s blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it’s even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You’d never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the “real story,” being at Dell now after six years at RedMonk covering tech from the outside, I’ll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company.


(Source: http://bit.ly/HQ2xRr)

How a BigCo actually got some innovation done – The Longer Story of Crowbar

Here’s the slides for the talk I gave this morning on lessons learned from working on a DevOps product in a large company, that is, Crowbar in Dell.

The abstract:

Sometimes it seems like It’s near impossible to get anything innovative, interesting done in a large company – it’s as if BigCos are goaled to prevent just that. While you can’t type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps!

I’m amazed when I find a skunk-worked project that’s blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it’s even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You’d never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the “real story,” being at Dell now after six years at RedMonk covering tech from the outside, I’ll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company.