1 / 5

Stateful Subsystems and General Architectural Wisdom

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

pilon
Télécharger la présentation

Stateful Subsystems and General Architectural Wisdom

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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”

  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

More Related