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
Fantastic elastic How to design an elastic application
Uwe Friedrichsen, codecentric AG, 2013-2014
@ufried Uwe Friedrichsen | [email protected] | http://slideshare.net/ufried | http://ufried.tumblr.com
A promising business case
Euphoria …
… and disenchantment
It‘s about elasticity, dude
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
10 Design Principles for Elastic Applications
Standardize
Standardize everything Avoid individual setup Consider system sizing
Automate
Avoid manual interaction
Automate routine tasks
Infrastructure as code
Automate configuration & coordination
Ensure Startup Consistency
Nodes must (re-)start in a safe state
Use checkpoints or data reset, or …
Never restart, always create new nodes
Be Stateless
State makes … … scaling hard … shrinking hard … restart hard
Avoid state if possible Move to client or backend Use caches if necessary
Make Actions Idempotent
Distributed systems are probabilistic
Go for „at least once“ semantics
Makes failure recovery a lot easier
Don‘t loose action before it completes
Design Failure Units
System must not fail Design failure units Avoid cascading failures Additional design concern
Couple loosely
Complements failure units Always guard interfaces Requires failure strategy Or use message passing
Relax Temporal Constraints
ACID transactions do not scale well
CAP theorem
Go for BASE transactions
Real world is BASE, not ACID
Expect Inconsistencies
Failures, BASE, …
Leads to … … Resolver … Quorum based decision … CRDT … Marked Data … Consistency checker … Journal …
Hard for most people
Provide Transparency
Control needs information Monitoring Logging Operations database
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
