Every time I get into a discussion about security and trust in cloud computing these days, I end up talking about service level agreements. People considering cloud computing rightly worry about whether their data is going to be secure, and private, and accessible when they need it. The umbrella term they use for that is ’security’, but their worries encompass a broad range of performance, security, privacy, operational and cost criteria. That’s why I end up talking about SLAs — the contracts that govern the provider’s commitment to meet all those various criteria. It turns out that, once you drill down into what people really want, the answer is much more granular and textured than a single metric about security, privacy, or whatever. We’re actually talking about a framework for governance across a broad range of policy settings.
The discussion then rapidly leads into the realization that service levels as they’ve traditionally been defined and measured aren’t fit for purpose in this new environment. SLAs, like everything else in the classic IT realm, have been designed on the assumption of a one-off, upfront determination of a set of static requirements that will remain the same throughout the lifetime of the contract. To make matters worse, those requirements are defined in terms of the technology infrastructure, specifying feeds and speeds for engine-room components that may in the end have very little relevance to the ability to conform to business policy objectives.
These fixed SLAs are out of kilter with the dynamic, elastic nature of the cloud environment. If the cloud is all about delivering IT on demand, then why can’t the service levels be on-demand, too? “You don’t need to be paying top-whack five-nines every time,” I opined in discussion the other day with Eddie Budgen, VP of technology services at Sensible Cloud, a start-up that specializes in business-driven SLAs for cloud computing. While some applications are so mission critical that anything less than five-nines reliability is out of the question, others can get by with much lower levels of continuous uptime. There may be differential requirements for other criteria, ranging from security and privacy to response times, and they can vary not only by application but also by user, by geography or by date and time of day.
The trouble is, such dynamic SLAs are only possible with automation. A traditional SLA will set static limits, and then the provider or the customer (often both independently) can program their monitoring tools to send out alerts as those limits get close. But if the limits are constantly changing in response to an array of interlocking policies, the monitoring tools have to be constantly reprogrammed to react to those changes. That level of responsiveness rules out manual processes in favor of configurable automation.
The infrastructure has to be flexible enough to respond to those policy changes, too, if we want an application to ramp up and down along a variable cost-availability matrix. At present, cloud providers don’t offer much in the way of service level choice — many of them even avoid specifying any SLAs at all. In a discussion at a CompTIA workshop at last week’s Cloud World Forum in London, one speaker said that cloud computing is bringing the disciplines of assembly line manufacturing to IT, but my response was that it’s still a primitive process in which the customer gets, in Henry Ford’s words, “any color … so long as it is black.”
At present, the only way to change your cloud computing service levels is to move from one cloud provider to another. Without interoperability standards and a common language to describe service levels, that’s a custom process that’s hard to automate. Nor is it in the interests of providers to rush to create standards that make it easier for customers to shop around for cloud services on the fly. Yet customers will want that flexibility and so it’s only a matter of time before providers start to offer enough visibility and control to give them real choice over service levels — at first on a proprietary basis within individual cloud infrastructures, and later on across multiple clouds, as standards gradually evolve.
Much of this is still at a research stage — there’s an EU sponsored program called SLA@SOI that’s looking into some of the technologies that may be required. In the meantime, customers of cloud computing are pretty much stuck with paper contracts and fixed SLAs (and often a struggle to get satisfaction even at that level). But next time you’re wondering what security guarantees you should be asking your cloud provider for, just remember there may be one or two other policy criteria you should be worrying about too.
