Don't proceed until you understand your services
If clouds are inefficient when resources aren't shared, they can be outright pointless if services aren't considered before all else. IBM, for example, begins every potential cloud engagement with an assessment of the different types of workloads and the risk, benefit and cost of moving each to different cloud models, says Fausto Bernardini, director IT strategy and architecture, cloud portfolio services, at IBM.
Whether a workload has affinity with a private, public or hybrid model depends on a number of attributes, including such key ones as compliance and security but others, too, such as latency and interdependencies of components in applications, he says.
Many enterprises think about building a private cloud from a product perspective before they consider services and service requirements – and that's the exact opposite of where to start, says Tom Bittman, vice president and distinguished analyst at Gartner.
"If you're really going to build a private cloud, you need to know what your services are, and what the [service-level agreements], costs and road maps are for each of those. This is really about understanding whether the services are going toward the cloud computing style or not," he says.
Common services with relatively static interfaces, even if your business is highly reliant on them, are those you should be considering for cloud-style computing, private or public, Bittman says. E-mail is one example.
"I may use it a lot, but it's not intertwined with the inner workings of my company. It's the kind of service moving in the direction of interface and independence – I don't want it to be integrated tightly with the company. I want to make it as separate as possible, easy to use, available from self-service interface," Bittman says. "And if I've customized this type of service over time, I've got to undo that and make it as standard as possible."
Conversely, services that define a business and are constantly the focus of innovative initiatives are not cloud contenders, Bittman says. "The goal for these services is intimacy and integration, and they are never going to the cloud. They may use cloud functions at a low level, like for raw compute, but the interface to the company isn't going to be a cloud model."
Only once you understand which services are right for the cloud and how long it might take you to get them to a public-readiness state will you be ready to build a business case and start to look at building a private cloud from a technology perspective, he says.
The final tiers: Service management and access management
Toward that end, Gartner has defined four tiers of components for building a private cloud.