Practical Microsoft Orleans

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:

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.


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.

Sample Application

As with other blog series I’ve done in the past, I find it helpful to take an existing OSS application that I can fork and use as a base.

Do you have a suggestion about an application I can fork to use as a base?  I’d love to hear your suggestions.  Let me know Twitter or in the comments.

Brighter MySQL Command Store

I’ve been wanting to explore Brighter for awhile, probably over a year.  I figured I’d try something new this time around and actually explore it by contributing to the project itself.  I noticed there were no Command and Message Stores yet supporting MySQL.  Turns out it was pretty straight forward to port the Sqlite Message & Command over to MySQL.  So that’s what I did, created a Brighter MySQL Command Store.


First, if you’re unfamiliar with Brighter, here’s a quick description:

This project is a Command Processor & Dispatcher implementation that can be used as a lightweight library in other projects.

It can be used for implementing Ports and Adapters and CQRS (PDF) architectural styles in .NET.

In addition, Brighter supports Distributed Task Queues. As such it can be used to improve performance by introducing concurrency using a queue, and/or as an integration strategy between Microservices using messaging via a lightweight broker.

I like to think of Brighter as your possible next step from MediatR.  Since everything in MediatR is in process, which is great in many situations, it can also be less ideal in others.  When you need task queues, retry,  and circuit breaker type functionality is where Brighter can help right out of the box.

Command Sourcing

Don’t confuse Command Sourcing with Event Sourcing.  If you are, check out the Brighter docs that go into it a bit to clarify.

Any command dispatched with Brighter can be stored.  It’s actually pretty straightforward to setup.  I’m going to use the new MySqlCommandStore that I recently created as the example.

Register IAmCommandStore

First thing you need to do is register the MySqlCommandStore as a IAmACommandStore and/or IAmACommandStoreAsync, in the container you are using in your HandlerConfiguration.  Here’s a modified version of the HelloWorld sample.

For reference, the two parameters in the MySqlCommandStoreConfiguration are the connection string and the table name.

UseCommandSourcing Attribute

Second and last step is to add the UseCommandSourcing attribute to the command handler you want to persist into command store (MySQL table).


When I run the sample app, here is the console output:

And the resulting record now stored in our MySQL database:


I plan on blogging more about Brighter in the near future.  Are you using Brighter?  Are there any specific features or topics you would like me to cover?  Let me know in the comments or on Twitter.

Explore DDD 2017 Review

I just returned from Denver, Colorado, where the first Explore DDD conference was held.  I originally heard about it earlier in the year on Twitter via the organizer Paul Rayner and decided to submit a couple abstracts for the CFP.

Fat Controller CQRS Diet

The talk that was accepted and which I delivered on Friday morning was my Fat Controller CQRS Diet talk.  The talk revolves around trying to decouple your application from top I/O layer or framework.  More info on the talk can be found in my series of blog posts as well as a episode of Software Engineering Daily podcast.

Domain Driven Design

I stumbled upon Domain Driven Design somewhere around 2010.  I actually found it because of watching a talk online from Greg Young making some indirect references to Domain Driven Design and CQRS.  The talk caught my interest and within no time I was captivated by DDD and CQRS.  I instantly went and purchased the book.  That was a very significant point in my software development career.

Explore DDD

The speaker lineup at this conference was simply incredible.  Eric Evans, Rebecca Wirfs-Brock and Ward Cunningham were the keynotes.  Crazy.

I cannot really believe that I was chosen to speak at such a conference. Imposter Syndrome was maxed out to 11.

It didn’t take too long to have some conversations at the conference to realize that I had different experiences and views that proved to be valuable.  This didn’t knock down the imposter syndrome completely, but definitely lowered it a just a tad.  On the other hand, the amount that I learned from discussions and talks were like no other conference.


This really summed it for me.  There was a real sense of community/family.  I can’t really put my finger on why that is but I have a few guesses.

Conference Space/Location

Incredible.  38th Floor of the Grand Hyatt, looking over downtown Denver.  The floor itself was broken down into 3 track rooms, general gathering room where food was served, as well as a unique blue track room.  The blue track was reserved for spontaneous modeling, discussions, problem solving, whatever.  I actually had several interesting discuss here and it was kind of a good place for the “hallway” track in some respects.

Paul Rayner

The conference kicked off on Wednesday evening with the keynote by Eric Evans.  Paul spoke to intro the conference as well as each day with some house keeping notes.  I felt the way Paul gave such a calm welcoming, really set a tone for the entire conference.

Thank You!

Hands down an awesome conference.   Thank you to Paul for organizing an incredible event and selecting my talk.  All the attendees and speakers (from all over the world!) for making it feel like a family.

I highly recommend attending this next year.  I hope to see you there!