Forrester's James Staten has a typically smart blog post up called "Why your enterprise private cloud is failing." It's based on "The Rise Of The New Cloud Admin," a report that James co-wrote with Lauren Nelson. James writes:
You're asking the wrong people to build the solution. You aren't giving them clear enough direction on what they should build. You aren't helping them understand how this new service should operate or how it will affect their career and value to the organization. And more often than not you are building the private cloud without engaging the buyers who will consume this cloud.
And your approach is perfectly logical. For many of us in IT, we see a private cloud as an extension of our investments in virtualization. It's simply virtualization with some standardization, automation, a portal and an image library isn't it? Yep. And a Porsche is just a Volkswagen with better engine, tires, suspension and seats. That's the fallacy in this thinking.
To get private cloud right you have to step away from the guts of the solution and start with the value proposition. From the point of view of the consumers of this service - your internal developers and business users.
The post and report do a great job of articulating why a private cloud isn't just an extension to virtualization. It may leverage virtualization and build on virtualization but the thinking and approach have more differences than may be readily apparent if you're just focused on the technology.
I think about it thusly. Even though it's about virtual rather than physical, the fundamental virtualization mindset is still about servers. Whereas, with cloud, that mindset should shift to delivering IT services to users. That's a big difference. (This shift is discussed in more detail in both Visible Ops Private Cloud: From Virtualization to Private Cloud in 4 Practical Steps by Andi Mann, Kurt Milne, and Jeanne Moraine and in my new book Computing Next: How the cloud opens the future.)
To make things a bit more concrete, here's another way of looking at the expectations for a private cloud.
Public clouds were initially largely a grassroots phenomenon. Users voted with their credit cards for IT resources delivered in minutes, not months. They voted for freedom from restrictions in the type of software they could run. They voted for easy-to-use interfaces and fewer roadblocks to developing new applications.
When an enterprise builds a private or a hybrid cloud, it needs to preserve the goodness that drove its users, often developers, to the cloud in the first place. It may well need to balance these desires with legitimate governance, consistency, compliance, and security requirements. But it has to do so without effectively throwing out the cloud operating model and going back to business as usual.
As RedMonk's Stephen O'Grady told me in a recent podcast:
If you're looking to reign in or at least gain some visibility into usage, you basically have two choices. You can try to say, "No, you can't do this and you can't use these tools." As I've said, that's an effort, in my opinion, doomed to failure in most cases. The alternative is to say, "I understand that there are reasons and very legitimate business reasons that you're doing what you're doing. I'm going to try to go along with that program as much as I can. In return for that, I want visibility into what's going on." In other words, trying to meet developers halfway and having them do the same.
This is where open, hybrid cloud management comes in. I'm going to discuss the components of this management, as implemented in Red Hat CloudForms and ManageIQ, in greater detail in an upcoming post. But, for our purposes here, open hybrid cloud management is fundamentally about balancing what users/developers want and what enterprises need. It's about offering the user experience of the public cloud within the policy framework of enterprise IT.