Actor Model: Microsoft Orleans versus Microservice Design

Author: Thomas Nelson

Editor: Cynthia Hill, Ph.D.

“Be what’s next” - Microsoft

Software languages and tools have evolved over the years to support increasing users, data, and

abilities. Businesses invest trillions of dollars into building and maintaining their own

datacenters (networks and servers). Software architecture has changed to support the growth of

the internet since the 1990’s.

Clean coding and development patterns—that is, how we structure code-- were introduced to

solve complex issues that many developers have resolved with various issue-prone means.

Dependency Injection (a way of abstracting objects) and unit testing (maintaining correct results

with future code additions) were also added for code maintainability. As coding practices were

being cleaned up, service architecture was also in need of a new perspective.

Google and Netflix introduced and pioneered microservice architecture which breaks down the

services into smaller scopes of work and reusable pieces. This has become a popular solution for

an expanding client base since it utilizes many existing coding patterns that are executed on a

smaller scale. However, that Actor Model (concurrent computation in distributed systems) is

gaining popularity for cloud geo-decentralized architecture. Unfortunately, frameworks that

support the Actor Model have been difficult for expert developers to maintain and new

developers to learn. Microsoft saw this issue and created Project Orleans which significantly

reduced this barrier by abstracting complexities away from the developers. Microsoft Orleans is

a strong contender for the future framework choice of concurrent, distributed, cross-platform,
scalable, robust systems (Orleans is a cross-platform framework for building robust, scalable

distributed applications: Microsoft Orleans Documentation).

Microservice architecture (created in 2005 by Dr. Peter Rogers) is the current choice for both

small and enterprise development (Mauersberger, L.). Amazon and Netflix were pioneers (2011)

by successfully implementing the new design which allows multiple smaller deployments in a

tighter timeline (Mauersberger, L.). Microservices popularity also grew because monolithic

services grew to a nearly unmaintainable state that caused constant dependency issues.

Microservices are built very similarly to their larger cousins’ design, which makes switching an

easier task for developers to understand (Fig. 1). Work scope is reduced with the micro-

perspective which in turn increases quicker releases to market and risk. Additional benefits allow

instances to be horizontally scaled—that is, to make identical copies of instances— or vertically

scaled—that is, to bring additional resources (CPU cores, memory) --to expand as needed based

on needed throughput. Caching—which is, information stored in memory-- implementation is

also relevant as more services will need access to persistent data. Caching stores the results –on

demand—from the database to reduce the database’s load.

 Other service wanting to
save Reports

Gather Initial Compute Service

Information Service

Save Reports

Initialization Information Initialization Information Reporting Database

Fig. 1. Microservice Architecture. Microservices perform a single scope of work and can be
individually released as needed. In the example, work begins with gathering information which
consists of checking if the result is in the cache, otherwise the database will be queried. If a result
is returned from the database, the application will then save it in the cache for future use. Once
general information has been completed, it is sent to the compute service which performs work
based on the information received. The compute service follows the same database and caching
pattern and will then hand off the complete work to the report saving service. Finally, the
reporting service will convert the information into a tabular format in order to be saved for future
reporting.

Microservices are also designed for multi-use, for instance, only Save Reports has access to the

reporting database which increases security by not sharing access keys. Save Reports would

handle saving reports for other services as well. Supporting multiple entry points is due to the
high availability—multiple instances running—throughput is increased that allows a single

microservice act as an entry point for many others.

Currently microservices are used with:

• Websites

• Streaming services

• Document creation, such as PDFs

• Healthcare services

The actor model is an older concept than microservices and the internet. Carl Hewitt (MIT)

created the actor model in the 1970s as to lay a framework for artificial intelligence systems and

concurrent computation (Bernstein. P., Bykov, S.). An actor model is defined as “a mathematical

model of concurrent computation that treats "actor" as the universal primitive of concurrent

computation.” (Actor model) This means that equations derived a way to handle thousands to

billions of computation executions at the same time.

Actors are able to perform four overall operations with messages. 1. Local computations can be

performed in the event of receiving a message (Actor model). 2. An actor is able to create other

actors to perform other forms of work (Actor model). 3. Messages are able to be sent to other

locations (Actor model). 4. A response can be determined based on the next message received

(Actor model).
Fig. 2. Actor Model. Actors are fine-grained isolated objects—also referred to as things or
nodes—that receive and send asynchronous messages with the ability to create other actors
(Bernstein. P., Bykov, S.). Each actor also runs in an isolated state as to not expose the current
data to other grains until the work has been completed (modified from Der Meer, P.)
Erlang and Akka are popular actor frameworks that have simplified distributed system
programming (Bernstein, P., et al., 2014). Erlang has been used in multiple Ericsson
telecommunication systems (Erlang Programming Language). Scala is another language actor
toolkit while Akka is the Java version which allows developers to choose which languages they
would prefer.
Current technologies that actor models currently support:

• “Telecommunication systems, e.g. controlling a switch or converting protocols.

• Servers for Internet applications, e.g. a mail transfer agent, an IMAP-4 server, an HTTP

server or a WAP Stack.

• Telecommunication applications, e.g. handling mobility in a mobile network or providing

unified messaging.

• Database applications which require soft real-time behavior.” (Erlang Programming

Language)
Fig. 3. Design and Frameworks compared. This figure displays the differences of expandability
and flexibility. Monolithic applications are very large and do not port well to multiple areas
around the globe. Microservices are broken down and can be ported around the world by using a
cloud platform to monitor the service health. Erland/Akka/Scala create flexible and expandable
services; however, developers must maintain low level abstractions. Orleans’ framework
removes the tedious work while sustaining all of the positive attributes of Erlang/Akka/Scala.

Unfortunately, Erlang, and Akka are still a burden to developers because they provide low-level

abstractions (Fig. 3), which forces developers to maintain the complexities of distributed systems

(Bernstein, P., et al., 2014). One of the primary issues is determining how and when to return

resources of actors. An Actors’ lifecycle—activation, wait between jobs, and deactivation—

encompass some of programmers’ tedious duties. Determining lifespans for such large and
complex systems can lead to detrimental results when incorrectly implemented. Server resources

are extremely valuable and can be easily overused if actors do not release resources in time.

Project Orleans created and released (2015) the concept of virtual actors which removes a

majority of low-level abstraction issues from developers. Reliability and distributed resource

management are managed by the Orleans’ framework which also attains scalability with high

performance (Bernstein, P., et al., 2014). This was done by creating virtual actors—also known

as “grains” --which means the grains are active in memory at any given time (Bernstein. P.,

Bykov, S.). Active grains are a subset of grains that were created and saved in storage that have

been created dynamically within a hardware resource pool (Bernstein. P., Bykov, S.). Grains

automatically initiate and then return resources when they are no longer used (Bernstein. P.,

Bykov, S.). Developers that are experts or new to building distributed systems—Erlang and

Akka—do not need to tediously maintain the lifecycle (Fig. 3). Risk and development time are

significantly reduced by using a simpler framework and less code is used to maintain actors.

Orleans chose the actor model to expand due to its natural concurrency need with cloud

development. Today, we can see Orleans in use with video games (Halo 4), messaging (Skype),

and Internet of Things (IoT) (Honeywell). Orleans virtual actors’ concept is also tightly woven in

Azure’s service fabric’s reliable actors. Extreme production use has proven the framework’s

robustness through its performance with Halo 4. By utilizing distributed parallelism and high

throughput, simply adding additional CPU cores to the cluster proportionally increased the

system’s overall throughput capacity (Bernstein. P., Bykov, S.). Nearly perfect scalability was

observed when testing the fully utilized Halo 4 service growth from 25 to 125 servers (Bernstein.
P., Bykov, S.). There weren’t indications—bottlenecks—that servers can scale beyond 125

(Bernstein. P., Bykov, S.).

Orleans was also created to take advantage of the concurrent, geo-decentralized cloud platforms

(Azure, GCP, AWS) with asynchronous messaging. Cloud platforms (Fig. 3.) are a mesh of

remote servers hosted on the internet to process and store data (Cloud Computing: Definition of

Cloud Computing by Lexico). The platform allows applications developed to be hosted in

multiple remote locations without the creator/owner to set up their own datacenter(s) which must

also be maintained.

Databases Webpages Apis

Users Databases Apis External Cloud

Fig 4. Cloud Platform. Clouds are able to communicate within themselves and to external users,
database, applications, and other clouds. The ability to create instances in multiple locations at a
moment’s notice increases availability to multi-geographic locations, reduces time of
transactions, while reducing risk from redundancy.

Clouds are inherently concurrent and distributed while also interactive and dynamic where actor

model frameworks can thrive (Bernstein. P., Bykov, S.). Cloud development has and is forcing

architectural changes because user bases are global and deployments can be made world-wide

within minutes. It is very difficult for 3-tier architectures—such as microservices— to fill the

requirement of an ever-growing user base that expects highly scalable interactive services that

require high throughput with low latency while also being highly available (Bernstein, P., et al.,

2014). The actor model’s framework inherently supports these needs and is also the basis of

Azure’s Service Fabric design which manages microservices and containers (Athinanthny).

Microsoft noticed the strong correlation between cloud between cloud develop and actor

patterns. Microsoft’s Project Orleans was created to reduce the issues of previous actor

frameworks such as Erlang and Akka. These frameworks placed the responsibility of the actor

lifecycle, location, and management on the developers. Project Orleans removed the overhead by

creating virtual actors—also referred to as grains—that maintain their own lifecycle while the

framework maintains location transparency and management.

 Active
in memory

Activating Grain Deactivating

Persisted

Fig. 5. Grain Lifecycle. Each grain maintains its own lifecycle after creation. Grains are active in
memory. Once grains stop receiving tasks, they deactivate. The deactivated grain is then stored
and will be reactivated if new work is needed. Modified from (Orleans is a cross-platform
framework for building robust, scalable distributed applications: Microsoft Orleans
Documentation)

Orleans’ abstractions, guarantees of message delivery, and silo maintenance increases new and

experienced developers’ productivity (Bernstein. P., Bykov, S.). Developers using virtual grains

creates a sturdy, easy to use framework much like comparing a manual vehicle to an automatic.

It allows the developers to spend more time on the project needs and not maintaining the needs

of the architecture whereas microservices require additional support (Fig. 6).

 Microservice Actor Model

Clients Clients

Silo Silo Silo

Instances
A A A B Q

D A F H A

B F T G K Cluster
Y E S Q U

I F H D X

Database/Cache

Database

Fig. 6. Microservices (left) compared to Actor model (right). Both models begin with a client
creating an event that requires another application’s assistance. Pertaining to microservices, the
event received processed while likely contacting the cache and/or database in one or more calls.
Calculations can determine the scaling up and down of the service—creating or removing
identical services—as well as the threshold—CPU/Memory utilization—which determines when
services should be scaled up or down (Hamon, A.).

Actors are housed within silos—which create the actors—where multiple silos can work together

as a cluster. The benefits can be seen when small objects are distributed to a large number of

servers (Bernstein. P., Bykov, S.). Individual grains can connect to the database. Grains can also
be designed to run as cache and their states are stored in the database. This allows grains to pick

up where the previous grain has failed.

Silos message one another through Transmission Control Protocol (TCP). A single connection is

created between each silo where even large deployments need small number of connections

(Bernstein. P., Bykov, S.). As a result, millions of endpoints (places we send work to be done)

can be sustained without an operating system overhead per actor (Bernstein. P., Bykov, S.).

Understanding the difference between the architectures is key to determine which design better

supports the project at hand. Microservices are able to be distributed and are able to handle

various forms of work. Unfortunately, microservices are not naturally geo-decentralized and

instead need the support from platforms and other tools. However, Orleans is naturally

concurrent and designed for cloud development.

Primary differences between Microservice and Orleans

Microservice expansion to support client growth

Clients Clients

Growth

Application Instances Application Instances

Database Cache Database

Fig. 7. Microservice expansion to support client growth. Microservice instances need to scale out
to support additional throughput. When concurrent messages are being sent to the instances a
threshold can be met that will horizontally scale the service. As an example, each service may
consume 256 megs– 2 gigs of memory. If a single section of the service is being overutilized an
instance of the entire service will be initialized. Cache is also shown to be needed for larger
workloads however, it is not a scalable item. Cache can be implemented with the initial design or
determined through monitoring.
Orleans expansion to support client growth

Clients Clients

A A A A A

B B B
Growth

C C C

Grain Instances Grain Instances

Database Database

Fig. 8. Orleans expansion to support client growth. Grains scale individually as needed. Grains
scale out in the same manner of microservices by creating another instance of the grain. Grains
are much smaller—1-5 megs—which allows more to be ran at once and quicker to create when
needed. Grain states and persistent data is saved to the database. Grains are able to do “smart
caching” where a grain persists information as a result from the database; removing a need for a
third-party tool.

Orleans and microservices both scale up on demand (Fig. 7 and Fig. 8) by creating additional

instances. The difference is how scaling is obtained. Microservices cannot scale alone, they must

be placed on a platform—such as the cloud—to monitor and perform the scaling actions. The

platform monitors several items—such as, CPU and memory usage—and will create or remove

instances based on the thresholds supplied. In this case, scaling is limited to business and

developer knowledge that assumes the min and max limitations. These can become expensive

(256 megs per instance) resource usage.

Grains are much smaller (1-5megs) and isolated with the ability to pass messages across clusters

making scaling trivial to load requests (Bernstein. P., Bykov, S.). Orleans’ grains scale faster

because they are smaller and live in memory. Scaling is only based on the resources available.

This abstracts the need for developers to determine the number of instances allowed based on

historical or assumed information.

Caching can also be seen as a difference (Fig. 6. and Fig. 7) between structures. As requests

handled by the database, a cache is implemented. Cache can also be used to reduce responses

across the globe. Cache can be placed in areas closer to various users which require less time to

return results. Orleans accomplishes this same feat by running applications on geo-distributed

clusters (Bernstein. P., Bykov, S.).

Fig. 8. Microservices caching pattern. Microservices begin by accepting work and then check
cache for persistent information. Cache will hold the information until it has been cleared or
expires which breaks consistency and semantic guarantees of the database layer (Bernstein. P.,
Bykov, S.) The instance will query the database and use the result and finally store it in cache for
future use. Cache is added due to latency and throughput limits where a database is consulted
about every request (Bernstein, P., et al., 2014).

Orleans Caching Pattern

2 5
Cache

1 3 4

Action Db Call

6 4
Database
Fig. 10. Orleans caching pattern. Orleans uses cache in the same manner as microservices,
whereas not to overstrain the database. Action grain is given work and checks the Cache grain—
known as smart caching—where the data will be returned if available, otherwise Db Call grain
will be used to query the database. Action will then use same the information to Cache grain
when completing its work. If Cache or Db Call do not exist, they will be created when needed.

Caching is needed to reduce throughput for the expanding audience. Unfortunately,

microservices are not capable of handling this requirement and need the support of vendor tools,

such as Redis Cache or SQL Cache. The vendor’s cache is added to the architecture which forces

developers to maintain them which adds complexity, risk, and cost. However, Orleans’ grains

live in memory and can be designed as “smart cache” which removes the need of maintaining

vendor tools (Bernstein. P., Bykov, S.). Caching is a design pattern which means that developers

continue to support Orleans while not having to also support vendors’ tools.

Microservices should not be regarded as a bad architecture since developers can quickly

transform a monolithic application into microservices with a direction of an architect.

Microservices excel in handling large, complex files (batches and PDF creation) due to having a

large amount of ram and dedicated CPUs. Complex business logic is also easily implemented

and maintained (Kambalyal, C.). Services can also be reused across multiple dataflows when

implemented with a fractal realization pattern (Arsanjani, A.).

Architects commonly use the fractal realization pattern which takes the overall domain into

account to deconstruct existing/new services and rebuild/build them based on various work

scopes in order to be reusable. For example, when a project is created and utilized a third-party

tool for queue publishing. The product may be expensive and add unnecessary timeframes. A

queue publishing microservice can be build utilized by internal and external teams. Versus
applications that deal with a majority of independent objects that interact with one another

without large group operations really benefit from Orleans (Bernstein. P., Bykov, S.). Social

network graphs can be used as an example where multiple objects (pictures, posts, and messages)

relate to one another with ad hoc communications (Bernstein. P., Bykov, S.).

As with all frameworks and designs, they were created as a tool to complete a specific job. More

specifically, a project’s requirements dictate the design. Monolithic services being converted to

microservices has been very successful for many companies. Microservices perform very well

and excel with larger files and complex logic. Cloud platforms have been designed to support

microservice architecture. However, cloud development illuminated the issues with microservice

designs by requiring vendor solutions to support future user growth and transmission latency.

Microsoft Orleans’ virtual actor patterns fix these issues and are also able to handle geo-

decentralized, concurrent transmissions with ease. Orleans advancements have blurred the lines

(tedious coding) of what actor models traditionally support—such as telecommunications, instant

messaging, graphing, and real-time devices (IoT)—and has proven itself as a backend solution

(Service Fabric, Halo, Gears of War). Also having the fluid nature of virtual actors allow data to

flow in a natural manner (Bernstein. P., Bykov, S.). As it continues to grow with its helpful and

growing opensource (publicly available source code) community, it has potential to, “Be what’s

next”. (Wilhelm, A.)

References:

Actor model. (2019, December 10). Retrieved December 11, 2019, from

https://en.wikipedia.org/wiki/Actor_model

Athinanthny. (n.d.). Overview of Service Fabric on Azure. Retrieved December 19, 2019, from

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview

Bernstein. P., Bykov, S. (2016, October 25). Developing Cloud Services Using the Orleans

Virtual Actor Model Retrieved November 17, 2019, from

https://ieeexplore.ieee.org/document/7676196/

Bernstein, P., Bykov, S., Geller, A., Kliot, G., & Thelin, J. (2014, March 24). Orleans:

Distributed Virtual Actors for Programmability and Scalability. Retrieved November 17,

2019, from https://www.microsoft.com/en-us/research/publication/orleans-distributed-

virtual-actors-for-programmability-and-scalability/

Cassar, I., & Francalanza, A. (2016, June 01). On Implementing a Monitor-Oriented

Programming Framework for Actor Systems. Retrieved November 17, 2019, from

https://link.springer.com/chapter/10.1007/978-3-319-33693-0_12

Cloud Computing: Definition of Cloud Computing by Lexico. (n.d.). Retrieved December 11,

2019, from

Datacenters Follow. (2010, June 14). 3-Tier Architecture. Retrieved November 17, 2019, from

https://www.slideshare.net/datacenters/3tier-architecture
Erlang Programming Language. (n.d.). Retrieved December 11, 2019, from

https://www.erlang.org/

Hamon, A. (2019, April 04). Do the Math: Scaling Microservices Applications with

Orchestrators. Retrieved December 11, 2019, from

https://www.toptal.com/devops/scaling-microservices-applications

Kambalyal, C. (n.d.) 3-Tier Architecture Arsanjani, A. (November 09, 2004). Service-oriented

modeling and architecture

Lee, E. (2003, Sept. 24). Model-driven development - from object-oriented design to actor-

oriented design. (n.d.). Retrieved November 17, 2019, from

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.230.1295

Mauersberger, L. (2019, January 29). Microservices: What They Are and Why Use Them.

Retrieved December 11, 2019, from https://blog.leanix.net/en/a-brief-history-of-

microservices

Orleans is a cross-platform framework for building robust, scalable distributed applications:

Microsoft Orleans Documentation. (n.d.). Retrieved December 11, 2019, from

https://dotnet.github.io/orleans/

Vturecek. (n.d.). Service Fabric Reliable Actors Overview. Retrieved December 19, 2019, from

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-

introduction

Wilhelm, A. (2010, November 08). Microsoft has filed trademark for their new slogan, 'Be

What's Next'. Retrieved December 18, 2019, from

https://thenextweb.com/microsoft/2010/11/09/microsoft-has-filed-trademark-for-their-

new-slogan-be-whats-next/