Best Practices for Integrating Akka.NET with ASP.NET Core and SignalR

How to Host Akka.NET Inside ASP.NET Core and SignalR Applications

In the recent past we blogged about hosting headless Akka.NET services using IHostedService and we thought we’d extend that train of thought to cover ASP.NET Core. .NET’s web ecosystem has changed a lot since 2015, when we last wrote about hosting Akka.NET with ASP.NET MVC and even NancyFX on .NET Framework 4.5 - so we’re due for an update.

So, we went ahead and put together a video: “Best Practices for Integrating Akka.NET and ASP.NET Core” which demonstrates how to work with Akka.NET and ASP.NET Core inside a single process.

This blog post accompanies that video and expands on some of the advice we give in it!

NOTE: Also, please check out our Petabridge.App.Web dotnet new template to use these patterns straight away inside your own applications!

Case Study: Vertech Using Akka.NET for Device Simulation

Vertech Akka.NET Case Study: Using Akka.NET to Simulate PLCs in Airport Baggage Handling Systems

Vertech Logo

Vertech is an industrial automation and information solutions company based out of the United States that develops solutions for a broad range of industries.

This case study was authored by John Wolnisty, a Solutions Architect at Vertech who, in the context of this case study, used Akka.NET to help test, simulate, and build solutions for airport baggage handling systems.

What does Vertech do?

Based in Phoenix, Arizona, Vertech designs and implements industrial automation solutions including traditional automation systems, SCADA systems, MES solutions, and OT networks. One of our industry focuses is airport baggage handling systems. A large airport can have hundreds of conveyors that need to be integrated and controlled by the system. Airport security requirements add layers of complexity requiring control systems that account for every bag on a conveyor and track suspicious activities, such as a bag suddenly disappearing or a new bag appearing from the middle of a conveyor. At Vertech we provide comprehensive solutions that handle all these details by personally writing everything from automation code in PLCs to the high-level systems that interface with airline data feeds.

What problem were you trying to solve?

A PLC (Programmable Logic Controller) is an industrial computer repetitively running logic that reads input sensors, implements operational behaviors and controls outputs. Inputs are control panel switches, push buttons, photo-eyes and the like. Outputs are motors, lights, warning horns and other devices. The PLC programmers have a problem, especially with a large system, of being unable to develop and test their code without the physical hardware being present. We had a need for a system that could simulate the conveyor hardware, provide relatively seamless connections with the PLCs, display the output conditions, and log what was going on without having to set up...

How to Build Headless Akka.NET Services with IHostedService

Creating Stand-alone Akka.NET Services with Microsoft.Extensions.Hosting and IHostedService

At Akka.NET’s inception, most of the server-side code samples we produced all demonstrated how to build so-called “headless” Akka.NET services as outright Windows Services primarily using libraries like Topshelf.

.NET has changed tremendously since then and become a truly cross-platform runtime that is capable of working with and within all of the amazing innovations that have sprung from the greater global open source community, such as Kubernetes and Docker. Thus, it’s time we modernize our guidance for how to build headless services in the age of .NET Core / .NET 5 and beyond.

We’ve produced a YouTube video demonstrating how to Host Akka.NET using IHostedService which demonstrates the modern approach to configuring and hosting stand-alone Akka.NET services:

This blog post compliments the YouTube video!

Akka.NET Dependency Injection Best Practices

How to work with the new Akka.DependencyInjection library and Microsoft.Extensions.DependencyInjection

As part of the Akka.NET v1.4.15 release we’ve completely rewritten how dependency injection works in Akka.NET and introduced a new library: Akka.DependencyInjection. In this blog post we’re going to introduce Akka.DependencyInjection and some of the best practices for working with it.

We’ve also produced a brief YouTube video that demonstrates how to work with Akka.DependencyInjection too:

Real World Akka.NET Clustering: Process Managers and Long-Running Operations

Using Process Managers with Akka.Persistence and Akka.Cluster.Sharding to Manage Complex, Long-Running Workflows

In our previous installment of “Real World Akka.NET Clustering”, we covered state machines - the tried and true tool for modeling event-driven behavior for business entities inside your domain. And we also demonstrated that using Akka.NET programming techniques such as behavior-switching it’s straightforward to implement them with actors.

In this post we’re going to take our discussion of real-world Akka.NET actors to a higher level and discuss how to use the process manager pattern with actors to model long-running, stateful workflows that naturally occur in all sorts of business domains.

Process Managers

What is a process manager? A process manager is a state machine used to direct a dynamic, stateful workflow. In the context of modern software applications most process managers tend to be responsible for managing distributed workflows that are executed across different services or multiple instances of a service.

Process managers are:

  1. Reentrant - when we say “long-running” in the context of a workflow this often means durations measured in minutes, hours, or days - not seconds. Therefore, process managers are often programmed so they can be passivated (i.e. put to sleep) and recovered at a future point in time. We typically accomplish this using Akka.Cluster.Sharding in Akka.NET.
  2. Durable - in order to be reentrant process managers must persist their state to a durable store of some kind, typically either a cloud filesystem or a database. This is a good fit for Akka.Persistence.
  3. Driven by State Changes - process managers determine the next course of action in a workflow based on the output of the current and previous states. If we’re in error, perhaps we retry the most recent failed operation. If the operation failed irrecoverably, maybe we need to perform some reverisions and send a report back upstream.
  4. Not Responsible for...

Phobos v1.0.0 - Programmatic Configuration, Improved Integrations, and Reduced Pricing

Phobos 1.0.0 is Cheaper, Faster, and Better Than Before

Phobos logo

Phobos is Petabridge’s application performance monitoring (APM) integration library for Akka.NET, which we released originally back in 2018. Since then it’s undergone some major changes and transformations in order to better support Akka.NET and Akka.NET users.

Short Version

  • Phobos, our Akka.NET application performance monitoring (APM) library that automatically traces and measures actor activity without requiring you to write any instrumentation code, 1.0.0 is now available.
  • It now easily integrates with non-Akka.NET technologies such as ASP.NET and works with a much larger selection of tracing and metrics APM systems than it did before.
  • Phobos now only costs $4,000 per year per organization with no limitations on the number of seats or nodes it’s installed upon.
  • You can buy Phobos instantly online via credit card at Sdkbin.
  • We offer a full 30-day money back guarantee, so if you contact us within 30 days of your purchase and are dissatisfied with your purchase we will refund you in full.
  • Each Phobos subscription comes with support provided by the Petabridge team, so if you need help installing / configuring / deploying Phobos or if it’s not capturing the data you need you can ask us to help at no additional charge.

You can learn more about Phobos at https://phobos.petabridge.com/ or buy instantly online at https://sdkbin.com/publisher/petabridge/product/phobos

What Phobos Does

Phobos is a set of properietary NuGet packages that you can install into a pre-existing Akka.NET application and automatically begin capturing operational metrics and tracing data, collectively called “telemetry” data, without needing write any APM decorator code.

Real World Akka.NET Clustering: State Machines

Using Akka.Cluster and State Machines to Build Reactive Systems

Petabridge recently launched its first cloud service, Sdkbin, and it’s been a great opportunity for our team to use the Akka.NET tools, patterns, and practices that we’ve been recommending to our customers for years.

In this blog post I’m going to walk through one of the most universal real-world Akka.NET actor patterns: the state machine.

Finite State Machines: a Primer

One of the major drawbacks of web programming is that due to its stateless and non-local affinity, many programming patterns that were commonplace in embedded, desktop, and client programming have lost their importance in everyday programming. These “lost patterns” tend to be stateful ones - and none more so than the “finite state machine” or “FSM” for shorthand.

Finite State Machine concept

The idea behind a finite state machine is simple but powerful:

  1. For a given type of entity modeled in your software system it can exist in one of many possible states - but it can only occupy a single state at a time;
  2. An entity usually has some “state data” objects that provide contextual information for the current unit of work in process - i.e. an Order entity might be in an Open state and have an OrderData object that contains a unique orderId, customerId, and so on;
  3. As the state machine processes events both its state and its state data can change - in particular, the state machine can transition from one state to another in response to 1 or more events being processed; and
  4. States can be re-entrant - an entity can return to its original state in the event of a timeout, error, or based on the type of event it processed.

When Do You Need a State Machine?

If...

Now Open for Business: Sdkbin - the Marketplace for .NET Developers

A Better Way to Buy and Sell Business-to-Developer Software and Services

Sdkbin Logo - The Marketplace for Software Developers I formally introduced Sdkbin back on my personal blog in June, 2020, but it was not yet ready for Petabridge, its customers, or the users of the open source projects we support. As of September 30th, Sdkbin is now live and open for business.

So, what is Sdkbin?

A Better Way to Buy and Sell Business-to-Developer Software and Services

Petabridge has been in business for nearly 6 years and nearly all of our business comes from supporting Akka.NET and its users.

Among the products and services we sell:

Some of these services, such as code review and onsite training, are inherently bespoke - we have to tailor what we deliver to the unique needs of each customer.

But other services, such as Phobos and our Akka.NET Support Plans, are valuable because they are so standardized - pick a license / service level, a quantity, buy it, and use it. As we’ve learned over the course of time: it is very painstaking to build and run sales, fulfillment, renewal, and support operations for these services manually.

The manual experience is also suboptimal for our customers:

  1. It’s difficult to keep track of license keys, remaining support hours, and which team members have access to each of these through all of the separate systems we use for delivering these products and services (i.e. Freshdesk, MyGet, and Github;)
  2. Business continuity is an issue - if a key decision maker leaves then service disruptions often occur; and
  3. Managing renewals often means an arduous procurement process if...

The Current State of OpenTelemetry in .NET

OpenTelemetry vs. OpenTracing and the Future of Observability in .NET

In the past we’ve discussed why distributed tracing is becoming commonplace and the OpenTracing standard for instrumenting libraries and applications. In this post I want to touch on the emerging OpenTelemetry standard, which will become a common component used to instrument ASP.NET Core applications in the not too distant future.

OpenTelemetry logo

What is OpenTelemetry?

OpenTelemetry is the convergence of two competing tracing standards:

  • OpenTracing - developed by a community of APM vendors and library authors and
  • OpenCensus - developed by Google.

The goal is to provide a unified set of APIs library authors can include inside their applications in order to:

  • Propagate distributed tracing context, including the new W3C HTTP tracing standard;
  • Aggregate metrics (counters, meters, etc); and
  • Export metrics and trace data to a variety of different Application Performance Monitoring (APM) backends, which can be configured entirely by the application developer.

OpenTelemetry vs. OpenTracing

OpenTelemetry vs. OpenTracing

So what are the material differences between OpenTelemetry and OpenTracing? Why do we need another new standard?

The major technical differences are:

  1. OpenTelemetry’s core library is the Tracer implementation - the traces are created and correlated using OpenTelemetry calls and then only during the export process do the traces hit any vendor-specific code. This makes the performance of OpenTelemetry very consistent regardless of what vendors end-users choose. In contrast, with OpenTracing all of the real calls are done by a vendor-specific implementation of the OpenTracing APIs - so as a library author you could have a great set of benchmarks using a Zipkin OpenTracing library but not-so-great ones using a Jaeger OpenTracing library. I prefer OpenTelemetry’s approach here.
  2. OpenTelemetry supports metrics instrumentation in addition to tracing - a library author...

Akka.NET v1.4 is Available on .NET Standard 2.0

Akka.Remote Performance Improvements, Akka.Cluster.Sharding out of Beta, Akka.Cluster.Metrics, and More

As of this week, Akka.NET v1.4 is now fully available for users to use. We’ve published a detailed article on the Akka.NET website that describes what’s new in Akka.NET v1.4, but we wanted to capture some of the highlights here.

Akka.Cluster.Sharding and Akka.DistributedData are out of Beta

Akka.Cluster.Sharding has been used by Akka.NET users in production for years, mostly relying on the underlying Akka.Persistence storage engine to save all of the sharding state used to distributed entity actors evenly across the cluster.

Akka.Cluster.Sharding actor distribution

However, the reason why the module remained in beta for the past couple of years is because Akka.Cluster.Sharding’s alternate storage mode, Akka.DistributedData, which uses eventually consistent in-memory replication to manage cluster sharding state throughout an Akka.NET cluster, lacked a stable wire format and hadn’t been certified for production yet.