50 likes | 65 Views
Stateful Subsystems and General Architectural Wisdom. George Porter , Armando Fox, Greg Messer, David Jaffe, HT Levine, ...many others. Stateful-vs-Stateless Architecture Breakout. Need for “assassin” component in system To centralize policy knowledge when there are restart dependencies
E N D
Stateful Subsystems and General Architectural Wisdom George Porter, Armando Fox, Greg Messer, David Jaffe, HT Levine, ...many others
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 i+1 • Often change during failure/attack—can 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”
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
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)
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