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.
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.
Top comments (8)
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.
Actually, localised autonomy is also very important in the Actor model as well: youtu.be/e5kek8vx2ws?t=1593
So I think the overlap could be quite good.
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:
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
ActorServicewould 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 :)"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').
I found the linked slides from Rotem Hermon enlightening:
speakerdeck.com/rore/actors-and-mi...
and I knew I'd seen something similar before, it was Microsoft's Orleans:
microsoft.com/en-us/research/proje...
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:
wiki.c2.com/?ActorLanguages
hope this helps!
Thought provoking article, nice! Ps visited your blog to help you out, every little helps.
Thank you! This reaction is exactly what I hoped for.