Akka!

Every now and again I come across a technology that wows me. I remember being impressed by the Amiga in the 1980s, Lotus AmiPro in the 1990s, and in more recent years, SSDs and Dropbox.

For the past week I’ve been reading and watching training videos about Akka. Specifically, I’m referring to Akka.NET, although Akka (for Java) came first. Officially, Akka is an actor-model framework, a modern interpretation of a 1970s-era computer science concept. More practically, Akka is a framework for building distributed, concurrent, clustered, and my favourite – fault tolerant applications. These are all things that are generally difficult to do. Akka makes them ‘easy’.

I feel like using Akka.NET for everything, even when it doesn’t make sense. I guess that’s a good thing to say about a technology, but I’m sure in time I’ll begin to be somewhat more conservative about when and where it is a best fit. The concepts are so powerful that I think it will modify how I write software, even when I’m not using it. Messaging, microservices and immutability have significant benefits outside of Akka.

What really struck me at first about Akka.NET is that its messaging is inherently unreliable. That sounds counter-intuitive, but makes complete sense when you realize that you can build reliability on top of unreliability (e.g. you can build software where actors send messages but require ‘receipts’ from the message destinations.) You get the best of both worlds, and only sacrifice performance when you need to.

All this gushing aside, there are some oddities about Akka that I don’t quite get. The configuration language, HOCON, seems unnecessary. Why not just use XML? And why not build remoting directly into the system instead of having separate classes for it?

Leave a Reply

Your email address will not be published. Required fields are marked *