[HN Gopher] Ask HN: Are you using actors in production? Why/Why ...
___________________________________________________________________
Ask HN: Are you using actors in production? Why/Why not?
In the realm of distributed computing, it seems like there are
folks that believe very strongly in the actor pattern. However,
they generally seem to be pretty niche? That said, this perspective
could be entirely due to my bubble, and so I was curious to hear
from folks that are using them in production, and how well they've
worked out in practice. Or, if you've evaluated using them in
production, but decided against it, I'd love to hear about that as
well!
Author : lostintangent
Score : 20 points
Date : 2022-03-20 18:08 UTC (4 hours ago)
| closeparen wrote:
| We run Flink for stream processing and Spark for batch
| processing, both of which are backed by Akka (and therefore the
| actor model).
| lostintangent wrote:
| Very dumb question: when you say backed by Akka, what exactly
| do you mean? That you've configured a "binding" between
| Flint/Spark and Akka, which spins up actor instances
| (Java/Scala classes?) whenever some events occur? Or that
| Flint/Spark use Akka behind the scenes?
| closeparen wrote:
| They both use Akka behind the scenes. I don't know the
| internal details exactly, but they're both capable of showing
| you the processing pipeline you've asked for as a DAG
| visualization. I think what's happening is something like
| each node on that DAG is an actor, receiving data from the
| previous node and sending it along to the next. You don't
| write that though, you just write map/filter/etc.
| weltmeister wrote:
| Imho its not so much the actor pattern but the single writer
| principle.
|
| actors are a tool which is not to used solely. Need encapsulate
| state? Actors can help. Need concurrency? Perhaps futures are a
| better fit.
|
| the question you ask is problatic at it sees actors as a single
| solution.
| evanmoran wrote:
| Let me second this. For example in Go, the simplest way to use
| a channel is to queue work to it from several endpoints. Then
| another Go routine can pull it off, usually becoming the
| exclusive writer of whatever the next step the computation is.
|
| So even though Go has this green/micro thread behavior behind
| the scenes (go routines), it's main innovation is around the
| concurrency safe queue (the channel) so those threads can
| communicate.
|
| Now with actors you can imagine more of a pattern where each
| holds its own state and messages cause them to modify
| themselves or send messages to other actors. This behaves more
| like AI in a game simulation and is useful if independence
| rather than coordination is a good solution to the problem.
|
| For lots of services this is not the case as the fastest path
| through all the queues is the best path and the problem isn't
| about deciding what to do independently or hiding state within
| the actor but throughput through known paths. So that's the
| difference. If you are tagging video with ML you want queues
| and throughput, if you are reacting to routing networking
| messages based on simple rules (erlang) you want actors.
| lostintangent wrote:
| I _really_ appreciate this reply! Naively speaking, when I
| look at actors, I just can't think of why they'd be superior
| to coordinated queues/channels, except for within an
| arbitrarily configurable, rules-based system (e.g. game NPC
| behavior, network routing). But I couldn't help but assume
| this was dramatically oversimplifying the problem/missing the
| point.
|
| If someone were using Go routines and channels, what do you
| think is the "clear" moment that they would benefit from
| actors? When the sequence of steps in a workflow are non-
| deterministic?
| jwstarr wrote:
| We use them both implicitly (underlying Akka Streams) and
| explicitly (both classic untyped actors and typed actors).
|
| For the explicit actors, we use them to model state machines
| around I/O (e.g. stateful protocols). I've found that the
| application area is fairly niche, as many patterns of async work
| are clearer through queues, futures, or streams. The use of
| actors is insulated from the rest of the application code through
| interfaces that use futures or streams. But, internally, if you
| have to manage complex state where events can occur at any time
| and a mail-box like/internal queue is sufficient, then they tend
| to be easy to understand... once the initial ramp-up period is
| over.
|
| Additionally, I've found them to require very little maintenance
| as developers tend to get to 100% _flow_ test coverage without a
| lot of difficulty.
| lostintangent wrote:
| Are you using Akka for your explicit actors as well?
|
| And could you share the distinction between typed and untyped
| actors? Is that related to how the caller addresses/accesses
| methods on that actor?
| mk89 wrote:
| I have been using Akka in production for several years now and
| it's one of the best things I ever did.
|
| The actor model itself is really good, it makes you think about
| problems differently, and in my opinion it's better than
| traditional OOP.
|
| The only issue I have had with Akka is with the tooling around
| metrics/logging of async calls. The rest, what can I say, it's in
| production and I am barely on call because of issues- certainly
| not because I write bug free code, but because I believe the
| framework is really solid, while the actor model makes you think
| in a different and probably more simplified way which might help
| with developing simpler solutions.
|
| I have also the feeling that it's niche, because of simpler
| frameworks like Springboot that offer most of what you need out
| of the box and it doesn't require additional "learning".
___________________________________________________________________
(page generated 2022-03-20 23:01 UTC)