Pros and Cons of Akka vs Traditional Method Calls as they Relate to module Reuse

I am considering learning Akka but it doesn’t look real easy so I’m not sure it is worth it. My main project goal is to build long-term reusable modules and to also be able to add 3rd party reusable modules to my project. (ie: module definition = large piece of code that does a high level task)

Could someone please give me a short list of the pros and cons of using Akka as it relates to module reusability?

At this point, two of the main features of Akka that I am most interested in are the actor model and the concurrency execution capability. Possibly in the distant future, Akka’s remote/distributed capabilities will also be beneficial. The languages which I am using are Scala and Java.

1 Like

Some of you wizards must know some pros and cons. Please help me decide if it is worth learning.

Akka looks intimidating to learn, but the actual subset you’ll use in a given project is probably typically going to be fairly small (e.g. many projects I’ve use have been just Alpakka Kafka, Streams, Cluster Sharding, and Persistence, which ultimately covers only 4 of the 12 Akka OSS components on doc.akka.io) and you can pretty much ignore the portions you’re not directly using.

Message passing is probably more amenable to reuse than traditional method calls because the messages are just data (better, they’re nearly always pure data): a client can send messages according to one protocol and the translation to some other protocol can often be a simple matter of conversion functions (if one protocol is particularly stateful, that’s a bit more difficult but tractable).

The fact that every actor can be thought of as its own microservice which is running in the same JVM process as other microservices also supports reusability. Even if you have a module A and a module B which can’t easily run in the same JVM process (e.g. a dependency conflict which you don’t want to shade), you can have the actors in modules A and B run in separate processes and have them form a cluster (probably defining different roles) and the actor communication is basically as before (exactly as before if the messages happen to be workably serializable, which is a good practice in Akka).

To the extent that there are downsides that aren’t present in traditional method calls, those are present in the actor model, by and large (designing for asynchronicity, the extreme encapsulation, and the general mental shift being the three major ones). If you’re not fazed by those, there aren’t really any downsides (since anything that’s better done through traditional method calls can still be done that way: you just don’t get the benefits of the actor model when you do that).

1 Like

Levi,
Thanks for the info. I really appreciate it!

Any other wizards with something to add?

LarryK

In would add that if you need completely separate services that can be consumed by clients written in other languages or frameworks you can use Akka gRPC or Akka HTTP for the public APIs. For the implementaion those play nice with other parts of Akka, such as Akka Streams.

2 Likes

Patrik,

Very interesting. Thanks for replying!

LarryK

It is very difficult to build anything sufficiently complex and distributed without state machines and protocols (as only those can have a true 100% test coverage and thus can be composed with a confidence of plugging a phone charger into a power outlet, unlike with most other design styles). That’s where AKKA Actors come handy.

Then you really don’t want to code your workflows as rigid synchronous (or rigid asynchronous) call stacks. That’s where AKKA streams/graphs come useful. And they come with a lot of tested building blocks for day-to-day and a nice extension point for very-custom bits.

Of cause you can code those primitives yourself, but it is a lot of low level work and cross-domain knowledge.

In comparison, AKKA has a very smooth learning curve, all essential syntax to get started with actors can be demo-ed with a 50 lines Scala application.

mrbald,
Yes, it looks like Akka (and similar libraries for other languages?) are the are the future of programming and thus the way to go if a person wants reuseable modules. Of course this discussion group may be a little bit biased, but it makes sense to me.

One concern that I have regarding reusability though, is: Is it a big job to wrap a traditional module in Akka wrapper to it can be used with Akka? Or is it necessary to completely re-write it to work with Akka? I suppose this is too broad of a question, since there are all kinds of traditional modules and many sub-libraries of Akka.

Still learning Akka so please forgive my newbie questions. Thanks for your reply.

LarryK

LarryK,

For enablement and examples of Akka I’d recommend the Akka Platform Guide. Additionally, if you have an interest in distributed state I’d also like to point you at my blog post here.

Michael

Michael,

Thanks for the links. I need all the help I can get!

LarryK

Any official news?

Sorry, this isn’t an official news thread.