NOT this SLA 
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…
(Cross-posted @ Software as Services Blog RSS | ZDNet)
