Understanding reactive architecture through the actor model

In this episode of the O’Reilly Podcast, I sat down with Hugh McKee, solutions architect at Lightbend. McKee and I discussed why the actor model is an ideal choice for building today’s distributed architecture, how actor-based systems manage requests to perform tasks, the kinds of enterprises already having success with actors, and best practices for getting started with asynchronous systems.

Here are a few highlights from our conversation:

A simple but elegant abstraction layer

The thing I like about actors are the abstraction that it provides for building systems, and it really covers things in two levels and makes it really fun both in the architecture and design of the system as well as in the actual implementation of the code. In the architecture and design of the system, the actor model gives us this abstraction layer that is simple and elegant but powerful.

In a way, with actors it is almost like you get this infinite box of Lego blocks and you can build things anyway you want. It is that fundamental model of actors that are very simple where actors communicate with each other asynchronously and send each other messages, and that’s it. On the code side, the fun is that you are able to decompose a system into a collection of actors from, say, high-level actors that live for a long time to relatively low-level actors that only live for a very short period of time but are very focused on what they have to do. They do one thing and they do it well—the Unix philosophy, but it was nice from the coding standpoint because you could build systems that had things like high levels of concurrency.

Asynchronous behavior

We can think of actors like humans that are texting each other. I think it is an analogy that we can use that has a lot of similarities in that if you send me a text message asking me to do something, you are free to continue to do whatever you want to do. You are not stopped waiting for me to respond. In an asynchronous system when we write synchronous code, of course, the caller waits until the thing that was called responds. In an asynchronous world, in the actor world, you have this more asynchronous behavior, and it introduces all kinds of interesting dynamics in how you build up the characteristics of your different actors.

That’s the biggest thing, and because it’s asynchronous, it is very efficient technology in that a request from one actor to another doesn’t hold a thread in a typical HCT-type web system or web service type system. In those systems, a request comes in, it threads out to that request, and it threads there until you respond. With actors, it is much more dynamic. Actors only use threads while they are busy. If they don’t have anything to do, they are just waiting for something to do. They can hold state, but they’re lightweight compared to threading-based systems. But, the fundamental exchange is that messaging operation where you send me a message and maybe you are waiting and asking me to do something, and you are waiting for me to send you a message back.

Enterprises are already using actor-based systems

On the one hand, you have companies like eBay doing massive amounts of transactions at super high volumes, and then I think on the other end of the spectrum, you have companies doing some really innovative things with Akka. I don’t know all the details of these things but almost by design and just by using these kinds of technologies, you can imagine they are building highly resilient systems that don’t go down.

If my WiFi goes down, my wife gets very, very upset, and that cannot happen. We cannot disappoint you, right? eBay is the same thing. If they went down, they would end up in the news, so they both have to have really resilient systems and this is the way to do it. But, it is really across the board. It is amazing what companies are doing with Akka. The one thing I do run into, though, is that in many cases developers start using Akka mainly for concurrency, but they are almost a little bit timid to go into the cluster architectures. I really try and encourage them to go because that is where you really have the fun, when you start architecturing the system that runs in a cluster that has that resiliency and maybe even add in elasticity and auto scaling. You can do these kinds of things with Akka.

Making the transition to reactive

The biggest transition that people need to go through, at least at first, is starting to think asynchronously. I have been around for a long time and I love running software, I love building systems, and throughout my whole career, I was doing things synchronously. When I ran into Akka, at first in a way, it almost makes your head hurt because, wow, this is so different than the way I had been doing things before. You really have to internalize these new concepts to do it. The whole actor paradigm, the whole asynchronous communication processes, the whole “what do I do if it doesn’t respond in time”—this is the reactive way of doing things. These are fundamentally different ways of doing things. But I can guarantee you it’s a lot of fun.

It’s way more fun than the traditional ways. It’s just there is a transition, and you have to go with it, sink yourself into it, really wrap your brain around these different concepts, and just be almost fearless to go after it. I mean, I am not saying it’s hard, it’s just different. Some people say it’s hard. I don’t necessarily agree with that, I think it is just a different way of doing things, but it’s fun to change. I think that’s one of the best things about people in software development—if you are doing things one way for too long, then just hang on it’s going to change, and this is definitely a big change in the way you do things. Like I said, it’s the most fun I have ever had.

This post and podcast is part of a collaboration between O’Reilly and Lightbend. See our statement of editorial independence.