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