The Connected Web

Listen to my conversation with Eddie Budgen, vice president of technology services at Sensible Cloud, which helps enterprises implement business-driven service level agreements for cloud computing.

In this podcast, find out how cloud computing is changing the context of service level agreements and learn why SLAs will have to evolve to give businesses better control of the day-to-day cost and performance of the cloud resources they use.

Listen to or download the 8:21 minute podcast below:

Download file

---Transcript---

PW: Eddie, in the past, service level agreements have been all about feeds and speeds — the classic hosting or telecoms kind of environment. I gather that doesn't work so well in cloud computing. Why is that?

EB: I think that's primarily to do with how the service levels have been defined, mostly by IT, in technical aspects. In an environment where they had purchased all of the pieces, they were managing, at a very granular level, all of the very complex technical aspects, which had been obviously part of their value — that they could do what they needed to do.

And part of the value proposition of clouds, where in fact you convert into more granular-level services that are offered through potentially different distribution channels, the Internet being a key one, where you don't actually need to worry, as a consumer, about the technical complexities of what you're consuming. But you have potentially more business-oriented aspects; you may be involved in a pay-as-you-go or a pay-as-you-use type model.

In fact, as a consumer of any type of cloud service, be it a software-as-a-service, or a platform-as-a-service, or an infrastructure-as-a-service, you're going to be more interested in some transparency of how the service is providing at a macro level and how much it's costing you. In the previous versions, that was kind of at a black-hole IT box.

Right. Okay. So basically, because the customer is not buying the infrastructure components any more — the technology is being taken care of by the provider — the service level agreement doesn't have to be down at that technology level anymore. And to some extent, it's perhaps even a mistake for customers to want it to be. Because they need to be more interested in — well, what sorts of things, then? — what are the business-level considerations that come into play in cloud computing?

I think the primary — I consider it a business level consideration — is security. Where consumers were comfortable — they thought they were comfortable — in security management within their own managed enterprise, their own managed data center — and it came with a cost, which most businesses were not aware of. As that's moved in some cases in a mixed environment, removed out of your own site, you're more focused on, 'Well, if I'm not in control of that, I need to put some service agreement behind it. I need to understand that I am still protected as I thought I was before.'

So we're talking about monitoring, I don't know, [that] there's a certain level of threat protection and that it's operating?

Correct.

So things that you might build into the contract as static considerations start to be things that you want to monitor?

Yes, exactly. Security will probably be the number one that certainly most CIOs will tell you about in all of the various polls that we see from the analysts and so forth. But then you move into other more granular agreements, to do with governance and compliance. And included in that, depending on your priority, is also a heavy view of the cost that you're actually employing. If cloud computing is offering us, in some cases, a drastically different cost model — I might be moving from CapEx to OpEx; I'm going to want to have — if that's a driver for me having done cloud computing — then I'm probably going to want to have a clearer view of how much I'm spending — against which elements of my business portfolio that I'm running over the cloud.

So you're talking about monitoring for things like value for money, quality of service, how quickly transactions are turning around for users, for example.

Actually, I suppose the other thing here is that, yes, of course, you're monitoring for reliability, but perhaps also you might want to, say, put some applications onto less reliable services, because actually they're not so important. You don't need to be paying top-whack five-nines every time.

I believe that's one of the strongest motivations for a comprehensive move across to cloud platforms. It's not an all or nothing. As you start to look at your portfolio, there may be some performance or security considerations that are just completely show-stoppers that you'll never move out — and that's going to be true on an ongoing basis for a long time. But then looking at the rest of the portfolio, you get an opportunity to, if you like, to rate and prioritize your own business applications and the value they provide, and the compliance you need to offer — and therefore, within that, service levels that you require to maintain the front-facing service level to your customer, or your consumer, or your internal user.

So yes, I strongly believe that you'll be able to prioritize, and should be looking at, granular service level agreements with the cloud services that you employ, even from the same vendor, if you can get it.

But Eddie isn't this getting — this is getting very complicated now. This is just going through my head that, okay, you've got some applications that you say, 'Well, that's okay on 99.7% availability services, but I've got other applications that I need 99.97%. And these customers, please don't send their data to a service in the US because they're in Germany and that's not allowed; and these particular transactions, don't let the response times slip below X.'

All of those different considerations could be service level agreement factors; but how on earth do you write rules that will monitor all of that in a way that actually can make sense down in the infrastructure itself?

That's one of the biggest issues the SLAs and the evolutions in the SLAs in the cloud will undergo. One of the prime factors that you'll need to consider — and this is different than most previous IT-based SLA environments. You will need to provide some level of automation and software that can monitor the things that you care about around each of those aspects: around a group of customers, around a group of data types that aren't allowed to move away from a particular region, from the EU to the US, as you've mentioned. If you had to articulate that in a contract, then the contract would be huge. And if you didn't have a way to organize how those SLAs are mapped into, and decomposed, and positioned close to the pieces of the cloud technology, or your internal infrastructure, and the application itself — yes, it's going to be a struggle.

One of the interesting projects that's happening in the European Union right now is actually a funded research project from the EU called SLA@SOI. And their overarching goal is to provide a blueprint of how to bring different types of SLA from a business perspective and to break them down into elements of both architecture and technical infrastructure where they'll be mapped to something that's meaningful to that level. Because as you said, an SLA that's at 99.9% at one level might break down to be something else at another level. So I think that one of the ones that we're watching most closely in terms of providing a blueprint so that we don't all make it up ourselves, which has happened many times before, is this SLA@SOI project.

Right. But of course, that's at a research and development level. Are there people actually doing this kind of thing at the moment in their cloud deployments today?

Yes. We are finding prospects who are actively wanting to add value to services — that are pretty basic from a cloud perspective — to allow them to either provide a higher level of business service that is just inherent in their offering, or to in fact increase their margin, because they could distinguish between a baseline service and a higher level service.

So as cloud services — and again, be they software-as-a-service components [such as] a Salesforce type transaction; be they platform-as-a-service, where you might be interacting with a custom application running in Google Apps; or they be infrastructure, where you might be, on a part-time basis, renting capacity from a Microsoft or from Amazon — we're seeing people begin to experiment by placing SLAs at the right level around prioritized applications, but then automatically tweak and balance how resources are aligned. And in some cases, act as a gateway, or a gate stopper, to not allow certain pieces of application requests to be sent offshore, as you said; a general request of, some data will never be placed against anything in the US, for example.

Well, that sounds as though this is a field that's going to become more and more important in the future. So thanks Eddie for coming on today, giving us a brief insight into what's happening there.