5 ms·
I'm also very positive on Akka having been deep into Cluster and Streams and Actors over the last few months. The barrier to entry is high because the problems
by Tanjreeve 5y ago
I'm also very positive on Akka having been deep into Cluster and Streams and Actors over the last few months. The barrier to entry is high because the problems Akka is appropriate for are complicated. Every time I want to complain I imagine managing state in a performant way using "simple" threadlocks or Futures and then magnify that over a distributed application.
- sorokod 5y agoCan you share a use cases where Akka provides a more performant solution over ""simple" threadlocks or Futures" ?
- tunesmith 5y agoIf you're talking about Akka Cluster sharding, basically any situation where you have distributed objects that have their own state and behavior. I've had two projects where objects needed to stay in memory so they could receive messages, update their state, and then behave by sending messages to other objects. And it was too many objects to live in one server. The naive solution of data repositories and caching isn't really sufficient for this, and a horizontally scaled Akka Cluster Sharding setup with Persistence was the right solution given the requirements.
- Tanjreeve 5y agoIt's not going to be more performant than the constructs it's built off for a Hello World application. But unless you are a deep expert in concurrency and memory management (and have a team who can keep up) if you have a complex problem of concurrency and scale then the Application built in Akka will have high odds of getting to production readiness and stay maintainable while being performant and not getting bogged down in memory issues and shared state performance issues. That difference in the odds of success increases by an order of magnitude again once you start talking about distributed data.
- sorokod 5y agoI'd like to form my own opinion on the trade-offs. Can you share a use case please?
- Tanjreeve 5y agoThe most obvious case for Actors are usually anything where the time to process something isn't predictable and you need to manage state of that process. So the common example is Chatroom session management where some sessions might last 5 seconds and others might last for days. Likewise Games companies have built multiplayer gaming servers using Akka. Telcos and others are common users. For me personally I'm using Akka to mangage the processing and reprocessing of a lot of entities through some algorithms where the processing time can't be known upfront and the data is unbounded. In terms of wanting something to tinker with then I guess building a chat application backend is probably the easiest one to demonstrate the complexity of trying to manage that (and there are also some demos in the docs as well)
- sorokod 5y agoThank you. Would be interesting to compare Akka based solution to your problem with a hand rolled alternative.
- Tanjreeve 5y agoThe other decent alternative for some of these problems are often some flavour of messaging queues and event sourcing. E.g for the chat system you could probably shoot messages through a broker and then send a "chat finish" message. The disadvantage of this is if your broker is under heavy load then your chat app will perform linearly worse under increasing load while using the actors and state mean you can have a lot more stuff happening concurrently without the problems of waiting for events to go through a queue hence the latency advantages. Let alone if your servers are ephemeral and changing constantly then that's just another level of complexity to manually roll to keep your session state going that pretty much comes out the box to a production standard in akka persistence and sharding.