Rotem Hermon
@margolis20
Actors, Evolved
#dmconf15
Not THAT
kind of actors.
Multithreading
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
Threads are EVIL!
There has to be a
better way…
The Actor Model
• Formalized in 1973 (Carl Hewitt)
• Concurrency by Message Passing
• Avoids problems of threading and locking
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
An Actor
• Lightweight
• Never shares state
• Communicates through asynchronous messages
• Mailbox buffers incoming messages
• Processes one message at a time
An Actor
• Lightweight
• Never shares state
• Communicates through asynchronous messages
• Mailbox buffers incoming messages
• Processes one message at a time
• Single threaded
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
(Actors are actually
Nanoservices)
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)
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
Akka Fundamentals
• Actors form an hierarchical structure
Akka Fundamentals
• Actor Lifecycle
• Actors needs to be created
and destroyed
• Fault handling is done via
supervision hierarchies
• Several available supervision
strategies
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
Akka Fundamentals
• Dispatchers
• Schedules the message delivery to actors (code execution)
• Can be shared across actors
• Several types of dispatchers and configurations
Akka Fundamentals
• Routers
• An actor that routes messages to other actors
• Several routing strategies
There has to be a
better way…
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”
Virtual Actors
• A Virtual Actor:
always exists
and
never fails
Virtual Actors
Actor types:
• Worker
• An auto-scaling processing unit – multiple instances created by
framework as needed
Virtual Actors
Actor types:
• Single Activation
• Guaranteed to have a single active instance in the cluster
Virtual Actors
Actor types:
• Single Activation
• Guaranteed to have a single active instance in the cluster
• A Stateful application middle-tier!
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
Virtual Actor Framework
Node
Node
Node
Node
Node
Node
Virtual Actor Framework
Virtual Actor Framework
User
#21
User
#73
Game
#254 Game
#33
Virtual Actor Framework
Auto Scaling
Virtual Actor Framework
Auto Scaling
Virtual Actor Framework
Auto Scaling
Virtual Actor Framework
Auto Scaling
Virtual Actor Framework
Failure Recovery
Virtual Actor Framework
Failure Recovery
Virtual Actor Framework
Failure Recovery
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
Simplified Programming Model
Simplified Programming Model
Use Cases
• Stateful Services
• Smart Cache
• Modeling objects at scale (games, IoT)
• Protecting resources / Aggregations
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)
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
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
Thank You!
Rotem Hermon
@margolis20
VP Architecture @ Gigya

Actors evolved- Rotem Hermon

  • 1.
  • 2.
  • 3.
  • 4.
    The problem withmulti-threaded concurrency • Shared memory and state • Race conditions • Locks and deadlocks • Blocking calls • Hard to understand and maintain • Not easily distributed
  • 5.
  • 6.
    There has tobe 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, CarlHewitt 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.
  • 13.
    Leading Classic ActorImplementations • 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 • Actorsform an hierarchical structure
  • 16.
    Akka Fundamentals • ActorLifecycle • Actors needs to be created and destroyed • Fault handling is done via supervision hierarchies • Several available supervision strategies
  • 17.
    Akka Fundamentals • LocationTransparency • 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
  • 21.
    There has tobe a better way…
  • 22.
    Virtual Actors • Asimplified 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 • AVirtual 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.
    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
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
    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
  • 39.
  • 40.
  • 41.
    Use Cases • StatefulServices • Smart Cache • Modeling objects at scale (games, IoT) • Protecting resources / Aggregations
  • 42.
    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)
  • 44.
    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
  • 45.
    Virtual Actors (Orleans) Chooseif: • 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
  • 46.