If we’re going to remain productive as programmers and truly scale our pro- grams to the hardware on which they run, while at the same time keeping them reliable and understandable, then we need to stop coding our concur- rencyand just let our coderun concurrently.
Enter Akka.
The dominant platform for enterprise (and cloud?) software development is still the Java Virtual Machine but what’s been missing from Java is a truly abstracted concurrency toolkit. There are some solid concurrency tools in the Java library, and many of those tools are employed by Akka to deliver its solution, but those tools aren’t what most of us would dream about when we sit down in front of our favorite editor.5 We want to code at a higher level and leave the pain of concurrency programming to someone else. Akka delivers on that need.
The shared-state concurrency tools we have today certainly have at least one thing right: they stay out of your way. Ultimately, the control of my application still belongs to me, which is exactly where it should be. Attempts
5I.e., Vim (http://www.vim.org)
have been made over the years to provide large frameworks that do all of the heavy lifting for you, but these have largely failed to provide us with the agility, speed, and flexibility that modern applications require. We don’t need another framework; we need a toolkit full of powerful abstractions we can go to when we’ve got a concurrency solution that needs modeling. Akka delivers here as well.
A short note regarding Akka and Scala
Akka was designed alongside Scala (and Java), which created some dupli- cation between Akka and Scala on a conceptual level. Scala has always had actors and futures, as has Akka. However, Akka’s design and implementa- tion of actors and futures has evolved far past that of Scala’s implementation.
Because Scala and Akka are so closely aligned, the code in Akka is mi- grating to Scala. For Scala 2.10 and Akka 2.1, this migration includes the
Futureimplementation, so we’ll be talking about futures in the context of the Akka paradigm. However, from a packaging perspective, we’ll be im- porting code from thescalaname space.
Akka tools
Akka brings together a solid set of tools into a new paradigm of concurrent development:
Actors In 1973, Carl Hewitt defined the actor6 and its most popular imple- mentation to date has been in Erlang.7 Unfortunately, Erlang itself has not seen the widespread adoption of a mainstream language like Java.
Futures We’ll see that the actor, while a powerful mechanism for concur- rency and resiliency, is not a silver bullet. In fact, some problems are just downright wrong to be modeled with actors. Where actors don’t apply, we often find that futures work incredibly well, and this is in no small part due to the fact that the Futureimplementation in Akka8is very powerful indeed. Using futures allows you to create ro- bust pipelines of concurrent code that can easily operate on immutable data safely and without blocking.
6There’s some decent information athttp://en.wikipedia.org/wiki/Carl_Hewitt 7http://www.erlang.se/
8Currently slated to become part of Scala 2.10.
Timers The timer has never ceased to serve us well and Akka doesn’t dis- criminate. Timers play a significant role in Akka.
Callbacks/Closures Shared-state concurrency uses callbacks and closures all the time, and there’s nothing wrong with them. However, syn- chronizing them has always caused us pain. With respect to modeling concurrency, these abstractions are fantastic.
There are some variations on these themes within Akka, but those con- cepts cover the bulk of what it is that the Akka toolkit provides. And, yes, Akka is providing it for youon the JVM, accessible even from Java itself.
Error handling (a.k.a.Resiliency)
Developers tend to ignore any serious error handling (i.e., those errors that fall outside of the usual ones that are found in unit tests) until after the nick-of-time. This situation isn’t helped by the fact that most asynchronous toolkits (or frameworks) don’t address error handling at all; it’s entirely your problem. Can you throw an exception? Can anything even catch it? Can you return an error code? To whom? What are they expected to do with it when they get it? Retry? Abort? Resume? Ugh. . . Far too often, developers are left trying to poorly bolt on some sort of concurrent error-handling mechanism all on their own.
The tools we are used to in imperative programming—exceptions and return codes—don’t help us when we’re developing complex concurrent sys- tems. Akka doesn’t ignore the problem of error handling, or bolt it on as an afterthought. One of Akka’s core philosophies is that errors and failures are part of the designof any good application, not things to be avoided. Your application will be affected by real life at some point.
When real life comes around and tries to kick you in the head, what do you do? Often, people try to change real life into some sort of fantasy land where things don’t go wrong, or simply ignore the problem in the hope that it won’t happen. Akka’s different; real life won’t stop kicking you in the head—that’s just what real life does—so since you can’t beat it, why not join it and just “Let It Crash.”9. Some sort of scenario will happen where a
9One of the core philosophies of the actor paradigm involves embracing failure to the point where we let small parts of the application crash, and trust the actor system to heal itself. You’ll learn more about this later.
small piece of your app will take a hit to the family jewels, and that’s going to take it down (who could stand up in the face of that?). Akka provides a mechanism where that piece of the application can heal itself and keep on trucking. Welcome toreliability.
Non-blocking by default
Threads are a precious (and very expensive) resource. When you start get- ting into programs that have to handle thousands of concurrent operations per second (we don’t even need to think about the ones that have to handle millionsto see this), blocking on a thread is a surefire way to ensure that your app won’t scale. Any toolkit that claims to provide a new concurrency de- velopment paradigm must provide a way to protect these precious resources.
Akka doesn’t disappoint, and you’ll become quite competent in ensuring that your threads are working their butts off.