How Akka Cluster Works: Actors Living in a Cluster • Hacker News Board

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

#21

Post by 29athrowaway » Sun, Jan 17, 2021, 12:58 AM UTC

halfmatthalfcat wrote: post #15

29athrowaway wrote: post #7

I used Akka cluster many years ago. One of the problems I encountered was that to finding actors in remote actor systems. i.e.: you have a unique actor responsible for X, living somewhere in your cluster and you need to know its name as well as the IP address of the actor system where it is running. A message queue solves this problem, but that was not the approach I took. My solution was to implement an actor discov…

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.

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

#22

Post by alextheparrot » Sun, Jan 17, 2021, 1:18 AM UTC

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 wonder what it would look like trying to implement something like the IO monad backed by Akka actors. Can't recall anything off the top of my head that would make that untenable aside from the aforementioned scoffing.

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

#23

Post by tormeh » Sun, Jan 17, 2021, 1:40 AM UTC

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 actors, which is a problem Kubernetes and a message queues don't have.

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

#24

Post by lostcolony » Sun, Jan 17, 2021, 1:57 AM UTC

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…

'legit downside of needing to use one language and one framework for all actors' - which is why a lot of Erlang users use it for coordination of messages, and delegate their handling to other services as needed.

That said, most work places I've been at, leadership has -wanted- to use one language. Even with containers and other decoupling technologies. So I don't know how much of a negative effect that downside has.

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

#25

Post by halfmatthalfcat » Sun, Jan 17, 2021, 2:01 AM UTC

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…

It doesn’t replace Kubernetes, it is the ultimate companion.

Kubernetes deals with the OS/node level failures, the actor system deals with the application level failures.

It’s actually amazing how complementary they are.

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

#26

Post by macintux » Sun, Jan 17, 2021, 2:01 AM UTC

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…

Dr. Hewitt often pops up to discuss Erlang and the actor model here, so you might have the opportunity to ask him for more details.

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

#27

Post by aaronmill1 » Sun, Jan 17, 2021, 3:08 AM UTC

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?

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

#28

Post by thelittlenag » Sun, Jan 17, 2021, 3:10 AM UTC

alextheparrot wrote: post #22

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 wonder what it would look like trying to implement something like the IO monad backed by Akka actors. Can't recall anything off the top of my head that would make that untenable aside from the aforementioned scoffing.

Take a look at ZIO Actors (https://zio.github.io/zio-actors/).

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

#29

Post by blandflakes » Sun, Jan 17, 2021, 3:45 AM UTC

lostcolony wrote: post #24

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…

'legit downside of needing to use one language and one framework for all actors' - which is why a lot of Erlang users use it for coordination of messages, and delegate their handling to other services as needed. That said, most work places I've been at, leadership has -wanted- to use one language. Even with containers and other decoupling technologies. So I don't know how much of a negative effect that downside has.

I've sort of come around in my career to aggressively simplifying the stack where possible... it's handy to be able to script stuff but I don't actually enjoy running a polyglot team. We get a lot more done with one language, one build tool, etc. I tend to save other languages for niche applications (e.g. Lua for nginx scripting).

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

#30

Post by valenterry » Sun, Jan 17, 2021, 5:23 AM UTC

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 for the user read it from a queue and then somehow tell the first machine how to respond the http request... but then you pretty much re-implemented Akka Cluster in a worse way.

Persistent queues and Akka Cluster solve different usecases.