SAF Use cases for CEP, GreenIT, Energy, etc

Mike,

Would you be willing to throw together some summary use cases for CEP, Energy, etc (as mentioned in the F2F yesterday)?

These Cloud use cases can be used as a template.

Use Case 1: Automation of Increased Provisioning (precipitated by consumer)

- Actors: Cloud Provider and Cloud Consumer

- Dynamic Composition of SAF Catalog:

o Provider contributes Protocols, ie: “increase capacity”, “reduce capacity”, etc.

o Consumer contributes Syndrome (with signature based upon Symptoms he will emit), ie: “increased sales. At this point, the associated Protocols field is empty.

o Consumer gets list of advertised Protocols from the Catalog.

o Consumer references “increase capacity” Protocol to his “increased sales” Syndrome.

o Consumer activates Syndrome.

- Business <-> Operations Bridge:

o Business elements

§ Protocols for “increase capacity”, “reduce capacity”

§ Syndrome for “increased sales”

o Corresponding Operational elements

§ Prescription associated with “increase capacity”

· Evaluate short-term load

· If load is predicted to be low – break; Otherwise…

· Allocate VM from resource pool

· Bring online

§ Symptoms associated with “increased sales”

· Transaction rate

· System performance

Use Case 2: Automation of Decreased Provisioning (precipitated by cloud)

- Actors: Cloud Provider and Cloud Consumer

- Dynamic Composition of SAF Catalog:

o Provider contributes a Syndrome generic template with associated Protocol template that detects idle VMs and decommissions them. The templates have substitutable parameters that help to define “idle” in more specific terms.

o Consumer copies the generic Syndrome (and associated generic Protocol)

o Consumer substitutes meaningful parameters, such as “<10% avg cpu load within 3 hours”.

o Consumer publishes/contributes to the SAF catalog.

o Consumer activates Syndrome.

- Business <-> Operations Bridge:

o Business elements

§ Consumer adds business level logic to the decommission Protocol that checks for a pending sales uptick (perhaps due to a marketing program). If sales are expected to increase, the decommission of VMs is postponed.

o Corresponding Operational elements

§ Prescription associated with “decommission” Protocol. Although note that “Decommission” itself may be an Operational term.

· Send notification

· Set systems to offline

· Initiate shutdown sequence

§ Provider defines operational level generic Syndrome for “detecting Idle VMs”

§ Provider defines operational level generic Protocol for “decommissioning VMs”

Mike – I just copied Use Case 3 directly from Whiteboard. Will try to sanitize later this morning.

Use Case 3: Green Policy Management

Actors: Cloud Provider and Cloud Consumer

Scenario:
   - The Provider emits a Symptom relating to the current CO2 burn of the customer's current computational estate.
   - The Provider might (optionally) publish Protocols to enable actions such as decommissioning virtual infrastructure or even switching to a lower-carbon,       higher cost energy provider.
   - The Consumer could essentially encode their green policy by creating Syndromes that map various QoS requirements and CO2 levels to the Protocols        that control energy utilization and/or energy provider.
   - The consumer's SAF diagnostician (internally or hosted/provided by the provider) to modify their QoS to keep CO2 below some policy determined level.

Business Value:
- An entirely new business model and opportunity for Cloud providers and consumers enabling a carbon-aware hybrid Cloud enterprise.

[[Paul]] I like this a lot. We should talk to the OASIS Emix TC about this. Emix feeds the money and carbon cost as Symptoms to a framework that reflects corporate *business and regulatory policy!* Try to encapsulate that with a simple management spec! This is multi-faceted with real business value.

saf message