Independent of the drama accompanying the news report and the ping-pong of responses, from the last act and the official confirmation from Lilly it appears that there was a requirement indeed for Amazon to provide guarantees and accept legal responsibility, to an extent further than what it currently provides.

The thing is that current cloud computing SLAs and their “take it or leave it” approach do not fit a world where business value is not uniform across all different data sets and workloads. Hard as it may be to argue that this stopped cloud computing from becoming a very successful paradigm already, it remains true that such requirements for liability in business partnerships remain. Automated or not, SLAs must become customizable if cloud computing is to be taken to the next level. Corporations (and especially the larger ones) need someone to blame when things go wrong — it is how the system has been working for ever.

Amazon made a step towards custom service level, by means of its Auto Scaling feature. Yet, this is marketed as a product, not as an adjustment mechanism for SLAs (naturally, given the single static EC2 SLA). Also, noone knows (or I could not find information) what happens if for any reason the automatic scaling fails. If it’s a product, shouldn’t it be tagged with some SLA itself?

It is a pity, because with this mechanism already available, the only remaining step towards custom SLAs is a meaningful and realistic penalty model that is not restricted to service credit. My assumption is that if some cloud service providers step up to the challenge, their customers and the market in general will reward them graciously.

But this post is related to the first comment of that post:

But, a step in the right direction, before we get to flexible SLA’s, is to get transparency from the cloud providers – cloud providers should be able to tell any customer whether, how, and when their individual SLA was breached. Transparency is an essential component of effective SLAs.

One idea I had about this is to make it very expensive for the provider to lie and get caught. You may call that quadratic penalty if you wish; the idea is that for all guarantees the penalties would be reasonable — whatever “reasonable” is according to the customer’s business values. Then, the SLA would also include a term to say that, if there is a violation (which can be proved by the customer) and the next service report does not include it, the provider would have to pay a significant penalty. This would provide incentive to providers to be honest, and customers would feel more secure that they get the facts. It is my uneducated assumption that customers would also be willing to pay more for such SLAs.

So what exactly is an SLA? It’s an instrument that makes business people comfortable, much like insurance. But in broader, less anxious terms, an SLA is a metric that defines how a service should operate within agreed-upon boundaries. It puts some financial muscle into the metric by establishing a schedule of credits for meeting goals, or possibly penalties if the service does not achieve them.

I found interesting both the simplicity of this informal definition, and the straightforward message it conveys. About the book, although still at the beginning of it, I find it both interesting and well-written.

Our SLA is fairly simple (and I’m happy to write it up for you in more official language):

• We can’t control data publishers’ availability, but if they’re up, we’ll get the data.
• Machines and clouds fail, even on EC2. If Amazon is up, we’ll get the data.
• The best way to guard against machine failure is duplicate hardware. We offer highly discounted backup boxes.
• You’ll always have my cell phone number — if our software breaks, you can call me 24/7 and I’ll get my team on it.
• If we aren’t living up to our end of the relationship, you can cancel the contract with no penalty.

This was actually the response of Gnip‘s CEO to a customer who asked what’s their SLA.

I find it an interesting approach, as it makes more apparent the direct relationship between the customer and the service provider, and builds on trust and good will. So there’s certainly a lot value to it in smaller setups. Nevertheless, I can’t see how could anyone use that successfully with critical services, e.g. investment banking. At the end of the day, if Amazon’s EC2 fails, and you (as a service provider) rely on it, it’s not your customer’s problem — he signed a contract with you, not Amazon.

This is just to say, strict SLAs may not be necessary in simpler cases, but for those kinds of services that make the world go around, it’s hard to do without them.

It appears that cloud providers are becoming aware of the necessity of such guarantees for mission-critical services and are designing their infrastructure accordingly. Amazon EC2, the golden standard of Infrastructure-as-a-Service, is offering 99.95% availability throughout the service year. I consider that to be quite high as well.

What I’m wondering about, is the effect of one-fits-all SLAs on implementation costs. That is, I am presuming some significant cost with resource duplication, server co-location as a constraint, and the like. What would costs be like, if someone would offer low standard QoS at extremely low cost, and then increase costs as requested QoS increases? If my application is such that it can deal with 99% availability, or with latency up to 100ms for example, why not take advantage of that and pay a lower subscription? Providers could do that without much complexity, by proper slicing of their infrastructure, and differentiated service offerings as such. A suitable brokering algorithm could then deal with assigning provisioning requests to the proper slice. Operational costs would become lower for low-QoS services, and the customers would be able to take advantage of that.

This is especially important in legacy platforms, which are doing things such as load-balancing anyway, taking into account current-time availability conditions. One such example is the recent trend to run grids on clouds (see StratusLab as an example). Driving down costs could be a game-changing factor for many potential cloud computing adopters — much like is the offering of 100% availability guarantees for others.

A Service Level Agreement (SLA) is a representation of all those features that a user should expect to receive by a service. By features here we refer not only to the functionality delivered by the service, but also to the quality that the user experiences. As a matter of fact, SLAs are typically associated with Quality of Service (QoS), but in a formal representation it is reasonably expected to find the service description as well.

Given the definition above, SLAs may be represented in various ways; SLA@SOI considers only their electronic representation for purposes of automated management by means of machine-readable documents. In a direct analogy with contracts as known from traditional business, we commonly refer to SLAs in our context as electronic contracts. As a consequence of this analogy, the following important questions come up:

• What are the legal implications of electronic contracts, when it is software that is making the decisions?
• What is the language that an electronic contract is written?
• How is electronic contract negotiation happening?
• How can the terms of the contract be expressed in uniform, commonly understood ways?

With regard to legal implications, it is clear that machines and software cannot be held accountable in the case of penalties, or more severe breach of contract. Therefore, it is commonly accepted that a formal (non-electronic) contract negotiated between humans needs to be in place, governing all automated interactions between software entities. This contract will have to define what are the purposes of the automated SLAs, the capabilities and administrative boundaries of the negotiating software entities, acceptable terms and penalties, and in general all those business and technical characteristics that apply to the automated interactions. Therefore, a framework contract must be in place to reflect accountability and responsibilities of involved business parties.

This contract will probably have to also define the language in which SLAs are negotiated and established. Just like typical business contracts which may be written in English, German, French or any other language, electronic contracts have to be expressed unambiguously in a commonly agreed machine-readable language. A few efforts on this front have taken place in the past, such as WSLA [1] and SLAng [2], but the only standardised such language which is also actively maintained, is WS-Agreement [3]. WS-Agreement is developed by the Open Grid Forum’s [4] GRAAP Working Group [5]. It defines the necessary building blocks for establishing a contract, currently in the form of a single-round negotiation without counter-offers: One party makes an offer, and the other party simply accepts or rejects it.

Although currently not a part of the standardised protocol, multi-round negotiation is in the works and will be made available soon in an amendment of the standard. This extension is a simple series of agreement template exchanges, each template defining candidate terms to be agreed and the acceptable ranges for these terms. When both involved parties agree on a template, then an offer is made by one of the two parties. Renegotiation is still not addressed but will probably take the same form.

Having defined in complete a signalling protocol for the establishment of SLAs, the question of proper definitions for terms comes up. WS-Agreement does not go into this area, which is domain-specific and cannot be addressed uniformly except for specific common definitions for terms such as cost/price, re-negotiation policies, etc. Therefore, domain-specific languages have to be agreed and implemented by WS-Agreement users, or existing languages can be reused. For instance, infrastructure provisioning requests may be addressed by embedding OVF [6] requests in WS-Agreement offers; for Grid storage reservations, SRM [7] can be used as a term language; for job submission, JSDL [8] is a typical candidate. WS-Agreement’s extensible characteristics allow the inclusion of any language deemed appropriate.

[1] http://www.research.ibm.com/wsla/
[2] http://doi.ieeecomputersociety.org/10.1109/FTDCS.2003.1204317
[3] http://www.ogf.org/documents/GFD.107.pdf
[4] http://www.ogf.org/
[5] https://forge.gridforum.org/projects/graap-wg
[6] http://en.wikipedia.org/wiki/Open_Virtualization_Format
[7] http://en.wikipedia.org/wiki/Storage_Resource_Manager
[8] http://www.gridforum.org/documents/GFD.56.pdf