Rotem Hermon Actor Frameworks in .NET 

Not THAT kind of actors. 

The problem with multi-threaded concurrency • Shared memory and state • Locks and deadlocks • Race conditions • Blocking calls • Not easily distributed • Hard to understand and maintain 

Threads are EVIL! 

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 • Single threaded 

(Actors are actually Nanoservices) 

The Actor Model • Simpler concurrent programming model • Higher abstraction level • Write single-threaded code (easier to understand) • Scale via actor instances • Maximize CPU utilization • Easy to distribute 

Leading 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) 

Actors in .NET Before 2015 

Actors in .NET After 2015 

Akka.NET MS Orleans 

Akka.NET • A port of Akka to .NET. • Started Jan 2014 by Roger Alsing and Aaron Stannard • V1.0 – March 2015 • Some modules still in beta (Persistence, Clustering) • Founded Petabridge as an OS company behind Akka.NET (cooperating with Typesafe) 

Akka.NET 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.NET Fundamentals • Actors form an hierarchical structure • Actor Lifecycle • Actors needs to be created and destroyed • Fault handling is done via supervision hierarchies • Several available supervision strategies • 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.NET Fundamentals • Dispatchers • Schedules the message delivery to actors (code execution) • Can be shared across actors • Several types of dispatchers and configurations • Routers • An actor that routes messages to other actors • Several routing strategies 

No content

Orleans • A project by Microsoft Research • Started at 2011, in production since 2012 • Serving high scale Microsoft services on Azure (Halo 4 cloud services) • Open sourced in January 2015 

Orleans • Project goal: a simplified Actors implementation to make distributed application programming easier • Prefer developer productivity and transparent scalability • Provides a higher abstraction level for actors: Virtual Actors 

Orleans – Virtual Actors • A virtual “actor space”, analogues to virtual memory • An Actor “always exists” • Orleans runtime handles Actor placement, activation and GC when needed • Orleans balances resources across the cluster, provides elastic scalability 

Orleans – Programming Model • An Actor is a .NET class, implementing an interface with asynchronous methods • Orleans uses code generation to create Actor proxies • The caller of an Actor uses the actor interface via the proxy • Messaging is transparent and handled by Orleans. Programmers deal with interfaces and methods 

Orleans (Virtual Actors) • Focus on simplicity and productivity • Implicit lifecycle, handled by runtime • Automatic clustering and load balancing • Actor interfaces are regular interfaces (standard OOP) • No hierarchy, all actors are directly accessible Akka (Classic Actors) • Provide full power (exposing complexity) • Explicit lifecycle, handled by programmer • Clustering and load balancing available (but more complex) • Actors communicates via explicit message classes • Actors are ordered in hierarchies and accessible by path 

No content

Orleans or Akka ? • Choose Akka if • Need full power – complex topologies, fine grain failure handling, dynamic changing of behavior, explicit message handling • Experienced development team • Choose Orleans if • Need a simple model for distributed applications • Automatic and straightforward scaling • Development team with varied levels of experience 

Thank You! We’re hiring! http://gigya.com/careers/ Rotem Hermon VP Architecture @ Gigya