Since releasing Akka.NET 1.1 I’ve been spending more time sharpening the saw here at Petabridge. Combing over the ways we spend our time and money and quantifying the returns that provides to us and to our customers. As it turns out, quantifying this is rather difficult for reasons that are all-too-common in the business world: data silos.

Our “business output” is measured and recorded in a number of disparate, disconnected, off-the-shelf systems. For example: We record our sales through Stripe and Quickbooks Online, but we never correlate them with the end-user interactions with Akka.NET Bootcamp, our YouTube videos, or our blog.

We want a complete picture of what really lead to a sale or to a successful deployment of Akka.NET, because that helps tell us what were good investments of our resources. So in order to do this I started designing a business intelligence application called “Brute” designed to perpetually stream information from all of these sources into a consolidated view. The first version of it is extremely simple but we have plans to expand what it does and the number of systems it can connect to.

Designing an Akka.NET Application

I decided that “Brute” presented a good opportunity for Petabridge to dogfood Akka.NET, especially some of the new modules such as Akka.Streams and Akka.Cluster.Sharding. Thus I’ve spent the past few weeks in the design process writing specifications, models, and documentation.

Protocol-Driven Design

Here’s the catch with designing an Akka.NET application, or really, any actor-based application: your actors aren’t the correct place to begin the design.

Instead, you always want to start the design of any Akka.NET application with the flow of events and information that go through it.

Read more

More and more companies are choosing to use Akka.NET each day to fulfill mission-critical workloads in tons of different business domains: finance, health care, fleet and vehicle tracking, energy, and more.

Beginning today Petabridge is pleased to offer these companies Akka.NET certified builds, developer support, and production support to give them additional tools for getting the job done with Akka.NET in production.

Certified Akka.NET Build

The idea behind the certified build of Akka.NET is to make it easier to support; each Petabridge support subscription uses a certified build of Akka.NET which is authenticode signed and (optionally) strong named.

Our certified build is also subjected to additional testing and certification beyond the open source implementation before it’s released (specifically, it’s integrated and deployed into supported production environments and run under continuous load prior to being certified.)

Right now the certified build is limited to just the core Akka.NET modules but we will be adding support for specific plug-ins as-needed.

Developer Support

The first flavor of support Petabridge offers is “developer support” - this support plan is designed to assist Petabridge customers with design and developer activities to help head off issues before you go into production.

Each support customer can expect to have their design and development questions answered and issues resolved by an Akka.NET expert promptly.

Production Support

For customers who are already live in production Petabridge offers “production support” for them, to troubleshoot issues that occur in production in real-time. We guarantee fast turn-around times and the ability to get a live human being on the phone promptly (depending on your Service Level Agreement) if an issue occurs.

All of these services should help give any organization looking to leverage Akka.NET in production...

Read more

One of the most frequently asked questions about Akka.Cluster I receive is “how do I reliably distribute state in an Akka.NET Cluster?”

Akka.Cluster is primarily for building highly available, soft real-time applications in server-side environments - and one of the concepts that is essential to delivering “soft real-time” is statefulness.

Stateful applications are becoming more and more common because they execute types of work that are infeasible and impractical with stateless CRUD applications, but they also introduce new types of challenges such as:

• How do I evenly distribute state across my cluster? No “hotspots.”
• How do I find the state I need within my cluster?
• What happens to my state if a stateful node goes down?
• How do I guarantee that my state is modified safely? Consistent histories for state, in other words.

We can address, at a high level, all of these questions using a tool built into Akka.Cluster: consistent hash routers and Cluster.Sharding.

Read more