Microsoft Codename Orleans Public Preview


Yesterday at build the public preview of Micosoft’s Codename Orleans project was announced.

You can download the Orleans binaries here:

The blog post on the .NET blog has more details:

I was privileged enough to have early access to the project, and I wrote a few of the samples available in the Codeplex repository:


Why is Orleans Interesting?

Orleans is ideally suited to problems requiring both high scale and low latency, but that doesn’t preclude you from using it at small scale.

What Orleans does well is manage a large number of grains (the Orleans term for an actor) in memory, think hundreds of thousands of grains per server. It does this by managing the lifecycle of these objects, so they are only active when required, and after a certain period they can be garbage collected. Keeping these object in memory gives you low latency, as you can respond to requests on your system out of state you have in memory, rather than having to load information out of a database. It’s a bit like an in-memory cache in some regards, only the objects in the cache are programmable.

Orleans can run on a cluster of machines (think hundreds of machines) to provide the high scale. The system has a fairly linear relationship between throughput and cluster size, which in plain english means that adding more machines to your cluster will increase your capacity, and doesn’t degrade too badly due to inter-server communication.

Orleans is written in .NET, and you write your grains in C#. Grains are simply an interface and a class. The system is designed to be easy for the developer use. You don’t have to be a distributed system expert, those kinds of problems have been solved for you in the framework.

Orleans will run on Windows Server, but it’s really designed for Azure. It’s a simple xcopy deploy to install, and comes with libraries designed to work with Worker Roles. You’ll need to front Orleans with your own API, which will have to be .NET (probably ASP.NET/WebAPI).

Orleans gives you some constraints you must work within. You cannot have any shared state between grains, and all code must be asynchronous.

However Orleans gives you some good guarantees. These are that there will only ever be one instance of a grain of a given identity and that the code in the grain will only run in a single thread (you can have exceptions to these rules). This means you don’t have to worry about thread safety, locking and parallel programming. You just write simple class implementations.

Single threaded async, it sounds a bit like node.js doesn’t it? It even has the node hexagons. This is probably the reason I like Orleans so much!

What next?

Watch this space. I expect a small ecosystem of tools and libraries to grow up around Orleans, let me know if you’re interested.