Getting Started with Microsoft Orleans

Creating a highly scalable and reliable application is a difficult task that is more complicated than it appears. Following complex concurrency and scaling patterns can exacerbate the application’s complexity and muddle things up.

Scalable applications are in high demand in this digital age because viral marketing can turn your app into an overnight sensation with a massive influx of traffic. But, exactly, what is scalability?

Simply put, scalability is a system’s ability to handle increasing amounts of usage in multiple directions. While scalability is the cherry on top, distributed computing is the entire cake.

Components in distributed systems are located on different computers in a network that communicates and coordinates with one another by sending messages. Distributed also implies that your database is not run on a single massive database. Your data is replicated across multiple computers so that if one system fails, the data replicated on the other system can be used.

A good example of a scalable distributed system is Netflix. Banking systems, massive multiplayer platforms, chat rooms, and cellular networks are some other examples. Consider creating a system that is scalable in all directions.

When traditional concurrency methods and scaling patterns are used to build a distributed system, it can become even more complex. This is where a developer-friendly framework for building a scalable distributed system comes into play. Microsoft Orleans fulfils the stated purpose.

WHAT IS MICROSOFT ORLEANS?

A virtual actor model is a theoretical model for enforcing concurrency. It specifies the general rules for how various system components should interact with one another. An actor is a computational unit. An actor is a solitary figure with no shared memory. The state of an actor is never directly changed by another actor, whether they are exchanging signals or data. A message-receiving actor is capable of

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

Orleans entails creating a stateful middle tier in which various business logic objects are scattered across a sea of isolated globally addressable .NET objects. These are known as grains of various application types. They are distributed across a cluster of servers known as silos.

Scaling up is the only option in monolithic systems. Scaling out is an option with systems built with microservices and actor models. So, what exactly does scaling up vs scaling out imply?

Scaling up means adding more resources to the hardware on which your system runs, such as RAM, CPU, or memory. This implies that the entire development model is contained within a single box.

Scaling out, on the other hand, is a more outward approach that allows you to add a brand new machine to a cluster of servers with new resources.

WORKING OF MICROSOFT ORLEANS

Orleans is built on the following ideas:

Grains – These are the previously described virtual actors. Grains are objects that contain the logic that will be distributed. To avoid deadlocks and race conditions, each grain is accustomed to single-threaded operation. It is designed to run at a faster rate and is programmed to work asynchronously (allowing multiple operations to take place at the same time).

Silos – Assume these are the locations where your grains are stored. Silos can accommodate a variety of grain types and instantiations of those types, depending on your requirements.

Clusters are a collection of silos that allow you to take advantage of Orleans’ scale-out advantage. You can easily scale out your application by killing or adding clusters as you require more or fewer resources.

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.

Conclusion

You’ll appreciate the benefits of Orleans the moment you move from a single server setup to a distributed server system, whether it’s two servers or thousands. You can even use Orleans to build a single server setup when you need to scale them out one day so that it is fully fault-tolerant. The code would not change, which is the beauty of this situation. Scaling out is essential because the success and reach of your application are dependent on the number of customers who use it. Simply add more servers and watch the grains disperse across the silos, preparing your application to serve its customers during peak hours.