Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Akka Cluster Works: Actors Living in a Cluster

lightbend.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: How Akka Cluster Works: Actors Living in a Cluster

#31

Post by darksaints »

tunesmith wrote: post #2

In scala-land, a lot of people like to scoff at Akka because they prefer other pure fp concepts, but I don't think they've found a replacement for Akka Cluster - where you need objects that have both state and behavior, meaning they need to exist in memory, and where there are too many to exist on one server. If you don't need behavior, you can use things like distributed databases or caches, and if you don't need to…

I don't think the scala crowd scoffs at Akka because they are beholden to pure functional programming. The pure FP crowd is actually a minority...significant enough to acknowledge, but not enough to make or break anything about the community.

The real problem with Akka is that, at least until very recently, you had to abandon any semblance of type safety if you used it. That was very frustrating to work with. I can take or leave pure FP, but you can pry my strong static typing from my cold dead hands.

Re: How Akka Cluster Works: Actors Living in a Cluster

#32

Post by acjohnson55 »

aaronmill1 wrote: post #27
tormeh wrote: post #23

The actor model is brilliant, but I fear it will never get the adoption it deserves because it's too much of a break from convention. I guess it's maybe a bit too much of a leap? It replaces both Kubernetes and messaging queues, so once you've made software with it it's kinda hard to back out to a vanilla programming model. There's of course the legit downside of needing to use one language and one framework for all…

How would the actor model replace Kubernetes?

The way I see it, Kubernetes (with some type of message bus) is in some ways a system for deploying processes that will carry out process, kind of like actors. It doesn't use the same formalisms, but functionally, it's quite similar. Or, you could say that Akka Cluster is like Kubernetes, except that every process is contained within an Actor and has to be written in Java or Scala.

Re: How Akka Cluster Works: Actors Living in a Cluster

#33

Post by acjohnson55 »

29athrowaway wrote: post #21
halfmatthalfcat wrote: post #15

Earlier quoted context omitted.

They have Cluster Singletons that alleviate this concern now. You don't need to know their physical location in the cluster. All you need to do is ask the cluster for a pointer to the Singleton and you can message it directly.

That's cool. I wish I had this in 2014.

I used Cluster Singleton with much success, starting at the very beginning of 2016: https://github.com/artsy/atomic-store/

Re: How Akka Cluster Works: Actors Living in a Cluster

#34

Post by acjohnson55 »

halfmatthalfcat wrote: post #14

I use Akka Cluster extensively with Persistence. It's an amazing piece of technology. Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive o…

I'd echo this.

I worked for a company that made a real-time auction system, based on Akka. It's been frustrating in the years since to program on less powerful foundations.

If I were building a system that combined interactive and autonomous processes, I would absolutely reach for Akka again. The one thing I'd love to see is if they could build something like https://temporal.io on top of Akka. I think it would be complementary to the state machine style model of typed actors and the pipeline model of Akka Streams.

Re: How Akka Cluster Works: Actors Living in a Cluster

#35

Post by dragonwriter »

tormeh wrote: post #23

The actor model is brilliant, but I fear it will never get the adoption it deserves because it's too much of a break from convention. I guess it's maybe a bit too much of a leap? It replaces both Kubernetes and messaging queues, so once you've made software with it it's kinda hard to back out to a vanilla programming model. There's of course the legit downside of needing to use one language and one framework for all…

> There's of course the legit downside of needing to use one language and one framework for all actors

That's not inherent in the actor model, it's a potential artifact of some implementations. Though I think one VM is more common. E.g., BEAM instead of just Erlang, or JVM for Akka.

Re: How Akka Cluster Works: Actors Living in a Cluster

#36

Post by t-writescode »

valenterry wrote: post #30
t-writescode wrote: post #4

I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka Cluster was "why would I use this when I already have a message queue infrastructure?" Maybe real Akka is better than Akka.NET when it comes to Akka Cluster?

Akka Cluster works in-memory, RabbitMQ doesn't. Say you want to have multiple actors (one per user / customer or whatever) and you get HTTP requests and want that exactly this actor handles them (to guarantee consistency), then you can't really do this with RabbitMQ. I mean, you can make the machine that receives the request push it to the queue and keep the http connection alive, have the machine that is responsible…

At that point, you're still operating on a single machine, though, and you don't need Akka Cluster for that.

Re: How Akka Cluster Works: Actors Living in a Cluster

#37

Post by dragosmocrii »

halfmatthalfcat wrote: post #18
amelius wrote: post #16

Earlier quoted context omitted.

Could one implement a distributed filesystem using Akka?

You could but I don't think it would be the best tool for it. When I think of Akka, I'm using it because I don't want to worry about which node in my cluster any given actor is on, I just want to be able to scale horizontally and messages are routed appropriately. Akka embraces the "let it fail" mentality where as nodes go down (just as pods go down in Kuberentes), you don't have to worry about where your processes a…

Sounds like Akka and Erlang/Elixir have a lot in common

Re: How Akka Cluster Works: Actors Living in a Cluster

#38

Post by valenterry »

t-writescode wrote: post #36
valenterry wrote: post #30

Earlier quoted context omitted.

Akka Cluster works in-memory, RabbitMQ doesn't. Say you want to have multiple actors (one per user / customer or whatever) and you get HTTP requests and want that exactly this actor handles them (to guarantee consistency), then you can't really do this with RabbitMQ. I mean, you can make the machine that receives the request push it to the queue and keep the http connection alive, have the machine that is responsible…

At that point, you're still operating on a single machine, though, and you don't need Akka Cluster for that.

I don't understand what you mean.

In my scenario, multiple machines are used and necessary for the same service (otherwise there is no point in using Akka Cluster).

Example: online games. You have room/game being created on the fly and it is destroyed an hour later. There are many of these rooms and they are distributed over multiple machines. You can't really use rabbitMQ here, it's not performant enough.

And even if you did, you would pretty much reimplement what Akka Cluster does for you: instance synchronization, different strategies for handling split brain scenarios, dead letter handling, direct message forwarding, persistence (if needed) and so on

Re: How Akka Cluster Works: Actors Living in a Cluster

#39

Post by playing_colours »

halfmatthalfcat wrote: post #14

I use Akka Cluster extensively with Persistence. It's an amazing piece of technology. Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive o…

I remember using Akka in the domain of IoT. A persistent actor represented a sensor: state and history of readings. There was a great feature in Akka Persistence: if an actor went idle for a while - no new sensor data, it would be offloaded from memory to the storage (Cassandra). As soon as the sensor started to send new signals again or the sensor state was queried by a user the actor got loaded back to memory.

Re: How Akka Cluster Works: Actors Living in a Cluster

#40

Post by jpcooper »

hilbertseries wrote: post #11
jpcooper wrote: post #6

Carl Hewitt, the inventor of the actor model, wrote this paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 , which he posted a link to on a recent post here on Erlang. In it, he claims that Godel's Incompleteness Theorem is not true, and that the actor model is more general than the Turing machine. I am open to entertaining the idea. I've seen that his ideas have been discredited elsewhere on HN. I w…

> he claims that Godel's Incompleteness Theorem is not true, and that the actor model is more general than the Turing machine He is certainly wrong about the incompleteness theorems. And it’s entirely possible to create a model of computation that is more general than Turings. The question is whether it better represents what’s computable, the abstract mentions computations involving an “infinite number of computatio…

How is he wrong about GIT?

What more general systems of computation are there than Turing? Are any in use? Are they really more general?

The claims of the generality of Actors seem to rely on continuous time and non-determinism. Actors, determinism, non-determinism, concurrency and the completeness axiom are models which we can use to express computation and our surroundings, and nothing more.

One man says lambda, another says actor. Given our models of physics; given Planck and Heisenberg, are they really different? If so, how? Measure theory rests on the completeness axiom, but it is just a very useful axiom.

Am I missing something?

Post reply on HN