Your SlideShare is downloading. ×
Project Orleans - Actor Model framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Project Orleans - Actor Model framework

1,021

Published on

Project "Orleans" is an Actor Model framework from Microsoft Research that is currently in public preview. It is designed to make it easy for .NET developers to develop and deploy an actor-based …

Project "Orleans" is an Actor Model framework from Microsoft Research that is currently in public preview. It is designed to make it easy for .NET developers to develop and deploy an actor-based distributed system into Microsoft Azure.

Published in: Software, Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,021
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
14
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PROJECT “ORLEANS” Neil Mackenzie
  • 2. Who Am I • Neil Mackenzie • Azure Lead –Satory Global • neil.mackenzie@satory.com • @mknz • http://convective.wordpress.com • Author: Microsoft Windows Azure Development Cookbook • Microsoft MVP forWindows Azure
  • 3. Agenda • Actor Model • Project “Orleans” • Developing with Orleans • Demonstration • Q&A
  • 4. ACTOR MODEL
  • 5. Actor Model • Core concepts: • Actor – stateful entity • Message – communication token passed between two Actors • When an Actor receives a message it can concurrently: • Send messages to other actors • Create newActors • Change its internal state • No guaranteed order for delivery of concurrent messages • Created by Hewitt, Bishop and Steiger in the 1970s • Many implementations including Erlang and Akka
  • 6. PROJECT “ORLEANS”
  • 7. Cloud Compute Problems • Cloud compute uses commodity hardware • => need to design for failure • => need to scale horizontally • Distributed computing is a hard problem • Need new paradigms to simplify things • SQL -> NoSQL • NoSQL stores hide data sharding from developers • Can we use an Actor Model to simplify distributed compute?
  • 8. Project “Orleans” • .NET Implementation of an Actor Model • Goals: • Provide easy-to-use distributed compute model for developers • Provide deployment model scaling from one node to a high-scaleAzure cloud service • Developed by Microsoft Research • Currently in public preview • Used in production by 323 Industries for Halo presence and game statistics
  • 9. Grains and Silos • Orleans has the following concepts: • Silo – deployment host for grains • One or more silos per compute node • Grain (Actor) • Eternal existence – but activated into a silo when invoked • Automatically garbage collected when not used (and memory pressure on silo) • Different activations of the same grain may be into different silos • Messages implemented as proxied method invocation • Exist in stateless and stateful versions • Always accessed through a grain reference
  • 10. Deployment Models • Orleans provides the following deployment models: • In-process – development/debugging inVisual Studio • Single host – development/debugging inVisual Studio • Multiple hosts – DIY production deployment • Azure Cloud Service – high-scale production deployments
  • 11. Use Cases • Orleans good for: • Systems with large numbers of simple entities (social, devices) • Loosely connected systems • Intelligent caching • Orleans not good for: • Strongly-coupled systems • Compute-intensive tasks
  • 12. ORLEANS DEVELOPMENT
  • 13. Development Model • Design grain interfaces • Implement grain interfaces • Implement deployment model
  • 14. Grain Interface • A grain is defined by its grain interface which specifies the messages it can receive • Grain interface: • Is derived from IGrain • Exposes messages as public methods returningTask orTask<T> • Supports method parameters • Does not support property set methods (avoid properties) • Visual Studio tooling creates client proxies from the grain interface
  • 15. Grain Interface - Example public interface IDeviceGrain : Orleans.IGrain { Task<String> GetName(); Task SetName(String deviceName); Task<Boolean> SetStatus(DeviceStatus deviceStatus); } public interface IControllerGrain : Orleans.IGrain { Task AddDevice(IDeviceGrain device); }
  • 16. Grain Implementation • A grain implementation class: • Is derived from GrainBase or GrainBase<TGrainState> • Implements the grain interface • Base class methods: • ActivateAsync • DeactivateAsync • GetLogger
  • 17. Grain Implementation - Example public class DeviceGrain : Orleans.GrainBase, IDeviceGrain { private String name; public Task<String> GetName() { return Task.FromResult(name); } public Task SetName(String deviceName) { name = deviceName; return TaskDone.Done; } }
  • 18. Referencing Grains • Orleans tooling creates proxy classes and a factory class for each grain interface • Use the factory class – GrainInterfaceNameFactory – to access a grain reference var grain = HelloGrainFactory.GetGrain(0); String response = grain.SayHello("Walking to New Orleans").Result; • Orleans runtime provides a transparent distributed locator service • A grain may be activated on any silo • Each silo has a grain-location cache
  • 19. Concurrency Model for Grains • Orleans uses a cooperative multithreading scheduler • Scheduler schedules only one message at a time for a grain • A message is processed completely before another message is scheduled • A message is processed as a sequence of one or more turns (continuations) async Task<Boolean> DoThings() { await serviceGrain.DoSomething; Boolean success = await serviceGrain.DoSomethingElse(); return success; } Turn 1 Turn 2 Turn 3
  • 20. Grain Persistence • Orleans provides automated state persistence • Do the following: • Define aTGrainState class to hold the persisted state • Use GrainBase<TGrainState> as the base class for the grain implementation • State property automatically hydrated when grain is activated – ReadStateAsync() • State must be persisted programmatically –WriteStateAsync() • Storage provider named in class definition, configured in Orleans configuration • Storage providers: in-memory (development), AzureTables
  • 21. Advanced Grain Features • Stateless worker grain • Can be scaled out automatically by Orleans runtime • Always activated in-silo • Reentrant grain • Can have interleaved message turns (i.e., they can be scheduled out of turn) • Remindable grain • Can receive scheduled reminders from Orleans runtime • Observer grain • Can observe events happening on other grains
  • 22. UsingTask andTask<T> • CompletedTask with void return TaskDone.Done; • CompletedTask<T> with a specific value: Task.FromResult(value); • Fan-outTasks List<Task> promises = new List<Task>(); for (Int32 i = 0; i < 10; i++) { var someGrain = SomeGrainFactory.GetGrain(i); promises.Add(someGrain.DoSomething()); } awaitTask.WhenAll(promises);
  • 23. Visual StudioTooling • Project Orleans provides 3Visual Studio project types • Orleans Dev/Test Host – creates a console app with an Orleans silo for development purposes • Orleans Grain Class Collection – contains the grain class implementations • Orleans Grain Interface Collection – contains the grain interfaces
  • 24. Downloads and Documentation • Download Orleans: http://aka.ms/orleans • Samples & Documentation https://orleans.codeplex.com/ • Microsoft Research page for Project Orleans: http://research.microsoft.com/en-us/projects/orleans/default.aspx • Channel 9 discussion on the Actor Model with Hewitt, Meijer and Szyperski bit.ly/1nOAtW9
  • 25. Summary • Project “Orleans” provides: • A .NET implementation of an Actor Model • A highly-scalable deployment model • Development support inVisual Studio • Deployment support for MicrosoftAzure • With the goal of simplifying the task of creating distributed systems for developers not skilled in the art

×