What is “Service Level Agreement” (SLA)

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:

  • Sun Icon High: service is operating within normal bands and can happily accept more instances;
  • Medium Medium:  service is loaded but, can host other instances.
  • Low Lowservice is quite busy and it is appropriate to instruct a scaling strategy.
  • SLA Status - No Service No serviceservice 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.
The logic to switch from one status level to another is configured at deployment and can be tuned dynamically during runtime operation. Developers, architects and business stakeholders are responsible to choose the metric(s) and thresholds to transition from one SLA level to another. This lets sense immediately start balancing those services by choosing the most performant delivery platform with regard to the configured business drivers.

Podcast – “Measuring What You Get From the Cloud”

Please listen to this podcast interview with Phil Wainewright and Eddie Budgen outlining the change in value and approach for SLAs (Service Level Agreements) in the new era of cloud services and cloud computing. SLAs help make the cloud enterprise ready. The podcast is hosted here by ebizQ under The Connected Web.

What is a ‘service’?

The term service has been massively overloaded in the marketing brochures of Service Oriented Architecture (SOA) solutions.

A simple description from the point of view of computing technologies could be: a service is a self-describing software entity that is designed and developed in isolation offering near frictionless interoperability to deliver some kind of business value or input.  This covers a wide spectrum including; web services, application services, hardware services, virtualization services, cloud services and others.

In sense‘s view almost all elements of computing technology and infrastructure can be considered services if

  1. they can be interfaced and interacted with,
  2. they can be affiliated and managed by an external actor,
  3. they deliver some form of measurable business input or value.

By its nature, sense is a self federating system that hosts sense  nodes, services, external interactions, business rules and others; with each entity being represented with sense as a service.

A sense service extends the of idea of Service Level Agreement (SLA) to declare business drivers that influence and change the behavior of a runtime scenario automatically in order to maintain an adequate SLA, without the need for human intervention. An SLA lets a service declare a series of ‘states of health’ that are advised within the sense federation during runtime. The switch between the service level states is computed by the service itself depending on used defined criteria, such as the average response time of the service or how much revenue is acquired by the service: sense evaluates the health and can overload the service and intelligently redirect the call to the best performing service provider within the federation.
As a last level fall back, if all services within the federation are failing to the lowest health state, sense is able to intercept all the calls and propagate a mock response from the mock strategy configured for each service. This protects the calling system from a possible system crash and lets the overall system catch its breath and continue operation while some of the services themselves are still in a crisis or unavailable state. sense‘s mock strategy disrupts the domino effect seen in many applications when one component of the system fails.