Building cloud-native applications can be a challenging and complicated task. Cloud-native apps must be designed to handle elasticity, resiliency, distributed infrastructure, and other concerns. Developers often rely on frameworks to provide abstractions over these internal implementation details, so they can focus on building business features. Orleans is a robust framework for building scalable, distributed, cloud-native applications. Orleans runs cross-platform anywhere that .NET is supported and integrates well with other platform features.
Orleans simplifies the process of building distributed, scalable applications. There are several key concepts to understand in order to work with Orleans effectively.
The virtual actor model
Orleans is built around the “actor model”, which is an established design pattern that has existed since the 1970s. The actor model is a pattern that stores pieces of state data and corresponding behavior in lightweight, immutable objects called actors. Actors communicate with each other using asynchronous messages. Orleans manages and simplifies much of the parallel communication required by distributed apps for you. Orleans invented the virtual actor model, where actors exist perpetually whenever they’re needed. This architecture lends itself well to cloud-native applications, which require distributed and resilient state and parallel operations.
Grains
Grains are the most essential primitives and building blocks of Orleans applications. They represent actors in the Actor model and define the state data and behavior of entities you define, such as shopping cart or product. Grains are each identified and tracked through user-defined keys and can be accessed by other grains and clients.
Grains are stored in silos, which you explore later. Grains that are currently active and in use by your application will remain in memory, while inactive grains can be persisted to your desired storage. A grain becomes active again when it’s needed or requested by the app. Grains have a managed life cycle, which means the Orleans runtime handles activating, deactivating, storing, and locating grains as needed by the application. Developers don’t have to worry about managing these concerns themselves and can write code that assumes a grain is available in memory.
Silos
Silos are responsible for storing grains and are another core building block of Orleans. A silo can contain one or more grains; a group of silos is known as a cluster. The cluster coordinates work between silos, allowing communication with grains as though they were all available in a single process. You can organize your data by storing different types of grains in different silos. Your application can retrieve individual grains without having to worry about the details of how they’re managed within the cluster.
Other features of Orleans
Orleans supports plenty of other features for more specific or advanced scenarios.
Streams: Streams help developers process sets of data in near-real-time. Like other features of Orleans, streams are managed by the runtime and available on demand. They’re loosely coupled and can apply various queue technologies, such as Azure Event Hubs.
Timers and Reminders: Orleans supports scheduling operations for grains. You can ensure that various actions are completed at a given time even on inactive grains.
Versioning: Grains can be versioned to account for changes in your application. Orleans will handle mapping and managing different implementations of your versioned grains across your silos and clusters.
ACID transactions: Grains can have transactional state and support ACID transaction features.
These capabilities can be explored as you start to build more complex apps. Next post you’ll explore the basics of how Orleans works.