Listen to my conversation with Dan Foody, vice president of product management at application infrastructure software vendor Progress Software.
In this podcast, learn about the role of service level agreements (SLA) in the management of cloud services, and find out why investing in SLA infrastructure could become a source of strategic advantage.
Listen to or download the 7:59 minute podcast below:
---Transcript---
PW: Dan, we're talking today about the whole topic of managing SLA — Service Level Agreement — in the cloud, which is something I've been writing and talking to various people about recently. What's your take on the state of the art with SLAs in the cloud arena at the moment?
DF: Well frankly, it's a still very early-stage. Most of the SLAs people are offering are really not SLAs that customers would think of as what they care about. So, the availability of the overall system — as a customer, I don't really care whether the whole system is available, what I care is whether I can use the system or not. And so one of the challenges people have right now is, SLAs are vendor-centric rather than customer-centric. That's the first thing that needs to be changed. It needs to be put into the face of the customer, on an individual customer-by-customer basis.
Well Dan, I think that's — perhaps it's fairer to say that it's technology-centric rather than business-centric or process-centric.
Yeah, or you could even say, inwards-focused versus outward-focused is a better way to think about it.
Because the people who've been negotiating SLAs have been the technologists or the IT buyers, haven't they?
They have been — and it's almost like there have been two extremes of thought. There's the people who have one SLA for everyone, so this is the SLA take it or not. And then there's the other extreme, which is every individual customer gets a unique and custom SLA. Neither of those are very effective business models frankly. People need to get to middle ground between that.
Well, and of course, the cloud — you can't really be a cloud provider if you've got to actually hand-craft SLAs for everybody. But at the same time, the kind of one-size-fits-all model is not satisfactory either in the business or enterprise market, and therefore there needs to be some way of letting people configure an SLA to suit their individual need, but have some kind of automation within it, don't you?
Yeah, either you need to have a Chinese menu of options where you can pick what different parts of the SLA matter to you, or at least a set of predefined SLAs that you can choose from.
Yeah, I think that part of the conversation that I've been having is that, well, that's fine if you know what you are going to want and if it's never going to change. But of course the cloud is an on-demand environment and shouldn't there be the potential for the SLA to be on-demand, i.e., that people should have the ability to be able to have different SLAs at different times of year, or different times of day, or for different parts of the application stack?
Yeah absolutely. I think the best way to think about it is, just like you may price per user, you should price per SLA as well. So if someone wants a higher-level SLA, you should allow them to switch it on immediately, but it isn't necessarily going to be free. That may be an added option, depending on what level of SLA they want at that point in time.
Yeah. And do you think that there is the potential for people to be able to have SLAs that vary in a cyclical way or in response to demand?
Well, I think the way to think of it is almost in reverse, which is that the SLA should be what level you want — [that] someone needs. The demand should trigger how you behave being different. But the SLA — as a customer of a service, I don't really care what the demand level is, I still want three-second response time, for example. So the SLA should be a driver.
I think in a sense, it probably is, because we all — and I've just been guilty of this — we use the term very loosely. And when we talk about the SLA, we don't actually mean the SLA. We talk about the policy framework, within which we want to consume the services.
And so I suppose what I'm arguing for is, having a service level agreement that has got a number of different options in it that can be switched according to certain policies coming into effect. For someone who's got an e-commerce site, for example, if it's December then you actually want more capacity and more availability than perhaps you're going to ask for in March.
Yeah, I mean you can think of an SLA as a give and take, which is, if I'm going to have ten thousand versus ten million requests hitting every day, what level of responsiveness are we going to get out of that? So there's the trade-off in terms of how much load are you going put on, versus what guarantees do you want. And the more load, either the lower the guarantees you get; or the higher cost it'll be to provide those higher guarantees, typically.
Right, right, yes. And those are the sorts of decisions that people might have different answers to at different times of the year, or different times of the day, or different applications.
Yeah, and I think where it really gets interesting, though, is when you go beyond the granularity of, every transaction is the same. So as an e-commerce vendor, not all of my customers have the same value to them. Some make million-dollar orders; others make one-dollar orders. If I'm an e-commerce vendor and I'm leveraging a SaaS or PaaS platform, I actually may want to have, on a transaction-by-transaction basis, different service levels for those. Because to me they have different value, those individual transactions.
Yes, yes. And of course, the other factor here is whether there's some kind of arbitrage that you can do as a consumer of services to perhaps be able to bring in external services at certain times or for certain functions — again, governed by some kind of policy framework or SLA definition.
Yeah, absolutely. It may be that you say, if I can get the service for less than $10 a CPU minute, or whatever your pricing metric is, then I'm going to put load on it, or I may switch between different providers if they've got extra capacity and they're offering a special at that point in time. So the more dynamic you can get, the more you take advantage of arbitrage opportunities. And fundamentally, that's about optimizing your own costs.
So — but there's a cost also in having all of that instrumentation and in having the automation that will then implement those policies on the fly. Does the technology exist to — all this theory we've just been talking about — is the technology there today that can actually make it happen at a reasonable cost?
So, there are definitely technologies that let you do it. I wouldn't say there's a cohesive technology to solve all the problems in one. But there are technologies that let you look at and manage your SLAs on a consumer-by-consumer basis. And if you're getting close to your SLAs, trigger automated activities like adding more capacity. Those kind of technologies exist.
On the other extreme, if you look at the, 'I want to move my computing from one location to another,' there's technologies to help with that, things like caching infrastructures and grid infrastructures help you with that. What people haven't done today yet is really connect those two together seamlessly.
So it's still a work in progress, but a lot of potential there that people can tap, that perhaps hasn't been explored as fully as might be at the moment?
Absolutely. And I think there's — at this point in time, there's almost a strategic advantage someone can gain by taking advantage of SLAs. As with any technology in its infancy, when the pieces are there but they're not integrated, the first mover who can bring those pieces together for their own customers can actually get an advantage over their competitors. So there is an opportunity for a lot of organizations to take a lead in here.
Well, that's an interesting note to finish on.
Listen to my earlier podcast with Dan Foody on How to Mashup the Cloud Without Glitches, recorded in March 2009.
Leave a comment