What Are the Best Use Cases for Akka Framework

What are the best use cases for Akka framework

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.

What are some common use cases for using the Akka Microkernel?

The Akka Microkernel module gives you a very light-weight and free "application server" bundle so it's easy to distribute and run your Akka application.

Read more about it here: http://doc.akka.io/docs/akka/2.0.1/modules/microkernel.html

Apache Spark vs Akka

Apache Spark is actually built on Akka.

Akka is a general purpose framework to create reactive, distributed, parallel and resilient concurrent applications in Scala or Java. Akka uses the Actor model to hide all the thread-related code and gives you really simple and helpful interfaces to implement a scalable and fault-tolerant system easily. A good example for Akka is a real-time application that consumes and process data coming from mobile phones and sends them to some kind of storage.

Apache Spark (not Spark Streaming) is a framework to process batch data using a generalized version of the map-reduce algorithm. A good example for Apache Spark is a calculation of some metrics of stored data to get a better insight of your data. The data gets loaded and processed on demand.

Apache Spark Streaming is able to perform similar actions and functions on near real-time small batches of data the same way you would do it if the data would be already stored.

UPDATE APRIL 2016

From Apache Spark 1.6.0, Apache Spark is no longer relying on Akka for communication between nodes. Thanks to @EugeneMi for the comment.

Akka and RESTful Services

Why do you think that asynchronous means slow? :)

Of course because of the nature of HTTP protocol, from client point of view HTTP calls will be synchronous. But internally Akka will use its asynchronous capabilities to process requests as soon as possible.

spray.io is a standard Akka HTTP layer that will be replaced with Akka HTTP module soon (which is basically Spray 2.0). It's very lightweight and super fast.

And this is an example about how you can integrate synchronous HTTP and asynchronous Akka Actors. As you can see it creates Future and sends result back when it's done.

More advanced examples: http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/

Difference between Lagom and Akka Projection

Lagom is an opinionated framework on top of Akka, especially around Cluster Sharding and Persistence (as well as a means to define HTTP interactions similarly to Play, and a defined approach to dependency injection). It included, in its ReadSideProcessor an opinionated way to project an event stream from persistence for CQRS.

Many recent advances in Akka are partially based on incorporating some learning from Lagom around being more opinionated. Projection brings something similar though more general (as it can project, e.g. events from Kafka) to the ReadSideProcessor to Akka; it may be noteworthy that Projection is largely the work of one of the core maintainers of Lagom.

I wouldn't really categorize Akka Platform as a PaaS, but more of an alternative pricing/consumption model for a subset of the "Lightbend Subscription" (Akka Platform is usage-based without as much of a consulting-type arrangement; the Subscription's pricing might fairly be described as "if you have to ask how much it costs, you probably can't afford it", but it does include some level of consulting engagement from a group that really knows the Akka/Lagom/Play stack). Otherwise the Akka Platform is Akka.

Akka Serverless's PaaS is Akka under the hood, but the Akka-ness is hidden (for better or for worse) behind a gRPC API. As in Lagom, you're defining domain entities' behavior and a framework layer is manifesting that as an Akka actor; Akka Serverless more strictly separates that manifestation than Lagom (it's quite possible and sometimes even useful in Lagom to strip away the Lagom veneer to expose more Akka), but that in turn allows the behavior to be defined in any language that can speak gRPC.

I can't speculate on what the future holds. Akka itself is pure open source (and not a small portion of its contributors aren't employed by Lightbend): so it's somewhat immune from whatever happens with Lightbend (the scope of the commercial add-ons has also decreased over the years, most notably with the multi-region persistence and the split-brain resolver being open-sourced). There are use cases for Akka that will probably never effectively be useful in Akka Serverless. As for Lagom, it's possible that it's achieved its goals and will be considered mature (joining various other microservice-first frameworks).

I personally would tend to use vanilla Akka: I'd consider the recommended Typed APIs (especially in Scala) to provide "just the right amount" of opinionation, albeit less than Lagom. Coming from a Scala background, the lack of DI is also appreciated. If you decide you want the commercial add-ons and are running in a public cloud on Kubernetes, then the Akka Platform is probably worth getting; for other deployments, the Subscription might be worth it.

How to store a list of Akka actors in Play framework 2 application?

Instead of having a static reference to an Actor (WebSocketRouter in your case), why not come up with some messages to send it? That way, the actor can maintain its own internal state in a consistent way. State change through messages is one of the main benefits of the Actor Model.

Before I get into code, I'm sorry if this isn't 100% accurate, I've only used the Scala version of Akka and am basing this off a quick scan of the Akka Documentation.

So in your case, I would define a few objects in order to express Join/Leave...

public class JoinMessage { } 
public class ExitMessage { } 

Note that ExitMessage is really only needed if you intend to keep your WebSocket open and have the user stop listening to the router. Otherwise, the router can detect when the Actor has been terminated.

And then you would change your MessageSender actor to send these messages whenever they join or leave a chat room....

public class MessageSender extends UntypedActor {

    public static Props props(ActorRef out) {
        return Props.create(MessageSender.class, out);
    }

    private final ActorRef out;
    private final ActorRef router;

    public MessageSender(ActorRef out) {
        this.out = out;
        this.router= getContext().actorSelection("/Path/To/WebSocketRouter");
    }

    @Override
    public void preStart() {
        router.tell(new JoinMessage(), getSelf());
    }

    @Override
    public void onReceive(Object message) throws Exception {
        if (message instanceof String) {
            out.tell(message, getSelf());
        } else {
            unhandled(message);
        }
    }    
}

And then your router can change to manage state internally rather than exposing internal methods on the Actor (which as you know is not good)....

public class WebSocketRouter extends UntypedActor {
    private final Set<ActorRef> senders = new HashSet<>();

    private void addSender(ActorRef actorRef){
        senders.add(actorRef);
    }

    private void removeSender(ActorRef actorRef){
        senders.remove(actorRef);
    }

    @Override
    public void onReceive(Object message) throws Exception {
        if (message instanceof JoinMessage) {
            addSender(sender);
            getContext().watch(sender); // Watch sender so we can detect when they die.
        } else if (message instanceof Terminated) {
            // One of our watched senders has died.
            removeSender(sender);
        } else if (message instanceof String) {
            for (ActorRef sender : senders) {
                sender.tell(message, getSelf());
            }
        }
    }
}

Again, this code is to give you an idea of how to accomplish this task by taking advantage of the Actor Model. Sorry if the Java isn't 100% accurate, but hopefully you can follow my intent.

---

Related Topics