A few weeks ago I wrote about the importance of being stateful. So you can imagine that I’m quite excited about the Public Preview of Orleans that Microsoft announced at Build 2014.
Orleans is a new cloud programming model that was designed for use in the cloud, and that has been used extensively in Microsoft Azure.
Orleans was created to solve the problem of building high performance concurrent applications that run on the cloud. It really shines when it’s used in social graphs, mobile backends, Internet of things and with real-time analytics. Of course, the use of Orleans isn’t limited to these specific scenarios. In fact Orleans lends itself pretty well for applications who work with free-form relationships, who require high throughput and where low-latency is crucial. Furthermore, it’s a great fit for solutions where data and Actors naturally partitions themselves into manageable pieces.
Building cloud-based solutions that scale out to meet the workload demand is becoming the new way of doing things. Forget about 3-tier architectures, they just doesn’t scale. Because stateless solutions need to rebuild their internal state for each call, they can generate tremendous pressure on our data stores. Consequently, this generates back pressure that bubbles up through the layers and reaches out to the edge. Back pressure then translates into unavailable services and is often the cause of downtime for Cloud Services. A great example of back pressure in action, is the all too familiar Fail Whale that was used during periods of downtime by Twitter.com.
The situation I described above probably isn’t new to most of us. We actually experience these interesting moments as developers and sometimes as consumers and believe me its irritating for everyone.
Building for the cloud isn’t like building on the cloud. I know, I keep repeating this all the time but we really need to embrace this as a community.
Services are not Servers and Servers are not Services.
What Orleans brings to the table is a change in the way we think about Cloud Services as a whole. We can stop thinking about Role instances and all the goop that needs to be built around them in order for us to build our solution. We can start thinking in terms of Actors.
Developers can now concentrate on building Actors like games, cars and users that are responsible for their own state. In a way, Orleans brings us back to building Objects the way it was original intended by the fathers of Object Oriented Programming (OOP) instead of building armies of Data Transfer Objects (DTOs) and losing our ways with ORMs.
Orleans is interesting because it’s a familiar programming paradigm. It relieves us from many concurrency hazards, headaches and concerns because activations are single-threaded. The runtime is responsible for scheduling method executions and for multiplexing work across threads.
Since the state of each Actor isn’t shared, we can avoid creating complex code that relies on locks in order to avoid pesky race conditions.
Being an avid supporter of clean code and principles like SOLID, I see some great opportunities to simplify existing solutions by leveraging the natural separation of concerns imposed by this programming model. For instance, each game Actor owns its own state. If a user Actor Instance needs information from a specific game, it’s going to ask the game Actor Instance directly. In turn, the user Actor will not need to implement logic that ultimately belongs to the game Actor.
So far I’ve been using the term Actor to represent a unit that combines an object instance and its state. Each object is identifiable by an ID and is virtually always accessible. If it doesn’t exist the runtime will create one for you, otherwise it will make sure that it’s accessible whenever you need it.
In Orleans, Actors are called Grains. Their Activations reside in Silos and their Instances (state) can be persisted to cold storage. The runtime is responsible for managing the Grain’s in-memory lifetime so you don’t have to worry about resource management.
Think of Silos as virtual memory (RAM). Most of our personal computers have gigabytes of RAM spread over multiple memory chips. When you come to think about it, it’s no walk in the park. But our operating systems abstract this away from us, so that we can concentrate on our real business problems and not have to think about which chip the data came from. In essence, Silos are a bit like that. They are capable of distributing Grain Activations over multiple Cloud Service Role instances. But don’t worry, the runtime is responsible for finding individual Grains for you. In other words, you don’t know where a specific Grain Activation exists and that’s OK.
Getting rid of lots of complexity, allows developers to concentrate on the problem at hand instead of wasting their time on complex infrastructures that usually require much of our love. It also means that we can split development responsibilities across developers and IT Pros.
From http://channel9.msdn.com/Events/Build/2014/3-641
Bear with me just a little longer as I go over a few points about Orleans before I conclude this post, which by the way, I’m honestly trying to keep short.
I’m really excited about this public preview, because with Orleans we get scalability by default. To my surprise, Microsoft has observed near linear scaling to hundreds of thousands of requests per second without having to write any special code. Services built using this technology benefit directly from this characteristic. Whether your service is small or your service becomes popular overnight, this runtime seems to be a good fit. It allows us to use our resources efficiently, which can ultimately help us reduce operational costs.
From http://channel9.msdn.com/Events/Build/2014/3-641
At this point, I could go on and on about Orleans, but I think that I probably lost you a while back and that you’re probably already playing around with the bits!
For those who stuck around, get the bits from Microsoft Connect and check out the CodePlex site, which has samples and documentation to get you started with Orleans!
- Available Now: Preview of Project “Orleans” – Cloud Services at Scale
- Download the Project “Orleans” Preview
- Get Samples and Documentation
- Read the Microsoft Research Technical Report
- .Net Rocks Episode 969 – Microsoft Orleans with Richard Astbury
Be sure to watch these awesome sessions from Build 2014
Alexandre Brisebois ☁ 
Hey Alex,
Sounds like a powerful concept.
Can you clarify couple of things though?
The grains can be the objects of your business domain. But if you do need to have extensive interaction between certain grains, is there a way to guarantee the access speed?
Let’s say certain grains exchange megabytes of data very often, 100 times in an hour. How does the Orleans know to keep these closer together in regards of distribution across resouces?
It may decide after all to put the grains on separate physical boxes, if control is not in the hands of the developer, no?
Is there some sort of automatic performance monitoring that helps framework figure out these things and optimize on the fly?
Or you have to plan and arrange grain distribution?
LikeLiked by 1 person
Hey Karen,
Typically you would not transfer 100mb data between grains. You would transfer references to other grains. Each grain being a self contained object (business logic + data).
For example you could have an assignment grain that contains a list of references to route grains. Each route grain has a collection of references to location grains.
Grain references are addresses used to find and communicate with grains.
Instead of shifting data around, you act on the data inside the actors and ship method references to consumers. We are moving away from DTOs and Entities to empower something that is much closer to OOP.
I do not know of any SLAs, but there is a promise that all calls must execute within 30 seconds.
As for the internal specifics of how grains are distributed, I do not have nay specifics at this time.
LikeLike