23

Both seem like parallel MPI communicating network of processes. I identify actors with services. Are actors more dynamic (you can create them and kill as breathing whereas service network is more static) or what?

11

Actor model - is mathematical model for concurrent computations, and microservices - an implementation of service-oriented architecture. The similarities are quite coincidental.

It's certainly possible to build microservices based on some actor model, and model some microservice architecture with actor model, but it does not mean these are equivalent. Replace "microservice system" with "email system", and it will still be true. Replace "actor model" with "Communicating sequential processes" (CSP), and it will be also "true", because CSP and actor model systems can be modelled by one another.

Given actor model you can go and implement it using microservices, or SOA, or even email, but it does not mean they are at the same level of abstraction to truly compare.

Also, actor model emphasizes buffers (can be thought of as message queues in microservices world), so some actor/microservice can be not ready while inherently asynchronous communication is still possible.

In other words, comparison with actor model can bring some creative insights at some very high level of consideration, but mostly it's apples vs oranges.

If the goal is to compare mathematical model of SOA / microservices to Actor model, then it also not trivial, because: 1) there is no agreed upon mathematical model for SOA, 2) model usually includes the purpose. And SOA/microservices modelling is very likely to be different from the actor model purpose. One example of attempt to model SOA here.

Of course, one can create actor model system with microservices and call each service an actor (refer to strict definition of what actor model is). But this does not mean there is any meaningful relation between the two in general sense.

  • I mean that actor model can't be compared with microservices on the same level. Let me update my answer – Roman Susi Dec 26 '16 at 19:00
  • I do not say that. Microservices can implement actor mode, as well as assembly or C programs can. But I do not say they always do or even often. And yes, Erlang is also an example of actor model implementation. Not sure I understand your argument. – Roman Susi Dec 26 '16 at 19:04
  • Sorry, I first did read that Actors are mathematical model and uServices implement (that model). I have not noticed that they implement Service Architecture. So, my question is how two mathematical models, Actors and SOA compare to each other. A service is something that has a message loop which accepts requests and generates response messages. This is what Actor is/does. What is its difference from microservice in SOA? In ohter words, when I have a distributed network of services, should I refer to them as microservices or actors? – Little Alien Dec 26 '16 at 19:26
  • Note that this is a question and answer site, not a forum or newsfeed. Monikers such as UPDATE and EDIT are not necessary; every post on Stack Exchange already has a detailed edit history that anyone can view. – Robert Harvey Dec 26 '16 at 20:00
1

Microservices are a way to organize software by splitting each area of concern into its own deployable artifact (executable, script, JAR, WAR, etc). This gives you flexibility, for example by allowing you to scale by deploying more instances where they're needed. Say users spend more time looking at your catalog than they do adding things to a shopping cart; one deployable artifact handles catalog functions, another handles shopping cart functions -- you can run more copies of the catalog services to handle the load.

It also isolates them from internal changes. Say you move from a relational database to a document database for storing product data -- odds are your shopping cart services won't need to change.

The actor model is a lower level than the deployable artifact, more about what types of objects you've implemented the service with. Continuing with the above example, you may have the shopping carts in your system represented by actors, so every user's cart is a distinct actor, and messages tell it to add items, remove items, respond with the current contents, add shipping, check out, etc. In this case, you still have a microservice, and it's implemented with the actor model.

  • When you have told that you can have multiple instances of the same service, I started to think that it is opposite: service is a type whereas actors are objects :) – Little Alien Jan 11 '17 at 11:52
  • Actors can not be deployed individually? Are you sure? dotnet.github.io/orleans/Documentation/Grain-Versioning/… – Daffy Punk Feb 5 '18 at 12:50
  • To me it seems that there is, implementation wise, maybe a bit of a convergence occurring between the two concepts... – Daffy Punk Feb 5 '18 at 12:50
1

I'd say that the main difference is one of granularity.

For the actor model it's relatively fine-grained, in that an actor tends to represent the equivalent of one object in OOP.

For micro-services it's relatively coarse-grained, in that a single micro-service may consist of a large number of actors or objects.

Note that you wouldn't really need to stretch your imagination too far to say that modern web is just the same thing at an even larger granularity ("macro-services"); and that (e.g.) a HTTP server is a macro-service, a database server is a macro-service, a web browser is a macro-service, etc.

It's all roughly the same - isolated pieces that communicate. It's only the size of the pieces (and therefore the number of pieces) that change.

  • Every java application, no matter how larger, is a single object. Objects are made of other objects and can grow indefinitely larger. I guess that uServices are also kinds of application that are made of other objects. – Little Alien Jan 11 '17 at 10:39
0

Microservices scale horizontally by creating multiple replicas, each of which is capable of serving requests due to the stateless nature of the service. They are resilient to failure by virtue of their stateless nature.

Actors scale by moving them to partitions with less load or more available resources. They are stateful. They are resilient to failure because -- depending on the actor framework -- another actor could be spun up dynamically or a hot backup of the actor could be maintained at all times to deal with the primary actor failing.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.