Beginner's Guide to Microsoft Orleans

14 juli 2021 om 10:00 by ParTech Media - Post a comment

Designing a highly scalable and reliable application is a daunting task and is more complicated than it may appear to us. Following complex concurrency and scaling patterns can aggravate the complexity of the application and muddle up things.

Scalable applications are in high demand in this digital era as viral marketing can make your application an overnight sensation with a huge influx of traffic. But what exactly is scalability?

Simply put, scalability is the property of a system to handle growing amounts of usage in different directions. While scalability being the icing on the cake, distributed computing is the whole cake.

In distributed systems, components are located on different computers in a network that communicates and coordinates with each other by passing messages. Distributed also means your database does not run on a single colossal database. Your data is copied to multiple computers so that if one system fails, the data copied onto the other system can be used.

Netflix is a good example of a scalable distributed system. The other examples include banking systems, massive multiplayer platforms, chat rooms, and cellular networks. Now imagine building such a system that is scalable in all directions.

The use of traditional concurrency methods and scaling patterns to build a distributed system can make it even complex. This is where the need for a developer-friendly framework to build a scalable distributed system arises. Microsoft Orleans serves the exact purported purpose.

Table of contents

  1. What is Microsoft Orleans?
  2. What is an actor model?
  3. Working of Microsoft Orleans
  4. Use cases of Microsoft Orleans
  5. Wrapping Up

What is Microsoft Orleans?

Microsoft Orleans is a cross-platform framework for building robust distributed applications that can be scaled on demand. Orleans builds on the developer productivity suite of .NET Core. It then brings it to the world of distributed services such as the cloud. Orleans extends its scaling from a single on-premises server to globally distributed applications in the cloud.

Developed by Cloud Research, it uses the virtual actor model as a novel approach for building the next generation of distributed systems in the cloud.

What is an actor model?

A virtual actor model is a conceptual model for enforcing concurrent computation. It defines the general rules on how different system components should interact with each other. An actor is a unit of computation. An actor is isolated and never has a shared memory. Be it exchanging signals or data, the state of an actor is never directly changed by another. An actor receiving messages is capable of

  1. Sharing the message to other actors concurrently
  2. Create new actors and
  3. Change their internal state

Orleans involves building a stateful middle tier, where various business logic objects are found in a sea of isolated globally addressable .NET objects. These are called grains of different application types. They are distributed over a cluster of servers called silos.

In monolithic systems, you have only the option of scaling up. But with systems built using microservices and actor models, you have an option of scaling out. So, what does scaling up vs scaling out mean?

Scaling up means adding more resources, be it RAM, more CPU or memory to the hardware in which your system runs. This means that the whole development model is confined to a single box.

But scaling out is a more outward approach, which means you can add a brand new machine to a cluster of servers with new resources.

Working of Microsoft Orleans

Orleans works on top of the following concepts -

Grains - These are the virtual actors as described above. Grains are actually objects that contain your logic to be distributed. Each individual grain is accustomed to single-threaded operation, so as to avoid deadlocks and race conditions. It is programmed to work asynchronously(which means allowing multiple operations to take place simultaneously) and intended to run at faster rates.

Silos - Assume this as the areas where your grains are kept. Silos may accommodate several grain types and instantiations of their types depending on your needs.

Clusters - A collection of silos, This allows to leverage the scale-out advantage of Orleans. The more or fewer resources you need, you can kill or add clusters to scale out your application easily.

Use Cases of Microsoft Orleans

Orleans is ideal -

  • When you have systems with a large number of entities
  • When you have loosely connected systems and Intelligent caching
  • When you are compelled to run the application on more than 1 server(might be during peak hours like black Friday sale)
  • When your application needs zero downtime
  • When your client needs fast response time
  • When you have applications that have several actors with a long lifetime. A good example will be products, inventory, warehouses, etc. And also with actors with shorter lifespans like payment transactions, orders, and cart items.

Orleans is not ideal -

  • When you have tightly coupled systems that have no distributed system prospect
  • When you have systems with fewer components and objects
  • When you intend to compute-intensive tasks.
  • When you have actors who need direct access to each other’s memory
  • When global coordination is necessary for the functioning of the application
  • When managing multiple versions of grains is quite complicated and can become unmanageable in the long run. So multiple additional deployments are required to migrate the grains from state A to state B.

Wrapping Up

You will relish the perks of Orleans the moment you switch from a single server setup to a distributed server system, be it 2 servers or thousands. You can even start leveraging Orleans to build a single server setup when you need to scale them out one day so that it works fully fault-tolerant. The beauty here is that the code would not change. Scaling out is an indispensable thing to do as the success and reach of your application depend upon the number of customers frequenting it. Just add more servers and watch the grains spread across the silos, getting your application ready to serve its customers during peak hours.

Nieuwste