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.

Read more

The Petabridge team (all two of us) just wrapped up a big two weeks. We launched Akka.NET V1.0 and then traveled to Portland to talk about .NET open source software at .NET Fringe.

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:

1. Switch jobs to someplace else and hope the environment is more stimulating; or
2. Become complacent (the “default” option) and stop being curious about software development; or
3. Take matters into your own hands and become responsible for your own happiness when it comes to software development.

Read more

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!

Akka.NET (repo) is a community-driven port of Typesafe’s Akka project to .NET. Akka is a framework for building powerful concurrent & distributed applications that scale up/out or down on any cloud.

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

Read more