DEV Community


Actor model vs Microservices

stereobooster profile image stereobooster Originally published at on ・2 min read

This idea happened recently to me: what if microservice is a reinvention of the wheel? What if microservices try to accomplish the same thing as actor model?

I’m not the first one who asked this question

There is a similar question on StackExchange. I’m not convinced by given answers.

Actor model - is a mathematical model for concurrent computations, and microservices - an implementation of service-oriented architecture.

And? There are a lot of things that can be used for computations, for example, Lambda calculus (formal system in a logic ), billiard balls, quantum, live cells, Game of life. The fact that they are in different categories doesn’t prevent to use all of them for computations.

Again, microservices could be stateful too, but it goes against the design principles of microservices.

Right, but you need to store the information somewhere (accounts, records, users)? If you don’t count the database as service itself, the same logic can be applied to the actors.

What if?

For microservices, you need to use some kind of protocol for communication, like REST, Protocol Buffer, GraphQL, and many more examples. In actor model it is not harder than a function call.

When you deploy microservices it assumes that each microservice is isolated in its machine (virtual machine, jail, docker, etc.), because of this you end up with big number of machines, it is hard and expensive to deploy a lot of machines instead you can deploy virtual machines and to do this you need to use Kubernetes or similar. Where is in actor model you deploy actors to cluster and they can be spread automatically.

When you work with microservices you need to use distributed tracing to debug issues. In actor model you can use “stack trace” (which can be a feature of the programming language itself).

When you develop microservices you start to put everything in separate repositories, but then it’s hard to do changes across multiple services, so you put everything in monorepo. It feels like we are walking in circles.

The big difference is that you in microservices you can use different programming languages, but in actor model you need to use one (not counting external interfaces and shell calls).

Once a programmer becomes used to a complex solution to a problem, simple solutions to the same problem feel incomplete and uncomfortable.

Doug Hoyte

Disclaimer. I’m not referring to any specific implementation of actor model, it’s a more idealistic version of actor model. I hope that pony can come close to what I imagine, but I haven’t played with it yet.

Discussion (8)

Editor guide
avalander profile image
Avalander • Edited

I think that the actor model and micro-services solve entirely different issues. The problem that micro-services solve is not parallelization of computations, but organizational scaling.

In a tech organization with 80 developers working on the same product, it's easier to split the services into mostly independent and self-contained smaller services than can be developed and maintained by a small team.

While it is technically possible to have everything in the same application and have every team commit to the same repository and deploy everything together, splitting it into smaller chunks gives each team more autonomy and the possibility to adapt and set up different processes for different services.

redbar0n profile image

Actually, localised autonomy is also very important in the Actor model as well:

So I think the overlap could be quite good.

coreyoconnor profile image
Corey O'Connor • Edited

In reading a book about distributed systems (edit: see reply for details) I ran across a similar thread. Liked the idea so much I built an EDSL in Scala for this. Will official release in a free weeks. :) Here's what an example looks like:

Would love your thoughts on that example. :)

The getting started guide is being completed as I write this:

coreyoconnor profile image
Corey O'Connor

The reference was: "Programming Distributed Computing Systems" by Varela (2013). On pg 172 they discuss a particular aspect of the SALSA (2001) programming language (a language by the same author):

"The ActorService ... is used to annotate behaviors whose instances are not to be garbage collected. The reason is that it is possible to create references to instance of behaviors implementing this interface from their [host and path]"

They proceed to describe how an instance of an ActorService would be routed using a host and path. They are, in effect, describing technology similar to a proxy plus service. However, their specific representation is inappropriate for microservices. Interesting tho :)

vertigo profile image

"Right, but you need to store the information somewhere (accounts, records, users)? If you don’t count the database as service itself, the same logic can be applied to the actors."

Actors are stateful by having internal state (no pun). Microservices (if stateless), treat every request without (internal) knowledge of the past, while actors might carry state over to the next message (Hence one of their core principles is 'decide what to do with the next message').

phlash909 profile image
Phil Ashby • Edited

I found the linked slides from Rotem Hermon enlightening:

and I knew I'd seen something similar before, it was Microsoft's Orleans:

In essence: the Actor Model (a mathematical concept from 1973) can be implemented as a set of services (micro, nano, chose your buzzword!), and that's what Orleans does to provide an opinionated, scaleable platform for developing parallel applications without all the inherent risks of rolling your own distributed architecture.

Other opinionated platforms that are similar: Map/Reduce, Apache Spark, AWS Lambda, all of which isolate/protect the developer from the details of distributing and scaling their code by placing some constraints on it (typically requiring stateless operation between instances).

The Actor Model can also be implemented in a non-distributed single application, allowing it to operate effectively on a multi-core processor without the inherent risks of writing your own multi-threaded software.

Some languages were designed to embody the Actor Model:

hope this helps!

adam_cyclones profile image
Adam Crockett

Thought provoking article, nice! Ps visited your blog to help you out, every little helps.

stereobooster profile image
stereobooster Author

Thought provoking article

Thank you! This reaction is exactly what I hoped for.