Download the episode directly right here, or subscribe to the feed in iTunes or other podcatcher to have episodes downloaded automatically.

In this episode, John and I use my past week of cloud conferences to - largely - explore more of the question of what monitoring and managing cloud computing would look like. We start with a brief mention of Microsoft's Hyper-V being released (congrats to them!), then get into a discussion of Hyperic's CloudStatus.

Lacing into the tail-end of that, we move to a sort of spastic run-thru of the Force.com, Velocity, CloudCamp, and Structure conference I attended this week.

Finally, John starts walking through some of the monitoring metrics he's been thinking about for cloud computing.

As ever, our recording was cursed, so pardon the technical scattle towards the end.

Disclaimer: Microsoft is a client, as is Hyperic. See the RedMonk client list for more clients mentioned.

Download the episode directly here, or subscribe to the feed to have episodes downloaded automatically.

After a long abcense, John "johnmwillis.com" Willis and I return for this episodes. We do some "admin" house cleaning at first, for example, figuring out what happened to the Zenoss jacket in the No Country for Old IT Guys series. The answer is pretty simple, turns out.

Next, I mention the iTricity/Blue Cloud announcement iTricity of this week, which gets John on a commentary about trying to figure out what the Blue Cloud stuff actually is and what it's made up of, comparing to other cloud management systems out there like RightScale, Elastra, 3Tera, the use of Puppet and others.

After getting cursed by the echo effect, I pull in Matt Ray, Community Manager for Zenoss, to join us. He gives us an update on the recently released Zenoss 2.2 Enterprise. John and I then of course ask Matt Ray a bunch of Zenoss related questions, esp. around ways people are using Zenoss and developments in the Zenoss community.

We also decide to life the ban on cloud talk after a multi-episode hiatus, so we get in all sorts of discussion around that. I note that the conversations I get into now-a-days around "The Cloud" are largely definitional ones: that is, "what exactly is this cloud stuff?" We get into what we think that answer is, but more importantly we discuss what's left untouched in IT management by all the current cloud talk. I also ask the question, are enterprise applications ready to run on these clouds?

I close out by briefly covering the recent Spiceworks 3.0 release and their new number of users: 350,000.

Thanks to Matt Ray for being Johnny on the spot and jumping in ;>

Disclaimer: Zenoss is a client, as are Spiceworks, IBM, and Reductive Labs. See the RedMonk client list for other clients mentioned.

Download the episode directly or subscribe to the feed in iTunes or other podcatcher.

This week, Ryan and I finally get back together for a brief but packed episode. The title pretty much covers the topics. We don't spend a lot of time detailing news - as there's not a whole lot of it - spending most of time talking about geographic concerns and getting back to a discussion from episode 14, we talk about Google Gear's aspirations to be the new web standards work-horse, supplanting the W3C or any other standards body.

Disclaimer: Adobe is a client, as is Microsoft. See the RedMonk clients list for other clients mentioned.

Download the episode directly here, or subscribe to the RedMonk Radio podcast feed to have this and other episodes downloaded automatically for you.

I recently talked with Reductive Lab's Luke Kaines and Google's Nigel Kersten on the topic of Puppet. First, we go through a quick overview of what Puppet does - establishing the desired configuration of machines by modeling services and then enforcing that model.

As I note in introducing Nigel, while Puppet is well known for managing servers, I haven't heard about it being used too much to manage desktops, making his expierience that much more interesting. On this note, later in the conversation, Luke paints out the many different scenarios that Puppet is used in: from servers, desktops, to new situations like virtualized installs, even on Amazon EC2.

Using Puppet at Google

Nigel has been using Puppet to manage "many, many thousands" of Mac desktops used at Google by developers and others. He tells us how he got involved in using Puppet last year during WWDC last year and quickly applied its use to managing Google Mac desktops.

How Puppet Works

I then ask Luke and Nigel to tell us how people usually get started with Puppet. Both recommend starting with a very small service to get started quickly, for example, managing sudo or SSH. As Luke explains, sudo is the command that allows users to execute other commands with administrative privileges, and managing it means ensuring that sudo itself is permissioned and configured correctly for use. Nigel says that, indeed, this is exactly the service they started with.

We then dip into the details of Puppet by talking about the modeling language that it uses. While Puppet is written in Ruby, the modeling language isn't, being more like "the psuedo-code you write down when you're planning what a program should look like," as Nigel says. On the topic of the modeling language, Nigel comments on new user's common reaction to the language, namely looking for something more script-ish. The point of the language is to simply model resources rather than describing in detail how to go about configuring those resources. As such, there's more giving up control on how configuration desires are fulfilled - focusing on the what and ignoring the how, as Luke says.

Deploying Puppet and Ongoing Use

At this point, I get curious about how Puppet itself is configured and deployed. Each machine to be managed needs the Puppet agent installed that works with the main Puppet server. Nigel also tells us how his team tracked down the unmanaged desktops in Google.

Here, we get into the ongoing use of Puppet once the initial setup is done. Luke talks about his ideas that admins and operations people would benefit from thinking more like developers - using the term "infrastructure developer." For example, Nigel talks about using a version control system to keep track of the configuration models used by Puppet and Luke talks about work that he and Andrew Shafer (at Reductive Labs as well) are doing around brining unit testing to operations.

Expanding Puppets Use in Google

Finally, while wrapping up, Nigel tells us that his group has convinced the people using CF Engine to manage Linux work-stations to start switching over to Puppet. More than just cause for Luke to do a little dance, this is interesting because, as Nigel says, it's encouraging the Mac and Linux operations groups to collaborate more which, one would hope, would increase their overall effectiveness both in human terms (reducing repetitive work across the two groups) and work-product quality (making sure both actually have the exact same effect when desired across both platforms).

Disclaimer: Reductive Labs is a client and sponsored this podcast.