In my last post after getting back onto the blogging network, I mentioned that I’ve had a heavy travel schedule over the past few months. Most of my travel has been out visiting IT organizations; with the lion’s share of the discussions focused on cloud computing. I’ve been intrigued with the successes that I’ve heard during my travels – most everyone I’ve talked with is planning, building, or has already built and is using an internal cloud.
I have to mention the paper that Chris Wolf recently published (Gartner subscription to the IT1 [Burton] service is required) titled: Stuck Between Stations: From Traditional Data Center to Internal Cloud. In this document, Chris sets forth a guidance framework that outlines the five steps to get to a cloud enabled state:
- Technologically proficient
- Operationally ready
- Application centric
- Service oriented
- Cloud enabled
He covers five areas of maturity that organizations must address to move down the steps listed above:
- Service automation
- Service management
- Cloud infrastructure management
- HIaaS infrastructure
As I’ve talked to IT organizations moving along the path to “cloud enabled,” I’d have to say that most are currently between the “technologically proficient” and “operationally ready” phases. Another interesting aspect is that “service oriented” defines what most people think of as an internal cloud today. “Cloud enabled” means that an internal cloud has been interfaced with external clouds to allow for workload balancing, spill over for capacity on-demand, and lower-cost operations leveraging those external clouds for qualifying workloads. Given that, some of you that I spoke with feel that “service oriented” will be your end goal (at least for now).
This brings up another observation: Thus far, everyone I’ve talked to that is operating an internal cloud has indicated to me that they had to roll their own. Off-the-shelf software was not to be found to build a cloud interface when they started. As a result, they were forced to build their own service catalogue and workflow interfaces with connecting middleware to the back end virtual infrastructure (VMware vSphere in most cases). Granted, VMware released vCloud Director at VMworld in August-September of this year. Other companies have also released or are releasing software to solve this problem, such as CA, Canonical (Ubuntu), Novell, and Red Hat. Hardware vendors such as HP, IBM, etc. are bundling solutions with hardware. And as is typical of a new market, I think there could be nearly 100 startups offering “cloud-in-a-box” solutions. But all of these have one thing in common: They are v1.0 and the ability to customize is either immature or lacking. As a result, these offerings may help those in the design phase, yet for those further down the road, probably not.
Moving to “cloud enabled” requires that an organization implement policy and controls whose functions are enabled by workload meta-data. Think of defining a workload with specific requirements, such as availability, performance, security, data protection, lifespan, and termination (archive, delete, secure delete, etc.). Many have talked about service levels: Diamond, Platinum, Gold, Silver, etc. that define groupings of requirements. This level of workload or VM meta-data is required in order to ensure that the workload is dynamically placed with an internal or external cloud service and can be properly migrated between services so that its requirements are met while keeping the costs as low as possible.
But while the concept of dynamic workload mobility based on policy driven from workload service level requirements is a fine end-goal, IT organizations must take each step at a time to get to that end goal. This brings me to one last observation: Governance seems to be the biggest hurdle, not technology, for the organizations I’ve spoken with.
Let me know your thoughts…