Our Akka.NET Virtual Meetup on August 12th was a huge success - we had about 100 users on the livestream with us and the recording of the meetup has been viewed several hundred times since.

One of the topics I covered during my presentation about using Akka.NET in production at MarkedUp was the concept of stateful applications built with actors - the idea that state can reside within your application rather than outside of it by default, and how it was this idea that made our marketing automation product possible to build.

This tweet from an attendee sums up the realization well:

Exactly right! Actors can be stateful - and that means we no longer have to factor round-trip times to SQL Server, Redis, Cassandra, or whatever into the design of our applications. The application already has the state it needs to do its job by the time a request arrives!

The Limitations of Stateless Design

The traditional way of developing web applications is stateless - and that’s a natural consequence of HTTP, itself an inherently stateless protocol.

Many people in the Akka.NET community have been asking for case studies over the last few weeks, since we shared the MarkedUp case study. There are a ton of production deployments, but getting actual case studies out always has some lag time.

To that end, I wanted to share an email case study that I received from Joel Mueller, an Akka.NET community member, that just BLEW MY MIND (reprinted with permission).

Check out Joel’s story of how Akka.NET changed the trajectory of his business, which is now a part of McGraw Hill—owners of this little thing called Standard & Poor’s—and now proud users of Akka.NET, acquiring SNL Financial for $2 billion:

SNL Financial Joel Mueller Joel Mueller, Software Architect, SNL Financial

One of the features of a larger product I’ve been working on for years is a budgeting/forecasting module for community banks. Picture an ASP.NET project that is roughly the equivalent of 200-300 interrelated Excel workbooks, using a custom mostly-Excel-compatible formula engine, lots of business rules, lots of back-end queries against both SQL and Analysis Services, and a front-end in SlickGrid that communicates with the back-end over XHR and Web API. The object model for Forecast instances is (was) stored in ASP.NET session state until changes are saved to the application database. That, of course, means one instance per session, even if two people open the same forecast.

Then, as an afterthought bullet point at the end of a list of other new features being requested, “oh by the way, can you make it work for multiple concurrent users in a single forecast, Google Docs style?”

After I was done freaking out and yelling at people, I sat down to figure out how...

This is a short update, but an important one.

The first Akka.NET Virtual Meetup will be next Wednesday, August 12 @ 18:30UTC. RSVP Here.

The first ever community-wide meetup for Akka.NET will be taking place next Wednesday, August 12. You can RSVP here.

When is the meetup?

18:30UTC on August 12, 2015. (Click here to see that in your local time zone.) We tried to find a time when people from all over the world could attend, given the geographical diversity of the Akka.NET community.

Why should I come?

I can think of a ton of reasons, but here are three:

  • To ask questions & swap ideas with other community members
  • To learn about interesting case studies or use cases for Akka that you don’t already know about
  • To have connect and have fun with other really smart developers like you!

What will be covered?

This will be a combination of speakers sharing their stories / case studies, and an open forum for Q&A with the core team. In particular, Aaron will be sharing a powerful Akka.NET case study and story. We will also:

  • providing an update on the state of the project and its trajectory
  • give timelines for upcoming Akka.NET major releases
  • have open Q&A for anyone to ask whatever they want!

Where do I join?

RSVP here. Or, if you don’t have a Google account, here is the watch page link.

See you next Wednesday!

One of the questions that has been coming up a lot lately as many people are building with Akka.Remote is this:

How big of a message can I send over the network?

I’ve been asked about this four or five times this week alone, so it’s time to put out a blog post and stop re-writing the answer. This is a great question to cover, as it starts to reveal more about what is going on under the hood with Akka.Remote and the networking layer.

Up until I worked on Akka.NET, I honestly hadn’t thought much about the networking layer and so this was a fun question for me to dig into and research.

When Does This Come up?

This comes up all the time when people have large chunks of data that they need to transmit and process. I’ve been asked about this lately in the context of doing big ETL jobs, running calculations on lab data, web scraping, for video processing, and more. People asking about sending files that range anywhere from 20MB to 5GB.

All of these contexts involve large amounts of data that need to be processed, but no clear way to link that up with the distributed processing capabilities that Akka.NET provides.

So what’s a dev to do?

Here’s the first answer people try: “network-shmetwork! JUST SEND IT!”

Why This Is A Bad Idea

This is basically what that does to the network:

Python eating an entire pig

That is a python trying to eat an entire pig. Ewwwww. Gross.

If it could feel, that’s how the network would feel about our large messages.

What else do people try to do? Here are some of the common approaches I’ve seen:

  • crank up...

Just the other day, I saw this tweet and knew this post was long overdue:

Quite understandably, people want to know what the design patterns in Akka.NET are! There are quite a few-our team has cataloged 30+ across various areas of the framework so far-but there is also that rarefied set of patterns that show up again, and again, and again.

These patterns cover four broad categories:

  1. Actor Composition
  2. Messaging
  3. Reliability
  4. Testability

Let’s get going.

Actor Composition Patterns

“Actor Composition” patterns are used to create groups of interrelated actors in order to accomplish specific goals. Patterns of this type help you think about how many actors you need, and how to structure the relationships between them in your hierarchy.

These patterns are aimed at allowing you to use Akka.NET’s supervision hierarchy to your advantage in order to achieve maximum reliability and transparency when working with actors. They will also make your architecture more intuitive.

Composition Pattern: Child-Per-Entity

The Child-per-Entity pattern occurs whenever some /parent actor is responsible for a domain of entities and elects to represent each entity as its own actor. The parent maintains a mapping to know which child actor corresponds with which domain entity. The /parent can then lookup/create/kill child actors as domain object enter or leave its going concerns.

One of the most powerful ways to use Akka.NET in production is to create clustered applications that can scale on-demand. 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.Cluster module. AkkaCluster is the module that adds clustering capabilities to our Akka.NET applications.

When do I need clustering?

Clustering is something you need to use in high availability scenarios, or when you need elastic scalability in your systems.

Here are some examples of high availability scenarios that come up often in the real-world, and these are projects that often use clustering!

  • Analytics
  • Marketing Automation
  • Multiplayer Games
  • Devices Tracking / Internet of Things
  • Alerting & Monitoring Systems
  • Recommendation Engines
  • Dynamic Pricing
  • …and many more!

As you can see, clustering has a wide-range of use cases, and it’s also the way to create a scalable microservices architecture in Akka.NET. To put it bluntly, you should use clustering in any scenario where you have:

  • A sizable load of traffic;
  • With non-trivial work that has to be performed;
  • And an expectation of fast response times;
  • And frequent mutation in state.

How Do I Form a Cluster of Services?

After you’ve enabled Akka.Cluster inside your Akka.NET application, it’s easy to make your locally developed application cluster over the network.

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

If you’re interested in Akka.Persistence, things just became a lot more interesting! In the previous Akka.NET release (v1.0.1) we shipped Akka.Persistence.SQLServer (docs) (NuGet.)

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:

  1. 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.
  2. Accessing machine-specific resources - if you wanted to gather PerformanceCounter data 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 ActorSelection?

I loved this question, because there is more nuance to the seemingly mundane ActorSelection than meets the eye.

When Should I Use An ActorSelection?

The guideline I follow is to use an ActorSelection when:

  1. I need to take advantage of wildcard selection in actor paths for some reason.
  2. I need to communicate with an actor on a remote actor system, and I don’t have an actor reference for it yet.

Wildcard Routing

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 ActorPath.

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 NewOrderActors...