Real-time services such as e-commerce, online gaming, and social media demand an interactive, dynamic cloud computing application and platform as their workload continues to grow. However, designing those scalable and reliable computing applications can be complicated and challenging. Are you facing such challenges? If yes, view this slides to learn how to ‘Build distributed, highly scalable applications in .NET using Microsoft Orleans’. In this slides, you will find out: - How to build a scalable computing application - How to protect applications from perils of concurrency - The need to simplify programming in the cloud

1. Build distributed, highly scalable applications
in .NET using Microsoft Orleans

2. Agenda
Introduction – Microsoft Orleans1
Grains and Grain Persistence2
Cluster Management3
Streaming, Observers, Reentrancy4
Q & A5

3. Implementation is based on
the Actor Model
Actor
Model
Orleans grains are virtual
actors
Orleans
Grains
Physical instantiations of
grains are completely
abstracted away and are
automatically managed by
the Orleans runtime
Physical
Instantiations
Virtual Actor Model - High-
scale dynamic workloads
like cloud services
Virtual
Actor Model
Build distributed high-scale computing applications without the need to learn and
apply complex concurrency or other scaling patterns
Introduction

4. Introduction
Typical stateless n-tier model
Orleans as a Stateful middle tier

5. Stateful 3-tier Architecture
State
Event
Stream
System
WEB hosts
with
Orleans clients
Orleans cluster

6. Grains
What is a
grain
Grain
Identity
• Primitives of the Orleans programming model.
• Building blocks of an Orleans application, they are atomic units of
isolation, distribution, and persistence.
• Objects that represent application entities.
• An individual grain is a uniquely addressable instance of a grain
type (class).
• Each grain has a unique identity, also referred to as a grain key,
within its type.
• Grain identity within its type can be a long integer, a GUID, a string,
or a combination of a long+string or GUID+string

7. Grains
Accessing a
Grain

8. Grains
Active in
Memory
Deactivating
Persisted
Activating
Grain
Lifecycle
Activation
• Constructor of the grain is executed leveraging
Dependency Injection, if applicable
• If Declarative Persistence is used, the grain state
is read from storage
• If overridden, OnActivateAsync is called
Deactivation
• The grain remains idle for some time
• Silo runtime decides to deactivate the grain
• Silo runtime calls OnDeactivateAsync, if
overridden
• Silo runtime removes the grain from memory

9. Grain Persistence
Orleans provides different type of storage providers for persisting the
grain state
AzureTableGrainStorage AzureBlobGrainStorage DynamoDBGrainStorage
MemoryGrainStorage AdoNetGrainStorage
SQL Server
MySQL/MariaDB
PostgreSQL
Oracle

10. Cluster Management
Orleans provides cluster management via a built-in membership protocol, which we sometimes
refer to as Silo Membership. The goal of this protocol is for all silos (Orleans servers) to agree on
the set of currently alive silos, detect failed silos, and allow new silos to join the cluster.
Azure
Table Storage
Apache
Zookeeper
Consul IO AWS
Dynamo DB
In memory emulation
for development setup
Membership Table Implementations

11. Streaming
Streaming extensions provide a set of abstractions and APIs that make
thinking about and working with streams simpler and more robust
Makes the programming model compatible with and portable across a
wide range of existing queuing technologies, such as Event Hubs,
ServiceBus, Azure Queues, and Apache Kafka
No need to write special code or run dedicated processes to interact with
such queues
For receiving data from streams implicit/explicit subscriptions can be
used

12. Reentrancy
Grain activations are single-threaded and,
by default, process each request from
beginning to completion before the next
request can begin being processing.
In some circumstances, it may be desirable
for an activation to process other requests
while one request is waiting for an
asynchronous operation to complete
• The grain class is marked as [Reentrant]
• The interface method is marked as
[AlwaysInterleave]
• The requests within the same call chain
• The grain's MayInterleave predicate returns true

13. Other Core Concepts
1 Timers and Reminders
2 Request Context
3 Event Sourcing
4 Grain Services
5 Interceptors
6 External Tasks and Grains
7 Stateless Worker Grains

14. Demo

15. Q & A
• Website: www.winwire.com
• Email: marketing@winwire.com
• Blog: http://www.winwire.com/blog/
• Twitter: @winwire