What are the best use cases for Akka framework

Question

I have heard lots of raving about Akka framework (Java/Scala service platform), but so far have not seen many actual examples of use cases it would be good for. So I would be interested in hearing about things developers have used it succesfully.

Only one limitation: please do not include case of writing a chat server. (why? since this has been overused as an example for lots of similar things)

Solution 1

I have used it so far in two real projects very successfully. both are in the near real-time traffic information field (traffic as in cars on highways), distributed over several nodes, integrating messages between several parties, reliable backend systems. I'm not at liberty to give specifics on clients yet, when I do get the OK maybe it can be added as a reference.

Akka has really pulled through on those projects, even though we started when it was on version 0.7. (we are using scala by the way)

One of the big advantages is the ease at which you can compose a system out of actors and messages with almost no boilerplating, it scales extremely well without all the complexities of hand-rolled threading and you get asynchronous message passing between objects almost for free.

It is very good in modeling any type of asynchronous message handling. I would prefer to write any type of (web) services system in this style than any other style. (Have you ever tried to write an asynchronous web service (server side) with JAX-WS? that's a lot of plumbing). So I would say any system that does not want to hang on one of its components because everything is implicitly called using synchronous methods, and that one component is locking on something. It is very stable and the let-it-crash + supervisor solution to failure really works well. Everything is easy to setup programmatically and not hard to unit test.

Then there are the excellent add-on modules. The Camel module really plugs in well into Akka and enables such easy development of asynchronous services with configurable endpoints.

I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.

Solution 2

Disclaimer: I am the PO for Akka

Besides offering a concurrency smorgasbord that is much simpler to reason about and to get correct (actors, agents, dataflow concurrency) and with concurrency control in the form of STM.

Here are some use-cases you might consider:

1. Transaction processing (online gaming, finance, statistics, betting, social media, telecom, ...)
   • scale up, scale out, fault-tolerance / HA
2. Service backend (any industry, any app)
   • service REST, SOAP, cometd etc
   • act as message hub / integration layer
   • scale up, scale out, fault-tolerance / HA
3. Snap-in concurrency/parallelism ( any app )
   • Correct
   • Simple to work with and understand
   • Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby)
4. Batch processing ( any industry )
   • Camel integration to hook up with batch data sources
   • Actors divide and conquer the batch workloads
5. Communications hub ( telecom, web media, mobile media )
   • scale up, scale out, fault-tolerance / HA
6. Game server (online gaming, betting)
   • scale up, scale out, fault-tolerance / HA
7. BI/datamining/general purpose crunching
   • scale up, scale out, fault-tolerance / HA
8. insert other nice use cases here

Solution 3

An example of how we use it would be on a priority queue of debit/credit card transactions. We have millions of these and the effort of the work depends on the input string type. If the transaction is of type CHECK we have very little processing but if it is a point of sale then there is lots to do such as merge with meta data (category, label, tags, etc) and provide services (email/sms alerts, fraud detection, low funds balance, etc). Based on the input type we compose classes of various traits (called mixins) necessary to handle the job and then perform the work. All of these jobs come into the same queue in realtime mode from different financial institutions. Once the data is cleansed it is sent to different data stores for persistence, analytics, or pushed to a socket connection, or to Lift comet actor. Working actors are constantly self load balancing the work so that we can process the data as fast as possible. We can also snap in additional services, persistence models, and stm for critical decision points.

The Erlang OTP style message passing on the JVM makes a great system for developing realtime systems on the shoulders of existing libraries and application servers.

Akka allows you to do message passing like you would in a traditional esb but with speed! It also gives you tools in the framework to manage the vast amount of actor pools, remote nodes, and fault tolerance that you need for your solution.

Solution 4

We use Akka to process REST calls asynchronously - together with async web server (Netty-based) we can achieve 10 fold improvement on the number of users served per node/server, comparing to traditional thread per user request model.

Tell it to your boss that your AWS hosting bill is going to drop by the factor of 10 and it is a no-brainer! Shh... dont tell it to Amazon though... :)

Solution 5

We are using Akka in a large scale Telco project (unfortunately I can't disclose a lot of details). Akka actors are deployed and accessed remotely by a web application. In this way, we have a simplified RPC model based on Google protobuffer and we achieve parallelism using Akka Futures. So far, this model has worked brilliantly. One note: we are using the Java API.

View more solutions

Comments

[StaxMan]

So is it fair to say it is case of (some) long-latency requests, where single-thread per request would not scale well?

[StaxMan]

Thanks -- I didn't mean chat server is necessarily bad, just that I would want complementary examples; easier to get better idea of potential.

[Wade Arnold]

I think the important part of actor programming in general is message flow. Once you start conceptualizing in flows of data that does not have side effects you just want as many flows to happen per node as possible. This is much different than High Performance Computing were you have semi homogenous jobs that do not send messages and take a long time to process. I think an actor based Fibonacci implementation is a very limiting example as it does not showcase why to use actors but only that actors paralyze taks. Think Event-driven architecture for use cases.

[StaxMan]

So which aspect do you like most if you had to choose? Existing integration for other frameworks, automatic fault tolerance, or something else?

[StaxMan]

Do you know what is responsible for better performance (and also compared to which alternative)? Is that due to using JRuby on JVM (vs native Ruby), scalalibiliy due to non-blocking I/O or something else?

[StaxMan]

Ok. So one important part is that actors are good abstraction for modeling and implementing complex message flows? Sounds like this would be great for many kinds of distributed systems (my experience is mostly with distribute ("nosql") storage, message queues (Sqs)).

[Wade Arnold]

Event driven architecture is a different way of thinking about problems. It's worth reading Erlang OTP in Action from manning if you are thinking about coding in Akka. A lot of the constructs in akka are influenced by Erlang OTP and the book gives you the principles for why Jonas Boner built akka api the way he did. Akka is a big mountain that you are standing on! If your actors are persistent through state changes do you really need 10k writes a second sustained

[Omer]

The comparison I wrote was: Jruby sequential VS Jruby with actors. Therefore, the only thing that can be responsible for faster execution is the participation of the actors. No I/O participated on the experiments (a file is load from disk, but it is done before the benchmark timer is set).

[Admin]

From a personal perspective it is the raised abstraction level which Akka brings to the table that I like best. From an enterprise perspective it is the integration capabilities. Got to make a living and Akka covers business and pleasure both very nicely :-)

[chaostheory]

I've recently implemented a map reduce example as well, but it's just plain vanilla java github.com/chaostheory/jibenakka

[James]

Wade, how do you guys handle message guarantees? you mention: (email/sms alerts, fraud detection, low funds balance, etc), I assume these are potentially sent to remote actors? How do you ensure those operations actually happened? what if the node failed while processing a fraud alert? Is it gone forever? Do you have an eventually consistent system that cleans it up? thanks!

[Kaan Yy]

Good question James. It is obvious that it fits in a system where reply is not needed urgently. For example you can process credit card bills; calculate; send e-mail etc. I really wonder how these things (transaction) are handled when a reply is needed. At the end; if a request is made from external (internet user; a representative from call center etc.); he or she waits a reply. How can I be sure that sub tasks (which are executed async) are executed; in a xa transaction so that I can return reply?

[n1r3]

"I can share the code with anyone interested to have a cross check." I would like to if you don't mind.

[magiconair]

What is the benefit of this approach in comparison to using a messaging backend (e.g. ActiveMQ) for message passing in your opinion?

[Aktau]

Could you tell us a bit more please? Afaik Futures can't be sent over the wire (serialized). Do you use a lot of futures and few actors or a mix between the two or...? You use protobuf for all serialization and send as a message to the actors?

[Gautam]

I would also like the code, can you post a github link ?

[piotrga]

And I forgot to mention that the monadic nature of akka futures, which leads to much cleaner parallel code saved us thousands in code maintenance...

[StaxMan]

I assume calls are high-latency, low throughput? Like making calls to other servers, waiting for response (proxy)?

[Samir Alghazaly]

MQ products are really for a different use case. different guarantees and very different performance. MQ products need a lot of setup, you would not use queues in such a product in the same way as you would use objects. Actors are first class citizens in akka, you use them as you please, similar to how you would use objects, so there is far less of an overhead both in your programming model as in the setup. MQ products you would use more to integrate with other external systems, not to build the 'internals' of a system, which is something you would use actors for.

[sutanu dalui]

Thank you for your interest. Unfortunately I have some problems setting up a github repo. If you can give me your emails, I can mail over the source code. And regrets for a late reply!

[Martin Konicek]

I understand the benefits of Futures and STM but don't find good use cases for actors. For a game or betting server, what's the advantage of using Actors vs multiple app servers behind a load balancer?

[Bas]

New URL for the DBP case study is downloads.typesafe.com/website/casestudies/…

[Erik Kaplun]

This seems like it could have been handled just as easily without Akka.

[Erik Kaplun]

are you also using Akka's fault tolerance?

[floer_m]

Building off @RaymondRoestenburg re: MQ systems and alternatives. RabbitMQ, for example, is built on an actor-based programming language, Erlang. That's one way to think about the relation (and distinction) between actor and MQ. Meanwhile Apache Spark is neither worker-and-queue nor Actor-based, BUT can be used with Akka: Typesafe demonstrates how to use Spark Streaming with Akka.

[Jay]

@sutanudalui Do you still have the code please, if so I can share my email ?

[Roman Kagan]

TDC is Telco company in Fiaddesio's case.

[Jarek Przygódzki]

See lightbend.com/resources/case-studies-and-stories

[taylorcressy]

@ViktorKlang POs != Tech Lead. They work together, but are different roles.

[rapt]

@RaymondRoestenburg You neglected to mention that the Actor model as-is promotes spaghetti-like structure. The "Akka in Action" book you wrote is the best demonstration for this "feature". The code examples deal with fairly basic stories. Yet the workflow is very difficult to comprehend and follow from the code. A related problem is that Akka code will be IRREVERSIBLY all over your business logic in the most intrusive way you could imagine. Much more than any other non-actor framework. It is simply impossible to write a basic workflow without dissecting it into different separate sections.

[surfmuggle]

Could you elaborate how the flow of messages is? Is the user the person in a repair shop and enters details about the crash into a http-form and then sends the data to the server. Does this create a message that is handled by akka? To do what with this message? Extract the entered information to query the database and then queue the reply to send it back to the web-frontend?

[surfmuggle]

Hello Joe, could you explain how messages are used to update the site? Do you have one system for the content author; he creates a new article and hits save. Does this create a message that is send to several servers that handle the incoming traffic. Each server processes the update-message as soon as they can. Every fresh browser-request then gets an updated version of the page? Thank you

[software.wikipedia]

Curious to know how the REST server fits here? Are you mentioning it in context of Node.js style async server? Thanks for sharing the example use cases. I found them useful.

[skjagini]

I think a higher level framework like Kafka is better suited for this, isn't it?

[skjagini]

How about Spark Streaming if we you have access to Spark cluster?