Here's my thought process. I was chatting with a bunch of guys who had done lab work with some of the private cloud platforms. And they were grousing that, just as introducing a hypervisor creates another layer of complexity around a server (though it does remove some complexity as well), private cloud software introduces yet another layer of complexity. So IT folks who implement Eucalyptus need to master the Eucalyptus skill set as well as the hypervisor skill set. Not only that, prior to implementing Eucalyptus, they need to master the Rocks Cluster software, since it's a dependency of Eucalyptus. There are similar examples with other cloud software.
That's indeed a very different cup of tea from just clicking "launch instance" in your Amazon Web Services console, while allowing Amazon to manage all of the hairy backend complexity.
There's complexity underneath public cloud services, but it's not your complexity. It's the service provider's. And chances are your service provider is way more situated to handle that complexity because of (and I know this is a tired old phrase when it comes to the cloud, but it's true) economies of scale. As in, they do it all the time and you don't.
The discussion turned to the "core competencies" principle: the one that stipulates in-house IT staffers shouldn't take on tasks they don't do very often because the cost and risk are way too high. For instance, how many times does in-house staff do the architecture planning, installation, and integration for Microsoft Exchange Server 2010? Probably once in the lab (if they're disciplined) and once in production. Woo. Isn't that fantastic. As opposed to, call in a contractor who has done it 20, 40, 60 times.
That service provider has run into scary crazy moments during installation. That service provider has run into many of the undocumented workarounds, limitations, and bugs requiring hot fixes. So why would you pay your staff to do this? It's not a core competency because it's not done more than once or twice. Instead, farm it out to a contractor.
How many times do you really want to touch your private cloud software? Ideally, you won't touch it much at all. Ideally, it will run fine while you provision private cloud instances all over your organization. But if there are problems, does your team have the core competency to handle them?
Not having a core competency in private clouds or anything else makes it effectively more complex, and as complexity rises, so does the risk of failure. Since public cloud providers handle the complexity--and it's a core competency--the relative complexity and risks of those services are lower. Somewhere in between would be a private cloud maintained by a service provider.

The trouble is that I have a hard time believing there are private cloud service providers with deep core competencies. Private clouds just aren't entrenched yet.
It's a lot like virtual desktop infrastructure: Everyone's talking about it, but not a lot of people are actually doing it yet. As someone who really wanted to do a VDI pilot, I scouted around and did an RFP, trying to find a deployment expert. Suffice it to say that the service provider we ended up hiring was only marginally more competent in VDI than my staff. I think that those who seek private cloud service providers will have a similar experience. It won't be that way forever, but that's what I'm thinking right now.
So for now, I'm very cautious about private clouds. I'm not a Pollyanna about the public cloud. I realize that hybrid clouds--with a relatively small private cloud component--are very likely for a number of organizations. But the benefits of maintaining an actual private cloud (not just lots of virtualization, but an actual scalable, API-driven private cloud) in-house probably don't outweigh the implementation risks. It's a huge opportunity for service providers that build a competency, and when they finally get their acts together, the implementation risks will be on par with public cloud services. It's just not there yet.
Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at [email protected] or at @_jfeldman.
Read our new report, State Of The IT Service Desk: Change Management Remains Key. Download the report now. (Free registration required.)