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.

1. Fantastic elastic
How to design an elastic application
Uwe Friedrichsen, codecentric AG, 2013-2014

2. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

3. A promising
business case

4. Euphoria …

5. … and
disenchantment

6. It‘s about
elasticity, dude

7. Characteristics
• Off-the-shelf hardware & software
• No fault tolerance on infrastructure level
• Higher per-node failure probability
• Many nodes
• Distributed system

8. Challenges
• Elasticity
Add and remove nodes transparently for the users
• Resilience
Ensure availability in face of unreliable nodes
• Distribution
Ensure availibility in face of system distribution

9. 10 Design Principles
for Elastic Applications

10. Standardize

11. Standardize everything
Avoid individual setup
Consider system sizing

12. Automate

13. Avoid manual interaction
Automate routine tasks
Infrastructure as code
Automate configuration & coordination

14. Ensure
Startup
Consistency

15. Nodes must (re-)start in a safe state
Use checkpoints or data reset, or …
Never restart, always create new nodes

16. Be Stateless

17. State makes …
… scaling hard
… shrinking hard
… restart hard
Avoid state if possible
Move to client or backend
Use caches if necessary

18. Make
Actions
Idempotent

19. Distributed systems are probabilistic
Go for „at least once“ semantics
Makes failure recovery a lot easier
Don‘t loose action before it completes

20. Design Failure Units

21. System must not fail
Design failure units
Avoid cascading failures
Additional design concern

22. Couple loosely

23. Complements failure units
Always guard interfaces
Requires failure strategy
Or use message passing

24. Relax
Temporal
Constraints

25. ACID transactions do not scale well
CAP theorem
Go for BASE transactions
Real world is BASE, not ACID

26. Expect Inconsistencies

27. Failures, BASE, …
Leads to …
… Resolver
… Quorum based decision
… CRDT
… Marked Data
… Consistency checker
… Journal
…
Hard for most people

28. Provide Transparency

29. Control needs information
Monitoring
Logging
Operations database

30. 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

31. 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!

32. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com