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?
The difference between Actor model and Microservices
actor-modelmicroservicesterminology
Related Solutions
The short answer is no, it's not correct.
starts reasonably correct (each Actor at least potentially executes as an independent thread), but then largely goes off the rails. There's nothing about the model that makes lots of threads work well -- that's up to the implementation. At most, the ease of creating lots of threads puts pressure on the implementation to provide efficient threading. At least as far as the model cares, any resemblance between actors and objects is mostly coincidental. "Object" carries fairly specific implications about how you combine code and data. An actor will generally involve both code and data, but implies little about how they're combined (other than the fact that the only data visible to the outside world is messages).
The usual way of describing the interaction is as message sending, yes. I don't have a citation handy, but somebody proved quite a long time ago that mechanisms like C++ virtual functions are isomorphic to message sending (as virtual functions are normally implemented, you're using an offset into a vtable -- but if you sent an offset into a table of messages instead, the effect would be the same).
It's not quite that simple. If you can find a copy, Henry Baker (with somebody else whose name I don't remember right now) wrote a paper about the rules necessary for data consistency in the Actor model.
"Better" is highly subjective at best. Some problems are highly parallel in nature, and really do involve a large number of essentially autonomous entities, with minimal interaction that's primarily asynchronous. When that's the case, the actor model can work very well indeed. For other problems, that's really not the case. Some problems are almost entirely serial in nature. Others can be executed in parallel, but still require close synchronization between those actions (e.g., essentially a SIMD-like mode, where you execute one instruction at a time, but each instruction acts on on a large number of data items). It's certainly possible to solve both of these types of problems using the actor model -- but for such problems, it often involves a fair amount of extra work for little or no gain in return.
Concurrency and parallelism are two related but distinct concepts.
Concurrency means, essentially, that task A and task B both need to happen independently of each other, and A starts running, and then B starts before A is finished.
There are various different ways of accomplishing concurrency. One of them is parallelism--having multiple CPUs working on the different tasks at the same time. But that's not the only way. Another is by task switching, which works like this: Task A works up to a certain point, then the CPU working on it stops and switches over to task B, works on it for a while, and then switches back to task A. If the time slices are small enough, it may appear to the user that both things are being run in parallel, even though they're actually being processed in serial by a multitasking CPU.
Best Answer
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.