fantastic elastic
DESCRIPTION
This presentation explains that the naive cloud business case that is often presented does not work: simply deploy your existing enterprise applications to a cloud environment and save lots of money by automatically adopting resource usage (and payment) to the actual application load. The problem is that enterprise applications are not elastic by default, i.e. they cannot easily scale out and in, because it takes explicit design and implementation to create an elastic application. A set of design principles is presented in this deck that are required to create an elastic application. As always lots of the information of this presentation is on the voice track but yet I think that you can find some helpful pointers in this deck.TRANSCRIPT
@ufried Uwe Friedrichsen | [email protected] | http://slideshare.net/ufried | http://ufried.tumblr.com
Characteristics • Off-the-shelf hardware & software • No fault tolerance on infrastructure level • Higher per-node failure probability • Many nodes • Distributed system
Challenges • Elasticity
Add and remove nodes transparently for the users
• ResilienceEnsure availability in face of unreliable nodes
• Distribution Ensure availibility in face of system distribution
Avoid manual interaction
Automate routine tasks
Infrastructure as code
Automate configuration & coordination
Nodes must (re-)start in a safe state
Use checkpoints or data reset, or …
Never restart, always create new nodes
State makes … … scaling hard … shrinking hard … restart hard
Avoid state if possible Move to client or backend Use caches if necessary
Distributed systems are probabilistic
Go for „at least once“ semantics
Makes failure recovery a lot easier
Don‘t loose action before it completes
ACID transactions do not scale well
CAP theorem
Go for BASE transactions
Real world is BASE, not ACID
Failures, BASE, …
Leads to … … Resolver … Quorum based decision … CRDT … Marked Data … Consistency checker … Journal …
Hard for most people
10 Design Principles • Standardize • Automate • Ensure startup consistency • Be stateless • Make actions idempotent • Design failure units • Couple loosely • Relax temporal constraints • Expect inconsistencies • Provide transparency
Wrap-up • Deploying your application in the „Cloud“ is
not sufficient • Elastic applications require a dedicated
design • Really elastic applications allow for a great
business case • Designing and implementing is challenging
but also a lot of fun … really!
@ufried Uwe Friedrichsen | [email protected] | http://slideshare.net/ufried | http://ufried.tumblr.com