Making the Leap from Virtualization to Cloud Computing: A Roadmap and Guide

Transcript of a sponsored BriefingsDirect podcast on what enterprise architects need to consider when moving from virtualization to cloud computing.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Get a free copy of Cloud for Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on making a leap from virtualization to cloud computing. We’ll hammer out a typical road map for how to move from virtualization-enabled server, storage, and network utilization benefits to the larger class of cloud computing agility and efficiency.

How should enterprise IT architects scale virtualized environments so that they can be managed for elasticity payoffs? What should be taking place in virtualized environments now to get them ready for cloud efficiencies and capabilities later? And how do service-oriented architecture (SOA), governance, and adaptive infrastructure approaches relate to this progression or road map from tactical virtualization to powerful and strategic cloud computing outcomes?

Here to help you answer these questions and to explain more about properly making a leap from virtualization to cloud computing, we are joined by two thought leaders from Hewlett-Packard. Please join me in welcoming Rebecca Lawson, director of Worldwide Cloud Marketing at HP. Hi, Rebecca.

Rebecca Lawson: Hi. Good morning.

Gardner: We're also joined by Bob Meyer, the worldwide virtualization lead in HP’s Technology Solutions Group. Welcome back, Bob.

Bob Meyer: Thanks, Dana. Hi, Rebecca.

Gardner: Let’s start by looking at market maturity. With the economy lately, we've certainly seen enough people looking for efficiencies and seeking out ways of extending the infrastructure so they can support more applications, data, network, and services. But, how do we go to the next level? What should you be thinking about now? Let me take that first to you, Rebecca.

Lawson: What we're seeing is that there has been an acceleration of our customers to start to get their infrastructure in order -- to get it virtualized, standardized, and automated -- because they want to make the leap from being a technology provider to a service provider.

Many of our customers who are running an IT shop, whether it’s enterprise or small and mid-size, are starting to realize -- thanks to the cloud -- that they have to be service-centric in their orientation. That means they ultimately have to get to a place, where not only is their infrastructure available as a service, but all of their applications and their offerings are going in that direction as well.

Gardner: Bob, just by virtualizing doesn’t mean you're services-enabling. Does it?

Focus on the service

Meyer: No, it’s a good start. I couldn’t agree more with Rebecca. We're seeing the same thing. A couple of years ago, people were talking about virtualization. The focus was all on the server and hypervisor. The real positive trend is to focus on the service.

How do I take this infrastructure, my servers, my storage, and my network and make sure that the plumbing is right and the connectivity is right between them to be agile enough to support the business? How do I manage this in a holistic manner, so that I don’t have multiple management tools or disconnected pools of data that I can’t drive my IT with.

What’s really positive is that the top-down service perspective that says virtualization is great, but the end point is the service. On top of that virtualization, what do I need to do to take it to the next level? And, for many people now that next level they are looking at is the cloud, because that is the services perspective.

With inward virtualization, as Rebecca said, there are moves to standardize on hypervisors and on different platforms, and, also as we’ve said in the past, virtualization is like the hand, and automation is like the glove. They fit together.

How do you scale virtualization and apply it more cost-effectively and bringing things like compliance? That’s where automation comes in. So, we are seeing all those things together in the notion of how to do this for the service.

Gardner: This strikes me as somewhat of an abstraction or perhaps scaling issue. In virtualization you might have a number of platforms that you would virtualize. You bring more applications across them and increase your utilization.

You talked about "pool," but when we talk about cloud, we're talking about pools of pools, making that something that you could access with more automation and less complexity.

The funny thing is that a lot of people are trying to make a link between virtualization and cloud computing. We think there is a link, but it’s not just a straight-line progression.

In fact, the people who are managing processes might want to access these pools of resources, rather than a traditional IT road map. Does that make sense to you, Rebecca? Are we talking about an abstraction from virtualization, and that cloud is just more of it?

Lawson: That’s a good question. The funny thing is that a lot of people are trying to make a link between virtualization and cloud computing. We think there is a link, but it’s not just a straight-line progression. In cloud computing, everything is delivered as a service, and that’s pretty intuitive to anybody who has used any cloud service like eBay, for example. Social networking is pretty obvious.

What's really useful about cloud services like those is that they're not necessarily used inside the enterprise, but what they are doing is they are causing IT to focus on the end-game. Very specifically, what are those business services that we need to have and that business owners need to use in order to move our company forward?

Do a few things well

For example, if you're a financial services company, you're focused very specifically on doing a few things well, which may be managing financial instruments. Not only are our customers starting to get successful with their virtualization strategy, building from the bottom up, and getting really efficient with pools of infrastructure, but they are starting to think in a more top-down point of view to say, "What is it that we really need to do well? Is it to provide technologies?" The answer is that they need to provide technology-enabled services, and that reorients their thinking a lot.

I want to mention that the scaling that you think of, when you think about cloud services, is not really what most enterprises need to achieve and they won’t achieve it, because they are managing so many different types of workloads. Naturally, every organization has to manage a lot of kinds of workloads. So, the more variation you have the less efficient you will be, but that doesn’t mean you can’t work for its efficiencies.

We're learning lesson from the big cloud service providers on how to standardize, where to standardize, how to automate, how to virtualize, and we're using the lessons that we are seeing from the big-cloud service providers and apply them back into the enterprise IT shop. But, you’ve got to have realistic expectations too. You are not going to get the same economies of scale as an Amazon or Google, if you are just a regular IT shop. Obviously, that’s not going to be the case.

Gardner: At the risk of over-simplifying, Bob, if we look at virtualization as a set of capabilities or a progression to move through, it seems that SOA is also important as a necessary step to be able to scale and get to cloud benefit. Is there a relationship here? Are people starting to embrace SOA, as they start to virtualize, or vice-versa? How does that work?

Meyer: We see them as parallel streams. If you go back a couple of years and get back to the service notion, people had equated virtualization as an infrastructure thing, and SOA as an application thing, and treated them on different tracks. But, when you take them in the notion of how to provide those technology-enabled services that Rebecca talked about, you could start to see how the thoughts merged together.

SOA eventually comes into that conversation, because you work through the service stack, and that’s just another part of the equation.

It’s not only efficiencies in the infrastructure, in the connecting and delivering that together, but you are also applying those same lessons to the application side. They do come together, when you're having a cloud conversation, and that’s the interesting part about it as well.

When people talk to us and ask, “How do I leverage virtualization to get to be an efficient cloud provider,” SOA eventually comes into that conversation, because you work through the service stack, and that’s just another part of the equation.

Gardner: When we look to a payoff, virtualization can often help in terms of return on investment (ROI) and total cost of ownership (TCO) to a certain level, when we're talking about standardization, utilization rates increasing, cutting your energy footprint, labor cost, and so forth.

But, if we can progress to that cloud benefit, where we might be able to actually start using third-party clouds to off-load certain spikes or types and character of workload, that strikes me as a real economic benefit here. Are people who are thinking about virtualization recognizing that they are setting themselves up for a much larger payoff should they make the progression to cloud computing? Let me open that up to either one of you.

Broader implications

Meyer: I’ll just open here and say the cloud discussion is important, because it looks at the way that you consume and deliver services. It really does have broader implications to say that now as a service provider to the business, you have options.

Your option is not just that you buy all the infrastructure components. You plumb them together, monitor them, manage them, make sure they're compliant, and deliver them. It really opens up the conversation to ask, "What’s the most efficient way to deliver the mix of services I have?"

The end result really is that there will be some that you build, manage, and manage the compliance on your own in the traditional way. Some of them might be outsourced to manage service providers. For some, you might source the infrastructure or the applications from the third-party provider.

This cloud conversation really is a conversation about what’s the best mix of service options for me to deliver to the business. And, how do I balance the risk, the cost, and the compliance across all of those? That’s the crux of the conversation. It’s a little bit beyond just a cloud. It becomes about the best and most efficient way for me to provide services to business.

Lawson: In fact, we're using one of the steps between virtualization and going out and sourcing cloud services. That's this notion of converged infrastructure, or as we’ve called it at HP, "adaptive infrastructure."

. . . The industry is starting to appreciate that we are moving from virtualization of just compute to a complete converged infrastructure.

We’ve started to come out with some products that make it incredibly easy to provision and de-provision a complete infrastructure. In other words, that's an in-a-box server storage network, everything ready to go, automation software so that you can spin up a virtualized machine on a logical, virtual, or physical server right from a catalogue that’s embedded into the whole BladeSystem.

So, the industry is starting to appreciate that we are moving from virtualization of just compute to a complete converged infrastructure. That abstracts away so much of the complexity. That means that IT can quickly serve the demand of their constituents who are typically appdev, test, or operations folks who need whatever they need "right now, right now, right now."

It’s actually a pretty exciting time, because we're moving into this converged infrastructure, and virtualization is becoming just part of that fabric. It’s almost embedded in that. It’s assumed that you can use a virtualized environment and that is it not so hard anymore.

That leads you to a place, where you can make, as Bob mentioned, a smart sourcing decision to say -- maybe for certain workloads -- "Do we want to go to a third-party or an outsourced cloud-based infrastructure offering or a cloud-based service that encapsulates infrastructure behind the application?"

Gardner: Perhaps one way to characterize this is that for the investment you make in virtualization, adaptive infrastructure, and SOA, you might get some pretty good payoffs, even in the short-medium term. You are setting yourself up and you are making investments for a much larger return, which is in that flexibility of sourcing and/or finding the right fit at the service level, but with perhaps an underlying fabric on the providing level. Does that make sense?

Lawson: It does. That’s exactly right.

Part of the picture

Meyer: It does. I was just going to say that, from that perspective, it’s really wide. We here at HP say time-and-time again that it’s the service perspective that makes sense, because if you address only the pockets, you only find a pocket for saving. It’s just as likely that, at some point, a cost or a risk may pop up somewhere else, because you're looking at only part of the picture.

When we talk about the whole notion of the service, we're really saying to look at the whole picture from that top-down perspective. That allows you to make sure to put out a fire, if you are saving money in some place, but that you're really saving it and not pushing it to a different place. That’s the perspective you don’t have, if you're looking at just from the infrastructure or from the view of "Here is a management tool I have to choose." You miss out from that perspective.

Gardner: Bob, moving back to this notion of a road map, what is that you need to do in order to come from virtualization as an endeavor and an activity with this new emphasis on getting to the cloud? What do you start thinking? How do you shift in your mentality?

Meyer: We've talked about looking at it from a top-down perspective, but there is bottom-up perspective and bottom-up work to be done. Rebecca ticked off a lot of these at the top of the discussion. She talked about looking at standardization, how that helps, and how you can start to pool and source infrastructure, when you standardize.

Then you start to understand the implications of shifting workloads, not losing specialty tools, and really getting to a point when you standardize. You could start to get to the point of managing a single infrastructure, understanding the costs better, and really be more effective at servicing and provisioning that. Standardizing has to happen in order to get there.

Everybody will have some combination of physical and virtual infrastructure.

We talked about virtualization as another element. I'm not just talking about the server and hypervisor itself. You have to really look across your infrastructure, at the network, server, and storage, and get to that level of convergence. How do I get those things to work together when I have to provision a new service or provide a service?

Most people know how to do the virtualized server stuff really well right now. They tend to see bottlenecks, maybe in provisioning the storage or connecting to the network. How do we get all those to flow seamlessly in harmony and really getting that virtualized infrastructure quickly, along with the physical infrastructure?

The third, or last, thing we look at is from the automation perspective, when you're looking to source something for a service or you're looking to pull assets together. Everybody will have some combination of physical and virtual infrastructure. So, how do I take action when I need a compute resource, be it physical or virtual?

How do I know what’s available? How do I know how to provision it? How do I know to de-provision it? How do I see it if that’s in compliance?" All those things really only come through automation. From a bottom-up perspective, we look at the converged infrastructure, the automation capabilities, and the ability to standardize across that.

Gardner: Are there any examples that you have about organizations that have gotten themselves ready to take the next step of virtualization? What’s been your experience? What may have been different for them than before, when they may have been looking at this a bit myopically?

Focal point

Meyer: I use virtualization as a focal point. It tends to be a series of maturity with virtualization. When most people start, they start with a server and hypervisor, and then they realize the storage and the IO and the automation has to come with it.

It’s that second step, when it’s gone beyond a server and hypervisor approach, and they've looked at the bigger picture, where the costs are actually being saved and pushed. The light goes on, and they say, "Okay, there is more to it than just virtualization and the server." You really do have to look, from an infrastructure perspective, at how you manage it, using holistic management, and how you connect them together.

I don’t think I've seen anybody who skips that first step at the server and hypervisor, but it really takes some time and maturity. Hopefully, at HP we can help make that progression faster, because we’ve worked with so many companies through this progression. But really it takes moving beyond the hypervisor approach, understanding what it needs to do in the context of the service, and then looking at the bigger picture.

Gardner: Rebecca, a similar question to you. Cloud computing isn’t just about providing services. It’s also being able to consume them well. Is there something going on for those companies that are already thinking about cloud that they should be then thinking about how to consume virtualized servers and services better?

Lawson: There's hardly a customer that doesn’t know that people in their organization are out there consuming cloud-based infrastructure services. That may be okay, but I think most IT organizations want to be aware and help govern what actually gets consumed.

There needs to be a governing entity, supported by tools and governance practices, that say what’s acceptable for the corporation and what’s not acceptable.

That’s hard to do, because it’s easy to have rogue activity going on. It’s easy to have app developers, testers, or even business people go out and just start using cloud services. That might be okay, but there also might be problems associated with that. So, there needs to be a governing entity, supported by tools and governance practices, that say what’s acceptable for the corporation and what’s not acceptable.

For example, you can get yourself in a lot of trouble, if you're consuming a service -- let’s say it’s a financial service -- and you, as a business person, don’t realize where your data lives. That could be problem from a corporate governance point of view, because where your data resides is important to a lot of organizations.

Sometimes, there are legal issues, and sometimes it has to do with the country that you live in. There are a lot of governance implications. People in the lines of business don’t always realize this, because that’s not their job. Their job is to get something done to execute a process or to get a certain result. They don’t take the time or have the understanding of all the implications of using some cloud service.

For sure, our customers are very interested in figuring out how can they put their arms around it, without seeming like they are trying to control everything, because that gives IT kind of a bad rep when they come in with a strong arm. There are definitely ways to do that.

Catalog of services

If IT is willing and able to step back and provide a catalog of all services that the business can access, that might include some cloud services. Maybe you have Amazon EC2 as one of the services that you provide that’s been pre-screened, and it’s appropriate for your particular organization. Or, maybe it’s appropriate for some people and some countries of your organization, but not others.

We think it’s important. We try to encourage our customers to use the tools, techniques, and the approach that says, "Let’s embrace all these different kinds of services, understand what they are, and help our lines of business and our constituents make the right choice, so that they're using services that are secure, governed, that perform to their expectations, and that don’t get them into trouble."

Gardner: It’s still early in this whole cloud discussion. We talked earlier about this hybrid model. There are not very many companies that I am aware of that are doing that, other than perhaps at a pilot level or maybe within the app-dev tool side of things.

Are there any examples that you are aware of, Rebecca, where that appreciation for the consumption and the governance has provided some benefits, and/or what would they be? Is there anything we can measure? I know that governance is a tough one to measure.

Lawson: What I'm seeing right now in customers is more of a softer measurement. For example, I was talking to a customer who knew that there was a lot of rogue activity going on. In their minds, it was rogue, because it wasn’t going through IT. They really wanted to have a way to encourage their stakeholders to use services from IT. So, they decided that in order to do that, they wanted to make it just as easy for appdev to secure a virtual instance from IT, as it was from Amazon.

Employees always want to do the right thing and now they had motivation to go back to IT and start using the internally provisioned infrastructure.

So, they worked on that, they put together about 10 different configurations that included storage, computing, network and all that stuff, and they made it available to the app developers. They said, "You can go outside for this stuff and pay for it, or you can use ours. By the way, if you use ours, we're going to be able to provision you just as fast, just as quickly. You are inside the firewall, and everything is cool."

They had a kind of pull mechanism, where they made it really easy for their constituents to use the services that were pre-approved. That’s really the right approach. The measurement of that is that, all of a sudden, they had an up-tick on their services. Employees always want to do the right thing and now they had motivation to go back to IT and start using the internally provisioned infrastructure.

That was a big win for them. All they did to do that was to look at the outside providers and looked at what kinds of promises, service level agreements (SLAs), and provisioning they use, and they just replicated that inside their shop. It worked really well.

Gardner: Right. A service is a service.

Lawson: There's no excuse not to do that these days, because the tools and technologies exist to allow you to do that. At HP, we’ve been doing that for many years. It’s not really brand new stuff. It’s new to a lot of organization that haven’t used it, but we’ve got a lot of experience in that area.

Gardner: Of course, the benefit of doing it through your own IT department is that you can go from test to dev in your production with a heck of a lot more ease than if you had to bring it in from a “rogue activity,” right?

Central governance

Lawson: That’s exactly right, and it may turn out that 30 percent of your infrastructure actually goes out to a third-party, like an Amazon, EDS, or some other third-party. But, the idea is that you want a central governance of what’s okay and what’s the right way to go, based on the value equation, not just based on the cost equation. That’s the direction we're steering our customers in.

Gardner: On this progression -- on the road map from tactical to strategic thinking and behaving more like a cloud provider and consumer -- it seems that there is a behavioral, cultural best practices aspect to this as well. Do those organizations that are seeking this need to plug into their road map something like ITIL, or a shared services approach?

Lawson: Absolutely. If you look at what ITIL Version 3 talks about, it’s all about service strategy and the lifecycle of each service. So, ITIL Version 3 is really important, underpinning to this whole idea.

Gardner: Let's look at the future a little bit,. With cloud-bursting benefits, I can spin up instances of a runtime for an adaption or a dataset, maybe even some network services, telephony, communication services, asynchronous communications, or collaboration. If I can start to do that, I'm going to need to manage this public/private divide somehow.

The catalog drives the right kind of discussion. Once you have that in place, you can start to make changes around what you offer out to the business and, by implication, what you don’t offer.

I wonder what HP is thinking about in terms of how to enable that. As you say, there are some of these aspects going on for years, but this whole notion of the hybrid crossing those boundaries is something a bit fresh.

Perhaps, you can describe what we might expect. I don’t expect to pre-announce products, but functionally what we should expect in terms of managing this hybrid capability.

Lawson: From a top-down approach, we encourage our customers to start immediately working on a service catalog. Because when you have a service catalog, you're forced into the right cultural and political behaviors that allow IT and lines of business to kind of sync up, because you sync up around what’s in the catalog.

It allows you to have that discussion of what’s really important and what’s not important. It also allows you to ferret out where are the squeaky wheels getting attention, but maybe they shouldn’t be. How can we better standardize our offerings? All that happens around the catalog.

So, the catalog drives the right kind of discussion. Once you have that in place, you can start to make changes around what you offer out to the business and, by implication, what you don’t offer. Once you have a services catalog, it might have services from the cloud, some internal services, mainframe services, or whatever., it’s going to be a whole mixed bag.

Control, manage, measure

Then you can start to control, manage, and measure across that hybrid ecosystem with standard IT management tools. For example, if you want to measure the performance and availability of every service -- whether it’s being served up from in-house, you're getting it from a managed service provider, or it’s a cloud service -- you want to have the same performance availability and security metrics on every single service.

Once you're organized, the organizing principle is the technology-enabled service. Then you can be consistent. You can say, "This external email service that we're using is really performing well. Maybe we should look at some other productivity services from that same vendor." You can start to make good decisions based on quantitative information about performance availability and security.

What you can expect to see from HP is continuing along that line of reasoning that says, "What are the right tools that IT can use to have full transparency into all of the elements of an SLA, regardless of where that service comes from, because we know that services are going to come from lots of different types of delivery models, lots of different form factors and technology attributes. And so that consistent transparency from an SLA point of view is really important and you'll see a lot more happening in that area from HP.

When you talk about standardization, it’s not just standardizing on a specific type of server or a specific management tool. It’s really standardizing on how you measure the services.

Gardner: How about you, Bob? You mentioned standardization a couple of times. How do we take standardization across cloud provider boundaries? Is there a neutrality or a certain set of agreements or contracts or de facto standards that need to happen there?

Meyer: Right, we’d go back to something that Rebecca said the about the importance of your internal processes. A lot of people talk about ITIL. They think about change management and change control. All of those elements really talk of standardization. Even the catalog Rebecca was talking about forces standard measurement, so you can really do an apples-to-apples comparison.

When you talk about standardization, it’s not just standardizing on a specific type of server or a specific management tool. It’s really standardizing on how you measure the services. In order to do that, you do need certain fundamentals in place. You need to have a service catalogue. It’s critical.

People are also talking about a configuration management database (CMDB) or a configuration management system (CMS) that holds all that information, so you can get those unified views.

So, yes, it's standardized contracts, but importantly your measurements standardized across whatever you agree that commonality is across the different service sourcing type. You have to come down to an apples-to-apples comparison and make sure that you are measuring and monitoring in the same way so that you can compare the values.

Common measurements

A lot of times, what we see is people have a set of measurements from managed services, another set for the traditional source services, and now even a third way of billing or measuring for virtualized services. You can’t really start to do that comparison, until you get to a common set of measurements and understandings across services. When we talk about standardization, it’s definitely much more than just the standardizing servers, although that’s important, and then standardizing on the storage.

Gardner: Let me drill down on the configuration data comment. It seems to me that moving across cloud service sets -- whether it’s internal, external or both -- many of the underlying services might be standardized or similar. It’s really going to change and be integral to an application activity, a user, or a process, with configuration information about the integration, about the application, the users, access, control, and so forth.

Does it make sense for organizations to get their configuration management act together now, as a precursor to SOA or standardization around virtualization, as a really important necessary step to take advantage of cloud.

Meyer: I wouldn’t want to say that that you have to stop everything you do and re-architect a CMDB that cuts across everything, but hopefully if people have been following and implementing ITIL for the last couple of years, they have a good majority of data.

. . . Then you have to rely on the human factor to pull all that information together into a common report and come up with common measurements and methodologies. That takes time and introduces human error.

Most people, at this point, have a CMDB or a CMS that federates from different data sources. It is important, if you want to measure from the service and you want to understand your options of insourcing/outsourcing, that you have that set of data. If you have it, federate it in the single repository with common measurement. It makes that job much easier and it makes you more agile.

If you don’t, then you have to rely on the human factor to pull all that information together into a common report and come up with common measurements and methodologies. That takes time and introduces human error. It is possible to do without, but that possibility means more expense and more risk, because you are open to non-compliance and lower agility.

Gardner: Rebecca, perhaps you are including this in your discussion about catalog, but let’s just take a quick pause and look at the configuration management issue if you don’t mind.

Change management

Lawson: If you start from the catalog, when somebody makes a selection -- let’s say you choose to on-board an employee -- all of the things that have to happen from that point onwards need to go and hit change management CMDB. The reason you are doing configuration management is to have the service of a change, because every time you make a change, whether it’s pre-approved or it has to go through the change advisory board, you're exposing yourself to something going wrong.

That’s why you want change management as practice, so that you know what configuration items you have. You know why they're important. You know what they're attached to, so that when it is time to make a change, that happens in an organized way and with full transparency.

I sometimes call change and configure "the artery system," because you can’t really do anything, unless you have the whole system well enough managed, so that, when a change happens, if you’ve got full transparency into what occurs, the good, the bad, and the ugly, it’s only then that you can either roll back, measure success, or replicate success by doing successful changes.

Change in config is at the heart of the whole equation. Regardless of this, cloud services are not cloud services. Every time you make a change to your policies about consuming an external service, that should go through change as well, which then hits config. I don’t know if that answered your question.

Gardner: I think it’s an affirmative.

Lawson: Yes.

Gardner: We’ve been learning a little bit more about the road map from virtualization strategies toward more cloud-like benefits, some of the necessary steps, and how things can be looked at with that foresight of, "I'm going to want to do other cloud like activities later."

Helping us sort through this road map to move from virtualization to cloud computing, we have been joined by Rebecca Lawson, director of Worldwide Cloud Marketing at HP. Thank you, Rebecca.

Lawson: Thank you very much, Dana.

Gardner: Also Bob Meyer, worldwide virtualization lead for HP Technology Solutions Group. Thanks again, Bob.

Meyer: Thanks to you.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been enjoying a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Get a free copy of Cloud for Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Transcript of a sponsored BriefingsDirect podcast on what enterprise architects need to consider when moving from virtualization to cloud computing. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

IT Architects Seek to Bridge Gap Between Cloud Vision and Reality

Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on properly developing a roadmap to cloud computing adoption in the enterprise. The popularity of the concepts around cloud computing have caught many IT departments off-guard.

While business and financial leaders have become enamored of the expected economic and agility payoffs from cloud models, IT planners often lack structured plans or even a rudimentary roadmap of how to attain cloud benefits from their current IT environment.

New market data gathered from recent HP workshops on early cloud adoption and data center transformation shows a wide and deep gulf between the desire to leverage cloud method and the ability to dependably deliver or consume cloud-based services.

So, how do those tasked with a cloud strategy proceed? How do they exercise caution and risk reduction, while also showing swift progress toward an "Everything as a Service" world? How do they pick and choose among a burgeoning variety of sourcing options for IT and business services and accurately identify the ones that make the most sense, and which adhere to existing performance, governance and security guidelines?

It's an awful lot to digest. As one recent workshop attendee said, “We're interested in knowing how to build, structure, and document a cloud services portfolio with actual service definitions and specifications.”

Well, here to help us better understand how to begin such a responsible roadmap for a cloud computing adoption we're joined by three experts from HP. Please welcome with me, Ewald Comhaire, global practice manager of Data Center Transformation at HP Technology Services. Welcome, Ewald.

Ewald Comhaire: Hi, Dana.

Gardner: We're also joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio in the HP Technology Services Division. Welcome, Ken.

Ken Hamilton: Thanks. It's great to be here.

Jagger: And, we're also joined by Ian Jagger, worldwide marketing manager for Data Center Services at HP. Welcome, Ian.

Ian Jagger: Hey, Dana. Equally happy to be here.

Gardner: Cloud is an emerging and, frankly, a huge phenomenon driven, I think, by economics and the need for business transformation, as well as new IT service delivery capabilities. I wonder what implications this has for IT leaders. They're in the trenches, so to speak, and they are trying to make cloud happen. Ewald, how are these folks reacting right now?

A new benchmark

Comhaire: Independent of how we define cloud -- and there are obviously lots of definitions out there -- and also independent of what value cloud can bring or what type of cloud services we are discussing, it's very clear that the cloud service providers are basically setting a new benchmark for how IT specific services are delivered to the business.

Whether it's from a scalability, a pay-per-use model, or a flexibility and speed element or whether it's the fact that it can be accessed and delivered anywhere on the network, it clearly creates some kind of pressure on many IT organizations. The pressure really comes from three different angles.

The first one is, whether IT organizations should allow their businesses to consume directly those cloud services without any control by IT. Or, should IT basically build up some, what we call, service brokering capabilities, where they can select the cloud services that are of value to the company. Then, maybe they wrap some additional value around them and then offer those through the business, with IT being basically the broker of these capabilities.

The second pressure is, if you don't want it to be outsourced, should you compete and compare yourself to a cloud service provider and transform your own internal IT operations to function more like an internal type of cloud with the same benchmarks on flexibility, scalability and what have you.

Third, of course, is that you will not have everything in the cloud, and some companies may also

First of all, in the cloud, everything is about the service first, and then the technology will follow the service. That's something that companies will have to think about is.

think about becoming a cloud service provider themselves. This is the third element, if your company requests you to play a role in becoming a cloud service provider. How, as an IT organization, do you support that request coming from the business?

So, all in all, there are quite a few questions that the businesses have about their IT organization, which then lead to our recommendation that the company should think about building out the cloud strategy.

Gardner: I'm curious, Ewald. Is this something new in terms of how they approach the problem or are there some precedents that they can go? Perhaps there are procurement precedents and how they secured partners or vendors in the past, outsourced in the past, or if they've done any work with software as a service (SaaS). Where do they start in terms of looking to the past in order to leapfrog into the future?

Comhaire: There are some things that are unique about the cloud. First of all, in the cloud, everything is about the service first, and then the technology will follow the service. That's something that companies will have to think about.

First, think in terms of the services they want to deliver and then fill in those services with the right technologies that achieve the goals of the service. Some companies may already have quite some expertise there. For example, they may have started to build an internal shared services environment, which may already have that service-oriented thinking behind it, but architecturally their services may not have reached the attribute that a typical cloud service has.

Working on the architecture

These companies will have tremendous benefits on the thinking model, the organizing for a service centric delivery model, but they may need to just work a little bit on the architecture. For example, how can they address scalability and the way that supply and demand are aligned to each other, or maybe how they charge back for some of these services in a more pay-as-you-go way versus an allocation based way.

These companies will already have a big head start. Of course, if you're working on an internal cloud, have things like virtualization in place, have consolidated your environment, as well as putting more service management processes in place around ITIL and service management, this will benefit the company greatly. We'll want to have the cloud strategy rolling out in the near future.

Gardner: Now, I'm aware that HP is doing quite a bit of work around cloud. I wonder what you are finding in the field, as you talk to these customers. Ian, what are some of the top reasons that you are hearing from these folks as they're trying to educate themselves, and grapple with this transition? What are the top reasons that you are seeking to do this in the first place?

Jagger: That's an interesting question, because I think the pressure is coming from two sides. One is from the business side in terms of what cloud means for the business, how a business can become more competitive and take a leading gain within the marketplace in which they operate. From the IT side, there is a required reaction of being proactive about looking at what cloud is all about and how cloud can bring advantage ultimately through the business.

So, there are two thoughts. One is that the business wants to gain a competitive advantage, and two, it is up to IT to do something about that. As Ewald was just saying, it could be that the business is already reaching out to services that are within the cloud and accessing those services. There is an onus on IT for them to keep their own shop in order and become the provider themselves of those services as a service.

Gardner: And, if they're looking for this increased agility, I suppose that also would cut out the need for a lot of upfront capital expenditures. It seems that in a down economy you'd want to be able to be agile, but without having to go through a long budget process and jump through a variety of hoops in order to get the funding. I suppose the pay-as-you-go model makes some sense, now more than ever.

Jagger: That's right, and it certainly does cut out some hurdles. If there are critical applications that you seek for your business, and they're available through the cloud, either from a service provider or through the shared services model that Ewald talked about, that's going to be far more efficient and cost-effective, subject to ... terms of the pay-per-use and security. But, once security is addressed, there are definite cost and efficiency advantages.

Gardner: Ken, we've heard for a number of years about the need for agility, something that's not necessarily new and I am sure won't go away. We'll be hearing about the need for agility 10 or 20 years from now. But, are there any specific business drivers for this interest in cloud, any business outcomes that people most frequently expect to happen as they move toward this model?

Growing interest

Hamilton: As we pointed out, we're seeing a growing interest in cloud specifically around cost savings. Certainly, in this economy, cost savings and switching from a capital-based model to an operational model, with the flexibility that implies, is something that a number of companies are interested in.

But, I'd also like to underscore that, as we've discussed, the definition of cloud and the variety of different, and sometimes confusing possibilities around cloud, are things that customers want to get control of. They want to be able to understand what the full range of benefits might be. The major ones we see right now are underscored by cost savings and financial flexibility in going from a capital-based model to an operational model.

By the same token, we're finding that they're also interested in exploring far-reaching benefits. As Ewald pointed out, some companies who have not traditionally been in the “technology business,” may find that cloud offers them the opportunity to be able to change their business model.

We're dealing with a couple of telecommunications providers, and even some financial institutions in Asia Pacific Japan (APJ), who are looking cloud as an opportunity to be able to expand their market and to be able to take on new capabilities, in addition to some of the economies of scale that come out of this.

In addition to that, we touched on faster time to market and agility. In a typical internal

So, cost savings as well as agility and new business capabilities really are the three main types of benefits that we are seeing customers go after.

environment it may take weeks or months to deploy a server populated in a particular fashion. In that same internal cloud environment that time to market can be as little as hours or minutes, along with some of the increased functionality.

So, cost savings as well as agility and new business capabilities really are the three main types of benefits that we are seeing customers go after.

Gardner: Ken, doesn't this in some ways fundamentally shift the role of IT? It seems, based on what you just said, that IT's role is now about betting on those who are supplying services, perhaps crafting a service-level agreement (SLA) or even getting at the contractual negotiations and then monitoring the quality of those services.

Is that a different role for IT? In the past, they would have simply defined requirements and then delivered the services themselves.

Hamilton: I wouldn't say it's a different role, but rather a greatly enhanced role. IT does procure services today and does a fairly decent job of it. Because of the service orientation, this puts a greater emphasis on understanding not just the technological underpinnings, but the contractual service level elements and the virtual elements that go with this.

A number of implications

As we know, virtualization is a big part of this, but when virtualization comes into play, there are a number of different implications for the service structure, availability, security, risk, and those types of elements. So, there is a greater emphasis today in terms of laying those out, defining them, and procuring the right structure to be able to meet their specific business needs.

Gardner: I suppose their concern, then, is defining the requirements and then measuring the outcome, rather than being concerned what that middle phase would be -- how you actually do it. Is that fair?

Hamilton: Right. If there is a big shift, it's moving from the orientation of a physical infrastructure, dealing with the products, and then delivering that as their service to a grouping of capabilities with service levels, particularly involving external service providers in that level of reliability or acting as an external service provider. So, there is a greater level of expectation on the part of customers for that level of service delivery.

Gardner: Going back to the market data that we've gathered through these HP workshops on cloud adoption and data-center transformation, Ewald, as folks now start to proceed in this direction toward cloud model, recognizing some shifts, looking for those agility and monetary benefits, what's holding them back? What do they say are their top inhibitors from pursuing that?

Comhaire: Dana, that's a very interesting question. We often talk about all the benefits, but obviously, specifically for our enterprise customers, there's also an interesting list of inhibitors. In every workshop that we do, we ask our participants to rank what they believe are the biggest inhibitors, either for themselves to consume cloud services or, if they want to become a provider, what do they believe will be inhibiting their potential customers to acquire or consume the services that they are looking for? Consistently, we see five key themes coming as major inhibitors.

A lot of companies have value chains that they've built, but what if some of the parts of that value chain are in the cloud? Have I lost too much control? Am I too much dependent?

The first one is about the loss of control. That means I am now totally dependent on my cloud-service provider in my value chain. A lot of companies have value chains that they've built, but what if some of the parts of that value chain are in the cloud? Have I lost too much control? Am I too much dependent?

There are some interesting stories that are absolutely real. A satellite service provider, for one of its key component in bringing the television signals to your home, was relying on a cloud service provider that was taken over by one of their competitors to that satellite company.

As a result, suddenly there were interruptions in the service quality and, of course, this leads into the reality that there could be a loss of control if you have parts of your value chain out in the cloud. That's a real concern, not a perceived one.

Also, there is lack of trust in your cloud service provider. That could have to do with the question of whether they'll still be in business five years from now, and will I have to take back control, if they go out of business. We know that this existed in the dot-com world and cost the companies a lot of money by bringing it back in-house when the provider went out of business.

It could also have to do with the things like price-hikes. What guarantees for me, for example, that the price of a CPU per hour wouldn't double, once the provider has achieved a big enough critical mass. They can decide to double the cost at any moment in time.

Security and vulnerability

Another area that's called out frequently is the whole security and vulnerability case. Some of that is perceived. If you architect it well, best-practice cloud-service providers can do a great job of actually being more secure than a traditional enterprise dedicated environment.

But, still, there are some things that are more difficult to control. For example, you become more vulnerable to attacks, when you are on the Internet. A well-known service provider becomes a natural source of all kind of attacks. Of course, that's more difficult to prevent architecturally. It's something you will have to deal with as a cloud service provider, and something that consumers will have to take into account.

There are also difficulties around identity management and all of the things to integrate security between the consumer and the provider that are an additional complexity there.

Confidentiality is the fourth reason and mostly concerning the data, because, more and more, the data goes with the service. What guarantees do we have, for example, that an employee at a service provider can't take that data and sell it to a government or some other third party.

So, this whole reliability concern and disaster recovery is obviously a key element, along with one that comes out more and more in recent workshops: How do I integrate with the cloud?

Also, data has to go over the network. There is always a risk of interception and there is always a risk, if you have a multi-tenant environment, that somehow, through an operation error, some data that should be confidential is exposed to another party. That is definitely a concern for a company.

The final one is reliability -- is the service going to be up enough of the time? Will it be down at moments that are not convenient? I go back to the example of the satellite company. What if the downtime is only five minutes but it's always at 8 p.m., the prime time of satellite television? It may only be five minutes, but it can take you an hour to recover, and it's coming at the most inconvenient moment.

So, this whole reliability concern and disaster recovery is obviously a key element, along with one that comes out more and more in recent workshops: How do I integrate with the cloud?

That is, if I need to make a little change in the business process, with an application in the cloud, can the cloud-service provider make that change? How can I process integration in such a distributed world? That gets a little bit more difficult than in a more traditional enterprise architecture.

Gardner: I hope that a lot of the cloud providers are listening, because it seems like they have quite a workload to overcome some of these issues around security and control. I was a little bit surprised not to hear that issues about standards and neutrality weren't in the top five or six. Do you perceive them as being a little bit lower or do they perhaps fall into these areas of security and confidentiality?

Standards and integration

Comhaire: That's a great question, Dana. They definitely fall in the category of integration, because if the cloud service provider has done everything in a unique way, it's still of great value, a great quality of service, and maybe with a great cost, but it's difficult to integrate the cloud service due to its not following certain standards or being difficult to integrate with the standards that already at the enterprise inside of their data center, then obviously you get this integration difficulty. So, standards and integration difficultly are the same issue expressed in different terms.

Gardner: I wonder if either Ken or Ian has any further points that they've observed in the field about inhibitors. What's holding customers back as they pursue cloud adoption?

Hamilton: I'd just underscore the concerns with security. Particularly in a multi-tenant environment, that seems to be the number one issue that the customers are concerned with. So, first is security, and number two would be reliability. There have been some large failures of some top-named cloud providers. I think they're getting better, but still not quite ready for prime time in some cases.

Gardner: Ian, any thoughts?

Jagger: I'd probably just add to that, not just from the IT side in terms of security, but also from the business side in terms of trade secrets. If you're a provider of cloud services, you know you have that application on there and you have got it out through cloud, which is the great business model you've used to get to market itself. But, how secure are my trade secrets with doing that, and also with respect to addressing to national privacy laws as well. There are some issues that need to be taken into account.

Gardner: Ken, let's go back to you. As customers need to get better informed and to lay out their roadmap, what options do they have? Perhaps you could tell us what would you try to offer them as a way to get started?

But, how secure are my trade secrets with doing that, and also with respect to addressing to national privacy laws as well. There are some issues that need to be taken into account.

Hamilton: Well, the first, and the most important thing, is to make sure that the executive decision makers have a common understanding of what they might want to achieve with cloud. To that end, we've developed a Cloud Discovery Workshop, which is really a way of being able to frame the cloud decision points and to bring the executive decision makers together.

They can have a highly interactive discussion around what key business objectives they might have and what risks and opportunities there might be, many of which we've covered already. It's also to make sure that the organization is crystallized around their specific areas of opportunity and benefit, as well as the specific risks and investments that might be required to focus on this customized view that they have.

This Cloud Discovery Workshop does a great job of engaging the executive team in a very focused amount of time, as little as an afternoon, to be able to walk through the key steps around defining a common definition for their view of cloud. It's not just our view or some other vendor's view, but their definition of cloud and the benefits that they might be able to accrue.

They, specifically drill that down into particular areas with a return on investment (ROI) focus, the infrastructure capabilities that might be required, as well as the service management operational and some of the more esoteric capabilities that go hand in hand, addressing security, privacy, and other areas of risk. It's just making sure that they've got a very clear way of being able to document that, and then move forward into more detailed design, if that's the direction they want to move in.

Gardner: Ewald, you mentioned earlier that those shops that have adopted service performance and IT shared services activities have a bit of a head start, but for them or others? What sort of roadmap process do you offer or recommend?

A better view

Comhaire: From the workshop customers basically get a better view of the strategy they want to go for. We have an initial discussion on the portfolio and we talk also a little bit about the desired state. In the roadmap service, we actually take that to the next level. So we really start off with that desired state.

We have defined the capability model with five levels of capability. We don't want to call it the maturity model, because for every company, the highest maturity isn't necessarily their desired state or their end state. So, it's unfair to name it "maturity." It's more a capability or an implementation model for the cloud. We have five levels of maturity and then six domains of capabilities.

The first thing we determine is an appropriate next state to put as an objective. If you want to become a cloud-service provider, but you haven't done the initial service enabling in your company, you have to go through this intermediate route. You need to say, "First, I will start to build something like an internal shared service that starts bringing technology together and delivering it as a service internally, before I step into the outside market."

So, you first build credibility within your own business, before you actually build credibility in the market. That could be a very logical step on the roadmap. That's Module 1 -- helping customers determine the next desired state on the roadmap and then the end state.

In the case of the cloud, the capacity manager will need to make decisions to acquire new assets to grow the business.

Module 2 is really about, "We know where you want to be now. Let's get more in detail about what projects we need to execute to get to there? What are the gaps? What resources are needed and what skills of resources do you need?"

In the cloud, you may have new roles, like a service delivery manager. The role of a capacity manager is totally different in the cloud than in the non-cloud. In the case of the cloud, the capacity manager will need to make decisions to acquire new assets to grow the business. They can't go to a finance manger. The process would take way too long and the scalability would not be there corresponding to a cloud model.

So, the roles are different. We look at how many people you need, in what roles, with what descriptions and what capabilities. We also look at the timing of what to do when, what the dependencies are of other parts of the organizations, and how to phase that in over a timeline. This is typically what Module 2 is.

Module 3 of the roadmap is then, "We now know where we want to be. We have a good idea of the gaps, the projects that need to be done, the resources, and their skills. How do we sell it to the company and how do we present our conclusion to an executive board or to the executives in the company?"

It's how do we build a business case and how we present that business case financially, value wise, and strategy wise through the corporation. That's really the three components of our roadmap service that then can lead into a cloud design and an implementation activity later on.

Gardner: I imagine of any transformative activity that this is a multi-year process. On that roadmap, do you have any timeline that gives us a rough sense of how quickly these organizations can get to the cloud, or should they not try to rush things?

Keep it simple

Comhaire: One core advice we always give is, "Keep it simple." Rather than bring out a whole portfolio of cloud services, start with one. And, that one service may not have all the functionality that you're dreaming of, but become good at doing a more simplified things faster than trying to overdo it and then end up with a five- or six-year's project, when the whole market will be changed when you can roll out. A lot of the best practice in building the roadmap is to simplify it, so it does not become this four- or five-year project that takes way too long to execute.

Gardner: Well we are just about out of time. I hope we could go around the group and get your impressions on how to get started or any specific areas that people could go to for further information or deeper background. Let's start with you, Ian. Where do people get started, and how should they proceed?

Jagger: I think they should talk to somebody like Ewald. That would be a great start.

But I would probably just like to add, Dana, that what we talked about here is simplifying what cloud is about for the customer, ignoring to an extent how the industry itself is defining cloud definitions. We're looking at this in three ways: do you want to be a service provider, do you want to source cloud, or do you want to build your own shared infrastructure on a private cloud.

And, we've just been talking about roadmap. You actually have the options of being any or all of the above. You can do all three of them. Your business model could be as a cloud service provider. Your sourcing model could be from an outsourcing perspective. What you're not outsourcing, you may actually prefer to build as a shared services internal model.

Keep it simple. Make sure that you've got a very good team understanding of what it is that you want to get done, and leverage experts.

You need to determine what your priorities are. I'm not being facetious when I say talk to Ewald. Ewald's team of guys, are absolutely the correct start point. But your local HP firm sales representative would also be an ideal start.

Gardner: Alright. Ken Hamilton, your ideas about first steps.

Hamilton: I would really underscore what Ian has just said. Keep it simple. Make sure that you've got a very good team understanding of what it is that you want to get done, and leverage experts. We have Ewald and a number of highly qualified people in each of our regions. We just really want to keep it simple, understand what it is that you're trying to get done and leverage the expertise of people who have done it in the past.

Gardner: Quickly back to you, Ewald. I keep hearing the word cloud computing, but if we were to interchange services-oriented architecture (SOA), it would probably just as accurate. Is there a commonalty now between the two?

Comhaire: There have many things in common. I would still argue that there are also some differences. A cloud's architecture will be using an SOA as its underlying fundamental, but the composability of an SOA is not just in how you design the application.

It also has to do with how the services in your cloud can be used together to achieve a bigger integration. That's not just at the level of the application, but it's also the IT services themselves. Are they composable and can they be combined to achieve a bigger thing than just the one service and its value as a standalone item?

Gardner: Thanks so much. We've been discussing some of the ways in which IT organizations and enterprises can move towards cloud and reduce risk, but perhaps accelerate attaining the business benefits of an "Everything as a Service" world. Here to help us with this, we've been joined by Ewald Comhaire, global practice manager, Data Center Transformation at HP Technology Services. Thanks so much, Ewald.

Comhaire: Thanks, Dana.

Gardner: We've also been joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio within HP Technology Services. Thanks to you too, Ken.

Hamilton: Thank you, Dana.

Gardner: And Ian Jagger, worldwide marketing manager for Data Center Services at HP. Thank you, Ian.

Jagger: My pleasure, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.