Using Codename “Orleans” in Enterprise Applications

One of the more interesting announcements at the //Build conference in April was the availability (in preview) of the new actor-based cloud framework, codenamed “Orleans” (watch the session here). 

I’ve been using Orleans for over a year now and it’s great to see it now generally accessible.

Orleans represents a new approach to computing, and cloud computing specifically. In Orleans, the unit of computation is the “actor,” a (usually) compact .NET object running in the context of a worker role. Orleans however makes it possible – and relatively easy – to scale up to thousands or even millions of instances of these objects, for them to communicate with one another, and for them to maintain state. Additionally, these object instances can exist on dozens or hundreds of servers, and the management of their locations – i.e., which server – is entirely handled by the Orleans runtime. In effect, Orleans abstracts out much of the complexity of distributed computing at scale for you.

Writing an Orleans actor – called a “grain” in the vernacular – is straightforward. Grains have an interface definition (along the lines of IDL) and an implementation. Visual Studio templates (provided with the download) do most of the behind-the-scenes work. What would you use Orleans for? Well, we used it for several different applications. The video game Halo 4 (in multiplayer mode) uses Orleans, where every player and every game was represented by grains; that is to say, for every player online there was, and is, a corresponding grain running on Orleans (running on Microsoft Azure). In Halo, Orleans is used for player presence detection and a number of other services (see Caitie’s description here); and unlike typical middle-tier functions, grains are stateful. (This state is easily persisted to a backing store so that grains can be reinstantiated in the event of a hardware failure or other exception.) With Halo, which at peak traffic supports a huge number of concurrent users, Orleans enabled the scale that was required.

But the usage of Orleans is not confined to games, and, in fact, it is already used a number of other scenarios. Just recently for example we hosted a hackfest here in Redmond for selected customers to try out Orleans in their scenarios, and we found that it is applicable to a number of scenarios. Think about using grains to represent devices in the Internet of Things world, or to represent people in a social networking context. Any time you have large quantities of object instances that need very rapid response time and communications between each other Orleans is a consideration.

I mentioned that I’ve been using Orleans myself for over a year. For me, what Orleans brings is an almost seductive simplicity to large-scale distributing programming. At first, all the developer creates is a simple .NET object, with an interface definition used by other objects that want to communicate with it. Grain interfaces use the Task Parallelism Library (TPL) to manage the asynchronous nature of many objects running on potentially many servers. So an Orleans method looks pretty much like any other object method, but with TPL syntax and semantics:

async Task<string> Hello(string message)
    return (“Hello there”);

And here is how it’s called from another grain:

async Task SayHelloToGrain()
     GrainRef g=MyGrainFactory.GetGrain(GUID); 
     await g.Hello(“Hi”); 


Orleans figures out where the grain is located, activates it if necessary, and invokes the method. Without really knowing it, your developers are writing scalable distributed applications. 

There’s a lot to Orleans and I hope I’ve whetted your appetite for more. Check out the public preview here.

Comments (0)

Skip to main content