Tag: chef

Link: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

“Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner. I encourage tracking of all changes that are made to the system. To do that, I use git and I track problems and resolution in a ticketing system. That could be Jira or Zendesk. When it comes to risk management, compliance, and security, again, I turn to the Chef ecosystem. Chef Compliance, as part of the Chef automation system, provides ways to specify compliance requirements as testable specification, which can then be used for audit and management.”

All that configuration management, logging, and automation gives what’s needed for ITIL-level tracking.
Original source: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

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

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

How a BigCo actually got some innovation done – The Longer Story of Crowbar http://slidesha.re/HQ2uVV

View more presentations from Michael Coté

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)