Orleans – a “cloud native” runtime built for #azure

Orleans – A “cloud native” Runtime Built

for #AzureBy Alexandre Brisebois

@Brisebois http://bit.ly/[email protected]

Forget about 3-tier architectures They don’t scale!

@Brisebois http://bit.ly/1lc9W3B [email protected]

Forget about 3-tier architectures They don’t scale!• Stateless frontends• Stateless middle tier• Storage is the bottleneck• Latency• Throughput• Scalability


Forget about 3-tier architectures They don’t scale!• Much better performance• Lost semantics of storage• Lost concurrency control


High-scale interactive services demand high throughput with low latency and high availability.






Servers != Services


Services != Servers


Meet Actors They enable applications to attain high performance, reliability and scalability


Start thinking in terms of Actors

• Performance of cache• Riche semantics• Concurrency control• Horizontal calls are natural• OOP paradigm• But there are still challenges


Challenges with Actor Model Frameworks• Too low level• App manages lifecycle of actors, exposed to distributed races• App has to deal with actor failures, supervision trees• App manages placement of actors – resource management

• Developer has to be a distributed systems expert


Welcome to Orleanshttps://orleans.codeplex.com@Brisebois http://bit.ly/1lc9W3B [email protected]


Distributed Actor runtime• Virtual Actor model• Location transparency

Built for .Net• Actors are .Net objects• Messaging through .Net interfaces• Asynchronous through async/await in C#• Automatic error propagation

Runtime execution container• Implicit activation & lifecycle management• Coordinated placement• Multiplexed communication• Failure recovery

Actor

Runtime


Actors are called Grains


Grains

Grain Type Grain (Instance) Grain Activation

Game Grain Type

Game Grain (Instance) #2,548,308

Game Grain (Instance) #2,031,769

Game Grain #2,548,308Activation #1 @ 192.168.1.1

Game Grain #2,031,769Activation #1 @ 192.168.1.5


Grains: Virtual actors

• Grain instances always exist, virtually• Needn’t be created, looked up or deleted• Code can always call methods the grain• Grains never fail

• Activations are created on-demand• If there is no existing activation, a message sent to it triggers instantiation• Lifecycle is managed by the runtime• Transparent recovery from server failures• Runtime can create multiple activations of stateless grains (for performance)

• Location transparency• Grains can pass references to one another around• References can be persisted to cold-storage

http://bit.ly/1lc9W3B [email protected]@Brisebois

Concurrency is hard!Distribution, high throughput and low-latency make it even harderGrains are Single Threaded


Grain execution model

•Activations are single-threaded• Optionally re-entrant• Runtime schedules execution of methods• Multiplexed across threads

•No shared state• Avoid races• No need for locks

•Cooperative multitasking

http://bit.ly/1lc9W3B [email protected]@Brisebois

Grain Activations reside in SilosThink of Silos as virtual memory (RAM)



http://bit.ly/Ry526A

Stateful Grain Instances reside in cold storageThe Activation (state) can be persisted to cold storage


Hello World!


public interface IHello : IGrain{ Task<string> SayHello(string greeting);}

Grain interfacesMarker interface to indicate grain interfaces

All grain interface methods must be asynchronous

public class HelloGrain : GrainBase, IHello{ Task<string> SayHello(string greeting) { var resp = "You said: '" + greeting + "', I say: Hello!"; return Task.FromResult(resp); }}

Implementing the grain type

private async static Task SendMessage(long grainId) { IHello friend = HelloFactory.GetGrain(grainId); string response = await friend.SayHello("Good morning!"); Console.WriteLine("Response: {0}", response);}

Talking to grainsFactory Class is auto-generated at compile time

Grain Id (long , GUID or String)

Give us an other example!






Azure & Orleans


Common characteristics• Large numbers of independent actors

• Free-form relations

• High throughput/low latency• These generally dictate stateful compute

• Fine-Grained partitioning is natural

• Cloud-based scale-out & elasticity

• Much broader developer audience

Orleans was built for…

Scenarios• Social graphs

• Mobile backend

• Internet of things

• Real-time analytics

• ‘Intelligent’ cache

• Interactive entertainment




A cloud native runtime

New Silo

Unavailable Silo

New Activation New Activations

What does Orleans bring to cloud services in Azure?


• A powerful Virtual Actor concept• Familiar programming model• Smooth learning curve for developers new to asynchronous

programming



• Faster development through separation of concerns (OOP)• Makes cloud-scale programming attainable



• Uncompromised performance• Scalability by default• Fewer concurrency hazard concerns and headaches• Simplified failure handling through error propagation

Scalability by default??


• Near linear scaling to hundreds of thousands of requests per second• Efficient resource usage• Location transparency simplifies

scaling up or down• Complements Azure PaaS• Easily adjust scale over time

Test Lab Numbers

Orleans – A “cloud native” Runtime Built

for #AzureBy Alexandre Brisebois

@Brisebois http://bit.ly/[email protected]

Using Orleans to Build Halo 4’s Distributed Cloud Services in Azure

http://bit.ly/1g6V5c3@Brisebois http://bit.ly/1lc9W3B [email protected]

Tackle Distribution, High Throughput and Low-Latency with Orleans – A “cloud native” Runtime Built for #Azure

http://bit.ly/1og5ZOI@Brisebois http://bit.ly/1lc9W3B [email protected]

Orleans: Distributed Virtual Actors for Programmability and Scalability

http://bit.ly/1gkv43A@Brisebois http://bit.ly/1lc9W3B [email protected]

Orleans: Cloud Computing for Everyone

http://bit.ly/QqiUik@Brisebois http://bit.ly/1lc9W3B [email protected]

Orleans: A Framework for Cloud Computing

http://bit.ly/1hDX4j0@Brisebois http://bit.ly/1lc9W3B [email protected]

Scenarios


Devices send telemetry to the Cloud

Per-device actors process andpre-aggregate incoming data

Multi-level aggregation by actors

Statistics, predictive analytics, fraud detection, etc.

Control channel back to devices

Grouping by location, category, etc.

Elastically scales with # of devices

[Near] real-time analytics

Actors hold cache values

Semantic operation on values

Function shipping (method calls)

Coordination across multiple values

Transparent on-demand reactivation

Write-through cache with optional batching

Intelligent cache

Scenario from Halo 4


Near-real-time processing

State is mostly in memory

Constantly evolving social graph

A fraction of total user base online

Very high throughput, low latency

Inherent races

Presence service

Game Session Grain A

Game Session Grain B

Game Session Grain C

Player Grain X

Player Grain Y

Player Grain Z

Presence(Router)Grains

GameClient

MobileClient

Heartbeat




Player Grain X

Player Grain Y

Player Grain Z


GameClient

MobileClient

Update game status




Player Grain X

Player Grain Y

Player Grain Z


GameClient

MobileClient

Player grain




Player Grain X

Player Grain Y

Player Grain Z


GameClient

MobileClient

Client observer




Player Grain X

Player Grain Y

Player Grain Z


GameClient

MobileClient

Technology

Orleans – a “cloud native” runtime built for #azure