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