Back at DevOpsDays Austin last week, John and I sat down for a (now-a-days) rare recording. He was interested in talking about the presentation I’d given the day before on lessons learned form working on a DevOps product, Crowbar, at Dell.

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.

Check out Barton George‘s quick interview with Matt Ray while he was visiting yesterday. See the original post for some notes and links.

The only think more fun than XML is…more XML.

In this exciting episode, Coté talk with Dave Fayram (aka “KirinDave”), currently of PowerSet, about his experience writing Rails back-ends (at places like mag.nolia. and mog), being part of the Rails community, and functional programming.

Thanks again to Dave for standing in for Charles who’s at destinations unknown in Finland…we think.

(This episode edited by Coté)

Tags: community, erlang, functionalprogramming, opensource, rails.

That is, instead of being huge, “enterprise software” platforms, systems management will be as easy as downloading my favorite SaaS thick-app/website combo, the flickr uploadr and drag-and-dropping stuff on it with a few key-strokes and clickity-clicks. You’ll have to go to the central website, and you won’t control all the precious data. It’ll go down sometimes, and you’ll be totally lost for a day or two.

But you know what? Even $100 x 12 months is just $1,200. Compare that to the thousands, hundreds of thousands, and even millions you’d spend on traditional systems management software.

The last hurdle for systems management SaaS is a collective shift in the domain’s mind-set, for both the customers and the vendors: customer fear loosing control, and while vendors have the technology to deliver the systems management as a service, they need to go ahead from their customers before they’ll make such a dramatic switch, taking an equally big risk.

Of course, this is the nut of Christensen disruption, which, by definition, bodes ill for the incumbents.

Tags: enterprise, software, sysmgmt.

BMC now has public weblogs and podcasts at http://talk.bmc.com/.

As usual, it looks like Tom Parish is the outside consultant who’s been helping BMC out with this. But I’m just guessing on that.

Agentless typically provides lightweight monitoring, with limited depth of data gathering or monitoring capabilities. In addition, without code or management intelligence installed on the system, the opportunities for management are little to none. The advantage is the ease of deployment – there is no need to deploy the agents – as well as the ease of maintenance. Despite its limitations, if the agentless monitoring provides all that you need for a specific device, then it is probably the right choice for you.

…

In addition, the agent-based approaches can deliver management capabilities through the interaction of the agents and the management servers. In short, the agent-based products offer more robust management (including monitoring) capabilities than the agentless varieties.

Yeah, that’s a bunch of bullshit. Agentless monitoring will get you exactly what you want, in any depth or amount of robustness about 95% of the time. I can guarantee that statement ’cause, having worked on an agentless system for some years, I’m one of the people who write the code.

The fact that there’s an image that agent-full monitoring is “beefier” is due to only two things: (1.) legacy and (2.) agentless people’s strong desire to keep things as simple as possible.

I say “legacy” because agent-based monitoring has a conceptual first-mover advantage. So many monitoring systems that have been around for a decade or more were originally coded to be agent based, putting it people’s minds that if you’re going to monitor something, hard-core and all, you need an agent. People just don’t think otherwise. But, now-a-days, you can get pretty much anything you want remotely without the need to install anything on the target machine — except maybe a username and password so you can access the box (which the agent system would need to get installed).

And, by simplicity I mean that (at least those I know) agentless people tend to prefer having 5-10 really good monitoring metrics over 10-50 everything-you’d-ever-want metrics that agent systems tend to have. Put another way, just because you’re monitoring more metrics doesn’t mean you’re monitoring more quality metrics.

So, if someone comes up to you and tries to tell you that agentless monitoring isn’t going to cut the mustard, be sure they know what they’re talking about. Sometimes it’ll be true, but in more cases than not, they’ll be wrong.

(Of course, none of this should matter to you if the systems management system does exactly what you want, and TCO’s equal to, or less than, what you want to pay. Agent vs. agentless is a distraction if your needs are taken care at a good overall price.)

I realize stuff like this is probably available, but I just want it built it into the cheap stuff I get, all the cheap stuff. Not all that data would be useful — who really wants to see a graph of the fridge’s temperature every minute for the past 4 months? — but, being a systems management person by day, I’ve developed a weird hunger for any sort of monitoring data: I got all excited when I found out that my Airport had an SNMP server on it. Of course, if everything was networked and had SNMP, my resulting excitement would require a change of pants.