Orleans: Azure Grains - Serverless Orleans

[creyke]

After working with Azure Functions for a number of months I've found great productivity in being able to deploy logic without worrying about hosting, scaling, or redundancy.

I've also found the triggers and bindings concepts extremely helpful, enabling rapid prototyping and development.

While Azure Functions is great for stateless logic, it does not provide, nor does it easily faciliate, a scalable stateful programming model. Therefore for some use cases such as event sourcing, caching, and stream processing, Azure Functions can put significant load on storage, and can incur significant delay on in-order event processing over the actor model, by having to consult either storage, or a separate cache tier.

One of the biggest barriers to adoption for Orleans is arguably the complexity in configuring and maintaining clusters of machines.

It would arguably therefore be of use (and I think an industry first?) to provide a stateful serverless service complimentary to Azure Functions.

Azure Grains would provide Grains as as Service (GaaS), fully compatible with the Orleans API, but only the grains and their interfaces would be need to be deployed, lowering the bar to adoption, and simplifying the hosting model for the majority of use cases which can take advantage of it.

The service would provide:

• An opinionated, fully managed Orleans host.
• Pricing related in some way to usage / throughput / cpu time.
• Automated deployment of grain binaries.
• Monitoring.
• A managed streaming runtime.
• Triggers and bindings for common dependencies as per Azure Functions.
• The ability to easily call grains from Azure Functions and vice versa.

I recognise there are some non-trivial challenges in achieving this, but I do feel the end product could very much warrant that investment, and become a key tool in an Azure solution architect's arsenal.

[galvesribeiro]

This is a must anticipated feature request... As @sergeybykov call it... Orleans as a Service...

IMHO, the major painpoint today is the way grain assembly is loaded and the _inability_ of unload assemblies in .Net Standard/Core like we used to have in fullfx.

I have something in the works that I should put on OrleansContrib as soon as it get some shape.

The target is to mimic how AWS Functions works. The _function_ code run inside a container and has access to Orleans features (stream, storage, reminders, etc.) thru RPC (i.e. a IClusterClient is magically bridged to the container running the function) and you can measure usage of the container.

The way it is being designed, the developer would actually not even need to know Orleans itself as everything is wrapped on top of it.

It is by far not the ideal scenario but since in a while we don't see any discussion/progress around that, I took that path as a way to leverage Orleans facilities but bypassing the load/unload grain code limitation.

[brandonh-msft]

So, Azure Functions' recent Durable Functions Extension had a similar ask - to enable the actor programming model - but the dev team folded saying the underlying framework just doesn't lend itself toward this usage (today).

I'm wondering if the statefulness of Durable Functions combined with Orleans could get us somewhere significant... ie: could a DF OrchestrationClient trigger serve as an Orleans Host and/or Client? I'm playing with this right now but I'm new to the Orleans space. So far the port & IP address "link" between host & client is throwing me for a bit of a loop ;)

[DannyvanderKraan]

If I may humbly weigh in on this discussion. I stumbled on this issue after researching Orleans vs Azure Service Fabric (Mesh). Azure Service Fabric supports the actor model and supports stateful actors in a scalable manner. When Mesh goes GA it'll be "as a Service" on Azure. What I miss is the elegant Grain/Silo architecture of Orleans though (IMHO). My question is, when Azure Service Fabric Mesh goes GA, what would be the use of Orleans as a Service on Azure? When would you choose one over the other? The answer to these questions might help the direction Orleans should take.

[ReubenBond]

@DannyvanderKraan, Mesh does not support actors. Orleans also runs on top of Mesh as well as regular Service Fabric. We recently added a sample for Mesh and I'm currently in the process of adding support for Stateful Services (some PRs for that are open, Stateless Services are already supported).

[DannyvanderKraan]

@ReubenBond Ah excellent. I understand the direction this project is going now. Thank you.

[skyflyer]

As a little tangent to this, I'm also researching how to run Orleans in Azure. I'm currently leaning towards running it in a container (Azure Kubernetes) which provides simple scaling mechanisms. Are there better alternatives to running Orleans on Azure?

[brandonh-msft]

I want to offer up Durable Entities for consideration of those wondering about this capability.

[creyke]

I want to offer up Durable Entities for consideration of those wondering about this capability.

I've had lengthy discussions with the Durable Entities team, and the product is looking promising.

It is possible that some use cases implemented in Orleans _could_ be modeled in Durable Entities.

However it is no like-for-like substitute for serverless actors / grains. Durable Entities are durable, but not stateful. State is hydrated per invocation to a non-deterministic host. It is not suitable for high throughput, low latency stateful in-memory stream processing. There's no control over local placement, immutable serialization avoidance etc.

To solve these problems, a host _like_ the Orleans silo is required.