Actors v.s. HTTP

Question

I don't really get if there is much of a difference between using actors and using HTTP endpoints for communication between processesses.

Documents online say all the time “actors receive messages and can change state”… well, so do HTTP endpoint functions.

HTTP can call async functions, so the fact that actors can be sync and async does not set them apart.

Oh, and if the difference is that actors can be self healing, or that some actors can create or kill other actors, well… using tech with http such as reverse proxies and/or kubernetes solve the same issues.

What am I missing? What differentiates actors from simply using the HTTP protocol, endpoints, and reverse proxies?

I am sure an answer to this question will not only help my confusion, but also that of a person with the same confusion in the future.

Answer 1

You seem to be conflating a few issues.

Why does Akka have its own RPC instead of HTTP.

The answer is routing/reliability. Akka is meant to hugely distributed systems, and when you do raw HTTP, how do you keep all the routes correct for each message? Also, with huge numbers of machines, how do you ensure each call happens once and only once on your cluster?

Why bother with Actors?

Actors are a pattern for highly concurrent systems. Actors allow developers to reason where state lives and where processes live, separate them out, and allow the actor runtime to quickly run huge numbers of actor instances without worrying about complex things like "threads" and "thread-safety".

When you get to a certain point in your career, you will find that "thread-safety" is incredibly hard to do right. Heck, my favourite programming language is one that is famous for forcing you to do threading correctly. The problem is that, without some systematic process to write your code, two seemingly unrelated lines of code in completely different projects can produce subtle bugs that are hard to reproduce.

Another paradigm for highly concurrent systems is Functional Programming, that however has massive performance penalties associated with it.

TLDR

The Actors pattern is designed to solve problems you encounter in large sprawling codebases with many non-genius level developers working on it at the same time, running on hundreds of servers.

Answer 2

Actors have nice property named "transparent locality", ie when you send a message, you don't care whether the receiver is local or remote. When it is local, the message delivery is quite cheap (ie you can deliver millions of messages per second at least in C++ actor systems), but for network messages (it can be http(s)) the amount is measured by (tens of) thousands.

So, the nice consequence, that you can relatively easily scale your app from single node over network cluster of nodes, or, you can offload some traffic from local node over network. So, actors, gives you some architectural flexibility in scaling. Without actors, you have a very strict border between locally processed requests/data and remotely processed, and moving between them is usually non-trivial task, might even affect architecture.