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.

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