Senior developer using Akka remoting directly to build a special type of cluster

Whilst I have always successfully discouraged my clients from using Akka Remoting in their application, I often get questions regarding remoting while talking about anti-patterns at conferences and user groups.

Don’t get me wrong. I love Akka remoting. Especially the new Aeron-based Artery remoting version that is based on UDP rather than TCP. Whilst it maintains the same delivery guarantees, it is quite a bit faster than the TCP counterpart.

So why not use Akka remoting? Well:

Never, ever, use remoting directly in your application

— Konrad Malawski, Akka Core Team

Everything is in the wording: just as you don’t use the LTE network directly by receiving and emitting radio waves with your brain (unless you’re Lucy), don’t use Akka Remoting directly in your application. Use your cell phone. Or use Akka Cluster.

“But why?”, you ask, “why should I not be one with the network, connecting my actor systems on a peer-to-peer basis, in total control, with the raw power of the Actor Selection in my hand?”.

“Fool!” is my answer to this, and the stern look on your face scares you a little “what then do you do if the remote system is quarantined? Do you, mere mortal, really wish to reimplement all of Akka Cluster on your own?”

Because, well, yes, that is what it amounts to. Here is the association lifecycle of Akka Remoting for you:

See, when a remote system is quarantined, the only way to recover is to restart its actor system. Akka Cluster provides a membership service for keeping track of nodes that belong to a same application and takes care of many of the subtle and difficult aspects related to running distributed applications. It propagates membership via a gossip protocol and implements the The ? Accrual Failure Detector in order to quickly detect node failures.

So by all means, use Akka remoting — but please, only transitively.