[Dev Tip] Microsoft Puts Orleans Code On GitHub


Microsoft has open-sourced Project Orleans a framework for writing highly scalable services that aims to simplify development of scalable cloud services.

According to its new GitHub page:

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 cloud services, as well as by a number of other companies.

A public preview of Orleans was released at Build 2014, where Microsoft gave a session on the project’s use by the well-known game Halo 4, still available in this hour long Channel 9 video:

http://channel9.msdn.com/Events/Build/2014/3-641/player

The problem addressed by Orleans is that of creating interactive services that are scalable and reliable. As pointed out by Sergey Bykov, Lead Software Engineer, interactivity imposes strict constraints on availability and latency, as that directly impacts end-user experience. To support a large number of concurrent user sessions, high throughput is essential.

orleans

A three-tier architecture with stateless front-ends, stateless middle tier and a storage layer has limited scalability due to latency and throughput limits of the storage layer, which has to be consulted for every request. The traditional remedy for this is to add a caching layer between the middle tier and the storage to improve performance. This means you lose most of the concurrency and semantic guarantees of the underlying storage layer, so the cache manager has to have concurrency control to prevent inconsistencies caused by concurrent updates to a cached item. Using a stateless middle tier means that for every request, data is sent from storage or cache to the middle tier server that is processing the request. This is known as the data shipping paradigm.

The alternative solution used by Orleans is to use the actor model. This relies on the function shipping paradigm, which treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. The actor model uses “actors” as the basic entity for concurrent computation. When an actor receives a message, it can do things such as create another actor, send a message, make some local decision, or work out what to do when the next message is received. Using actors enables the building of a stateful middle tier. This gives you the performance benefits of a cache, but holds data locally, and offers the semantic and consistency benefits of encapsulated entities by using application-specific operations. Actor platforms such as Erlang and Akka make it easier to program distributed systems, but you still need to know what you’re doing in terms of the system services. Orleans is designed to offer higher levels of actor abstraction. It is actor-based, but differs from existing actor-based platforms by treating actors as virtual entities, not as physical ones.

An Orleans actor always exists virtually. It cannot be explicitly created or destroyed, and its existence transcends the lifetime of any of its in-memory instantiations.

Orleans actors are automatically instantiated: if there is no in-memory instance of an actor, a message sent to the actor causes a new instance to be created on an available server. An unused actor instance is automatically reclaimed as part of runtime resource management.

Actors never fail: if a server S crashes, the next message sent to an actor A that was running on S causes Orleans to automatically re-instantiate A on another server, eliminating the need for applications to supervise and explicitly re-create failed actors. The location of the actor instance is transparent to the application code, and Orleans can automatically create multiple instances of the same stateless actor, seamlessly scaling out hot actors. Overall, Orleans gives developers a virtual “actor space” that lets them invoke any actor in the system, whether or not it is present in memory.

The use of virtualization to map virtual actors to their physical instantiations means the runtime can take care of many hard distributed systems problems that would otherwise have to be handled by the developer, such as actor placement and load balancing, deactivation of unused actors, and actor recovery after server failures.

Orleans has already been used to build multiple production services currently running on the Microsoft Windows Azure cloud, including the back-end services for Halo 4, and that this enabled the project team to validate the scalability and reliability of production applications written using it, and adjust its model and implementation based on this feedback. Now it is on GitHub it is available for others to use.

orleanslogo

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s