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.

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.

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

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:

• Akka.NET Online Training;
• Akka.NET Onsite Training;
• Akka.NET Code Review / Architecture Review;
• Akka.NET Support Plans; and
• Phobos - our Application Performance Monitoring (APM) suite for Akka.NET.

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

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.

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

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

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.

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.

The goal of this blog post is to give you a glimpse of the idea and basics behind Akka.Streams. What they are and why you may find them useful addition in your day to day job.

In short: Akka.Streams is a library build on top of Akka.NET, which allows you to consume and process potentially infinite streams of data in type-safe and resource-safe way.

To make it easier to visualize, let’s take an example: we have a queue (i.e. RabbitMQ), that sends us a documents, which we have to parse, turn into structured data and save in the database.

I originally started writing this post as internal documentation for our own team here at Petabridge, but I thought this would be useful for our readers and users as well.

Github has evolved over the years into a vast, rich ecosystem filled with lots of first and third party features that make developers more productive and effective.

Yet the vast majority of developers haven’t had much experience working effectively with Github in day-to-day work. Many developers don’t have a Github account; some have created some simple projects or filed some bug reports on popular projects; and few have forked a repository and made a pull request.

In this post you’re going to learn the best practices for working with teams of developers on Github who are working towards producing production-ready software. Everything in this post is equally applicable for developers working behind the firewall on proprietary software via Github Enterprise as it is for developers who want to submit a patch to popular open source projects like Akka.NET.

Two Unnecessary Costs of Software Development

Putting my “Chief Technology Officer” hat on for a second, there are lots of cost levers behind the total expense of software development and most of them are necessities. Yes, we should always allow plenty of time and money for testing and user feedback. Yes, we should try to pay down technical debt. We’re not talking about any of that.

What I’m talking about are unnecessary costs, waste costs, that can be avoided via using Github effectively as a communication platform among a development team. Those costs are:

1. False starts - designing the wrong thing from the beginning;
2. Blind alleys - designing the right thing using the wrong strategy.

In both of these cases the developers’ time and company money is wasted....

In this blog post we’re going to cover some best practices you can use when designing domain events and objects intended to work with Akka.NET. If you follow these best practices you’ll run into fewer errors, clearer log messages, and a better extensibility experience.

Use Marker / Identity Interfaces Generously

This first tip is designed to make it easier to extend your messaging systems without having to manually update the Receive<T> statements on a large number of actors.

Suppose I’m working the code from our new Akka.Cluster Workshop - in this application we have a large number of domain events for the purpose of trading stocks:

1. Bid - offer to buy N units of stock at a specific price point;
2. Ask - offer to sell N units of stock at a specific price point;
3. Match - the stock trading system has matched an Ask order with a Bid; and
4. Fill - some amount of a Bid or Ask order has been filled by a Match.

All of these events have several common identifiers and properties that can be really useful for routing, sharding, or distributing these messages:

1. The stock ticker symbol (MSFT, TEAM, AMD, etc…);
2. The id of the order; and
3. They all represent live trading events happening as a result of trader activity - this is distinct from an event emitted by the exchange indicating what the newest “market price” for a specific ticker symbol is.

Well, in order to make my system more extensible and easier to debug I’m going to introduce some common marker interfaces - for instance, an IWithStockId interface:

/// <summary> 
    

      
        
          Read more