Actors, Evolved - CodeMash 2016

Actors, Evolved - CodeMash 2016

Concurrent programming is hard. Concurrent and distributed programming is even harder. But building web applications at scale demands your application to be concurrent and distributed.

Is there a way to make this easy and approachable?

The Actor Model tries to answer just that. It is based on the concept of small computational units communicating through asynchronous message passing, thus allowing concurrency and scalability while negating a lot of the problems of concurrent programming.

But up until now the actor model remained a rather niche approach and has not become a commonly used practice. This may change with the introduction of “Virtual Actors” – a new abstraction for writing distributed applications.

This abstraction was introduced with the Orleans framework by Microsoft and adopted to Java by EA with their Orbit framework.

In this session you will learn about the the Actor Model, what’s novel about Virtual Actors, and why it makes distributed application programming a lot simpler. We will also explore the idea of building a microservices architecture on top of Virtual Actors, including some practical lessons we learnt at Gigya doing just that.

Ed52a75c8cf2f4cb1c2e9d8d161ca771?s=128

Rotem Hermon

January 05, 2016
Tweet

Transcript

  1. Rotem Hermon @margolis20 Actors, Evolved Slides: http://j.mp/actors-cm2016

  2. Not THAT kind of actors.

  3. Multithreading

  4. The problem with multi-threaded concurrency • Shared memory and state

    • Race conditions • Locks and deadlocks • Blocking calls • Hard to understand and maintain • Not easily distributed
  5. Threads are EVIL!

  6. There has to be a better way…

  7. The Actor Model • Formalized in 1973 (Carl Hewitt) •

    Concurrency by Message Passing • Avoids problems of threading and locking
  8. An Actor, Carl Hewitt definition • The fundamental unit of

    computation that embodies: • Processing • Storage • Communication • An actor can: • Create new Actors • Send messages to Actors • Designate how to handle the next message
  9. An Actor • Lightweight • Never shares state • Communicates

    through asynchronous messages • Mailbox buffers incoming messages • Processes one message at a time
  10. An Actor • Lightweight • Never shares state • Communicates

    through asynchronous messages • Mailbox buffers incoming messages • Processes one message at a time • Single threaded
  11. The Actor Model • Higher abstraction level • Simpler concurrent

    programming model • Write single-threaded code (easier to understand) • Concurrency and scale via actor instances • Maximizes CPU utilization • Easy to distribute
  12. (Actors are actually Nanoservices)

  13. Leading Classic Actor Implementations • Erlang • Developed in the

    late 90s by Ericsson for HA telecom exchanges • Actors are a core language feature • Akka • A JVM (Scala/Java) Actor framework library • Started by Jonas Bonér in 2009 • Became part of Typesafe (company behind Scala) • .NET port in progress since 2014 (Akka.NET)
  14. Akka Fundamentals Actors Contains: • State • Behavior • An

    actor can “switch” its internal behavior • Mailbox • Several types of mailboxes • Children • An actor is “responsible” for other actors it creates - Supervisor
  15. Akka Fundamentals • Actors form an hierarchical structure

  16. Akka Fundamentals • Actor Lifecycle • Actors needs to be

    created and destroyed • Fault handling is done via supervision hierarchies • Several available supervision strategies
  17. Akka Fundamentals • Location Transparency • Actors can be created

    remotely • Actors are called via an actor reference, same for local and remote • Akka Clustering for additional features
  18. Akka Fundamentals • Dispatchers • Schedules the message delivery to

    actors (code execution) • Can be shared across actors • Several types of dispatchers and configurations
  19. Akka Fundamentals • Routers • An actor that routes messages

    to other actors • Several routing strategies
  20. None
  21. There has to be a better way…

  22. Virtual Actors • A simplified Actors implementation with a higher

    abstraction level • Introduced by Microsoft Research – Project Orleans • Goals: • Make distributed application programming easier • Prefer developer productivity and transparent scalability • “A programming model and runtime for building cloud native services”
  23. Virtual Actors • A Virtual Actor: always exists and never

    fails
  24. Virtual Actors Actor types: • Worker • An auto-scaling processing

    unit – multiple instances created by framework as needed
  25. Virtual Actors Actor types: • Single Activation • Guaranteed to

    have a single active instance in the cluster
  26. Virtual Actors Actor types: • Single Activation • Guaranteed to

    have a single active instance in the cluster • A Stateful application middle-tier!
  27. A Short Example… URL Shortner Service • Shorten (URI) •

    Expand (shortURI)
  28. A Short Example… URL Shortner Service The Classic Way shrt.uri

    Stateless Service DB Cache Fetch from DB Set in Cache Expand Return URL Get From Cache
  29. A Short Example… URL Shortner Service The Virtual Actor Way

    shrt.uri Expand Return URL Virtual Actors Service Worker URLActor (“shrt.uri”) “URL” DB Fetch from DB
  30. A Short Example… URL Shortner Service The Virtual Actor Way

    shrt.uri Expand Return URL Virtual Actors Service Worker URLActor (“shrt.uri”) “URL”
  31. A Short Example… URL Shortner Service The Virtual Actor Way

    shrt.uri Expand Return URL Virtual Actors Service Worker URLActor (“shrt.uri”) “URL” And logic!
  32. Virtual Actor Framework • A runtime providing virtual “actor space”,

    analogues to virtual memory • Handles Actor placement, activation and GC when needed • Balances resources across the cluster, provides elastic scalability
  33. Virtual Actor Framework Node Node Node Node Node Node

  34. Virtual Actor Framework

  35. Virtual Actor Framework User #21 Game #254 User #73 Game

    #33
  36. Virtual Actor Framework Auto Scaling

  37. Virtual Actor Framework Auto Scaling

  38. Virtual Actor Framework Auto Scaling

  39. Virtual Actor Framework Auto Scaling

  40. Virtual Actor Framework Failure Recovery

  41. Virtual Actor Framework Failure Recovery

  42. Virtual Actor Framework Failure Recovery

  43. Simplified Programming Model • An Actor is a class, implementing

    an interface with asynchronous methods • The caller of an Actor uses the actor interface via a proxy • Messaging is transparent and handled by the runtime. Programmers deal with interfaces and methods
  44. Simplified Programming Model

  45. Simplified Programming Model

  46. Use Cases • Stateful Services • Smart Cache • Modeling

    objects at scale (games, IoT) • Protecting resources / Aggregations
  47. Virtual Actor Implementations • Orleans (.NET) • Started by Microsoft

    Research in 2011, in production since 2012 • Service high scale services on Azure (Halo 4 cloud services) • Open sourced in January 2015, active community • Orbit (Java) • Developed by BioWare (division of Electronic Arts) • Inspired by Orleans (“not a port but a re-write”) • Powering online game services • Azure Service Fabric (Reliable Actors)
  48. None
  49. Virtual Actors (Orleans) • Focus on simplicity and productivity •

    Implicit lifecycle, handled by runtime • Automatic clustering and load balancing • No hierarchy, all actors are directly accessible • Actor interfaces are regular interfaces (standard OOP) Classic Actors (Akka) • Provide full power (exposing complexity) • Explicit lifecycle, handled by programmer • Clustering and load balancing available (but more complex) • Actors are hierarchical and accessible by path • Actors communicates via explicit message classes
  50. Virtual Actors (Orleans) Choose if: • Need a simple model

    for distributed applications • Automatic and straightforward scaling • Development team with varied levels of experience Classic Actors (Akka) Choose if: • Need full power – complex topologies, fine grain failure handling, dynamic changing of behavior, explicit message handling • Experienced development team
  51. None
  52. Some more about Actors and (Micro) Services

  53. A single Actors universe?

  54. Back to microservices

  55. Actor Based Microservices Service A Service B ServiceB Interface Actor

    IMyServiceB
  56. Actor Based Microservices Service A Service B ServiceB Interface Actor

    IMyServiceB ServiceB HTTP Listener
  57. Actor Based Microservices Service A Service B ServiceB Interface Actor

    IMyServiceB ServiceB Client ServiceB HTTP Listener JSON over HTTP
  58. None
  59. Thank You! Rotem Hermon @margolis20 VP Architecture @ Gigya Slides:

    http://j.mp/actors-cm2016