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?

Today the Akka.NET project hit a massive milestone and became code complete for version 1.0.

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.

“Code Complete?”

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 -beta tag 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.FSharp
• Akka.Remote
• Akka.TestKit
• 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:

1. Bug fixes;
2. Spec verification;
3. Enhancements (don’t affect the public API);
4. Documentation;
5. 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...

Today we’re going to learn about one of the really cool things actors can do: change their behavior at run-time!

This capability allows you to do all sorts of cool stuff, like build Finite State Machines (FSM) or change how your actors handle messages based on other messages they’ve received.

Today, we’re going to cover how to make a basic FSM using switchable behavior. We’ll go over advanced FSM approaches in a future post.

Let’s start with a real-world scenario in which you’d want the ability to change an actor’s behavior.

Real-world Scenario: Authentication

Imagine you’re building a simple chat system using Akka.NET actors, and here’s what your UserActor looks like - this is the actor that is responsible for all communication to and from a specific human user.

public class UserActor : ReceiveActor { private readonly string _userId; private readonly string _chatRoomId; public UserActor(string userId, string chatRoomId) { _userId = userId; _chatRoomId = chatRoomId; Receive<IncomingMessage>(inc => inc.ChatRoomId == _chatRoomId, inc => { // print message for user }); Receive<OutgoingMessage>(inc => inc.ChatRoomId == _chatRoomId, inc => { // send message to chatroom }); } } 

So we have basic chat working - yay! But… right now there’s nothing to guarantee that this user is who they say they are. This system needs some authentication.

How...

Now that Akka.NET is leaving beta and hitting the 1.0 milestone, we’ve seen interest and production usage ramp up quickly.

The Last Few Months

Over the last two months, we’ve been working with several cutting-edge teams to help them rearchitect and build out new systems for use cases as diverse as citywide Internet of Things (IoT) monitoring, rearchitecting to microservices, and converting their ETL pipelines from batch to realtime.

Oh, and we’ve been teaching a lot of people the actor model and how to use Akka.NET through our Akka.NET Bootcamp and on-site training.

During that time, we got a little busy and forgot to announce this, so let’s fix that: Petabridge is now officially available for consulting, training, and support!

How We Can Help You

Consulting

Get your Akka.NET projects out the door faster by getting some help from the people who work on it.

Whether you’re looking to rearchitect your system to use microservices, migrate from hacky batch processing to responsive + streaming ETL, or you want to build out scalable new capabilities from scratch, we can help you get there faster. We also have a special offering for combining Akka.NET with Cassandra.

In-person Training

Want to learn how Akka.Cluster and Akka.Persistence can help you build high availability systems easily? And how to integrate them with other technologies your company currently uses like ASP.NET, SignalR, NServiceBus, or Windows Azure?

Well, we do that!

Support

Get fast resolutions to your issues with Akka.NET applications from members of the core engineering team.

In short, we can help you create the new system you’ve envisioned, train your team, and/or help you through whatever bugs come up in your system, saving you tens of thousands of dollars and hundreds of hours of aggravation.

Let’s...

Over the last several months, interest in Akka.NET has increased dramatically. And yet, many people find the actor model intimidating and can’t seem to really get up and running. Developers want to learn how to use Akka.NET, but where do they go? There haven’t been very many good answers to that question. Until now.

We decided to fix that.

And so…

Introducing Akka.net Bootcamp

I’m pleased to announce that we’ve launched Akka.NET Bootcamp to provide this exact learning resource to developers everywhere!

We put bootcamp together to help you learn the insanely powerful actor model in an accessible, fun way. The course starts from fundamentals and takes you all the way to knowing what you need to in order to create sophisticated, distributed apps in .NET.

What Is Bootcamp?

Bootcamp is a free, self-directed learning course. You can do it at whatever pace you wish. Bootcamp launched initially in C# only, but F# support is almost done. Hundreds of developers around the world are already members of Bootcamp.

Why Should I Do Bootcamp?

You know that you need to get ahead of the curve and learn about distributed computing, functional programming, and cloud computing. When we started learning about distributed computing, we were overwhelmed by the sheer amount of things we needed to know. Consistent hashing, consensus algorithms, PAXOS, Raft, replication strategies… the list goes on and on.

After over a year of hard work, we’re thrilled to announce that Akka.NET will soon be leaving beta! The community of global contributors has grown rapidly and is picking up even more momentum.

Akka.NET (repo) is a community-driven port of JVM Akka to .NET. Akka.NET is a programming framework, based on the Actor Model, for building powerful concurrent & distributed applications more easily.

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.

After releasing v0.8 last week, the core contributors met to lay out the roadmap to v1.0 and decide which features will be finalized for the release, and which will remain in beta.

The general focus for the release is a lot of polishing and testing, along with some feature improvements.

When Will 1.0 Come Out?

With some room for error built in, we expect to have 1.0 live in the next 1-2 months.

What’s in 1.0?

Scheduler API Rework

Håkan is leading the charge on redoing the Scheduler API. To revisit, this is the ability to schedule future and/or recurring tasks within your actor system.

Supervisor Strategy Serialization

Roger is already well-underway on reworking how Supervisor strategies are serialized. This will help us ensure that remote hierarchies work as intended when using Akka.Remote and Akka.Cluster.

Specs & Added Stability

The test suite is already thorough, but Bartosz is leading the charge on adding more tests, general polishing, and digging through APIs just to make sure.

Documentation Rework and Cleanup

Andrew is working with a number of community members to rework the documentation, especially the onboarding process for new users to...

NOTE: These are the official release notes from https://github.com/akkadotnet/akka.net/releases/tag/v0.8, but with some slight formatting changes.

Dependency Injection Support For Ninject, Castle Windsor, and Autofac

Thanks to some amazing effort from individual contributor (@jcwrequests), Akka.NET now has direct dependency injection support for Ninject, Castle Windsor, and AutoFac.

Let’s dive in!

How do you keep your actor system from falling apart when things go wrong?

The short answer is Supervision.

What Is Supervision, and Why Should You Care?

What Is Supervision?

“Look at this mess you made. Now clean it up and start over!”

Just kidding. You’re doing great. Relax.

But I bet you’ve heard (and probably said) something similar before. That’s similar to supervision in the actor model: a parent monitors its children for errors, and decides how to clean up messes when they happen.

Why Should You Care?

Supervision is the basic concept that allows your actor system to quickly isolate and recover from failures.

Supervision from the top to the bottom of the actor hierarchy ensures that when part of your application encounters an unexpected failure (unhandled exception, network timeout, etc.) those failures will be contained to only the affected part of your actor hierarchy. All other actors will keep on working as though nothing happened. We call this “failure isolation.”

How is this accomplished? Let’s find out…

One of the first questions developers ask once they learn how Akka.NET actors work is

If actors can only process one message at a time, can I still use async methods or Task<T> objects inside my actors?

The answer is yes! You can still use asynchronous methods and Task<T> objects inside your actors - using the PipeTo pattern!

(2/05/2022) Update

We have completely revised our guidance around await vs. PipeTo in our latest post”: Async / Await vs. PipeTo in Akka.NET Actors”

(8/20/2016) Update

Since Akka.NET 1.0 was released, Akka.NET actors have fully supported async / await inside actors. But there’s a catch involved. We still strongly recommend PipeTo over asyc / await for performance and cohesion reasons but there are scenarios where the latter makes life easier. Keep reading!

Actors Process Messages One at A Time

So actors process the contents of their inbox like this:

The actor’s mailbox pushes a new message into the actor’s OnReceive method once the previous call to OnReceive exits.

This is an important concept, because this is how Akka.NET enforces thread-safety for all of the code that executes inside an actor - by making sure an actor’s message processing code (OnReceive) can only be run one invocation at a time.

That being said, it’s still possible to take advantage of async methods and methods that return Task<T> objects inside the OnReceive method - you just have to use the PipeTo extension method!

When I write about Akka.NET and the actor model, this is not what I mean:

I’m probably going to abuse this stupid joke in every 100-level blog post and video where I introduce the concept of Actors, so please bear with me.

In all seriousness, an actor is a broad concept. Here’s my layman’s definition of the actor model:

An “actor” is really just an analog for human participants in a system. Actors communicate with each other just like how humans do, by exchanging messages. Actors, like humans, can do work between messages.

Think of something like a call center, where hundreds of customers might call a 1-800 number and have concurrent conversations with one of many possible customer service agents.