Skip to content
Robert de Forest edited this page Aug 19, 2018 · 12 revisions

Objects

  • Metric
    • generates Measurements
  • Control
    • Makes Changes to a system
  • Constraint
    • Expresses/defines a business requirement

TIC automatically adjusts Controls to drive Metrics to satisfy Constraints.

  • inventory/configuration

    • authz: User, Group, Role
    • resources: Host, Link, Service
  • ticketing

    • incident: observed violation of a constraint
    • service call: human request

All objects

  • must have
    • a UUID (to allow names to change without breaking references)
    • an origin (default/base install, user input, etc)
    • a name (may be partly an auto-incrementing number)
    • a version
    • one or more ISO OSI "7 layer burrito" model layers they touch. Some will vary by class (all Users are Application layer) some will vary by instance (Metrics may measure any layer or even several). May be 'inherited' from a previous version or from the object's class.
    • a 'deleted' flag
  • should have
    • a previous version reference, if not first version
  • may have
    • a parent namespace

ActionImplementation

  • has
    • context(s) (host, switch, user, group, ...)
    • an implementation
    • parameters
    • expected side-effects, if any
  • should have
    • rollback ActionImplementation
    • validation Constraint(s)
  • may have
    • pre-condition Constraint(s)

Action

An Action encapsulates a real or simulated interaction with a system. It includes the motivation for the interation, the target resource, the parameters of the interaction and it tracks the results and optional attempt at rollback.

When an ActionImplementation is used, it generates an Action which tracks the execution of the implementation.

  • has
    • ActionImplementation
    • parameters used
  • does
    • rollback
      • if possible, creates an action which reverses this action

Metric

  • has
    • parameters
    • ActionImplementation
    • units
    • an expected range of values

Side-effects should be minimized

Example metric: "one minute load average"

  • layers: application?
  • parameters: none
  • context: a host
  • implementation: uptime | sed 's/.*average: //;s/,.*//'
  • side effect: will increase load slightly
  • units: runnable processes
  • range: zero to infinity

Control

  • has
    • "bump" implementation
  • may have
    • expected metric effects
    • converse Control (un-bump)
  • will gather
    • observed metric effects

Constraint

A constraint requires that one value be greater than another. Either of the two values may be a constant, but one must be a formula which is composed of at least one Metric. TIC adjusts Controls to keep Constraints "true".

  • has
    • two formulae: upper and lower

For example: "Finish serving human-facing web objects within 100 milliseconds of when the load balancer receives the packet completing the corresponding HTTP request from the client." The upper formula is the constant expression "100 milliseconds". The lower formula would be a Metric reporting on how long it's taking to serve pages.

Through experimentation the system would discover that scaling up load balancers, caching servers, app servers and database shards can (eventually) lower latency.

NOTE: I considered "greater or equal" above but decided ops is never precise so equality is rare enough to be considered likely to be an error. If there is ever a use case where lower() == upper() isn't a breach, subtract a very small number from the lower bound and get on with your life.

ResourceType

  • is a kind of Metric
    • because Resources are discovered via measurement

Resource

  • is a kind of Measurement
  • has
    • a ResourceType

ContextType

A ContextType is a mode of interaction with a system. ResourceTypes use ContextTypes to explain how to manipulate them. All ActionImplementations which match a given ContextType can manipulate the ResourceTypes which have that ContextType.

Examples:

  • Router via CLI
  • Host via shell
  • Cloud Account via API

Context

A Context is a specific interaction channel. It connects an Action to a Resource.

  • has
    • ContextType
    • ActionType
    • Resource
    • Action

Clarification

Difference between Action, ActionType, Context and ContextType

An ActionType is a template for an Action. A ContextType is a template for a Context. A ContextType creates a Context from a Resource and parameters. An ActionType creates an Action from a Context.

Clone this wiki locally