Your SlideShare is downloading. ×
Orleans – a “cloud native” runtime built for #azure
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

309
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
309
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
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. Orleans – A “cloud native” Runtime Built for #Azure By Alexandre Brisebois @Brisebois http://bit.ly/1lc9W3Bbrisebois@outlook.com
  • 2. Forget about 3-tier architectures They don’t scale! @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 3. Forget about 3-tier architectures They don’t scale! • Stateless frontends • Stateless middle tier • Storage is the bottleneck • Latency • Throughput • Scalability @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 4. Forget about 3-tier architectures They don’t scale! • Much better performance • Lost semantics of storage • Lost concurrency control @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 5. High-scale interactive services demand high throughput with low latency and high availability. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 6. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 7. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 8. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 9. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 10. Servers != Services @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 11. Services != Servers @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 12. Meet Actors They enable applications to attain high performance, reliability and scalability @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 13. Start thinking in terms of Actors • Performance of cache • Riche semantics • Concurrency control • Horizontal calls are natural • OOP paradigm • But there are still challenges @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 14. 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 @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 15. Welcome to Orleans https://orleans.codeplex.com @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 16. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 17. • Virtual Actor model • Location transparency • Actors are .Net objects • Messaging through .Net interfaces • Asynchronous through async/await in C# • Automatic error propagation • Implicit activation & lifecycle management • Coordinated placement • Multiplexed communication • Failure recovery @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 18. Actors are called Grains @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 19. Grains #2,548,308 #2,031,769 Activation #1 @ 192.168.1.1 Activation #1 @ 192.168.1.5 @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 20. 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 brisebois@outlook.com@Brisebois
  • 21. Concurrency is hard! Distribution, high throughput and low-latency make it even harder Grains are Single Threaded @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 22. 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 brisebois@outlook.com@Brisebois
  • 23. Grain Activations reside in Silos Think of Silos as virtual memory (RAM) @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 24. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com http://bit.ly/Ry526A
  • 25. Stateful Grain Instances reside in cold storage The Activation (state) can be persisted to cold storage @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 26. Hello World! @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 27. public interface IHello : IGrain { Task<string> SayHello(string greeting); } Grain interfaces Marker interface to indicate grain interfaces All grain interface methods must be asynchronous
  • 28. 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
  • 29. 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 grains Factory Class is auto-generated at compile time Grain Id (long , GUID or String)
  • 30. Give us an other example! @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 31. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 32. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 33. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 34. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 35. Azure & Orleans @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 36. 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…
  • 37. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 38. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 39. @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 40. A cloud native runtime
  • 41. What does Orleans bring to cloud services in Azure? @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com • A powerful Virtual Actor concept • Familiar programming model • Smooth learning curve for developers new to asynchronous programming
  • 42. What does Orleans bring to cloud services in Azure? @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com • Faster development through separation of concerns (OOP) • Makes cloud-scale programming attainable
  • 43. What does Orleans bring to cloud services in Azure? @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com • Uncompromised performance • Scalability by default • Fewer concurrency hazard concerns and headaches • Simplified failure handling through error propagation
  • 44. Scalability by default?? @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com • 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
  • 45. Orleans – A “cloud native” Runtime Built for #Azure By Alexandre Brisebois @Brisebois http://bit.ly/1lc9W3Bbrisebois@outlook.com
  • 46. Using Orleans to Build Halo 4’s Distributed Cloud Services in Azure http://bit.ly/1g6V5c3 @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 47. 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 brisebois@outlook.com
  • 48. Orleans: Distributed Virtual Actors for Programmability and Scalability http://bit.ly/1gkv43A @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 49. Orleans: Cloud Computing for Everyone http://bit.ly/QqiUik @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 50. Orleans: A Framework for Cloud Computing http://bit.ly/1hDX4j0 @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 51. Scenarios @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 52. Devices send telemetry to the Cloud Per-device actors process and pre-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
  • 53. 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
  • 54. Scenario from Halo 4 @Brisebois http://bit.ly/1lc9W3B brisebois@outlook.com
  • 55. 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
  • 56. Heartbeat
  • 57. Update game status
  • 58. Player grain
  • 59. Client observer