Support Multi-Tenant Architecture Scenarios

[dsm0880]

Is your feature request related to a problem? Please describe.
Today we support multiple clients using durable functions as a multi-tenant Azure application. Ideally we could separate out the clients into separate table storage locations to ensure we meet compliance and security standards. Today we have to place everything into a single azure storage instance.

Describe the solution you'd like
It would be great it we could define the storage location during runtime as that would allow for our application to redirect to varying storage accounts for the durable task information. This would also fix any "single source of failure" problems by having one huge table.

Describe alternatives you've considered
I don't have any that have worked as it appears CORE to the architecture. I'm hoping in 2.0 you can address this as it appears you are abstracting away the store location to allow for more options.

[olitomlinson]

Hey @dsm0880 When you say separate table storage locations, are you implying each of your tenants would get its its own isolated Azure Storage Account? Or are you implying that each tenant gets its own Table within a single multi-tenant Azure Storage Account?

[dsm0880]

@olitomlinson Thanks for taking a look at this! It's a good question. Thinking through this I got the following:

1. Single Storage Account Multiple Tables
   a. Pros
   i. Single Storage account so your azure resources are not ever expanding
   b. Cons
   i. You get will be throttled at 20,000 transactions on the entire storage account and not per table, so when I consider scaling this would be a concern (I may be misreading Microsoft Documentation)
   ii. Single Storage Account Key for all clients, while this could be abstracted away through our API it may make it harder to work with other clients when wanting to access the storage account directly, instead we would have to pass them through our api first which would put pressure on our services
   iii. Durable Functions use blob storage for large messages, so you would have to make a corresponding architecture in the blob storage. Maybe separate containers or folders?
   iv. Same goes for queues. I guess the queue message would have to be read in for a property to know what storage account to look to?

2. Multiple Storage Account
   a. After typing the above I think the answer became obvious to me and maybe easier for Microsoft to implement, go with Multiple Storage accounts (one per client).

I hope that helps and feel free to reach out if you have any other thoughts.

Daniel

[olitomlinson]

@dsm0880

Disclaimer : I'm not a microsoft employee, just a community member, so don't take this as the gospel truth.

---

If you really need complete isolation of storage on a per tenant basis, it is probably worth evaluating an architecture where you use a Function App per tenant (running on Consumption Plan to keep the costs PAYG). Then you have complete isolation of compute and storage and would not require the Durable Functions runtime to change.

---

You definitely should abstract Durable Functions away from your clients, by wrapping an API service layer around your Durable Function that can handle Authentication/Authorisation. Durable Functions apps, are not intended to be directly exposed as public interfaces to your users/clients.

More on this here #838

---

With regards to throughput limits of a storage account, I can offer my experience.

Anecdotally, I run a multi-tenant Durable Function Application that serves approx 20,000 active customers a day. We actually have 4 copies of the Durable Function Application world-wide. 2 in UK South, 2 in UK West. Within each region there is a low-priority Function App and a high-priority Function App. A customer/tenant is bound to a Region and a priority.

This is all automated through Terraform, so as our customer base grows or our SLAs become challenged, we can introduce new Regions and new priorities and then redistribute the Tenants.

What I'm getting at is that you can offer a heck of a lot of throughput by introducing unique instances of the Function App, where each App services a portion of your customer base. Maybe this is something you could evaluate as part of your wider offering?

[ConnorMcMahon]

@dsm0880

In general, I agree with @olitomlinson that using a function app per tenant gives you most of what you are looking for at little cost. There is definitely an added dev-ops complexity, but there are thankfully many tools to help with these scenarios.

It is unclear how we would manage multi-tenancy on our end for you. We would need some way to decide how to assign orchestrations/entities to different tenants. Considering that there are many different ways to architect multi-tenant scenarios, I don't think us implementing our own opinionated version of multi-tenancy would be a good idea.

That being said, if you have a more concrete design that you feel would generally apply across many customers multi-tenant scenarios, I think we are open to the idea.