Stateful Subsystems and General Architectural Wisdom

1
Stateful Subsystems and General Architectural
Wisdom

• George Porter, Armando Fox, Greg Messer, David
  Jaffe, HT Levine, ...many others

2
Stateful-vs-Stateless ArchitectureBreakout

• Need for assassin component in system
• To centralize policy knowledge when there are
  restart dependencies
• Assumptions of what layer i offers to layer i1
• Often change during failure/attackcan we still
  function during that time?
• architecture must be evolvable and correctable
• Ex State could be list (graph) of restartable
  components and who talks to who

3
Restart as an action

• Restart at various levels
• JVM method, object, bean, .net
• Move from systems data to real app logic
• Means better visibility into what data is needed
  for reset
• Without the right alerts, errors can propogate
• Bad battery ? forced writes ? bad perf
• Router example
• Self correcting, but simple service (routing)
• Closer to user means few constraints and so few
  assumable properties

4
Stateful systems

• Arch. should provide abstractions for different
  types of state
• Bridge analogy No single architecture for all
  bridges (suspension, other types, etc)
• App user login name, ssn, shopping cart
• Session cookie, session id, token
• Recoverability checkpoint, who was I talking
  with when I crashed? (maybe they should be
  restarted too)

5
State cont.

• Configuration info
• because of access pattern and usage semantics,
  different type of data
• eg, read once at startup vs. check constantly
  programs must be written to allow on-the-fly
  config changes to affect operation
• Ability to encapsulate configuration
• to allow, e.g., multiple versions of SW to be
  resident simultaneously even if require different
  configs
• Mac applications (used to) allow this