You've told your ITOps team to make it happen, you've approved the purchase of cloud-in-a-box solutions, but your developers aren't using it. Why?
Forrester analyst Lauren Nelson and myself get this question often in our inquiries with enterprise customers and we've found the answer and published a new report specifically on this topic.
Its core finding: Your approach is wrong.
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.
To them, a private cloud is a service, not an infrastructure stack. They value the speed in which resources can be allocated to them, the simplicity of getting their work done and the lack of friction involved. To get private cloud right you have to start here, and that requires a completely different set of skills — skills your virtualization administrator, frankly, doesn't possess. And honestly, your virtualization administrator probably doesn't see how he benefits from a private cloud. In fact, he's probably threatened by it.
Cloud developers look at the private cloud through the lens of the public cloud and the benefits it provides: self-service, a low entry price, strictly limited sets of predefined resource configurations, and services and speed — where fast is defined as fifteen minutes or less. Cloud developers want these same characteristics in a private cloud and won't tolerate compromises in autonomy and agility. And the end customer of the private cloud doesn't care at all about the VM container their app will eventually run on or the underlying infrastructure — these elements have all but disappeared for them.
Bottom line: Your private cloud is very different than your static virtualization environment.
In looking at the organizations who are having success with their private clouds, their approach is completely different. And usually starts with a different person in charge — a developer or architect who approaches the cloud, not from the infrastructure up, but as a service. And they start their service definition with the public equivalent. The approach: How can I deliver the same value and experience of the public cloud from within our own data center? Those who have had the most success with this approach have also started with a complete Infrastructure as a Service or Platform as a Service solution, rather than trying to build one up from a virtualization foundation.
So if your team is struggling to deliver a private cloud and you have taken the bottoms-up approach, stop. This is the difficult, culturally challenging and slow approach to cloud value. Instead, put a new cloud admin in charge. Someone who understand and has direct experience with the public clouds, has a service orientation (not an infrastructure orientation) and is willing to start fresh with solutions that meet your developers needs out of the box.