In the Grid and Service-Oriented Architectures (SOA) community, there seems to be significant discussion about developing charging models for the provisioning of electronic resources (compute and data servers) and services -- examples include European projects such as SORMA and GridEcon -- and various Cloud computing vendors, for instance. Many of these projects utilize the concept of Service Level Agreements (SLAs) as a means to specify electronic contract between single/multiple providers and users. A question that continues to arise at workshops and conferences in this area appears to be identifying the types of SLAs that are really necessary, as many users currently are just happy to accept `Best Effort' services. For instance, although significant research exists about SLAs, those being used by commercial providers, such as Amazon.com for their Simple Storage Service (S3) seem to be very simple (in the case of Amazon.com, the SLA primarily uses Monthly Uptime Percentage based on an Error Rate, as the SLA metric). Similarly, in the SLA research community, there is significant discussion about aspects of negotiation (some of which are quite complex) -- however, when SLAs are being used by data center providers and compute centers (traditional Supercomputing centers), these appear to be mainly paper-based documents that only take account of "customer classes" (in the case of data center providers). One question one needs to ask is the level of complexity that could be (usefully) tolerated by an end user/provider in an SLA. Perhaps, the formula that seems to be recurring in other Internet-based systems also needs to be applied here -- i.e. to keep the technology simple (so that many people can use it), but keep the complexity under the hood (so that there are a suitably rich set of features, and a diverse range of applications can benefit from it). Perhaps, too much complexity is being exposed to the end user -- when, in fact, simple SLAs are what people really want (and need)?
image from http://www.freedigitalphotos.net/
Posts
