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.

[oising]

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.

All true, but there is light at the end of the tunnel: https://microsoft.github.io/durabletask-netherite/#/

[ReubenBond]

I see Workflows & Virtual Actors (Grains) as complementary primitives for cloud-based application frameworks. Workflows could be used as a clean alternative to functionality which developers currently implement using reminders & state.

While I am a fan of the workflows programming model, they do put some additional burden on developers, in my opinion, and have some downsides:

1. Workflows essentially encode the structure of the program in storage and developers must retain that structure when replaying those calls - the way this is tackled in some frameworks is to add conditionals to check the version the workflow is currently running at and modify behavior to match prior behavior. As you can imagine, that requires care.
2. Workflow code must be deterministic, so non-determinism must be carefully handled, shipped off to "activities"/"tasks" (which can be implemented as grain calls)
3. The performance of workflows will likely remain lower than the alternative (although if compute & storage gets cheap enough then it may become fast enough/cheap enough for pervasive use - if not for programmability challenges).

It would be interesting to integrate workflows into Orleans as a top-level primitive, next to grains. I have a very basic proof-of-concept for code-based workflows in the Hagar repository and I had workflows in mind when designing the new RPC system which is now a part of Orleans, so hopefully that would ease the implementation effort. Ideally, if we did decide to pursue workflows, we would integrate Durable Task Framework / Netherite itself, rather than develop yet another workflow framework from scratch.

Apologies for the side-tracking - we could create a new issue to discuss design/opportunities w.r.t. workflows.

[oising]

While I agree with your points @ReubenBond, the use of Durable Entities doesn't necessarily entail using "workflows" -- that comes with the Durable Orchestration pattern. Entities can be used as simple stateful actors without worrying about the idempotency and replay/event sourcing issues with orchestrations. It's just that they're (currently) dog slow compared to Orleans.

[ghost]

We are marking this issue as stale due to the lack of activity in the past six months. If there is no further activity within two weeks, this issue will be closed. You can always create a new issue based on the guidelines provided in our pinned announcement.

[ghost]

This issue has been marked stale for the past 30 and is being closed due to lack of activity.