Sponsor: Using RabbitMQ or Azure Service Bus in your .NET systems? Well, you could just use their SDKs and roll your own serialization, routing, outbox, retries, and telemetry. I mean, seriously, how hard could it be?
I’ve been wanting to take a deeper dive into Microsoft Orleans for awhile now. With the next release targeting .NET Standard 2.0, it felt like an great time to do it. This is the first blog post in a series that will go beyond a simple Hello World. The plan is to make this a practical Microsoft Orleans guide to follow along with.
Blog Post Series:
- Part 1 – Practical Orleans
- Part 2 – Grains and Silos
- Part 3 – Smart Cache Pattern
- Part 4 – Event Sourced Grain
- Part 5 – EventStore for Grain Persistence
Microsoft Orleans
If you aren’t familiar with Orleans, here’s a brief overview.Orleans is a framework that provides a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.Or maybe you have heard Orleans is an Actor model framework. Well…
Implementation of Orleans is based on the Actor Model that’s been around since 1970s. However, unlike actors in more traditional actor systems such as Erlang or Akka, Orleans Grains are virtual actors. The biggest difference is that physical instantiations of grains are completely abstracted away and are automatically managed by the Orleans runtime. The Virtual Actor Model is much more suitable for high-scale dynamic workloads like cloud services and is the major innovation of Orleans. You can read more details in the Technical Report on Orleans.
Docs
I have to give it to the Orleans team. Their docs seem fantastic. I’ve read over most of their Step-by-Step guide and feel like there’s a lot of insight being shared. There’s a section about Concurrency that has some great code samples that gives with code samples a deadlock scenario. I found reading over these docs to be really helpful in understanding and just looking at small code samples.Event Sourcing
One aspect that I find interesting is having a grain manage it’s state being event sourced.Event sourcing provides a flexible way to manage and persist grain state. An event-sourced grain has many potential advantages over a standard grain. For one, it can be used with many different storage provider configurations, and supports geo-replication across multiple clusters. Moreover, it cleanly separates the grain class from definitions of the grain state (represented by a grain state object) and grain updates (represented by event objects).My plan is to use event sourcing as grain state and persist events to Event Store. Luckily I’m familiar enough with Event Store however have to do more reading on if there is an existing implementation or have to roll my own.