Akka - an open source, event-driven middleware project
Akka is an open source, event-driven middleware project. It is designed to allow developers to write simpler, correct concurrent applications using Actors, STM (software transactional memory) and transactors. I recently talked with Jonas Bonér, co-founder of Typesafe, and creator of Akka.
Wong: You created the Akka Middleware, can you give us a bit of history on Akka and how you came to develop the platform?
Bonér: Sure. I have been working in the industry for more than 10 years. I was a core technical contributor at Terracotta, working on JVM-level clustering technology and at BEA, as part of the JRockit JVM team. I’ve spent a lot of time building middleware systems for the Java Virtual Machine (JVM), trying to solve the same things we are solving with Akka now.
About 5-6 years ago I got really interested in Erlang. Erlang is programming language, but it’s not just a language, it’s a completely different platform than the JVM. I got really excited about it. Later I was doing consulting in the high availability (HA) and scalability area and I found Erlang to be an excellent platform for that.
But there was a big problem - almost all my clients and friends was using the JVM or other languages on the Java platform. I knew it would be a really big challenge to get people to switch. But, I felt that HA and, to a greater extent scalability, were too good to be left to the Erlang folks alone. I wanted to implement these excellent concepts on the JVM, so I created Akka.
Around that time, I started a new startup called Triental where we did a portfolio management system for private banking with some features such as stock trend analysis and simulation. There was a great need for many of the things that you can achieve with Erlang, so Akka grew out of that to a large extent. The startup went out of business after awhile, but the ideas stayed with me and I rewrote them into the first release of Akka. That was about 3 years ago, and the first release of Akka was about two years ago.
Wong: If asked to describe Akka in one sentence, what would that sentence be?
Bonér: Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM.
Wong: What are the current, major challenges for writing concurrent and scalable applications? How does Akka address these hurdles?
Bonér: The main problem is that it’s way too hard. Modern systems today are generally almost too big and complicated to comprehend as they are, considering the use-cases, business logic and the actual things you should implement. When you add things concurrency, scalability, and fault tolerance on top of that, things get very complicated. Most systems just become too complex to comprehend. We need better tools and more high-level abstractions to solve this.
In my opinion, the default way to do concurrency in Java is not always the right default. Java uses shared-state concurrency, which means concurrent access to shared mutable state guarded by locks. Locks are known by everyone, experts included, to be incredibly hard to understand and to get right. It takes a lot of mental effort to fully comprehend a system that is based on non-concurrent mutable shared state. This is why many developers are used to writing massive test suites, they are so uncertain of their own code. They change something in one place of the system and it breaks in another and when they fix this problem it breaks in a third and it goes on... The primary reason for this is the use of shared mutable state, something that Java encourages. If you now add concurrency, e.g. non-determinism, to this system...well...run away and scream...
The problem is that the operating systems’ way of handling threading and correctness leaks all the way up to the programming model. Languages today have evolved in many, many different ways, but when it comes to concurrency, most people are still stuck on techniques that were used back in the 60’s and 70’s.
I believe that Akka has multiple solutions to this problem. What Akka tries to do is provide one toolkit to address both the concurrency, scalability and HA concerns. just one thing to learn and one thing to use. Akka has multiple tools that will help you as a developer; both Actors, Futures and Software Transactional Memory (STM) raises the abstraction level and makes it easer to both write, understand and maintain concurrent, scalable and fault-tolerant code. Instead of messing around with very low level, internal things, you think in terms of higher level concepts, like message flows and transactions. What is usually solved by using low-level plumbing in standard Java applications, using primitives like threads and locks - which are extremely hard to understand and reason about - becomes workflow in Akka. So you start to think about how the data flows in the systems rather than how to get the concurrency and scalability right.
Actors in Akka implements share-nothing architecture. They can be seen upon as OO objects, encapsulating state and behavior, but every state change is local and can not in any way affect any other part of the system. Actors are also decoupled, if one actor dies it will not affect any other part of the system. If an actor fails, you know where to look. Add to this the actor style of fault-tolerance by linking actors in supervisor hierarchies, to get a system that can monitor and heal itself, and you get a very robust system. Another solution that we encourage people to use together with actors is to program functionally, with immutable state.
With Akka, you also get the benefit of that all the plumbing is done at once and for all, in one runtime, tested over months and years, by many many users in multiple contexts, instead of everyone having to do this by themselves in their own applications over and over again.
Wong: What did you see missing in middleware and what challenges did you find most necessary to address?
Bonér: Most clustering tools and platforms try to emulate shared mutable state across the network. I believe that is the completely wrong approach; first as we have discussed shared mutable state creates a lot of problems by its own, if you now try to emulate that on top of a system that so inherently unreliable as the network, it will simply break down. It creates a leaky abstraction that in many cases leaks a bit too much to be really useful.
When creating Akka, I wanted to embrace distributed computing at its core. The essence of distributed programming is asynchronous message passing; e.g. message passing concurrency; which is very different from shared state concurrency which can only ever work reliably in-process. What I decided to do with Akka is embrace the network and message passing. Instead of trying to shield the programmer, we made message passing a first class construct using Actors.
Doing this makes it easier to understand what’s going on and easier to reason about things. This is exactly what actors do; actors make the network explicit by implementing message passing. Some people say that Actors can implement transparent distributed computing, but it’s actually the other way around: they implement very explicit distributed computing and then, if it’s used in the local context, it’s only an optimization.
So with the actor model you have the ability to scale up and scale out in a unified way. You don’t have to worry whether you are scaling up, meaning scaling for multi-core architectures on a single machine or scaling out across multiple, different machines on one network; regardless if you want to scale up or out (or both), you are using the same programming model, the same abstractions, the same techniques, and the same runtime so that’s really a big win.
Additionally, with the actor model, you have high availability built in. So without leaving the actor model, you get HA as part of it, which is another very important thing when writing scalable software today.
Wong: How does Akka work with Scala (see If Your Programming Language Doesn't Work, Give Scala A Try) and Java API?
Bonér: Akka has a Java API in addition to a Scala API which means smooth interoperability and no need to adopt Scala wholesale in every codebase at once. Akka offers Spring and Guice integrations and can be deployed in your existing Java application server or run stand-alone. The Scala and Java API look almost the same the only difference is that in Java, it looks a bit more verbose, but you can do the same thing.
Wong: What will be the next changes or extensions Akka will undergo in the next year?
Bonér: The next big milestone, apart from Akka 1.2 coming out in a couple weeks, is Akka 2.0. 2.0 will add many features to make it easier to write distributed, really scalable software. Akka already has some basic tools for that, but 2.0 will take it to the next level by adding things like: adaptive automatic load balancing and cluster rebalancing, replication both for fail over, partitioning, cluster wide deployment, explicit and implicit actor migration across machines and more.
What’s important to understand is all of this will be done solely through configuration, so you write the systems the same, whether you want to run it on a single machine or across 100 machines. You write things once without thinking about clustering or scalability but later you can feed it with a configuration defining the topology, which actors should be clustered etc. and the runtime will automatically scale your application out.
This process makes it very easy for developers, since they can develop on a laptop or workstation, and then scale the system on demand. Deployment, topologies, fail-over, replication etc all becomes a deployment and operations task. This makes it easier for small shops to grow on demand. If they’re starting with one or two machines, as the need comes, they can just change the configuration to scale out without changing the code. That’s huge.
We’ll also release REST-based, and later add SNMP and JMX-based, monitoring and management, and also a web console for browsing statics for managing systems. We are also adding provisioning to easily manage many nodes, so there is one way of doing deployment and managing all these applications on all these nodes.
Wong: What does the Akka middleware bring to the enterprise stack that other middleware doesn’t? What are the unique differentiators and advantages?
Bonér: One thing that Akka does really well is it scales from small projects to big projects in a very neat way. For example, the akka-actor.jar module is very small and has zero dependencies. Since it is so small it is used in embedded systems, like Android phones and such, but can easily be scaled up to hundreds of nodes. From then you can also bring in the modules you need as you need them; we even have a pluggable microkernel, a mini app server which can deploy and run the modules and applications you need.
Akka is very modular, it’s more like a toolkit. This toolkit has a bunch of different tools and abstractions for concurrency and scalability that you can mix and match. Each on of these tools solve the problem differently and brings something to the table, they are all orthogonal pieces with high cohesion that compose nicely. I believe that there is no single silver bullet. That is why we have many different ways of doing things.
Akka is completely open source and free with an open runtime and programming model. We have commercial products on top, such as monitoring and management, but everything that the developer needs it completely open and free, licensed under the Apache 2.0 License.
One final thing is the possibility to use other languages with the Akka middleware. In addition to Scala and Java, there are other companies using other languages like JRuby, Clojure and Groovy on Akka.
Wong: You recently co-founded Typesafe. Can you provide some background on why you started the company and what your goals are for the future?
Bonér: Martin Odersky, the creator of the Scala programming language, and I met for the first time in London about 3 years ago. We didn’t talk about starting a company back then, we just went out for coffee and got to know each other. Then about a little over a year ago, we started talking about joining efforts. Initially, we discussed a collaboration between our two companies. I had a company called Scalable Solutions that focused on scalability and high availability middleware; we had a lot of consultancy in using Scala, but it was not a purely Scala shop.
At the time, Martin also had a company called Scala Solutions that focused on Scala but Martin was leaning towards tackling the concurrency and scalability problem as well.
In Scalable Solutions we had based Akka, and a lot of our knowledge, on the Scala language and the possibility of an even tighter integration with Scala and a full stack where we controlled the entire thing from top to bottom sounded very appealing. So, after talking to a few investors, we decided to join forces and we formed Typesafe.
Since the Typesafe launch a few months ago, we have hired a lot of great developers and what we are now focused on is building a full stack on top of Scala, meaning the language at the core, the middleware based on Akka, runtime tools, developer tools to build the applications, an eclipse plug-in, and a migration manager that helps you smoothly transition between releases.
We also have commercial support to provide training and consulting for the Typesafe stack.