Speaking at the OpenStack Summit in Barcelona, John Arwe, a member of IBM's senior technical staff, offered up some pointers on the do's and do not do's of working with customers who are interested in OpenStack. Here we present a few of them - with some small edits from Computerworld UK for conciseness.
Arwe offers some insights from the service provider's point of view that will be useful for IT teams and CIOs to consider as well.
Do: Define the cloud
"One of the first problems we had was our own clients were being told by their CIOs you have got to be in the cloud. And sometimes the CIO kind of knows what that means, and just as often not really, let alone if their definition of the cloud is the same as the OpenStack definition of the cloud," Arwe said.
"Our own technical leaders in some cases, sales people in others, some of them had been doing virtualisation since the 1970s and they have their homegrown processes. Some people would say sure you can do cloud, you don't have to change any of that other stuff - don't worry about it.
"If you know OpenStack you know that's not really true, OpenStack has its ideas: this is my playground, everybody else get off. So you have to be careful about that. Probe them a bit and see what they mean - if they say we want to do cloud, find out what that means to them."
Don't: Forget your clients might not have a technical background
"The questions one client didn't know they needed to ask was: are you willing to give up custom scripts and things that you used to build and manage your guests for years, that are hooked up into your compliance systems?
"The answer of course was no, we don't want to give those things up, so there's an organisational debate going on. You have to figure out how you want to do compliance - you don't have to do it on OpenStack. You can't expect the kinds of enterprise clients you're going to get, especially from executives or managers of IT infrastructure groups, to understand all the technical details of OpenStack."
Do: Distinguish between public and private clouds
"The third thing is the assumption public and private clouds have the same needs. Another way to think about this is: are you trying to be a service provider or just try to run your own devops stuff in the cloud? They are very different business models - and that forces different effects on you. There are very different usage models and you have to have different metrics sometimes for your own development group."
Sign up for Computerworld eNewsletters.