Service Provisioning

Rio provides the dynamic provisioning of an application through the network. Key to the dynamic service provisioning model is the recognition that the network composed of heterogeneous compute resources with multiple architectures, operating systems - all with different capabilities. Compute resources are added, removed, some fail, etc... A lightweight dynamic 'agent' called a Cybernode turns heterogeneous compute resources into services available through the network. The Cybernode represents the capabilities of compute resource they run on through quantitative & qualitative mechanisms. Cybernode instances dynamically discover and enlist with dynamic provisioning agents, and provide a lightweight container to instantiate mobile services.

Project Rio provides a model to dynamically instantiate, monitor & manage service components as described in a deployment document called an Operational String. The Operational String provides context on service requirements, dependencies, associations and operational parameters.

Policy Centricities

Being able to inject rules & policies into the service fabric allows greater automation, scalability and controlled behavior. Ultimately, a system can provide advanced capabilities surrounding self-healing, self optimization & self configuration. Project Rio provides mechanisms to declaratively include behavior (if-then-else logic determining how to react to a set of stimuli), as policy mechanisms. The Policy Centricities of Project Rio align themselves along the following areas:

• Platform Policies
  Platform Policies determine if operational requirements can be met by qualitative capabilities of a compute resource. A qualitative capability indicates a specific type of mechanism or quality associated with a compute resource such as network capabilities (TCP, 802.11, Bluetooth) or platform software (drivers, database, software versions, ...).  Supportability is determined by Platform Capability objects, not by administrative configurations. Selection policy is enabled through a mobile code strategy, providing a decentralized collection of platform capabilities. This approach fundamentally changes how a network of compute resources makes their capabilities known through the network, allowing the network of resources to grow organically, instead of using a centralized database.

  Read more about platform capabilities here

• Behavioral Policies
  Behavioral Policies determine whether a service is operating to specified service objective(s). This is accomplished by providing mechanisms to declare and enforce Service Level Agreements (SLAs). SLA policy handlers can be declaratively attached to a service description, providing the behavior to determine what actions to take if SLAs cannot be met. SLAs may vary in scope and function, some targeted at compute resource quantitative behavior (a measurable depletion-oriented platform characteristic such as CPU utilization, CPU capacity, memory usage, bandwidth, ...), others at application specific metrical analysis (transaction time, number of connections, ...), and lastly at associations a service has with other services.

• Reachability Policies
  Reachability Policies provide heuristics determining whether a service is available on the network and are key mechanisms towards providing fault detection & recovery capabilities. Fault detection handlers are declaratively attached to service descriptions and may implement custom fault detection algorithms and protocols to determine service reachability

Provision Types

There are two different types available for service provisioning: 

• Dynamic
• Fixed