Successfully reported this slideshow.

Fantastic Elastic

2,108 views

Published on

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.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Fantastic Elastic

  1. 1. Fantastic elastic How to design an elastic application Uwe Friedrichsen, codecentric AG, 2013-2014
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. A promising business case
  4. 4. Euphoria …
  5. 5. … and disenchantment
  6. 6. It‘s about elasticity, dude
  7. 7. Characteristics •  Off-the-shelf hardware & software •  No fault tolerance on infrastructure level •  Higher per-node failure probability •  Many nodes •  Distributed system
  8. 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. 9. 10 Design Principles for Elastic Applications
  10. 10. Standardize
  11. 11. Standardize everything Avoid individual setup Consider system sizing
  12. 12. Automate
  13. 13. Avoid manual interaction Automate routine tasks Infrastructure as code Automate configuration & coordination
  14. 14. Ensure Startup Consistency
  15. 15. Nodes must (re-)start in a safe state Use checkpoints or data reset, or … Never restart, always create new nodes
  16. 16. Be Stateless
  17. 17. State makes … … scaling hard … shrinking hard … restart hard Avoid state if possible Move to client or backend Use caches if necessary
  18. 18. Make Actions Idempotent
  19. 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. 20. Design Failure Units
  21. 21. System must not fail Design failure units Avoid cascading failures Additional design concern
  22. 22. Couple loosely
  23. 23. Complements failure units Always guard interfaces Requires failure strategy Or use message passing
  24. 24. Relax Temporal Constraints
  25. 25. ACID transactions do not scale well CAP theorem Go for BASE transactions Real world is BASE, not ACID
  26. 26. Expect Inconsistencies
  27. 27. Failures, BASE, … Leads to … … Resolver … Quorum based decision … CRDT … Marked Data … Consistency checker … Journal … Hard for most people
  28. 28. Provide Transparency
  29. 29. Control needs information Monitoring Logging Operations database
  30. 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. 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. 32. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×