{"id":18469,"date":"2014-04-02T16:00:00","date_gmt":"2014-04-02T16:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2014\/04\/02\/available-now-preview-of-project-orleans-cloud-services-at-scale\/"},"modified":"2021-09-30T17:01:07","modified_gmt":"2021-10-01T00:01:07","slug":"available-now-preview-of-project-orleans-cloud-services-at-scale-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/available-now-preview-of-project-orleans-cloud-services-at-scale-2\/","title":{"rendered":"Available Now: Preview of Project \u201cOrleans\u201d \u2013 Cloud Services at Scale"},"content":{"rendered":"<p><em>This post was written by Niklas Gustafsson, Principal Program Manager on the Cloud Platform Tooling Team<\/em><\/p>\n<p>Today, at Build 2014, we are announcing the <a href=\"https:\/\/aka.ms\/orleans\">preview release<\/a> of a cloud programming model under the codename \u201cOrleans\u201d. This project originated in Microsoft Research. Project \u201cOrleans\u201d 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 designed for use in the cloud, and has been used extensively in Microsoft Azure.<\/p>\n<p>Project \u201cOrleans\u201d has been used in production at Microsoft since 2011. Publicly, it is most well-known as the basis of the Halo 4 services architecture. If you\u2019ve played Halo 4, you\u2019ve relied on it as part of the game experience.&#160; The Halo 4 services team will tell you that they could not have achieved the scale and level of user interactivity they needed without Project \u201cOrleans\u201d.<\/p>\n<p>Project \u201cOrleans\u201d enables scenarios that are difficult to productively implement using current technologies, complementing solutions like SignalR and WebAPI. Gaming, Internet of Things, social networks, and other scenarios with complex and dynamic relationships are particularly well suited for this model.<\/p>\n<p>We think that now is the time to start getting feedback from a broader audience.&#160; We\u2019d appreciate you downloading the preview, building services on top of it, and telling us about your experience. We\u2019ve had great experiences using it for products like Halo 4, but we know that we can make it better. We need your feedback to help us make the right updates.<\/p>\n<p><a href=\"http:\/\/research.microsoft.com\/apps\/video\/default.aspx?id=198324\"><img decoding=\"async\" title=\"clip_image001\" style=\"border-left-width: 0px;border-right-width: 0px;border-bottom-width: 0px;padding-top: 0px;padding-left: 0px;padding-right: 0px;border-top-width: 0px\" border=\"0\" alt=\"clip_image001\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2014\/04\/1856.clip_image001_59CFC530.png\" width=\"644\" height=\"279\" \/><\/a><\/p>\n<p>Go get the bits at Microsoft Connect and check out our GitHub site, which has samples and documentation to get you started with the Project \u201cOrleans\u201d preview!<\/p>\n<ul>\n<li><a href=\"https:\/\/aka.ms\/orleans\">Download the Project &quot;Orleans&quot; Preview<\/a> <\/li>\n<li><a href=\"https:\/\/github.com\/dotnet\/orleans\">Get Samples and Documentation<\/a> <\/li>\n<li><a href=\"http:\/\/research.microsoft.com\/apps\/pubs\/?id=210931\">Read the Microsoft Research Technical Report<\/a> <\/li>\n<\/ul>\n<h2>Building large-scale apps is challenging<\/h2>\n<p>Large-scale cloud applications and services are inherently parallel and distributed. They are often interactive and dynamic; commonly requiring near real time direct communication between cloud entities. Such applications are very difficult to build today, on any platform. The development process demands expert level programmers and typically requires expensive iterations of the design and the architecture, as the workload grows.<\/p>\n<p>No single solution will address all such challenges, they are too diverse and the constraints placed on systems by legacy investments and other business-specific considerations are too complex. That said, some solutions stand out as particularly promising, among them the actor model.<\/p>\n<h2>The Actor Model<\/h2>\n<p>The <a href=\"http:\/\/en.wikipedia.org\/wiki\/Actor_model\">actor model<\/a> is a long-standing model for concurrent computation, dating back to 1973 and invented by <a href=\"https:\/\/channel9.msdn.com\/Shows\/Going+Deep\/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask\">Carl Hewitt<\/a>. Many languages and frameworks have been inspired and built according to this model, including multiple for .NET. It is an established pattern, so has well understood implementation approaches, semantics and capabilities.<\/p>\n<p>The actor model is based on a collection of small objects that are referred to as \u201cactors\u201d. Everything \u2013 state and behavior \u2013 is modeled as an actor in this model. Actor is the sole primitive. The implementer defines a set of actors that makes sense for a given problem domain, and the allowable set of actions that they can have. This approach is very similar to object oriented-design principles, with a bias towards more finely defined objects. The execution mechanics is where the actor model starts differ in more obvious ways.<\/p>\n<p>Much like object-oriented design, actors represent and mutate state. An entire service built with the actor model might conceptually own a database or a collection of tables within it, while an actor might represent a single row. State is typically updated based on interactions with other actors.<\/p>\n<p>Actors communicate via asynchronous messages that are delivered via system-generated proxies. The actors themselves do not hold a direct reference to one another. This isolation and asynchronous communication simplifies scale-out and elasticity of applications as well as recovery from failures.<\/p>\n<p>Actors are always single-threaded, in terms of execution mechanics. That means that the state held by an actor is always consistent. There is no reason to consider data contention or locking schemes, since an actor is the sole owner of its data, and only ever runs on one thread. This characteristic simplifies writing highly concurrent systems by removing data races within and between actors. <\/p>\n<h2>Introducing Project \u201cOrleans\u201d<\/h2>\n<p>Project \u201cOrleans\u201d is a distributed implementation of the actor model. It is built on .NET and exposes a .NET API for you to build your own services. Its design borrows heavily from Erlang and distributed objects systems. Project \u201cOrleans\u201d is built on .NET, so it makes sense to take advantage of .NET features to expose an integrated .NET programming model. It relies on static typing, message indirection and actor virtualization, which differentiate it from other Actor Model implementations.<\/p>\n<p>Its main benefits are: 1) <b>developer productivity<\/b>, even for programmers who are not distributed systems experts; and 2) <b>transparent scalability \u201cby default,\u201d<\/b> that is, with no special effort from the programmer.<\/p>\n<p>The primary reason for the preview release is to get your feedback on the developer productivity aspects of the library. Please share any and all feedback you have about the API, and if you have feedback on scalability, we\u2019re interested in hearing from you on that topic, too. Tell us how easy it is to learn the API and build scalable services using it.<\/p>\n<h2>Familiar programming paradigm<\/h2>\n<p>Actors are .NET classes that implement .NET actor communication interfaces with asynchronous (Task &amp; Task&lt;T&gt;-based) methods and properties. Thus interactions between actors appear to the programmer as remote objects whose methods\/properties can be directly invoked, albeit always asynchronously. <\/p>\n<p>This provides the programmer with a familiar paradigm by turning messages into method calls, routed to the right endpoints, invoking the target actor\u2019s methods and dealing with failures and corner cases in a completely transparent way.<\/p>\n<p>A simple \u201dhello world\u201d interface may look like this:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\"><span style=\"color: #0000ff\">public<\/span> <span style=\"color: #0000ff\">interface<\/span> IHello : Orleans.IGrain<br \/>{<br \/>    Task&lt;<span style=\"color: #0000ff\">string<\/span>&gt; SayHelloAsync(<span style=\"color: #0000ff\">string<\/span> greeting);<br \/>}<\/pre>\n<p><\/div>\n<p>Every actor system seems to pick its own concrete name for the actor concept. Erlang calls them \u2018processes,\u2019 and Orleans calls them \u2018grains.\u2019 Thus, the presence of \u2018IGrain\u2019 as the base interface above is what marks it as an interface to an actor.<\/p>\n<p>An actor implementation that knows how to follow the conventions of the IHello interface might look something like this:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\"><span style=\"color: #0000ff\">public<\/span> <span style=\"color: #0000ff\">class<\/span> HelloGrain : Orleans.GrainBase, IHello<br \/>{<br \/>    Task&lt;<span style=\"color: #0000ff\">string<\/span>&gt; IHello.SayHelloAsync(<span style=\"color: #0000ff\">string<\/span> greeting)<br \/>    {<br \/>        <span style=\"color: #0000ff\">return<\/span> Task.FromResult(<span style=\"color: #006080\">&quot;You said: '&quot;<\/span> + greeting + <span style=\"color: #006080\">&quot;', I say: Hello!&quot;<\/span>);<br \/>    }<br \/>}<\/pre>\n<p><\/div>\n<p>There are restrictions on what you can do in interfaces and classes intended to represent actors, but they are relatively few. For example, all methods and properties in the interfaces must return Task or Task&lt;T&gt;, and you should never create an actor instance directly using \u2018new.\u2019 <\/p>\n<h5><\/h5>\n<h2>Invocation of actors and transparent activation<\/h2>\n<p>The runtime activates an actor as-needed, only when there is a message for it to process. This cleanly separates the notion of creating a reference to an actor, which is visible to and controlled by application code, and physical activation of the actor in memory, which is transparent to the application. <\/p>\n<p>This model is similar to virtual memory in that it decides when to \u201cpage out\u201d (deactivate) or \u201cpage in\u201d (activate) an actor; the application has uninterrupted access to the full \u201cmemory space\u201d of logically created actors, whether or not they are in the physical memory at any particular point in time. <\/p>\n<p>Transparent activation enables dynamic, adaptive load balancing via placement of actors across the pool of hardware resources. This featureis an improvement on the traditional actor model, in which actor lifetime and placement is application-managed.<\/p>\n<p>If I\u2019m writing a client of a system based on Project \u201cOrleans\u201d and need to establish a link to a particular actor instance, I would use the actor\u2019s factory method and the actor\u2019s global identity (each actor instance is identified by some unique key, for example a Guid). The factory methods are generated by the system as you compile actor interfaces.<\/p>\n<p>What is returned by the factory method is a reference to a proxy for the actual actor. Only when a message is sent to the actor, that is, my code calls the \u2018SayHelloAsync()\u2019 method on the proxy, does the actor get activated in memory somewhere.<\/p>\n<p>In this much-simplified HelloWorld case, where there is only one instance, \u20180\u2019 seems like a good identity:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\">IHello friend = HelloFactory.GetGrain(0);<br \/>Console.WriteLine(await friend.SayHelloAsync(<span style=\"color: #006080\">&quot;Good morning!&quot;<\/span>));<\/pre>\n<\/div>\n<h2>Location transparency<\/h2>\n<p>An actor reference is a proxy object returned by the \u2018GetGrain()\u2019 factory method; the programmer uses the reference to invoke the actor\u2019s methods or pass to other components. The reference only contains the logical identity of the actor. The translation of the actor\u2019s logical identity to its physical location and the corresponding routing of messages are done transparently by the runtime. Application code communicates with actors independent of their physical location, which may change over time.<\/p>\n<h2>Single-threaded execution of actors<\/h2>\n<p>The runtime guarantees that an actor never executes on more than one thread at a time. Combined with the isolation of its state from other actors, the programmer never faces concurrency at the actor level, and hence never needs to use locks or other synchronization mechanisms to control access to data held by an actor. This freedom from data races is in many ways the core feature of the actor model, making it relatively straight-forward to program concurrent systems.<\/p>\n<p>For example, and this is a bit of a contrived example, we can add a list of greetings and not worry about concurrent accesses to it, since invocations are arranged by the runtime to guarantee single-thread access:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\"><span style=\"color: #0000ff\">public<\/span> <span style=\"color: #0000ff\">class<\/span> HelloGrain : Orleans.GrainBase, IHello<br \/>{<br \/>    List&lt;String&gt; greetings = <span style=\"color: #0000ff\">new<\/span> List&lt;<span style=\"color: #0000ff\">string<\/span>&gt;();<br \/>    Task&lt;<span style=\"color: #0000ff\">string<\/span>&gt; IHello.SayHelloAsync(<span style=\"color: #0000ff\">string<\/span> greeting)<br \/>    {<br \/>        <span style=\"color: #0000ff\">if<\/span> (greetings.Count &lt; 100)<br \/>            greetings.Add(greeting);<br \/>        <span style=\"color: #0000ff\">return<\/span> Task.FromResult(<span style=\"color: #006080\">&quot;You said: '&quot;<\/span> + greeting + <span style=\"color: #006080\">&quot;', I say: Hello!&quot;<\/span>);<br \/>    }<br \/>}<\/pre>\n<p><\/div>\n<p>In most circumstances, checking the length of the list and adding an element to it would have to be protected by some sort of mutual exclusion mechanism. With actors, mutual exclusion comes with the programming model.<\/p>\n<h2>Transparent integration with persistent store<\/h2>\n<p>Project \u201cOrleans\u201d allows for declarative mapping of actors\u2019 in-memory state to a persistent store. It synchronizes updates, transparently guaranteeing that callers receive results only after the persistent state has been successfully updated. <\/p>\n<p>For example, we may want to keep the list of greetings around even when a grain is deactivated due to disuse or system failures. The way to do that is to identify a persistent storage provider in your configuration and mark an actor as relying on the configured provider.<\/p>\n<p>The runtime expects you to separate the persisted state in a type of its own, such as in this case:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\">[StorageProvider(ProviderName = <span style=\"color: #006080\">&quot;MyPersistentStore&quot;<\/span>)]<br \/><span style=\"color: #0000ff\">public<\/span> <span style=\"color: #0000ff\">class<\/span> HelloGrain : Orleans.GrainBase&lt;IHelloState&gt;, IHello<br \/>{<br \/>    async Task&lt;<span style=\"color: #0000ff\">string<\/span>&gt; IHello.SayHelloAsync(<span style=\"color: #0000ff\">string<\/span> greeting)<br \/>    {<br \/>        <span style=\"color: #0000ff\">if<\/span> (State.Greetings.Count &lt; 100)<br \/>            State.Greetings.Add(greeting); <br \/>        await <span style=\"color: #0000ff\">base<\/span>.WriteStateAsync();<br \/>        <span style=\"color: #0000ff\">return<\/span> <span style=\"color: #006080\">&quot;You said: '&quot;<\/span> + greeting + <span style=\"color: #006080\">&quot;', I say: Hello!&quot;<\/span>;<br \/>    }<br \/>}<br \/><span style=\"color: #0000ff\">public<\/span> <span style=\"color: #0000ff\">interface<\/span> IHelloState : IGrainState<br \/>{<br \/>    List&lt;String&gt; Greetings { get; set; }<br \/>}<\/pre>\n<p><\/div>\n<p>Note that the grain class has been modified so that it now extends GrainBase&lt;IHelloState&gt;, \u2018IHelloState\u2019 being the interface type used to define the persistent portion of the state. \u2018State\u2019 is a protected property found in the GrainBase&lt;T&gt; base class and refers to the persisted state. <\/p>\n<p>We also had to add a call to WriteStateAsync() in the GrainBase&lt;T&gt; base class, which is how you control when state is written out to the persistent store. Since WriteStateAsync is an asynchronous method, the SayHelloAsync method has also been made asynchronous with the <i>async<\/i> keyword and can use the \u2018await\u2019 operator to wait for the write operation to finish.<\/p>\n<p>Automatic code-generation at build time fills in the details, generating a class that implements the state interface; that is where the logic to map the state to something that can be stored is placed. Together with a configuration file entry shown below, this is all it takes to get the list backed up in an Azure Storage table:<\/p>\n<div id=\"codeSnippetWrapper\">\n<pre id=\"codeSnippet\"><span style=\"color: #0000ff\">&lt;<\/span><span style=\"color: #800000\">Provider<\/span> <span style=\"color: #ff0000\">Type<\/span><span style=\"color: #0000ff\">=&quot;Orleans.Storage.AzureTableStorage&quot;<\/span> <br \/>          <span style=\"color: #ff0000\">Name<\/span><span style=\"color: #0000ff\">=&quot;MyPersistentStore&quot;<\/span> <br \/>          <span style=\"color: #ff0000\">DataConnectionString<\/span>=&quot;&amp;<span style=\"color: #ff0000\">lt<\/span>;&amp;<span style=\"color: #ff0000\">lt<\/span>;<span style=\"color: #ff0000\">Your<\/span> <span style=\"color: #ff0000\">Azure<\/span> <span style=\"color: #ff0000\">Storage<\/span> <span style=\"color: #ff0000\">Connection<\/span> <span style=\"color: #ff0000\">String<\/span><span style=\"color: #0000ff\">&gt;&gt;<\/span>&quot; <span style=\"color: #0000ff\">\/&gt;<\/span><\/pre>\n<p><\/div>\n<p>Azure Storage is not the only place you can store data. While there aren\u2019t a lot of options \u201cin the box,\u201d anyone may extend the storage options by adding custom storage providers. These are not hard to write, and there\u2019s a sample storage provider solution on GitHub demonstrating a file-system-based solution and one using MongoDB.<\/p>\n<h2>Where to Get It<\/h2>\n<p>The preview bits themselves are available via Microsoft Connect. You will be asked to fill out a survey as part of downloading the preview.<\/p>\n<p><a href=\"https:\/\/aka.ms\/orleans\">Download the Project &quot;Orleans&quot; Preview<\/a><\/p>\n<p>We also have samples and some documentation on <a href=\"https:\/\/github.com\/dotnet\/orleans\">GitHub<\/a>. We intend to keep adding samples as we go along with the preview. The GitHub site\u2019s issue tracker can be used to discuss the preview and its uses.<\/p>\n<p><a href=\"https:\/\/github.com\/dotnet\/orleans\">Get Project \u201cOrleans\u201d Samples and Documentation<\/a><\/p>\n<p>Please provide us with feedback on bugs via the Connect site, or send us your thoughts directly if you are more comfortable doing it that way. You can reach us via email at <a href=\"mailto:orlprevsupp@microsoft.com\">orlprevsupp@microsoft.com<\/a>.<\/p>\n<p>On behalf of the entire Project \u201cOrleans\u201d team at Microsoft Research, as well as the team in DevDiv working on it, I hope you enjoy taking part in the preview and find it a good use of your time!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post was written by Niklas Gustafsson, Principal Program Manager on the Cloud Platform Tooling Team Today, at Build 2014, we are announcing the preview release of a cloud programming model under the codename \u201cOrleans\u201d. This project originated in Microsoft Research. Project \u201cOrleans\u201d provides a straightforward approach to building distributed high-scale computing applications, without the [&hellip;]<\/p>\n","protected":false},"author":11288,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[30,37],"class_list":["post-18469","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","tag-announcement","tag-azure"],"acf":[],"blog_post_summary":"<p>This post was written by Niklas Gustafsson, Principal Program Manager on the Cloud Platform Tooling Team Today, at Build 2014, we are announcing the preview release of a cloud programming model under the codename \u201cOrleans\u201d. This project originated in Microsoft Research. Project \u201cOrleans\u201d provides a straightforward approach to building distributed high-scale computing applications, without the [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/18469","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/11288"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=18469"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/18469\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=18469"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=18469"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=18469"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}