Microsoft Project Orleans Virtual Actors Set the Stage for Performance, Reliablity, and Scale

Sites Contact Microsoft Certified Solutions Developer Certified BizTalk developer Phoenix Connected Systems User Group Semi-active blogger (see sites) Proponent of Cloud Neudesic Senior Consultant Sites Blog: http://bloggedbychris.com Contact PCSUG: http://pcsug.org/ @pcsug @myerscj PCSUG *New (beta) http://www.pcsug.org/ myers.chris.j@gmail.com

Presentation Roadmap Demo & Solution overview Overview of Actor Model Introducing Orleans and virtual actors! Basics of Orleans Benefits of Orleans Advanced topics

College Class Scheduling Students Teachers 1 View classes 1 View classes 2 Create classes 2 Schedule classes 3 Find classes

So what’s all the hype with actors?

Wait… Sorry… wrong actors. Well… Actors are funny! Wait… Sorry… wrong actors.

Let’s Talk Actor Model Theory Concurrent digital computation Heavily influenced by work in the field of process calculi (or process algebra) Parallel composition Communication Theory within computer science that dates back to the 1973 Heavily influenced by packet switched networks

Actor Model Characteristics of actors Isolated Single-threaded Inherently concurrent Processes interact with actors through queues Actors are adressable Reference: http://blog.kjempekjekt.com/2013/02/16/actor-model-i-f-ved-hjelp-av-mailboxprocessor/

Actor Model – Mailbox Example Characteristics of actors Isolated state Data locality Locality There is no simultaneous change in multiple locations Message driven Actors are addressable Reference: http://3.bp.blogspot.com

Actor Models and Frameworks .NET Actor Framework NAct Retlang PostSharp Akka.NET Java and Skala Akka (toolkit) Erlang (Actor programming languages) Common complaints Actors are often not usefully typed Actors don’t always compose very well

What’s all this have to do with Orleans? Thank you Chris for the walk down memory lane, but… What’s all this have to do with Orleans?

Introducing Virtual Actors Teacher Student Class Subject Azure Silos Silos are hostable containers for virtual actors. Orleans Runtime Azure On-premise Hybrid Hosting

Virtual actors are called grains Concurrent components State Behavior Actor-based Silos communicate through Orleans conduit Silos are hosted via Orleans runtime Azure Windows Applications Grains communicate through message passing Reference: http://research.microsoft.com/en-us/projects/orleans/ 

Orleans Grains Grain Factory Clients Silos Grains Orleans Grain Grain Interface Grain Factory Clients Implements Provides Silos Use Grains Grain References Orleans Runtime

Creating the Interface Grain interface shared between client and server Implementations of grains inherit from a grain interface Grains always return either Task or Task<T> Grains are identified by a unique identifier: IGrainWithGuidKey IGrainWithStringKey IGrainWithLongKey Grain Interface Grain Interface Grain All communications with grains are implemented with Task or Task<T> All grains require a grain interface Establishes this as a grain interface that is referenced through a unique GUID

Creating the Grain Implements our IStudent interface and inherits from underlying Orleas.Grain Grain Implementation Orleans provides several helpers for managing Tasks No state is ever shared between grains or clients Local state only accessible from within grain Generate Task<string> from the string you wish to return

Running Your First Demo Download and install the Orleans SDK May also want to grab the latest Azure SDK at this time Create a grain interface project Create a grain collection project Create a DevTest silo using the VS project template Create a grain interface and corresponding grain Configure the client and server configuration files Run it!

Demo Time Creating a Standalone Grain Dev/Test Silo

Demo Time Implementing Grains in Azure

Recap Actors are isolated single-threaded components Orleans grains are like actors, but have differences (virtual actors) Grains encapsulate both state and behavior Developer interaction with grains is very familiar Object instances are similar grain references Runtime handles complexities that other actor frameworks do not: Actor placement and load balancing Deactivation of unused actors Actor recovery after server failures Indirection handled via a distributed directory

What’s the point? Why should I use this? This all looks really cool, but come on Chris… What’s the point? Why should I use this?

Here’s Why Grains are 3-tier architecture has limitations Low latency High availability Supremely scalable Promote reliability Extremely performant (will be discussed later) 3-tier architecture has limitations Throughput limits of the storage layer Storage layer has limited scalability due Storage layer that has to be consulted for every request

Orleans vs. Multi-Server 3-Tier Response time increases exponentially once resources begin to become strained Time (Response) Approximately even at low levels of consumption Orleans does suffer increased latency as it scales it’s silos Orleans Architecture 3-Tier Architecture Consumption (Transactions)

Come on… Let’s get into some more Advanced topics already!!!

Demo Time Implementing Grain Persistence

Demo Time Passing Grain References

Orleans is Dynamic Providers Custom Serializers Runtime Monitoring Azure Table SQL Server Memory (Grain) Roll your own Custom Serializers Runtime Monitoring Performance counters Silo statistics and metrics tables Liveness Provider Membership Table Grain Azure Table SQL Server Hosting Stand-alone Silo On-Premise Deployment Azure

Has it really been tested in the field? Who’s really using this? You may feel at this point that the framework is too new… Has it really been tested in the field? Who’s really using this?

Questions?

Orleans vs. Single Server 3-Tier Response time increases exponentially once resources begin to become strained Equilibrium point: Benefits of Orleans begin to shine Time (Response ) Orleans Architecture Network latency 3-Tier Architecture Consumption (Transactions)