A service level agreement is an agreed target for performance and/or quality of a provided service.  The specific SLA attributes to be measured for any given service will depend on the value perceived by to each of the service stakeholders.  These stakeholders include business owners, IT operations, IT development, Administrators, executives, and perhaps customers and partners directly etc.

A well defined and managed SLA allows the business to offer higher value and higher margin services to their customers or preferred channel. This applies equally in general and internet commerce as it does in intra-enterprise activities. SLA driven services can be monitored specifically to provide transaction, billing and penalty attributes to help the business track and manage overall performance against a business relationship or contract.

In computing in general, the business owners and executives are usually provided the least amount of information and support in this critical aspect of management - here sense re-balances the equation and provides a clear way to assign business policies that are dynamically used at runtime to enforce SLAs from the business perspective - business SLAs

sense lets the business specify an SLA(s) on each of the components participating in the cloud, and sense is able to maintain the status and management of each single component in the federation. This lets sense, and the system in general choose which is the best component in the cloud that can respond to any incoming request – this is a dynamic runtime evaluation and decision, and so allows the system to auto-tune itself depending on the circumstances at the moment of the request. This can include scaling for additional load, bypassing and rerouting out-of-band services, instantiating new resources from the cloud to support higher value services and other autonomic behaviors.  Together these increase the level of guarantee that a business service will match the desired business SLA without the need for extensive administrative or operational intervention – and all evaluations and actions are made transparently visible to the business users (if desired)

Technically, for each sense node in the cloud, sense feels the health status of the node and the services available there, through federation services built into sense. Every component declares what protocols are available while operating, and sense evaluates the health level for each protocol available on the node.

This is lets sense bridge the call to the service using the protocol that is:

• most performant in terms of business (as measured against the SLA);
• most performant in terms of technology;
• most performant in terms of computing (protocol)

In this way intra-sense calls between services, use the most effective protocol(s) available in the infrastructure. When the call has been performed, the invoked service informs the federation of its (possibly revised) health status.

A defined SLA is identified by an architect and can vary between different levels:

• High: service is operating within normal bands and can happily accept more instances;
• Medium:  service is loaded but, can host other instances.
• Low: service is quite busy and it is appropriate to instruct a scaling strategy.
• No service: service is not accepting new instances because no more computational space space is available or the service or network is down. When the service is declared with this status a mock strategy is activated, this lets the service at least respond normally to the request (so avoiding a domino effect), and sense can trigger self-healing strategies and/or send notifications to any nominated services or message managers.