A snapshot: actual customer questions about internal cloud computing

After my recent post covering Nicholas Carr's presentation at the IDC conference, I received a comment from Jon Collins voicing extreme skepticism that the transformation Carr talked about (and I agreed with) was, in fact, underway.

One of the fun parts of being on the front lines of what's going on in the data centers these days is having a pretty interesting set of data points that a lot of other folks don't have. When faced with questions like Jon's or even the more basic, "What's really going on out there with cloud computing?" I always go back to what our customers and prospects are saying.

So, while sitting in on customer meetings with the Cassatt sales team over the past few weeks, I began writing down a lot of what I was hearing and putting it into general buckets of responses. I'll share some of the more interesting ones here (leaving out confidential stuff, of course) with the hope of providing some direct, unvarnished views into what's happening.

I'll let you be the judge, but from the list of questions I gathered, I think people may be farther along than many think.

One caveat before I start: Cassatt talks to end users about ways to make their data centers more efficient. The way we can help them do that is to create a cloud-like environment inside their data center’s four walls, using their existing physical and virtual servers, networks, and other infrastructure resources – all managed by policies they set. We call that an internal or private cloud. A lot of other people do, too (see Gartner’s Tom Bittman or James Urquhart, to name two). As a result, the things people ask us about are generally in the context of internal cloud computing, and not much about external cloud services. So, don't expect me to make any sweeping generalizations about the external cloud part of the market; we're not getting good data about that. Instead, this should provide some real and specific insights into customers' thinking about internal clouds.

As you can imagine, we get all types of questions. I grouped the ones below into a couple different categories, based upon where people are in their adoption or thinking process:

Tire-kickers: Can you tell us what a cloud is? Aren't we already doing that with virtualization?

These folks are really just trying to get their heads around what cloud computing is. They aren't close to getting anything started, but have probably heard they should investigate the topic. So, these questions are pretty basic:

"What is the difference between an internal cloud and virtualization?"

"Do I need to virtualize everything in order to create an internal cloud?"

"What are the business use cases that indicate I should look at a cloud environment rather than focus on other IT spending such as virtualization?"

"I have a data center consolidation project on the table right now. How does this internal cloud environment intersect with that?"

You'll notice some pretty basic terminology confusion, and a big tendency to compare the new cloud concepts with things they know, like virtualization, even if that comparison is not always the best one. These reminded me of the 80% of conversations that we tend to have at trade shows.

Getting their arms around it: can you explain how and when an internal cloud can be useful?

The IT folks who asked these next questions were beyond the definition stage and were generally trying to think about specific use cases, in most cases as a way to begin to put the boundaries around a particular project. That makes these questions a lot more practical than the last, because they are thinking about the internal cloud concepts in terms of their actual business needs. This group seemed to be in the brainstorming stage about what the benefits and drawbacks could be, usually focusing on the benefits. (After all, it's the benefits that make these concepts appealing, right?)

"How do I determine if an application is ideal for an internal cloud?"

"If I have a widely distributed organization where there is not a lot of centralized IT for data centers, but instead I have lots of very small data centers, server rooms, closets, etc., should I still consider an internal cloud?"

"I want to manage our internal hardware as if it were Amazon EC2 instances."

"In our development environment, we want the ability to move workloads to and from Linux and Windows environments, including across physical and virtual servers."

"We have a zero-server-growth mandate. We're trying to figure out ways to repurpose servers to get around this, and to find other ways to cut back on expenses. We're watching usage patterns on our servers, but really have no formal methodology for doing so."

Reality bites: Thinking about trade-offs and impact on current operations

Another bunch of IT folks I heard from were beyond the brainstorming and blue-sky thinking regarding the potential internal cloud benefits. Instead, they wanted to go directly where most data center and IT operations folks take any conversation about new technology: what potential problems is this going to cause? And, once they're feeling a little comfortable on that front, they really want to figure out how they get there from here. They were trying to come up with some of the actual steps that would need to happen to make something like this work.

"How do I create a cloud when I have a lot of static infrastructure right now. How do I get started, and how do I get these servers to do this?"

"How do I assure everyone that this open usage of an internal cloud of servers improves SLA performance rather than hinders it? Why should I believe that this 'all-in-one' kind of solution will do any better than my specialized, hardened solution for making sure that my service levels are kept?"

"How do I agree on security concerns over networks in a private cloud. How does that work, and what do I have to give up network-wise to have a private cloud?"

"Does the internal cloud exist outside of my standard IT operations center or is it part of it? I have IBM Tivoli, so what happens to the application provisioning process? What happens to my current monitoring process?"

"Can I use an internal cloud and still have disaster recovery, and how does that work with my storage?"

"In the case of a major data center outage or failure, what happens to the internal cloud controllers themselves, and how is restoration handled?"

I should also point out that this stage of the conversation is where any fluffy hype about the wonders of cloud computing gets bowled over by the day-to-day realities of running a real data center that supports real applications and real users. If you are going to make a case that things are going to work much better with an internal cloud approach rather than how you're running IT today, you have to be able to answer these kinds of queries.

I'm actually ready to get started: any tips?

I also found a set of customers and prospects who really sounded ready to get going; they are just looking for some of the final important pieces to fall into place. They want to know what's worked and what hasn't worked with other implementations. They want the insider's view of how they should approach things. And probably most importantly, how not to.

"Should I focus on development to create a cloud or on production? If I choose production, what are the 'gotchas' when creating an internal cloud, like how do I know how many servers I will end up needing?"

"I have to actually prove I can create a cloud in the next 30 days. Management wants to know that it can service the jobs -- automation will come right after that. I need to be able to use this capability to add $2 million to the top line of our SaaS business."

"How do we figure out when to have our internal cloud provision more servers or turn something off because it has become idle?"

"What are the best practices for implementation of an internal cloud?"

Other more complicated issues are getting asked about, too

In addition, there are some more complex questions that usually are the result of a lot of experiences up front before they are even asked, and then take a team of implementation professionals to work with the customers in order to answer adequately. We heard some of those, too.

"How do I do chargeback for billing for internal clouds if I am not billing for a computer? What am I billing for: CPU, cycles, memory, etc.?"

"If I have a complex enterprise application, using some combination of STRUTS, SQL Server, Tomcat, and Apache, that accesses a mainframe, where some of the application will run in the cloud and some will be on traditional infrastructure, or controlled through another business unit, what are the considerations for considering a hybrid cloud model?" [Whew! Is that all?]

These and others like them frequently have answers that start with, "Well, it depends upon what you're trying to do...."

...

After posting all these questions, I realize I probably should provide links back to the Cassatt site or our product documentation to give some of the actual answers, but the point was not pitch Cassatt software, but to provide a snapshot of where some of the end user thinking is about internal clouds and their data centers at this moment in time.

My summary on all this? We talk mainly to very large corporate and government organizations with complex, messy data centers. They are conservative about change, but some are actively seeking a better way to run IT operations. And, within that group, I'd say we're seeing customers move from asking more questions like those at the beginning of this post to asking the ones in the latter part of it -- the ones more firmly based in reality and the nitty-gritty details of making something like an internal cloud work.

Time will tell, and this is obviously just one set of data points. But, as much as I want argue for or against the internal cloud concept (or Carr's "big switch"), what end users are doing will be the true measure of progress. I'll keep you posted.