Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reactive Revealed Part 2: Scalability, Elasticity and Location Transparency in Reactive Systems

5,180 views

Published on

Part 2: What you should know about Elasticity, Scalability and Location Transparency in Reactive systems

In the second of three webinars with live Q/A, we look into how organizations with Reactive systems are able to adaptively scale in an elastic, infrastructure-efficient way, and the role that location transparency plays in distributed Reactive systems. Reactive Streams contributor and deputy CTO at Typesafe, Inc., Viktor Klang reviews what you should know about:

How Reactive systems enable near-linear scalability in order to increase performance proportionally to the allocation of resources, avoiding the constraints of bottlenecks or synchronization points within the system
How elasticity builds upon scalability in Reactive systems to automatically adjust the throughput of varying demand when resources are added or removed proportionally and dynamically at runtime.
The role of location transparency in distributed computing (in systems running on a single node or on a cluster) and how of decoupling runtime instances from their references can embrace network constraints like partial failure, network splits, dropped messages and more.
In the third and final webinar in the series with Jonas Bonér, we go over resiliency, failures vs errors, isolation (and containment), delegation and replication in Reactive systems.

Published in: Software
  • Be the first to comment

Reactive Revealed Part 2: Scalability, Elasticity and Location Transparency in Reactive Systems

  1. 1. Elasticity, Scalability & Location Transparency in Reactive Systems √ Deputy CTO @viktorklang
  2. 2. 1. Lead-In 2. Scale-Up 3. Scale-Out 4. Show- Down 2
  3. 3. 1. Lead-In 2. Scale-Up 3. Scale-Out 4. Show- Down 3
  4. 4. The rules of the game have changed
  5. 5. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users Small data sets Large data sets Latency in seconds Latency in milliseconds
  6. 6. Tomorrow
  7. 7. The Principles of Reactive Systems
  8. 8. Scale on Demand? Why do we need to
  9. 9. 11 E l a s t i c i t y «Lagom is a Swedish word, meaning "just the right amount"» — Wikipedia
  10. 10. scalability? what is But
  11. 11. 15 “A service is said to be scalable if when we increase the resources in a system, it results in increased performance in a manner proportional to resources added.” - Werner Vogels
  12. 12. vs Scalability Performance
  13. 13. 1. Lead-In 2. Scale-Up 3. Scale-Out 4. Show- Down 17
  14. 14. UP Scale and down
  15. 15. 19 Modern CPU architecture
  16. 16. The CPU is a notorious gambler 20
  17. 17. Maximize Locality of Reference
  18. 18. Minimize Contention
  19. 19. Common points of ApplicationPhysical contention
  20. 20. Block 24 Never ever
  21. 21. Async 25 BE
  22. 22. 26 NOTHING share
  23. 23. DIVIDE & conquer 27
  24. 24. 28 Single Writer Principle IO device Producer s CONTENDED IO device Producer s Writer UNCONTENDE D
  25. 25. 29
  26. 26. 30 Needs to be async and non-blocking a l l t h e w a y d o w n
  27. 27. 31 Universal Scalability Law «N is the number of users; or the number of CPUs, α is the contention level, β the coherency latency. C is the relative capacity»
  28. 28. Perfect 32 Throughput Load
  29. 29. Imperfect 33 Throughput Load
  30. 30. Bounded 34 Throughput Load
  31. 31. Regressive 35 Throughput Load
  32. 32. The Role of Immutable State • Great to represent facts • Messages and Events • Database snapshots • Representing the succession of time • Mutable State is ok if local and contained • Allows Single-threaded processing • Allows single writer principle • Feels more natural • Publish the results to the world as Immutable State 36
  33. 33. on Demand Scale
  34. 34. 1. Lead-In 2. Scale-Up 3. Scale-Out 4. Show-Down 38
  35. 35. OUT Scale (and IN)
  36. 36. • Mobile / IoT • HTTP and Micro Services • “NoSQL” DBs • Big Data • Fast Data 40 Distributed Computing is the new normal
  37. 37. Reality check • separation in space & time gives us • communication for coordination • variable delays • partial failures • partial/local/stale knowledge 41
  38. 38. Cluster/Rack/Datacenter Cluster/Rack/Datacenter Cluster/Rack/Datacenter Middleware Node Node Node 42 Node
  39. 39. 43 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. The network is secure 5. Topology doesn't change 6. There is one administrator 7. Transport cost is zero 8. The network is homogeneous Peter Deutsch’s 8 Fallacies of Distributed Computing
  40. 40. Maximize Locality of Reference
  41. 41. Strong Consistency
  42. 42. 47 Linearizability “Under linearizable consistency, all operations appear to have executed atomically in an order that is consistent with the global real-time ordering of operations.” - Herlihy & Wing 1991
  43. 43. Strong Consistency Protocols
  44. 44. (Coordination in the Cluster) Minimize Contention
  45. 45. 50 CAP Theorem
  46. 46. Consistency Eventual
  47. 47. 52 CRDT CvRDTs/CmRDTs
  48. 48. 53 “In general, application developers simply do not implement large scalable applications assuming distributed transactions.” - Pat Helland Life beyond Distributed Transactions: an Apostate’s Opinion
  49. 49. The Event Log • Append-Only Logging • Database of Facts • Two models: • One single Event Log • Strong Consistency • Multiple sharded Event Logs • Strong + Eventual Consistency 56
  50. 50. 1. Lead-In 2. Scale-Up 3. Scale-Out 4. Show- Down 57
  51. 51. NOTHING 58 share
  52. 52. TRANSPARENCY 59 location
  53. 53. Data Center 61 Data Center ClusterCluster MachineMachine JVMJVM NodeNode ThreadThread CPUCPU CPU Socket CPU Socket CPU Core CPU Core CPU L1/L2 Cache CPU L1/L2 Cache
  54. 54. 62 Scaling Up / Out is essentially the same thing
  55. 55. Elasticity requires a message-driven architecture
  56. 56. Summary • Isolate & Contain + Distribute & Replicate • Single Purpose Components • Communicate asynchronously • Divide & Conquer • Avoid coordination & minimize contention • Embrace inconsistency • Strive for lagom amount of utilisation 64
  57. 57. EXPERT TRAINING Delivered on-site for Akka, Spark, Scala and Play Help is just a click away. Get in touch with Typesafe about our training courses. • Intro Workshop to Apache Spark • Fast Track & Advanced Scala • Fast Track to Akka with Java or Scala • Fast Track to Play with Java or Scala • Advanced Akka with Java or Scala Ask us about local trainings available by 24 Typesafe partners in 14 countries around the world. CONTACT US Learn more about on-site training

×