Today we shipped Akka.NET v1.0.2, a maintenance release that fixed a number of bugs as well as introduced some exciting new features.
Major Akka.Cluster Stability Upgrades
Akka.Cluster is still in beta at the moment, but we’re on target for a full Akka.Cluster release in Akka.NET v1.1.
In this release we had some new contributors emerge from the ranks of Akka.NET’s production users to deliver some major stability upgrades to Akka.Cluster. We fixed critical issues in the following areas:
- Leader election algorithm;
- Clustered group routers;
- Akka.Remote and Akka.Cluster dispatchers now run on their own dedicated thread pools; and
- Akka.NET scheduler now runs on its own dedicated thread by default.
These changes resulted in massive improvements in cluster stability and reliability for these customers, and has helped put us on track towards our goal of a stable Akka.Cluster release in the near future.
New Akka.Persistence Plugins
In Akka.NET v1.0.2 we’ve added two new backing stores for Akka.Persistence:
Akka.Persistence is still in beta, but it’s one of the most exciting libraries in Akka.NET due to its ability to add guaranteed delivery and event sourcing to actors with high consistency requirements.
Other New Features
In addition to the above changes, we’ve also added the following additional packages to Akka.NET:
Akka.DI.StructureMap Akka.NET’s dependency injection system now supports StructureMap! You can install Akka.DI.StructureMap via the NuGet commandline:
PM> Install-Package Akka.DI.StructureMap
Akka.TestKit.XUnit2 Akka.NET now has support for XUnit 2.0! You can install Akka.TestKit.XUnit2 via the NuGet commandline:
One of the absolute coolest things you can do in Akka.NET is remotely deploy actors over the internet to other machines. You can literally deploy code somewhere other than the immediate, local process making the call.
And the way this is accomplished is with the Akka.Remote package - it’s the module that adds remoting capabilities to our Akka.NET applications.
When Would I Want to Remotely Deploy an Actor?
There are two common scenarios for when you would want to deploy an actor remotely:
- Work distribution - you need to be able to push work onto remote machines using a remote or clustered router. This is exactly what the Cluster.WebCrawler sample does.
- Accessing machine-specific resources - if you wanted to gather
PerformanceCounterdata from an array of remote machines in order to get specific metrics from each machine, remote deployment is an effective tool for accomplishing that.
Outside of these two use cases, it’s far more efficient to contact remote actor systems via
ActorSelection and remote
IActorRefs than it is to work via remote deployments.
I have to level with you. Dealing with network programming in my applications has always freaked me out a little bit.
You know what I’m talking about, don’t you?
Let’s be real about it: low-level network programming is some scary shit. When you have to step beyond the nice client libraries that wrap the networking protocols, there are sharp edges that can gleefully poke you in the eye whenever you make the tiniest misstep in your code.
To put it lightly, low-level network programming has not been a very pleasant experience.
There’s Power Beyond The Pain
And yet… it’s CRAZY powerful. It’s the key to the kind of applications you want to be building in your future.
Want to create a serverless, peer-to-peer, multiplayer video game? Get ready to dive into the networking stack.
Want to build a realtime analytics system for a network of remote devices in the Internet of Things? Yeah, request/response ain’t gonna cut it.
What about creating a live trading or marketing automation system with single-digit-millisecond response times? Ciao, HTTP. It’s been fun while it lasted.
Most developers I know are THRILLED by the idea of working on applications like this. And yet for most, building applications like this seems out of reach. Somehow off the table.
WTF? What’s up with that?
An HTTP Too Far?
It’s actually very simple. The reason that bold ideas like this seem out of reach is because most of us have been conditioned to use HTTP for…wait for it…everything.
My favorite part about teaching Akka.NET to people is the questions I get. I never have any clue what someone is going to ask me, and that’s kind of exciting.
Last Thursday, we had an awesome group of developers participate in our advanced Akka.NET Design Patterns training for half the day. We covered a ton of material, but in that time, there was a basic question that came up:
When should I use an
I loved this question, because there is more nuance to the seemingly mundane
ActorSelection than meets the eye.
When Should I Use An
The guideline I follow is to use an
- I need to take advantage of wildcard selection in actor paths for some reason.
- I need to communicate with an actor on a remote actor system, and I don’t have an actor reference for it yet.
The first case when I usually use an
ActorSelection is when I need to leverage wildcards in my actor paths. This is pretty rare, but one example could be if I needed to distribute a message to a number of actors who all lived at the same level in the hierarchy, or had a well-defined and predictable
For example, let’s imagine I had an
OrderActor and needed to report on new orders to finance, marketing, and fulfillment. Let’s imagine that each of those concerns has its own hierarchy, with a
NewOrderActor at the second level that is the ingestion point for new orders. It would look like this:
In this case, I could send the new order messages on to all three
The release of Akka.NET 1.0 marked the delivery of the project’s first major milestone and enabled us to commit to preserving long-term APIs for the foreseeable future.
The core Akka.NET team and I have put together a rough roadmap that outlines our development priorities for the next 12-18 months. Our chief objective is to build out all of Akka.NET’s high availability (HA) components and release them.
Here’s what the roadmap looks like in release order:
- Akka.NET v1.1 - full release of Akka.Cluster
- Helios 2.0 & Akka.NET v1.x - add TLS/SSL support to Akka.Remote and improved performance of networked actor systems. Can be released independently of other changes. Learn more about Helios 2.0.
- Akka.NET v1.2 - full release of Akka.Persistence with SQL Server, Windows Azure, and filesystem support built in.
- Akka.NET v1.3 - full release of Akka.ClusterSharding.
- Akka.NET v1.x - add support for Akka.IO, Akka.ClusterClient. Can happen independently of other changes.
- Akka.NET v1.4 - release of Akka.Streams and the initial Reactive Streams specification for .NET.
If you’re not sure what the names of these modules refer to then ask in our Gitter chat!
All of these represent major projects that are currently underway on the Akka.NET project itself. These priorities may change as new things occur in the .NET and Akka ecosystems, but for the time being these are the milestones we’ve committed to based on discussions with end-users.
We’re looking forward to having another great year and working with our contributors to deliver more new modules and tools for you to use! So make sure you follow the Akka.NET project on GitHub and get the latest changes!
Today, we’re going to begin introducing the world to the internals of Akka.NET. These are the advanced technical topics and explain what is actually going on “under the hood” to make the magic happen.
We begin our exploration with Akka.Remote.
What Is Akka.remote?
Akka.Remote is one of the most important modules in the entire framework. Akka.Remote is the module which actually enables a big percentage of the awesome feature of Akka.NET, such as:
- location transparency (not having to care which process—local or remote—an actor lives in)
- ability to scale out via configuration, instead of code
- Akka.Cluster and highly-available clustered systems (built on top of Akka.Cluster)
- ability to remotely deploy actors from one machine to another
In short: understanding Akka.Remote is a powerful tool to have at your disposal for building distributed systems in Akka.NET.
Akka.NET Remote Connections Explained
The most important piece to understand about Akka.Remote is how remote connections work, and what is the topology of actors responsible for managing remote connections.
One of central themes of .NET Fringe is open source communities - and there’s two sides to this coin:
- How does an open source project successfully attract contributors and make them effective?
- How does your typical software developer become an OSS contributor?
I’m going to touch on the former topic in a subsequent post, as that appeals to a more niche audience than the latter.
Why Do Open Source?
All OSS contributors start off like any other typical software developer… So let’s start there.
You work in an office and you’re initially really satisfied with what you do. But engineering is as much a creative endeavor as it is a technical one… And your day job doesn’t really scratch your itch entirely.
You really have the languages, frameworks, tools, and design methodologies that you currently use down cold. At least you think you do. So, in your opinion, there’s not a lot of new or exciting stuff happening at your work place.
After enough time passes, you start to feel unsatisfied. Bored. Unfulfilled.
And thus, you choose one of following:
- Switch jobs to someplace else and hope the environment is more stimulating; or
- Become complacent (the “default” option) and stop being curious about software development; or
- Take matters into your own hands and become responsible for your own happiness when it comes to software development.
Open-source frameworks these days, they just grow up so darn fast…
Today marks a major milestone on a long road—466 days since the first commit, to be exact—in bringing the Reactive Model to the CLR.
Akka.NET has officially left
-beta and is production-ready with stable C# and F# APIs, on both Mono and Windows!
The framework itself handles all thread management, low-level networking, and the utility code and “plumbing” for you. You just focus on the logic and workflow of your application.
Akka.NET has full C# and F# support, on Windows and Mono.
The Reactive Model Comes to .NET
In early 2014, Roger and Aaron teamed up to bring .NET developers the same power and flexibility that Scala/Java developers enjoy on the JVM. They were inspired by Typesafe’s Akka—the most powerful and important distributed computing framework in the world, trusted by Amazon, Twitter, Klout, Walmart, LinkedIn, Apache Spark and many more for doing massively parallel and stateful computing.
What Akka.NET v1.0 represents is the next step in bringing the principles of the Reactive Manifesto to the Common Language Runtime (CLR). The Manifesto is comprised of the following parts:
Reactive Systems are:
- Responsive: The system responds in a timely manner if at all possible.
- Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure.
- Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by...
Last week, Wired ran an article called “What Happens When Apple Buys a Company You Depend On?,” which tells the story of how FoundationDB was acquired by Apple and subsequently threw their customers under the bus.
This is a developer’s worst nightmare. The realization of their worst fears when they choose a technology to build on top of.
Imagine yourself in this scenario: you took a chance on a product or open-source project, invested time with your team to learn what it is and how it works, and figured out to use it to further your mission. You counted on it to be reliable, and wanted it to power your systems for years to come.
And then it gets abandoned, discontinued, or re-licensed, and all your work that depends on this technology is lost.
Anyone whose production systems depend on FoundationDB today is going to have to spend real dollars and real hours replatforming off of it. That’s time and money they could be investing into new development, but instead those resources have to be used to recover. That sucks.
How else could this acquisition occurred, assuming that Apple has no interest in continuing work on FoundationDB?
This puts us on track to hit the v1.0 public release within the timeframe that we (the core Akka.NET contributors) committed to back in February.
This means that every major feature and every public API has been completed and finalized in preparation for release.
1.0 is the release in which we’re going to shed Akka.NET’s
-betatag and commit to preserving these APIs long-term, so this is a major deal. More than a year’s worth of production usage, discussion, and designs have gone into these APIs.
A lot of carefully considered choices and designs go into each Akka.NET release, but this is the most important one we’ve ever done.
Here’s what will be included in the stable release of Akka.NET v1.0, for both Mono and Windows:
- Akka.NET Core
- Akka.DI (dependency injection)
- Akka.Loggers (logging)
We will be committing to the v1.0 APIs for long-term, production use.
Can I Still Contribute to 1.0?
Yes! You can! We’re no longer accepting public API modifications or additions, but here are some areas where we’re still actively accepting and encouraging contributions:
- Bug fixes;
- Spec verification;
- Enhancements (don’t affect the public API);
- And work on modules that aren’t shipping as part of V1.0, such as Akka.Cluster and Akka.Persistence.
If you want to start contributing to Akka.NET, join us in the Akka.NET Gitter chat. We’re a friendly bunch!
Timeline For V1.0 Release
We still have some work we do before we release the v1.0 bits - mostly documentation...