Actors: not just for movies anymore

Clusters are getting bigger and bigger and machines are getting more and more powerful and yet we continue to use architectures that worked for websites built during the 90’s internet scale. Microservices vs. Monoliths glosses over a key architectural distinction in the way we build concurrency into our applications.

We’ll define terms like concurrency and parallelism and learn how the key question in an architecture is message passing vs. shared mutable state. We’ll also look at concepts like Actors and CSP for creating a holistic messaging passing architecture that will let you truly scale your architecture.

Transcript

1. Actors: not just for movies anymore Coupling your architecture to physics not fiction
2. @boulderdanh
3. @Mtn. basecamp Big rewrite of a database contended pipeline to an event- sourced system
4. "Scaling up" is not a sustainable practice
5. Scaling to lots of processes is difficult
6. Languages and frameworks favor running on a single machine
7. Designing and tooling for concurrency can be the answer
8. Concurrent vs. Parallel • Simultaneous • Implementation • Independent • Design • Asynchronous
9. @ Transmogrify Inc.
10. Concurrency is planning The Golder The Shaper
11. Construct pipelines
12. Construct pipelines
13. Isn't this more work? VS.
14. Isn't this slower? VS.
15. Scalable
16. Concurrency Parallelism
17. Parallelism scales "The parallelism in today’s machines is limited by the data dependencies in the program and by memory delays and resource contention stalls "
18. A resource computation 1 computation 2 computation 3 computation 4 computation 5
19. Concurrency in frameworks Monolithic Rails LAMP Distributed Finagle Erlang / OTP
20. DB Web Process Web Process Web Process Web Process
21. Latent Concurrency
22. Latent Concurrency • Concurrency is unplanned • Rely's on a subset of the system
23. Web Process Web Process Web Process Web Process Service A Service B Service C Service D Service E Worker Worker Worker Worker
24. Holistic Concurrency • Concurrency is planned and constructed • Concurrency is a property of the system • Reduction in contention / sharing
25. Holistic Concurrency • Parallelizable / Scalable • Resource density • Fine grained scaling
26. Plan for concurrent systems
27. The fundamental choice Shared data or Message passing
28. Concurrency in frameworks Shared data Message passing
29. Shared data concurrency Locks Semaphores https://stackoverflow.com/questions/tagged/thread-safety Synchronization CAS Atomic Memory barriers STM JSR-133 Happens before a tag cloud of pain, in comic sans Thread safety
30. Shared data lots of primitives Locks Semaphores Atomic Memory barriers STM Volatile
31. Shared data correctness is elusive
32. Shared data "The first huge barrier to bringing clockless chips to market is the lack of automated tools to accelerate their design"
34. Actors, abstractly • create actors • send messages • store information for the next message
35. Implementation • mailbox • similar to an object • concurrency and distribution
36. Coupled with physics • Actor sends • Stop • +1 • +1 • +1 • What state does it end up in? Actor Stop +1 +1 +1
37. Actor definition class Counter extends Actor {
 var count = 0
 
 def receive: Receive = {
 case Increment(by) => count += by
 case Get => sender ! count
 }
 }
38. Actor definition class Counter extends Actor {
 def receive = next(0) // initialize base state
 
 def next(count: Int): Receive = {
 case Increment(by) => become(next(count + by))
 case Get => sender ! count
 }
 } store information for the next message
39. Actors as bank accounts class BankAccount(name: String) extends Actor {
 var count = 0
 
 def receive = {
 case Credit(by) => count += by case Balance => sender ! count
 case Debit(by) if (count - by) < 0 => sender ! NSF
 case Debit(by) => count -= by
 case "whoru?" => sender ! name
 }
 }
40. Actors can create actors class Bank(name: String, insured: Boolean) extends Actor {
 def receive = {
 case AddAccount(name) => context.actorOf(Props(new BankAccount(name)))
 }
 }
41. A program using actors override def main(arg: Array[String]) = {
 val system = ActorSystem()
 val counter: ActorRef = system.actorOf(Props[Counter])
 
 counter ! Increment(10) 
 val result = counter ? Get
 result.onSuccess { case t => println(t) }
 }
42. A key abstraction val counter: ActorRef = system.actorOf(Props[Counter]) • The address for an actor • Tells you nothing about where the actor is • Deployment is a runtime/config decision
43. Sending messages • Asynchronous • Response is optional acct ! Increment(10) acct.tell(Increment(10)) def !(message: Any): Unit
44. • Still Asynchronous • Implemented with Actors Asking for information (counter ? Get).onSuccess { case t => println(t) }
45. Actors are great at concurrency • No synchronization • Communication is asynchronous • Late binding deployment decisions
46. Actors are great at concurrency • Light weight • Actors are micro-services
47. Surely there are other ways
48. Communicating Sequential Processes
49. Key distinctions • The channel is fundamental • Communication is synchronous • Channels are anonymous vs. named actors
50. Message passing frameworks • Streams (Reactive Java) • DataFlow • CPS (not to be confused with CSP)
51. Wrapping up • Concurrency is inevitable • Use tools that help you write software to plan for it • Choose tools that promote message passing • Scale your systems
52. Any Questions? @boulderdanh
53. References • Everything you wanted to know about the actor model - http://bit.ly/16O4qSP • A Universal Modular ACTOR Formalism for Artificial Intelligence - Carl Hewitt • Communicating Sequential Processes - C.A.R. Hoare • Coming Challenges in Microarchitecture and Architecture - Ronny Ronen • The Tail at Scale - Jeffrey Dean and Luiz André Barroso