actor model: microsoft orleans versus microservice design · current technologies that actor models...
Post on 18-Aug-2020
0 Views
Preview:
TRANSCRIPT
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.
Gather Initial Information Service
Compute Service
Save Reports
Other service wanting to 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.
ApisDatabases Webpages
ApisDatabases External CloudUsers
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
Deactivating
Persisted
Activating Grain
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).
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
Microservice Actor Model
Cluster
Instances
Database/Cache
Clients
A A
D A
B F
Y E
I F
A
F
T
S
H
B Q
H A
G K
Q U
D X
Silo Silo Silo
Database
Clients
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
Cache Database
Application Instances
Clients
Application Instances
Database
Clients
Growth
Microservice expansion to support client growth
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.
Database
Grain Instances
Clients
Grain Instances
Database
Clients
Growth
Orleans expansion to support client growth
A
B
C
A
B
C
A A A
C
B
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).
Action
Cache
Db Call
1
2
3 4
4
5
6
Orleans Caching Pattern
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/
top related