Aaron Stannard talk about Akka.net 1.1

Akka.net 1.1 has been released recently, bringing new features and performance improvements. Infoq interviewed Akka.net maintainer Aaron Stannard to learn more about Akka.streams and Akka.cluster. Aaron also elaborated on the roadmap plans related to the implementation of the Akka for JVM.

InfoQ: What are the salient features of this version?

The main goal of Aaron Stannard:Akka.NET 1.1 is to turn akka.cluster from beta packages into final version (RTM) packages. This release also provides testing tools to test a wide range of different network scenarios that may occur in the process of running akka.net clusters in a production environment.

Don't underestimate the great effort we have made; Akka.cluster Beta was originally released in August 2014. So it took us about two years to develop akka.cluster and collect feedback from production users. In the final phase of development of version 1.1, we are primarily improving the reliability and speed of the cluster system so that it can be used for highly available workloads. There are already banks, healthcare providers, energy producers, fleet and fleet management companies, SaaS companies, and many others who use akka.net in production environments. Akka.cluster is what they most want to see published.

Another prominent feature of version 1.1 is the first beta version of Akka.streams, which introduces a new approach to building responsive applications using akka.net, allowing developers to represent a range of asynchronous operations into a large number of interconnected and reusable flow-processing diagrams. You can see from our documentation what the Akka.streams diagram might look like.

What performance improvements does the InfoQ:Akka.Net 1.1 offer?

Stannard: The most significant performance improvements include:

• Reduced memory footprint by 34% for all actors;
• Increased throughput by 5 times times for each akka.remote connection (subsystem supporting the Akka.cluster network connection);
• Corrected a number of places where memory is overused, most notably the log system;

While we are constantly measuring, testing, and improving the performance of akka.net, performance is not the true purpose of this release. The improvement in performance stems from our finding a more robust approach to implementing some of the internal artifacts used by akka.net.

InfoQ: What is your favorite feature in this release?

Stannard: Oddly enough, in version 1.1, my favorite part is a part of me that has nothing to do with me: Akka.streams.

What's really striking about akka.streams is that it allows users to simply express complex workflows in just a few lines of code, including traditionally very difficult concurrency programming problems, such as avoidance and throttling. In the absence of experience, I used akka.streams yesterday to rewrite the part of the WebCrawler Akka.cluster demo program that handles heavy tasks in a few hours. I also used some built-in buffer streams to solve the throttling problems that existed in that code base for years. As with the first use of the actor, I was thrilled to be using Akka.streams for the first time: I realized that I was using a new programming method that I had never used before.

InfoQ: How did you make the roadmap?

Stannard:Akka.NET the current roadmap is facilitated by a number of factors, and consistency with the original Akka for JVM is an important factor. We benefit from their experience and user-reported bugs, and therefore, follow their implementation with great benefits.

InfoQ: What benefits do you get by following the implementation of the Akka for JVM?

Stannard: Developers should never forget that "production time (Time-in-production)" is the most valuable metric for measuring the health of a codebase and its ideas. A large, open-source project with thousands of users and 7x24 hours running on thousands of servers compared to a proprietary single line of business application can accumulate more time in a production environment. That means that more bugs, design flaws will be discovered more quickly, and productivity can be improved more often. This explains why, in the daily WTF article on Scary code bombs, almost all of the code bombs that were not discovered for years were from a single proprietary code or an open source software that was not widely used. That's why we're trying to follow the Akka for JVM idea-their design comes from a long run in a production environment.

InfoQ: What is the difference between your roadmap and the Akka for JVM?

The Stannard:Akka.NET itself has been used for a long time in the production environment. We've got our own productivity improvement/bug/different ideas from our customers. The huge difference between net and JVM ecosystems is also what we must consider when we develop a roadmap. For example. NET developers are particularly fond of dependency injection frameworks, which are often rare in scala development. That difference would have an impact on the roadmap, and in the future we might choose to design something different from the JVM, such as making di support a one-off feature rather than a plug-in.

There are also some modules in the Akka for JVM that we don't have much interest in porting-like Apache camel integration. I haven't met any other family. NET workshop with it. And Akka.http, a monster-class module We've been developing for years. We will not be porting in the near future because it is less valuable than what we are now providing to users.

Generally speaking, our users often use Akka.net in server-side applications. What they really want is our high availability (HA) modules, like akka.cluster, persistence, streams, and sharding, all running on. NET core on Linux. So next, the main task that will affect our roadmap may be that Akka.net provides initial support for. NET Core.

InfoQ:Akka.NET is primarily C #, but it also has the F # API. Did you use F # in your implementation?

Stannard: Personally, I'm not using F #, but I'm going to change that. I maintain our build system. The system was written in F # and used fake. Most of my experience with F # has come from there. I am planning to build some applications for Petabridge internal use in the near future, and I would consider using suave and akka.cluster on Windows Azure Service fabric. Undoubtedly, akka.net made me fall in love with functional programming. Many of the basic concepts of FP, such as pattern matching and "stream iteration", are the main parts of the actor system. In any. NET developer's career, F # will naturally become the next step in Akka.net.

Akka.net is an open source project hosted on GitHub. Detailed documentation is available on the Akka.net website.

Original address: Http://www.infoq.com/cn/news/2016/07/akka-dotnet

Aaron Stannard talk about Akka.net 1.1