Akka.NET 1.1 was recently released, bringing new features and performance improvements. InfoQ reached out to Aaron Stannard, maintainer of Akka.NET, to learn more about Akka.Streams and Akka.Cluster. Stannard also explains how the roadmap is planned with regards to the JVM implementation of Akka.
InfoQ: What are the highlights of this release?
Aaron Stannard: The primary goal of Akka.NET 1.1 was to release Akka.Cluster from a beta package to a released to market (RTM) package, complete with testing tools and coverage for a large number of different network scenarios that can happen during the course of running an Akka.NET cluster in production.
It can't be understated how big an effort this was; the original beta for Akka.Cluster was released in August 2014. So we spent roughly two years(!) developing Akka.Cluster and collecting feedback from production users. The home stretch of 1.1 was to improve the reliability and speed of the clustering system so it could be used for highly available workloads. We already have banks, healthcare providers, energy producers, fleet and vehicle management companies, SaaS companies and lots of others using Akka.NET in production. Akka.Cluster was at the top of their list for things they wanted to see released.
The other big highlight of the 1.1 release is the first beta for Akka.Streams; this module introduces a whole new way of building reactive applications with Akka.NET, by allowing you to express series of asynchronous operations as rich stream processing graphs that can be interconnected and re-used. You can see some visuals for what Akka.Streams graphs might look like in our documentation.
InfoQ: What are the performance improvements Akka.Net 1.1 brings?
Stannard: The most notable performance improvements are:
- Reduced the memory footprint of all actors by 34%.
- Increased the per-connection throughput of each Akka.Remote, the sub-system that powers Akka.Cluster's network connections, by 500%.
- Cleaned up a bunch of excess memory usage in several places, most notably our logging system.Performance wasn't really the goal of this release, although we consistently measure, test, and improve the performance of Akka.NET over time. Performance improvements came as a result of finding more robust ways to implement some of the internals Akka.NET uses.
InfoQ: What would be your favorite feature of this release?
Stannard: Funnily enough my favorite part of the 1.1 release is the part that I had nothing to do with: Akka.Streams.
What's truly remarkable about Akka.Streams is how it lets users succinctly express complex workflows in just a few lines of code, including traditionally difficult concurrent programming problems such as backoff and throttling. I was able to rewrite the heavy-duty portion of our WebCrawler Akka.Cluster demo using Akka.Streams in a couple of hours yesterday with no prior experience using the library and was able to use some of the built-in buffering flows to solve a throttling problem we've had for years in that code base. Using Akka.Streams for the first time gave me the same rush that using actors for the first time did: made me realize that I have access to an entirely new way of programming than what I had before.
InfoQ: How do you establish your roadmap?
Stannard: The current roadmap for Akka.NET is driven by a number of factors; parity with the original JVM implementation of Akka is a big one. We benefit from their experience and from the bug reports of their users, so there are tremendous benefits to sticking closely to their implementation.
InfoQ: How do you benefit from following in the footsteps of the JVM implementation of Akka?
Stannard: Developers must never discount that time-in-production is the most valuable metric for gauging the health of a code base and its ideas. A large open source project with thousands of users running it 24/7 on thousands of servers is going to accrue way more time in production than a proprietary, singular line of business application ever will. That means more bugs, design flaws, and productivity improvements will be found faster and more often. This helps explain why virtually every Daily WTF article about some horrible code bomb that goes undiscovered for years originates from single-use proprietary code or not widely used OSS. This is why we try to stick with the JVM's ideas - their designs are informed by the long time it's spent in production.
InfoQ: In what ways does your roadmap differ from Akka for the JVM?
Stannard: Akka.NET itself has been in production for a long time now. We've accrued our own productivity improvements / bugs / different ideas from our users, and there's some significant differences between the .NET ecosystem and the JVM that we have to factor into our roadmap. .NET developers are addicted to dependency injection frameworks, for instance, whereas you tend not to see as much of that in Scala. So that plays into how we might choose to design something in the future that diverges from the JVM, such as making DI support a first-class feature rather than a plugin.
There's also some modules the JVM has that we don't have much interest in porting - Apache Camel integration, for instance. I have yet to find a .NET shop that uses it. There's also Akka.HTTP, which is a monster of a module that has been worked on for years. We won't be porting that any time soon because it's relatively low value compared to everything else we're delivering to our users right now.
In general our users tend to be using Akka.NET in server-side applications. What they really want is our high availability (HA) modules like Akka.Cluster, Persistence, Streams and Sharding to all run on .NET Core on Linux. So the next big effort that will shape our roadmap will likely be some initial forms of .NET Core support for Akka.NET.
InfoQ: Akka.NET is primarily C# but has also an F# API. Do you use F# in the implementation?
Stannard: Personally, I'm not much of an F# user but I'm looking to change that. I maintain our build system, which is written in F# using FAKE. That's where I get most of my F# practice. I'm looking to build some internal applications for Petabridge soon and I'm considering using Suave with Akka.Cluster on Windows Azure Service Fabric for that. Akka.NET has definitely been a gateway drug into functional programming for me. Many of the concepts that are fundamental to FP such as pattern matching and stream iteration, are the meat of and potatoes of an actor system. F# is a natural next step from Akka.NET in the progression of any .NET developer's career.
Akka.NET is an open source project hosted on Github. Detailed documentation is available on the Akka.NET website.
