Traditionally, a formal service agreement involves the creation of a legal contract with the associated costs. Those costs can be amortised across a service’s consumers so long as the agreement is sufficiently generic to suit all. However, requiring consumers to sign up to (or tick box) a legal document has two distinct disadvantages. Firstly the terms of the contract are difficult to interpret at run-time and therefore it may impossible for either consumer or provider to effectively monitor the service to ensure it is behaving as the agreement promised. Secondly, legal documents are time-consuming and expensive to vary. However, variation of service agreements is vital not only in order to provide consumers with choice but will also be required in order to allow for change over time.
As an example of the later requirement, let’s imagine a provider offering a service agreement which is initially suitable for some consumer. However, given that change is inevitable, what happens when the required quality of service changes, perhaps because the importance of the service to the consumer increases (or declines), or the data security needs change, etc. The change may even concern some aspect of the service not previously considered in the original agreement. Does the consumer have to move to a different service provider (one able to satisfy the new required quality of service) or do they have to manually renegotiate a new quality of service from the provider? Doesn’t this sound somewhat inflexible, undynamic and uncloud-like?
What is actually required is the ability to capture quality of service requirements and to modify those dynamically. The cloud can then respond to any changes e.g. by reassigning resources, as appropriate. Let’s take a simple example. Imagine we have a new application that’s providing a service to end-users and which has the potential to be extremely popular. The application is free when first launched and the application developer is cash-strapped. So, an initial quality of service requirement from the developer upon their cloud provider might be that the application can only consume $100 worth of resources per day and additional load which would cause that to be exceeded should be shed in some controlled manner. This prevents an initial viral explosion in the service’s popularity from bankrupting the developer. Later, once the success has been proven, the developer raises some cash and now wants the application to be capable of scaling to consume a maximum of $1,000 per day.
Changing the quality of service requirements (and indeed setting the original quality of service) requires an agreement between the cloud user and the cloud provider. But, in this example and many others, the means of reaching that agreement could be fully automated. For example the cloud provider’s response to an on-line request to increase the maximum cost might require a on-line cash deposit intended to underwrite the potential costs.
Note that our choice of ‘cost’ as a quality of service requirement might appear unusual. However, probably nothing is of greater importance to the cloud user. If the cloud user can’t define cost limits who will? Service agreements need to capture the real business requirements of users not be couched in the language of the IT professional.
In our view, the inability to capture and then dynamically vary service agreements will significantly constrain enterprises’ consumption of third party services in the cloud. Until this problem is resolved enterprises (and individuals) will be restricted to the consumption of flexible services with poorly defined quality of service, or of inflexible services backed by formal contracts.
Read about how Agility provides the glue for the Federated Cloud
