Best architecture for multi-tenant SaaS application

[Florian]

Hi everyone!

I'm looking for creating a multi-tenant application using ArangoDB (and maybe Foxx apps).

In the user's point of view, user can have access to an application (a tenant) and share data with application's users, but he can also signin to another application (without creating another account) and share other data with users in this application context.

Problems to solve :

• User can create an application on demand (click on "Create my application" and everything is created in time)
• User who belongs to multiple applications can easily switch from an app to another

What is the best way to do this with ArangoDB :

• create tenant specific collections/graphs with a shared users collection, and manage switching between tenant collections depending on application
• create a Foxx app by tenant allowing this split between collections (regarding Foxx applicationContext) (is it possible on-demand ?)
• create shared collections/graphs and manage queries by tenant in the code
• another solution ?

Thanks for your answers !

Florian

[Wilfried Gösgens]

Hi Florian,
You can use one central instance of a foxx service do authenticate your merchants.
You could then use the foxxmanager to deploy foxx applications.
However, whether its clever to trust users to deploy files and program code to your ArangoDB server is left as an excercise to the reader.
Its definitely not what Foxx was intended to be used like.

A better solution could be to use a primary ArangoDB with Mesos, and implement controlling Mesosphere Marathon from within your foxx service. Your users would then be allowed to launch their own new ArangoDB instances in your cluster.
Their foxx services would then run separated in their own VM/Docker container protected againt each other.  However, this aproach brings the overhead of running separate ArangoDB instances. Billing etc. could probably handled more easily.

Regarding graphs, you can generate the names of the graphs and their collections via methods of the application context - which then will prepend the mountpoint to these names.

Hope this helps,
Willi

[Florian]

Hi Wilfried !

Thanks for your response !

I think that the solution to allow user to create a completely new ArangoDB instance represents too much overhead for our use case, since data are quite small for every customers and doesn't need a complete ArangoDB instance.

I was wondering if this case would work :

• Manage the creation of new customer application within a unique Foxx app, which handle the creation of tenant specific collection (eg : tenantID_modelcollection1, tenantID_edgecollection1, ...)
• Route every authenticated requests to the specific tenant and handle route to the good collection "namespace"

Although there are not many collections per tenant (up to 10 collections), is there some big overhead to create collections per tenant on the fly like this ?  ?

Thanks in advance !

Florian

[Wilfried Gösgens]

Hi Florian,
the problem about foxx is, that in its current implementation state its not intended to be multi tenant enabled.
Therefore it doesn't have a good way to insulate the different services forcefully - be it collections or filesystem access.
Means: as long as you make shure all foxx services are mounted at a proper place, and foxx services use their mountpoint via their context to get the names of collections and don't do any mad disk i/o it will work.

However, there is no way to enforce this. So if you let your tenants create & upload their own foxx services, they get the ability to disturb each other or maybe even compromise the whole system.

If you have a set of foxx services reviewed or authored & maintained by you, you would be able to control that these services are properly implemneted to  behave well in your environment.

Your management service:
 - would authenticate the tenants (and maybe even their users).
 - would store information about the services it deployed in a collection accompanied with the owner for later privilege checking
 - would manage the mountpoints (i.e. force the customer name to be prepended) and make shure no mountpoints and configurations are broken.
 - would use the foxx-manager bindings to control these services it previously deployed.

The tenant foxx services:
 - would create and initialize their collections with their mountpoints prepended to the collection names, as its standard for foxx services.
 - in some way derive the authentication or do their own auth.
 - eventually do file i/o with their mountpoint prepended to filenames

Resource Usage:

Collections represent files on the filesystem.
Their size changes in threshholds with possible overhead per collection.
For that reason ArangoDB rather scales well on fewer huge collections than a huge number of small ones.

Similar holds true for foxx services:
They're instanciated into each V8 context which equivilents into RAM and resource usage.
This works well for several hundred services, but may not scale well to several tenthousand services.


So depending on the number of tenants you're intending to work with, the better (and intended) way of using ArangoDB would be to integrate tenant management into your services.
If it ranges into the thousands, you should think about my sugestion, if its several hundrets, your aproach may work well.


Hope this helps,

Willi

[Florian]

Hi Wilfried,

Thanks for your answer !

My use case was for something simpler than letting my tenants create & upload foxx services, but more for data separation between tenants.

However your answer helps me to understand potential overhead performance at scale.

Thanks !

Florian