What are the actors? What are they used for? And how can we develop them? And how are they published and used on Azure? Let's see how it's done in this session

1. 1
TOPIC
Developing Actors
in Azure with .NET
Marco Parenzan

2. Thanks for collaboration

3. Marco Parenzan
Senior Solution Architect @ beanTech/Smart Factory
1nn0va Community Lead (Pordenone)
Microsoft Azure MVP
Profiles
Linkedin: https://www.linkedin.com/in/marcoparenzan/
Slideshare: https://www.slideshare.net/marco.parenzan
GitHub: https://github.com/marcoparenzan

4. 4
TOPIC
Developing Actors
in Azure with .NET
Marco Parenzan

5. Agenda
The need for a state
What is an Actor?
Already players in the Actor’s arena (really?)
Many ways to create actors
.net Orleans
Azure Durable Entities
Azure Digital Twins
“my own actor”

6. The need for a state
Scaling 3-tier architecture
(statelessstateful)
Data stream processing
Sampling
Aggregation
IoT
GPS Tracker (RFID, inventory, cars)
Counters (running total)
Sensor data
Service
Service Service
Stateless Services

7. My own problem
«Light» time window aggregation
Redis is good but not enough
Concurrency problem is «probabilistically» minimized, but not
solved
I worked on it about three years ago:
https://www.slideshare.net/marco.parenzan/stateful-stream-
processing-of-iiot-events-with-c-and-containers
Evaluate runtime expressions
Mature for enterprise grade «scripting languages»
Heavy for stateless approach
I’m still working on it:
https://www.slideshare.net/marco.parenzan/math-with-net-for-
you-and-azure

8. DEMO

9. shared state
concurrency, locks, and all that jazz
Stateful Services

10. What is an Actor?
The actor model in computer science is a mathematical
model of concurrent computation that treats actor as the
universal primitive of concurrent computation.
In response to a message it receives, an actor can: make
local decisions, create more actors, send more messages,
and determine how to respond to the next message
received.
Actors may modify their own private state, but can only
affect each other indirectly through messaging (removing
the need for lock-based synchronization).
From: https://en.wikipedia.org/wiki/Actor_model

11. Fundamental concepts
The actor model adopts the philosophy that everything is an
actor. This is similar to the everything is an
object philosophy used by some object-oriented
programming languages.
An actor is a computational entity that, in response to a
message it receives, can concurrently:
send a finite number of messages to other actors;
create a finite number of new actors;
designate the behavior to be used for the next message it
receives.

12. Multithreading
Thread 1
Objects
Thread 2
Objects
Shared
Resource

13. Actor Model
Single threaded
Not per actor, but thread
pool
One message at a time
(internal message queue)
No data sharing
Message passing
Actor
Single
Thread Internal
State

14. Actor Model
Message Passing

15. Points
Always expressed as theorydifficult
Affinity with microservices
it’s own state
Affinity with DDD
bounded contexts (messaging to get out the others)
aggregate roots (responsible for its own work)

16. Already players in the Actor’s arena (really?)
Sure!
Erlang
Azure Service Fabric
Akka.netThe «best»...but really the winner?
DAPRMicroservices in K8s (Actor is always one scenario)
What’s happened
Orleans is now .NET Foundation project since 2021
(https://dotnetfoundation.org/projects/spotlight?project=Orleans)
Alignment with with ASP.NET Core development model

17. .net Orleans

18. Grains and Silos
Grain: a virtual actor
Silo: a server instance,
holding many grains
Turn: processing a message
Activation: single living
instance of a grain

19. Activation and Life Cycle
Grains always “exist”
The runtime activates them as needed
They are deactivated automatically after an idle period or
when requested
Can control what happens on activation/deactivation
Comparison with normal actors:
Control creation, full life cycle, hierarchy

20. Handling Failure
No supervision hierarchies
Exceptions are thrown back to the caller
Grains on dead nodes are automatically reactivated
elsewhere by the runtime

21. Location Transparency
No actor path
Just a grain ID
Actors are allocated automatically to different nodes
Typically, you would not know where an actor lives
Forces you to think distributed first

22. Asynchrous Messaging
No need to declare a message class
Methods provide an abstraction
Grain methods must be asynchronous
Must return Task or Task<T>
Enforced by the runtime
Invocation patterns
Await: preserves order, affects throughput
Fire and forget: parallel (faster, no ordering)

23. Orleans is …
… runtime and programming model for building distributed
systems based on actor model
Built by eXtreme Computing Group in MSR in 2014
(https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/Orleans-MSR-TR-2014-41.pdf)
Has been used internally (during last few years)
Open-sourced in 2015
built for *
Scalability
Availability
Reliablity

24. Routing Problems supported
Cluster Membership
Workload Distribution
Static
Distributed Consensus
Dynamic
Timeouts
Lifecycle
Co-location
10.0.0.1
10.0.0.2
10.0.0.5
10.0.0.8

25. DEMO

28. Azure Durable Entities

29. Azure Durable Functions
Write long-running orchestrations as a single function while
maintaining local state.
Simplify complex transactions and coordination (chaining,
etc.) Easily call a Function from another Function,
synchronously or asynchronously.
All of the above using code-only. No JSON schemas. No
graphical designer.
Generally available (v1). Supports multiple languages (C#,
JavaScript)

30. Durable Functions Scenarios

31. Orchestrator
Function
Activity
Function
Starter
Function
Activity
Function
Activity
Function
Components

32. Durable Entities

33. DEMO

34. Azure Digital Twins

35. Anatomy of a Digital Twins Solution
A Digital Twin instance
IoT Hub and Connected Devices
One or more client apps that connects with the DT Instance
Create and manage a fraph o twin instances
Extract insight from twin state
A set of Azure functions or other propessing resources for
custom processing
Downstream services fro long-term storage, bulk data
analutics, etc

36. Azure Digital Twins PaaS
Platform for developers to model the real world
Controlled using a rich set of REST APIs
And Azure Portal and CLI
C# SDK available for Public Preview
SDK for additional languages coming
Parser library for validation and “reflection” over DTDL

37. Open Modeling Language
Create custom domain models using «Digital Twins Definition
Language» (DTDL)
Model sdescribe twins in terms of
Telemetry
Properties
Commands
Relationships
Components
Models define semantic relationships to connect twins into a
knowledge graph
Models can specialize other twins using inheritance
Digital Twins Definition language is aligned with:
IoT Plug and Play
Time Series Insights data model
More defined rather that IoT Hub
New!

38. Simple interface example
The top level of any twin
description is called an
interface
At the top level the twin
description has a dnumber of
necessary fields:
@id
@type
Contents
@type
Name
Schema
@context

39. Live execution environment
Create a live execution environment from the DTDL models in
ADT
Abstraction from writing into a DB
Abstraction from hosting a twin in...a container, a function, an app
service
Twin instances and relationships form a live graph
representation of the environment
Use a rich event system to drive business logic and data
processing.
Extract insights from the live execution environment with a
powerful query API
Query using rich search conditions, including propertu values,
relationships, replationship properties, type information and more

40. DEMO

41. “my own actor”

42. Windows Azure Service Bus 101
Queues
brokered messaging communication model
components of an application don’t communicate directly, but
rather exchange messages via an intermediary queue
One-to-one, asynchronous, follows FIFO
Topics & Subscriptions
pub/sub messaging communication model
components of an application don’t communicate directly, but
rather exchange messages via an intermediary topic
one-to-many, can register multiple subscriptions to a topic, each
message sent to a topic is available for each subscription to
handle independently

43. Queues
Decouple sender and receiver
One or many senders.
One or many (competing)
receivers.
Load leveling Receiver is never
overloaded, process at its own
pace.
Temporal decoupling Allows taking
the receiver offline for servicing.
Load balancing Multiple receivers
compete for messages.
Sender Receiver
Sender
Receiver
Sender
Sender
Receiver

44. Topics & Subscriptions
Senders send to a topic
Receivers receive from
subscription
Each subscription has one
copy of the message.
Filters, Rules and Actions
Message distribution
Deliver the same message
to more than one client.
Subscribers can filter by
interest.
Message partitioning
Receiver get mutually
exclusive slices of the
message stream.
Sender
Receiver
Sender
Sender Receiver
F1
F2
Receiver

45. Features of Service Bus
Sessions
Ordering
Duplicate detection

46. DEMO

47. Conclusions

48. Conclusions
State is still bad
K8s help visualize that it can be not so bad
It’s an approach, not just a library
It is not yet common, so from a pure biz view, it can be risky
It can be a game changer in some areas

49. The various projects: Orleans
Pro
Towards full product with full Microsoft support
Integrated with modern .NET 6.x / .NET 7.x timeline
Can be hosted under App Service Plan
Cons
Towards full product with full Microsoft support...really?
No real success at the moment
Hosted under Container Apps?

50. The various projects: Durable Functions
Pro
Azure Function Success
Hosting in App Service Plan and on premise
Cons
Architecturally «slow» (event basis, not streaming basis)
Rigid persistence (table storage and just few providers)

51. The various projects: Azure Digital Twin
Pro
Azure strong IoT member
Big momentum
Cons
No on-edge product
No strong acceptance

52. The various projects: my own actor
Pro
Your actor, your success
Messaging syncronization...not so bad, not so difficult
Full control and adaptation
Service Bus is a really strong infrastructure
Cons
Your actor, your success...your work, your pains 
Lot of work, probably
Service Bus probably is not suitable for thousands of
subscriberspartitioning?

53. Thanks
Questions?
marcoparenzan marco_parenzan marcoparenzan