Q
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?
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.
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.
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.