If you asked ten random techies to define "cloud computing," you might get twelve or thirteen different answers, but if instead you asked those same ten folks to identify the most overused buzzword of the last year, they'd probably all agree that "cloud computing" was it. Truly, "the cloud" is aptly named, because everyone who stares at the concept sees something a little different. So imagine my surprise when, on attending a session at this past summer's AlwaysOn conference, I heard someone on the stage talk intelligently, coherently, and technically about a topic that I had written off as so much noise.
That person was HP's Russ Daniels, CTO and VP of Cloud Services Strategy, and by the time his panel was done, I knew that I had to talk to him in more detail about cloud computing. I managed to land an interview with him a few weeks ago, and it was so good that I've reproduced it (in slightly edited form) in this article. The interview is extremely substantial, so if you're at all interested in the cloud—especially if you're a skeptic—I urge you to dive in.
This interview (see Part I for the first half) actually altered the way I thought about the cloud and about software delivery in a networked world. I hope that you find it as illuminating as I did.
Mobile devices as "sensors" for the cloud
RD: Let me give you another example that describes the expressiveness of the cloud and the role that devices play. We tend to think of devices too narrowly. I do a fair amount of business travel, and every now and then I'm lucky enough to be on a plane where I have a screen and I can watch a movie. But, a common occurrence is that the flight crew comes on the PA and announces that we're landing, so they shut down the entertainment system with ten or fifteen minutes left in the movie. Consequently, I have a surprising number of movies that I've seen most, but not all of.
Think about that problem, and then imagine that you go into your hotel room, turn on your entertainment system and it asks if you'd like to continue the movie that was interrupted in your flight. To do that, it's just a matter of propagating a small amount of state—the airline knew who was in the seat, they know what channel was being watched on the entertainment system and they know what frame the movie was interrupted on. That little bit of state can be propagated up to a profile that's associated with me, the passenger.
When I check into my hotel, I can provide access to that profile for the aspects of the profile that I think are relevant to the hotel, and that provides them with the opportunity to offer me that surprise of being able to finish watching the movie.
I didn't own the device in the airplane; I don't own the device in the hotel. By expanding our thinking about what Internet-capable devices ought to be, aside from the notebooks or phones, we are able to include anything that has the ability to be technology-enabled. These cloud-enabled devices can play a role in understanding what you're doing, offering you assistance and improving the experience that you have doing it.
Devices increasingly become important not only as user experiences, but also as sensors. One of the great things about a cell phone is that it has the ability to generate event streams relevant to what I'm doing—the hotspots that I go by, all of that kind of stuff. When you accumulate those streams, you can then do analytics to start to identify my defaults, my preferences. You can notice patterns of behavior that suggest when I do one thing, there's a pretty high probability that I'm going to do this other thing.
All this means that technologies can start to identify your intentions, rather than you having to map between what you want to do and how technology can help you—and, then, of course, forgetting the fact that you spent a lot of time coaxing the technology to go along.
Ultimately, the cloud creates a fundamental opportunity to approach user experience in a much different way.
Selling the cloud vs. selling clouds
JS: I want to go back to the four components of cloud computing that you mentioned. First, I have more of an observation than a question: this flexibility and granularity that cloud computing gives you in remapping resources seems to be related to #4 in your list—"the variable cost model related to delivery"—in the sense that they're almost the same thing. You can vary the cost of delivery precisely because you have this flexibility to do a fine-grained pairing of a set of resources with demand.
There will be a small number of customers that will have their entire infrastructure delivered as a service, but the vast majority of our customers will continue using data centers, servers, storage, and networks.
So my question is, you guys want to rent this out as a business, but you also sell the hardware that people can use to do this for themselves. So on the one hand, you're renting out this capacity... In your announcement for your HP Adaptive Infrastructure as a Service product, you said: "With HP AIaaS, customers can realize improved service levels and convert traditional capital investment into an ongoing operating expense because all assets are owned and managed by HP."
But you guys are selling that capital that enterprise customers would've invested in, so do you guys see yourselves moving in this services direction? Is there a tension with enterprise customers between leasing the service vs. running it in-house, or are you trying to sell both?
RD: The IT function in an enterprise has the responsibility for sourcing and delivering services that a business needs. Gartner describes this as an "enterprise-class problem," which means that IT only has to solve this for its own enterprise, not for everybody. But if you think about a service provider, they're providing services to many customers; Gartner calls that a "global-class problem." The problems are different, but that doesn't mean that they're simpler on one side or the other.
The IT function has to do with what the business needs, so they can't simply say, "No, that can't be done, we're not going to do it. Do without." The service provider can say "no." They can say, "Here's what we do—if you want something else then you can go to a different service provider." So that's different, and the cost structures are different too.
The enterprise IT function tends to have to deal with more complex environments and legacy systems, but again, they only have to solve the problem for one customer. Think about something like an infrastructure utility—how do I take advantage of virtualization and automation to deliver IT capacity at a lower cost? If you're the IT function, you want to build an infrastructure utility that you can use for your own purposes. We've been helping our customers with that for years.
HP has a lot of intellectual property in our software, enterprise server and storage businesses. We have servers, storage, and networking technologies that have been designed for this style of delivery. We have consulting services to help our customers with that. So, there's a lot of work that we do to help our customers build an infrastructure utility today. The direction that we're driving in that space is to make it more and more of a turnkey solution because, while you can do it today, there's some assembly required. We want to make it easier for customers to have their own infrastructure utility.
A service provider, similarly, wants to build an infrastructure utility, but they want to deliver infrastructure as a service to IT customers, and they need to support multiple customers. Consequently, they have different needs. Service providers have to be able to deal with issues of multi-tenancy: how do they make the tradeoffs between isolation of workloads vs. the cost and integration that they can get across their full infrastructure. The key thing to keep in mind is, if the IT function builds its own infrastructure utility, it has fixed costs: it owns the assets, it owns the data center, it has to do the power and cooling, it has to do the operations, and those are all fixed costs. It might be able to reflect those costs variably to the business, but for the IT function they're fixed.
Similarly the service provider can provide variable costs to their customers, and from their internal perspective, costs are fixed—they own the gear, they own the data centers, etc. Whenever you think about these things, you have to make the distinction between whether you're playing the provider role or the consumer role, because the dynamic changes in each case.
RD: HP does offer today various infrastructure as service offerings. These are focused on the enterprise, so we spend more time addressing key requirements that enterprises have around security, give them more control of the deployed architecture, and that all comes at a cost: it's a little less automated than the way we could deliver them; they pay more than they would have to pay for having an hour of a virtualized Linux container.
The types of infrastructural services that can be delivered vary based on how much control you have, what the basis for the billing is, the type of relationship you have and whether you can customize it.
Ultimately, we believe that long-term customers will operate in a hybrid environment. There will be a small number of customers that will have their entire infrastructure delivered as a service, but the vast majority of our customers will continue using data centers, servers, storage, and networks. These customers have essential operations running in those environments that are critical to them, and they need to be able to deliver it to the business.
So this idea that the end of IT is just around the corner—we think it's unlikely.
What's also true is that we have a lot of business selling to the service providers; we have specialized hardware products, servers, storage, and networking technologies designed to address the particular needs of a service provider who's trying to operate in a global-class environment. We also have more innovations in the pipeline.
Ultimately, you need to understand the relationship between the consumer and the provider as one of trying to balance risk.
Again, a lot of things that we do in our research group are focused on improving the results that each of these potential customers realize. This research determines how we help the service providers meet the much larger scale that they have to deal with, and how we provide the higher levels of automation that they need. It also helps us approach issues of multi-tenancy and how they can provide the right kind of security isolation. For example, we have a project called Cells as a Service, focused on creating secure isolation in a virtualized space that spans all the way from the client to the back room systems.
We also have lots of research taking place in areas such as exascale computing, where we want to be able to build systems that can scale to much larger than what's delivered today: lower power utilization, faster interconnects, photonics, etc.
Another thing to point out is that HP offers Internet services today. We have sites such as Snapfish, for photo sharing, Upline, a consumer backup cloud service, and other Internet-facing services that need that same global-class kind of infrastructure.
JS: Yeah, that answers my question. I was thinking of things in overly simplistic terms, as in, if a company needs X amount of capacity, but they buy X + 5 from you to overprovision, then that difference is more money for you guys. But if you're giving that up by giving them the ability to buy exactly X when they need it, and X + 5 when they have a spike in demand... Then, well, it's in your interest when they overprovision.
RD: We don't really think so. It turns out that one of the worst ways to build a business is to sell people stuff that they don't need, because the repeat business isn't all that great.
The reality is that systems tend to be overprovisioned, not because we have business models that are based on selling them that, but it's the result of a deeper reflection of the architectures that have evolved in the traditional IT space. We've created some very complex applications that are very sensitive to the configuration in which they run. Because of the role that those applications play in the business, if they aren't running, the business loses money.
Those kinds of issues cause you to be quite willing to have extra headroom, because it's a risk arbitrage.
It isn't that we're making money because we sold them too much. They bought the amount they needed because the risk of it not working was so great that it makes sense for them to have excess capacity.
I will say that when you think about the difference between building infrastructure and running it yourself vs. having someone else run it for you, it's not always a matter of it being cheaper. This idea of having an infrastructure utility or buying infrastructure as a service doesn't always translate into lower cost. That's one of the key things you might be concerned about, but there are others.
It can be things like knowing that you have a way to handle periodic workloads in a way that meets the business demand. If you think about the price you pay per computation, it might be higher than if you had bought that capacity and used it regularly as a steady state, it's just that that's not what you need. So you're willing effectively to pay a premium for using it a shorter period of time.
It's like renting a car. I commute back and forth from San Francisco on a train, and I used to keep a car here so that I could commute to Cupertino when I needed to, but it's really quite expensive, so I started using ZipCar. Now if I need to go to Cupertino I can arrange to rent a car for three hours and pay $8 an hour, but if you compare that to what it would cost me to have a car fulltime, it's cheap.
Ultimately, you need to understand the relationship between the consumer and the provider as one of trying to balance risk. There are different ways that the provider can charge you for what you use, and the differences end up balancing who takes what kinds of risks. If I charge you for the hours that you have a system accessible to you, then I'm not taking any responsibility for whether or not those systems are being utilized —it's just you had access for six hours, you pay me six hours times the fee.
This is a different model than if I charge you based on the number of compute cycles you consumed (or how much storage, or how much bandwidth), which is a pure utilization model. When I think about how to price this, certain kinds of pricing models mean that I have to start bundling more costs with those things than just the direct cost, in order to decrease the risk that I have with other parts of my business. So it's just balance back and forth.
If you buy a perpetual software license, you're taking the risk that that license will pay off to you over time. If you pay a subscription fee, you don't take that risk, but you might pay more per seat (per month per user) as a result, because you've shifted the risk to the provider—you can leave at any time, so the provider has to think about how they manage the cost that they have associated with a license.
JS: And in today's environment, you have to think about what happens if the provider goes under, and you all of the sudden don't have access to the services, which is a discussion that lots of people are having right now.
RD: It's a huge one, and I spend a lot of time talking to enterprises, and the reality is that the IT function needs to source and deliver services appropriately, so they have to think about things like data portability: can I get the information back out if I need to move? If I get it out, is it in a form that I can reuse?
In the same way that if you use one particular application and your data gets stored in a form that's usable by that application, if you want to change applications your data might have to go through a transformation, which might be expensive. If you're using an external service provider, those same kinds of concerns are there.
That's why, if you're going to be a service provider to the enterprise, you have to think of many classes of services that might make sense to meet the varying needs of the market you intend to serve.
No comments:
Post a Comment