Category Archives: Software development

StackExchange.Redis Connection In Short

Last year I wrote an article about the right way to set up a Redis connection using StackExchange’s Redis client library. A lot of people found this useful, but at the same time the article went into a lot of detail in order to explain the dangers of doing this wrong. Also, there is a connection string format that’s a lot more concise.

So here’s how you set up a Redis connection using StackExchange.Redis, really quickly. If you need to just try this out quickly, you can grab a copy of Redis for Windows (just remember that this is not supported for production environments).

First, install the NuGet package for the Redis client library:

Install-Package StackExchange.Redis

Then, figure out what connection you need, and build a lazy factory for it (ideally the connection string should come from a configuration file):

        private static Lazy<ConnectionMultiplexer> conn
            = new Lazy<ConnectionMultiplexer>(
                () => ConnectionMultiplexer.Connect(
                    "localhost:6379,abortConnect=false,syncTimeout=3000"));

My original article goes into detail on why this lazy construct is necessary, but it is mainly because it guarantees thread safety, so the ConnectionMultiplexer will be created only once when it is needed (which is how it’s intended to be used).

You build up a connection string using a comma-separated sequence of configuration parameters (as an alternative to ConfigurationOptions in code, which the original article used). This is more concise but also makes configuration a lot easier.

At the very least, you should have one or more endpoints that you’ll connect to (6379 is the default port in case you leave it out), abortConnect=false to automatically reconnect in case a disconnection occurs (see my original article for details on this), and a reasonable syncTimeout in case some of your Redis operations take long.

The default for syncTimeout is 1 second (i.e. 1000, because the value in milliseconds), and operations against Redis should typically be a lot less than that. But we don’t work in an ideal world, and since Redis is single-threaded, expensive application commands against Redis or even internal Redis operations can cause commands to at times exceed this threshold and result in a timeout. In such cases, you don’t want an operation to fail because of a one-off spike, so just give it a little extra (3 seconds should be reasonable). However, if you get lots of timeouts, you should review your code and look for bottlenecks or blocking operations.

Once you have the means to create a connection (as above), just get the lazy value, and from it get a handle on one of the 16 Redis databases (by default it’s database 0 if not specified):

var db = conn.Value.GetDatabase();

I’ve seen a lot of code in the past that just calls GetDatabase() all the time, for each operation. That’s fine, because the Basic Usage documentation states that:

“The object returned from GetDatabase is a cheap pass-thru object, and does not need to be stored.”

Despite this, I see no point in having an unnecessary extra level of indirection in my code, so I like to store this and work directly with it. Your mileage may vary.

Once you’ve got hold of your Redis database, you can perform your regular Redis operations on it.

            db.StringSet("x", 1);
            var x = db.StringGet("x");

On Akka .NET Actor Creation

Abstract: this article is a bit of a rant about how actors are created in Akka .NET, and suggests a way of making it just a little bit more manageable. This is written based on my limited knowledge of Akka .NET, and I will be more than happy to stand corrected on the matters I write about.

Actors Need Props

Creating an ActorSystem and actors in Akka .NET is one of the most basic necessities, and it is something you’ll be doing all the time. Once you have an ActorSystem, you can create actors using an IActorRefFactory implementation (i.e. the ActorSystem itself, or an actor’s Context). This requires you to use Props.

            using (var actorSystem = ActorSystem.Create("MyActorSystem"))
            {
                var props = Props.Create<MyActor>();
                var actor = actorSystem.ActorOf(props);

                Console.ReadLine();
            }

What the hell are Props?

This is explained by Unit 1 Lesson 3 of the Petabridge Akka .NET Bootcamp. Basically, the answer is something like: it’s a recipe for creating actors, but don’t worry about it for now; we’ll use it later.

As a matter of fact, it’s needed mainly for advanced scenarios such as remote deployment and clustering. Most of the time as you’re learning to use Akka .NET, you don’t really care about them.

Creating Props

There are three ways to create Props, all involving some manner of a call to Props.Create().

The first way is to give it a Type.

var props = Props.Create(typeof(MyActor));

This is discouraged by Akka .NET, because it has no type safety and in fact lets you do stupid things like this:

akka-actorcreaton-typeof

The second way is to use a generic form:

var props = Props.Create<MyActor>();

While this is encouraged in the bootcamp, I personally discourage this. This is because while it gives you type safety over the actor type, it doesn’t give you any guarantees with the parameters:

akkanet-props-generic-2

The third way is to pass in a factory method. This is a great way to create Props because it’s the only one that lets you pass dependencies into the actor’s constructor in a type-safe manner (particularly important to use constructor injection if you’re thinking of writing tests against your actors).

var props = Props.Create(() => new MyActor());

Making It Better

In reality, most of the time I don’t care about Props. So why do I have to constantly bother about them? Actually, if we take a closer look at the third way of creating Props, we can wrap them into oblivion:

akkanet-props-expression

See that generic Expression over there? That’s what we need to avoid all this madness. Based on that, we can create a generic method to take care of everything:

    public static class IActorRefFactoryExtensionscs
    {
        /// <summary>
        /// Creates an actor, creating props based on the provided
        /// actor factory method.
        /// </summary>
        /// <typeparam name="T">The actor type.</typeparam>
        /// <param name="actorRefFactory">ActorSystem or actor Context.</param>
        /// <param name="actorFactory">Actor factory method.</param>
        public static IActorRef CreateActor<T>(this IActorRefFactory actorRefFactory,
            Expression<Func<T>> actorFactory) where T : ActorBase
        {
            var props = Props.Create(actorFactory);
            var actor = actorRefFactory.ActorOf(props);
            return actor;
        }
    }

To create an actor directly from the ActorSystem, we now only need to do this:

var actor = actorSystem.CreateActor(() => new MyActor());

…and to do it from inside an actor, it’s just as easy:

var actor = Context.CreateActor(() => new MyActor());

Weird Conventions

This is where the rant begins.

Apart from all the weirdness associated with having to deal with Props in the first place, Unit 1 Lesson 3 of the Petabridge Akka .NET Bootcamp has this little gem that makes my day brighter every time I read it:

How do I make Props?

“Before we tell you how to make Props, let me tell you what NOT to do.

DO NOT TRY TO MAKE PROPS BY CALLING new Props(...). Similar to trying to make an actor by calling new MyActorClass(), this is fighting the framework and not letting Akka’s ActorSystem do its work under the hood to provide safe guarantees about actor restarts and lifecycle management.”

Here’s a similar gem from Unit 1 Lesson 1:

NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you’re using new you might be making a mistake.”

Wait, what? These guys are telling us to call static Create() methods rather than using constructors. These are the same people who told us that using async/await in actors is bad (which has since been corrected). I don’t know, but I bet if you ask anyone who has done OOP before, they’ll tell you that if there’s a mistake, it’s in Akka .NET’s design.

But to really top it all, check out the following comment from Aaron Standard (Petabridge CTO and Akka .NET co-founder) on the Reddit thread about one of his articles (emphasis mine):

Orleans is a piss-poor implementation of the Actor model and breaks a lot of the conventions that make it powerful, aside from having an overall hideous set of programming conventions. But because MSFT released it, people will flock to it like lemmings.

“We’re going to keep working on Akka.NET because there’s a community supporting it now and because we believe in TypeSafe’s vision for actor systems.”

A case of the pot calling the kettle black? Or quoting Confucius, “Don’t complain about the snow on your neighbor’s roof when your own doorstep is unclean.”

In any case, my goal is not to start a flame war but to understand why the Akka .NET API (and codebase) is such a mess. If you look at the source code for ActorSystem, for instance, it does not do anything so particularly complicated that would justify banning constructor calls. In fact, the call to ActorSystem.Create() ends up here:

        private static ActorSystem CreateAndStartSystem(string name, Config withFallback)
        {
            var system = new ActorSystemImpl(name, withFallback);
            system.Start();
            return system;
        }

In fact, although you shouldn’t do this, this code works just as well as what we had before:

            using (var actorSystem = new ActorSystemImpl("MyActorSystem"))
            {
                actorSystem.Start();

                var actor = actorSystem.CreateActor(() => new MyActor());

                Console.ReadLine();
            }

Why is this even public such that I can call it?

Conclusion

The API provided by Akka .NET, particular in ActorSystem and actor creation, is very strange indeed. We are discouraged to do something as trivial a calling a constructor, and have to deal with Props even though we won’t need them most of the time. It is hard to speculate on why this API was written this way without having the developers provide insight on it.

At the very least, aside from pointing out these obvious flaws, this article aims to suggest best practices on how to go about creating Props, and to provide an extension method to hide the existence of Props for the majority of cases where using them directly isn’t really necessary.

Using ReceiveTimeout in Akka .NET

In Akka .NET, you can opt to receive a special message when an actor is idle (i.e. does not receive any message) for a certain period of time. This message is the ReceiveTimeout, and is particularly useful to clean up idle actors when using the Entity Per Child pattern (although various other scenarios exist where this might be used).

The source code for this article is available at the Gigi Labs BitBucket repository.

Let’s consider an ActorSystem with a single actor. The ActorSystem sends a message to this actor every few seconds, using the built-in Akka .NET Scheduler:

            using (var actorSystem = ActorSystem.Create("MyActorSystem"))
            {
                var actor = actorSystem.ActorOf(
                    Props.Create<SomeActor>(), "SomeActor");

                actorSystem.Scheduler.ScheduleTellRepeatedly(
                    initialDelay: TimeSpan.FromSeconds(1),
                    interval: TimeSpan.FromSeconds(5),
                    receiver: actor,
                    message: "Hello!",
                    sender: ActorRefs.NoSender
                );

                Console.ReadLine();
            }

In the actor itself, we call SetReceiveTimeout() in order to be able to receive a ReceiveTimeout message after the specified idle period elapses. Then, we handle the ReceiveTimeout message just like we would handle any other message.

    public class SomeActor : ReceiveActor
    {
        public SomeActor()
        {
            this.Receive<string>(Handle, null);
            this.Receive<ReceiveTimeout>(Handle, null);

            var timeout = TimeSpan.FromSeconds(3);
            this.SetReceiveTimeout(timeout);
        }

        private void Handle(string msg)
        {
            Console.WriteLine(msg);
        }

        private void Handle(ReceiveTimeout msg)
        {
            Console.WriteLine("Timeout received!");
        }
    }

If we run the application with the code we have so far, we get this:

akkanet-receivetimeout-nokill

Although we are handling the ReceiveTimeout message, we aren’t really doing anything to react to it. As the ReceiveTimeout documentation states, the ReceiveTimeout will keep firing after periods of inactivity.

To disable the ReceiveTimeout altogether, just call SetReceiveTimeout() again, passing in null:

this.SetReceiveTimeout(timeout);

You will often want to kill the actor altogether. In particular when using the Entity Per Child pattern, you will want to kill off actors that aren’t in use to keep your memory footprint low; and since you’ll have a parent actor taking care of routing messages and creating child actors as needed, any new message to that actor will cause it to be recreated.

There are different ways to kill an actor, so just pick one and use it in your ReceiveTimeout handler:

        private void Handle(ReceiveTimeout msg)
        {
            Console.WriteLine("Timeout received!");

            Context.Stop(Context.Self); // stop the actor
        }

Since we’re killing the actor now, any subsequent messages become undeliverable:

akkanet-receivetimeout-kill

WPF/MVVM DataGrid with Select All

Introduction

WPF is great to quickly build tools because it’s very versatile. In this article, we’re going to disregard the WPF DataGrid’s row selection functionality, and create a DataGrid that allows (a) selection of individual items using a checkbox, and (b) selection of all/none using a master checkbox:

wpf-dgselectall-finalresult

We’re going to do this using the Model-View-ViewModel approach, which you should be already familiar with (at least in theory) before reading on.

The source code for this article is available at the Gigi Labs BitBucket repository.

Setting up MVVM

After creating a new WPF application, install the MVVM Light Toolkit using NuGet. install the libs-only version to avoid getting a lot of extra junk in your project:

Install-Package MvvmLightLibs

Create a class called MainWindowViewModel, and make it public:

    public class MainWindowViewModel
    {
    }

In MainWindow.xaml.cs (the codebehind file for the main window), set up the view model as the DataContext:

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            this.DataContext = new MainWindowViewModel();
        }
    }

A Model Object

We need to create a data object (Country in this case) whose fields will be displayed in the DataGrid. For this sort of thing, it typically needs to have:

  1. An ID. We won’t use this here, but if your data is coming from a database, you’ll usually need it.
  2. A name. This will be displayed in the DataGrid.
  3. A selection boolean. This will be used to indicate whether the item has been selected or not, and we will bind the checkbox to it.

Create a class called Country. It needs to be public, and it also needs to derive from GalaSoft.MvvmLight.ObservableObject:

    public class Country : ObservableObject

This will allow us to call the handy Set() method which handles all the INotifyPropertyChanged stuff and makes sure that WPF’s data binding engine gets notified that the property has changed, so that it can update the UI:

    public class Country : ObservableObject
    {
        private int id;
        private string name;
        private bool selected;

        public int Id
        {
            get
            {
                return this.id;
            }
            set
            {
                this.Set(() => Id, ref id, value);
            }
        }

        public string Name
        {
            get
            {
                return this.name;
            }
            set
            {
                this.Set(() => Name, ref name, value);
            }
        }

        public bool Selected
        {
            get
            {
                return this.selected;
            }
            set
            {
                this.Set(() => Selected, ref selected, value);
            }
        }

        public Country(int id, string name)
        {
            this.id = id;
            this.name = name;
        }
    }

The need to do the INotifyPropertyChanged bit prevents us from using autoproperties when implementing WPF models (and adds a significant amount of boilerplate), but the MVVM Light Toolkit reduces this overhead as much as possible.

Setting Up the DataGrid

Let’s add a list of countries to our MainWindowViewModel:

    public class MainWindowViewModel : ViewModelBase
    {
        public ObservableCollection<Country> Countries { get; }

        public MainWindowViewModel()
        {
            var countries = new Country[]
            {
                new Country(1, "Japan"),
                new Country(2, "Italy"),
                new Country(3, "England"),
                new Country(4, "Norway"),
                new Country(5, "Poland")
            };

            this.Countries = new ObservableCollection<Country>(countries);
        }
    }

Here, we’re inheriting from GalaSoft’s own ViewModelBase class, which gives us access to various methods we typically need when doing WPF with MVVM (we’ll use a couple of these later). Other than that, we’re simply creating an ObservableCollection of countries. ObservableCollection is great because it automatically notifies the UI that an item has been added or removed. Although it’s not strictly necessary here, it’s quite ubiquitous in WPF code that uses MVVM.

Next, let’s add the actual DataGrid in MainWindow.xaml:

<Window x:Class="WpfDataGridSelectAll.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:WpfDataGridSelectAll"
        mc:Ignorable="d"
        Title="Choose Countries" Height="350" Width="525">
    <DataGrid AutoGenerateColumns="False"
              ItemsSource="{Binding Path=Countries, Mode=OneWay}">
        <DataGrid.Columns>
            <DataGridTemplateColumn>
                <DataGridTemplateColumn.CellTemplate>
                    <DataTemplate>
                        <CheckBox HorizontalAlignment="Center"
                                  IsChecked="{Binding Path=Selected,
                                      UpdateSourceTrigger=PropertyChanged}" />
                    </DataTemplate>
                </DataGridTemplateColumn.CellTemplate>
            </DataGridTemplateColumn>
            <DataGridTextColumn Header="Country" Binding="{Binding Path=Name}" />
        </DataGrid.Columns>
    </DataGrid>
</Window>

Note that I could have used a DataGridCheckBoxColumn for the checkbox, but I didn’t. That’s because there’s this annoying problem where you need 2 clicks to select a checkbox in a DataGrid (one to give the row focus, and the other to check the checkbox). A simple solution for this issue is to use a DataGridTemplateColumn instead, and set UpdateSourceTrigger=PropertyChanged.

So now we have a simple DataGrid:

wpf-dgselectall-justdatagrid

Basic Select All

Let’s add a checkbox in the header of the checkbox column. This will act as the master checkbox. When you click this, it will toggle all the other checkboxes.

            <DataGridTemplateColumn>
                <DataGridTemplateColumn.Header>
                    <CheckBox IsChecked="{Binding Path=DataContext.AllSelected,
                                   UpdateSourceTrigger=PropertyChanged,
                                   RelativeSource={RelativeSource FindAncestor,
                                       AncestorType={x:Type Window}}}" />
                </DataGridTemplateColumn.Header>

The binding is a little elaborate because it needs to look for the AllSelected property (which we’ll implement next) on the MainWindowViewModel, which is actually the DataContext of the window.

Next, in the MainWindowViewModel, let’s add a property that the above binding will work with:

        private bool allSelected;

        public bool AllSelected
        {
            get
            {
                return this.allSelected;
            }
            set
            {
                this.Set(() => AllSelected, ref allSelected, value);

                foreach (var country in this.Countries)
                    country.Selected = value;
            }
        }

Note how in the setter, we’re doing some extra logic. When we change the checked value of the master checkbox, we go in and change the Selected state of all the countries accordingly.

This is enough to give us a working Select All/None toggle:

wpf-dgselectall-basic

If you click the top checkbox, all the others will be checked. And if you uncheck it, all the others will be unchecked.

Full Select All

What we did in the previous section has a flaw:

wpf-dgselectall-flaw

If you check the master checkbox, but then uncheck one of the other checkboxes, the master checkbox remains checked! And likewise, if start with nothing checked, and check all of them one by one, this is not reflected in the master checkbox.

In order to make this work properly, the individual checkboxes need a way to tell the view model that their state has changed, so that it can update the master checkbox as needed. One way to do this is to have the Country take a function that it will call whenever the selection state changes:

    public class Country : ObservableObject
    {
        private int id;
        private string name;
        private bool selected;
        private Action<bool> onSelectionChanged;

        // ...

        public bool Selected
        {
            get
            {
                return this.selected;
            }
            set
            {
                this.Set(() => Selected, ref selected, value);

                this.onSelectionChanged(value);
            }
        }

        public Country(int id, string name, Action<bool> onSelectionChanged)
        {
            this.id = id;
            this.name = name;
            this.onSelectionChanged = onSelectionChanged;
        }
    }

In the MainWindowViewModel, we now need to update the Country initialisation to pass in a method which we’ll create next:

        public MainWindowViewModel()
        {
            var countries = new Country[]
            {
                new Country(1, "Japan", OnCountrySelectionChanged),
                new Country(2, "Italy", OnCountrySelectionChanged),
                new Country(3, "England", OnCountrySelectionChanged),
                new Country(4, "Norway", OnCountrySelectionChanged),
                new Country(5, "Poland", OnCountrySelectionChanged)
            };

            this.Countries = new ObservableCollection<Country>(countries);
        }

The method that gets called whenever a checkbox changes needs to cater for two edge cases:

  1. Master checkbox is checked (i.e. all are selected), but a checkbox just got unchecked. The master checkbox needs to be unchecked.
  2. Master checkbox is unchecked (i.e. not all are selected), and all checkboxes are now checked. The master checkbox needs to be checked.

Here’s the implementation:

        private void OnCountrySelectionChanged(bool value)
        {
            if (allSelected && !value)
            { // all are selected, and one gets turned off
                allSelected = false;
                RaisePropertyChanged(() => this.AllSelected);
            }
            else if (!allSelected && this.Countries.All(c => c.Selected))
            { // last one off one gets turned on, resulting in all being selected
                allSelected = true;
                RaisePropertyChanged(() => this.AllSelected);
            }
        }

Note how we are not setting the AllSelected property directly, as that would execute the foreach statement that affects the other checkboxes. Instead, we are bypassing this by setting the backing field, and notifying WPF’s data binding engine that it needs to get the latest value for the AllSelected property.

And this gives us a fully working master checkbox:

wpf-dgselectall-finalresult

Interview: Virtual Actors with Microsoft Orleans

Introduction

In recent years, the ever increasing demand for computing resources has rendered traditional single-threaded programming inadequate for most modern applications. Faced by heavy performance and scalability challenges, many developers are forced to turn to concurrent and distributed programming.

While multithreaded programming has been in use for many years, those who have used it will know that building a performant shared memory system free of race conditions can be very challenging to get right.

It is possible to avoid the complications of shared memory systems, and indeed multithreading, by using a message passing system. An actor model is a framework where processing is done by a large number of single-threaded actors, which communicate together by sending asynchronous messages.

As it turns out, Microsoft have their own actor model, and it’s called Orleans. Sergey Bykov (SB), Principal Software Development Engineer Lead at Microsoft, and project lead of the Orleans project, has very kindly agreed to answer my (DD) questions about Orleans.

Orleans Overview

DD: What is Microsoft Orleans?

SB: The home page of our docs says the following.

“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. It was created by Microsoft Research and designed for use in the cloud.

“Orleans has been used extensively in Microsoft Azure by several Microsoft product groups, most notably by 343 Industries as a platform for all of Halo 4 and Halo 5 cloud services, as well as by a growing number of other companies.”

SB: In other words, Orleans provides a programming model (backed by the Orleans runtime) for building distributed scalable applications almost as easily as single machine apps. The goal of the project from the beginning was to democratize cloud development by making a broad range of developers with little to no distributed systems expertise productive and successful in building scalable distributed systems in general, and cloud services in particular.

The introduction explains that Orleans is built around a distributed actor model, and the key innovation there is the notion of Virtual Actors. Detailed description is in our publication.

DD: Out of curiosity, why the name, ‘Orleans’?

SB: It was a general rule within Microsoft that codenames should be chosen from geographical names like names of cities because those aren’t trademark-able. Over time, the codename of Orleans accrued enough brand recognition that we decided to stick with it when we went open source.

DD: Tell us a little about the history of Microsoft Orleans.

SB: Orleans started in 2009 as a research project within a new Microsoft Research lab that eventually was named eXtreme Computing Group (XCG, it was later merged with MSR’s Redmond lab). The goal for the project was to try to create something that would qualitatively simplify creating software for the cloud. The two major challenges we focused on were 1) the complexity of building distributed systems that has traditionally been the domain of a relatively small population of expert developers; and 2) the pattern of major re-architectures required from nearly every successful web property as they experienced exponential growth of their user base.

We took on building a framework with a programming mode that would make mainstream single-machine developers productive in the cloud and would help build systems and services that could easily scale through several orders of magnitude of growing scale. While focusing on mainstream developers, we wanted Orleans to be as appealing to expert developers, by reducing the amount of low level ceremony they have to deal with. As we went through several early prototypes and iterations, we learned quite a bit from building first Orleans applications, and even more so when we started collaborating with internal product groups. The programming model has evolved, and we arrived to what we ended up naming the “Virtual Actor Model”.

Using Orleans

DD: How does Microsoft Orleans compare with other actor models?

SB: The Actor Model is quite old, and there are many various implementations of it. There’s a much smaller number of available Distributed Actor Model solutions. The most popular ones are Erlang/OTP and its JVM “younger sibling” Akka. Erlang and Akka organically grew from being single process actor libraries into the multi-machine scenarios by gradually adding remoting and distribution features. They brought the fault tolerance model of hierarchical supervision trees that are easy within a single process, acceptable for small-scale fixed topologies, but are difficult to manage at cloud scale, especially for developers with limited distributed systems experience.

The Virtual Actor Model of Orleans removed a lot of coordination and fault tolerance complexity from developers’ shoulders by providing an intuitive notion of actors that don’t need to be created, destroyed or looked up. The “Virtual” qualifier comes from the analogy with virtual memory. Actors in Orleans live “eternal” life, always available for a call to process, and the Orleans runtime is responsible for instantiating their physical “incarnations” in memory on an as needed basis, and for removing idle ones to free up resources. The Orleans runtime also transparently handles failures of servers by keeping track of instantiated actors and recreating them when needed on a different server in case of a failure. As a result, the developer writes much less code (we’ve received anecdotal reports of 3-5 times reduction of code, up to 10 times in some cases) and much simpler code, free from data races and complex distributed coordination logic.

The effort of Orleans to ‘democratize’ distributed programming and to raise developer productivity received an endorsement of sort from the inventor of Actor Model, Carl Hewitt. In his recent publication Actor Model of Computation for Scalable Robust Information Systems he wrote that: “Orleans is an important step in furthering a goal of the Actor Model that application programmers need not be so concerned with low-level system details.” Obviously, that made the Orleans team very proud.

DD: In Microsoft Orleans, virtual actors are also known as grains. They run within host processes called silos. Why were these names devised?

SB: Early on we had the intuition that we’d end up with a novel programming model. In hindsight, that was prescient. The “grains” term is distinct from the already overloaded term actor, where it’s hard to tell upfront if somebody is talking about single machine concurrency or about a distributed case. In the end, “grain” is a shorthand for “Orleans actor” or “virtual actor”. When we needed to name the runtime containers for grains, we naturally went down the agricultural path with “silos”. Just imagine the confusion if called them “containers”.

DD: Who is using Microsoft Orleans, and how well does it support their systems’ scalability?

SB: Orleans has been used in production inside Microsoft since 2011. It is enjoing a growing adoption outside Microsoft after we publicly released a binary preview, and then open-sourced it. We see a wide range of systems built with Orleans: online gaming, finance, collaboration solutions, fraud detection, social network analysis, and more. One of the hottest areas is IoT. There we see Orleans-based systems that manage devices like thermostats and even, I’m not joking, mousetraps. One of the fascinating projects is the green power storage facility in Hawaii. We showed some scalability numbers in our paper.

DD: Is Microsoft Orleans meant only to be used in the cloud?

SB: The advent of the cloud brought the challenges of building reliable scalable distributed systems into the spotlight. Orleans as a project focused on solving those fundamental challenges. As a result, Orleans is equally applicable in any cloud and on premises. We have customers running Orleans in AWS and some interested in GCP, but also those that use it in private datacenters and on corporate IT infrastructures. Our first target was naturally Azure, and we built providers and extensions for it first. But Orleans was designed with extensibility in mind, and it is fairly easy to make it run pretty much anywhere.

Development and Support

DD: What is the Microsoft Orleans team currently working on, and is there a roadmap for future development?

SB: Our current focus is on making Orleans run on .NET Core, support for geo-distribution, improvements to streaming, application lifecycle and the upgrade and versioning process. Even though the project moved out of Microsoft Research to the product group, we have an ongoing collaboration with Research, which gives us a healthy pipeline of new ideas and advanced prototypes. Support for geo-disribution is one example. We also have support for indexing of actors, ACID multi-actor transactions, and reactive computations at various stages of readiness. Orleans is one of the most popular Microsoft open source projects, right next to .NET Core and Roslyn. We continue to work on it and recently substantially increased our investments.

DD: What resources are available for developers building their systems upon Microsoft Orleans?

SB: We keep hearing that our documentation is very good compared to other open source projects, but we keep improving it (and samples) as people point to topics that aren’t clear or can be explained better. The community around the project is our biggest “brain trust” and the best source of support for new people. It’s an amazing group of experienced and passionate engineers around the globe that come to our GitHub repo and Gitter chat not only because they use Orleans for their projects and contribute to it, but also because they enjoy hanging out with this very welcoming and encouraging community that always tries to help, even with topics not directly related to Orleans.