DEV Community

Ibrahim Hasan
Ibrahim Hasan

Posted on

Which cloud provider should I use to build Multi-tenant SAAS?

I'm building a saas and I decided to use cloud, after some research I've done on my own I found out that there aren't tools that could help for example in creating new tenants and routing users to the right tenant automatically.

All what I found from AWS, Google and Azure was explaining how to architect your multi-tenant app.

As an example I want to develop an application like zoho.people
https://www.zoho.com/people/

Top comments (10)

Collapse
 
theoutlander profile image
Nick Karnik

The question you are asking is not right based on the problem you're trying to solve. You need to first build an Application that can handle multiple tenants. You need to apply Authentication / Authorization to do this. In your setup, you can isolate a client's data, but you will need to design all that. You should be able to run your setup locally first.

As for the cloud provider, anything works. That's not where your problem lies. Cloud providers will simply provide multiple features at various price-points.

Collapse
 
himamegahed profile image
Ibrahim Hasan

I see excuse me if my question was ubiquitous, the problem that I can't find over the internet how this can be made on reality.

My first thoughts were that the cloud provider will do almost everything & I just need to deploy my application with my database schema and that's it, but lately, I found out that's a daydream.
So if it possible how should I architect my app to handle multi-tenancy on the first basis, any links/books/blogs/tutorials I'd be grateful.

Collapse
 
simo97 profile image
ADONIS SIMO

Hi mate,

I think i can help you. You want to build a multi-tenant SaaS app and as @nick Karnik said up there, it need to run first on you local machine without any stuff from the cloud provider.

The fact is that you are intending to have the same database model for multiples clients there is usually 3 ways to build a SaaS application at the DB level

Data isolations levels

  • Low data isolation : Here you store all clients data in the same databse within same tables and use a kind of client's ID (or UUID) to filter queries. SAME DB AND TABLES

  • Mid data isolation : Here you store clients data in the same database but in different schemas (NOTE : schemas can be seen like a kind of small database within the ) SAME DB, BUT DIFFERENT TABLES

  • Hight data isolation : In this cas you totally separate client's data by storing them in wholw differents databases( whole different SGBD instance) DIFFERENT DB

How does it work

To choose which tenant's data you should use to display results of a query you need to use a tenant detection strategy there is a lot out there, but the most used is the one based on request's url. Let assume that you have urls as follow client1.yoursite.com client2.yoursite.com the strategy based on request's url assume that you will choose you tenant from the request domain name so for the first url you will know which client's data are asked and depending on the isolation level you have implemented you will retrieve the right data. Another tenant detection strategy is based on HTTP request header.

At this level depending on you business logic you can manage static/upload file from a way to another.

I had already implemented this but in python with Django so i don't know which technologies you are using but the principle remain the same,

for Ruby-on-Rail : github.com/influitive/apartment Apartment

Some links :

medium.freecodecamp.org/building-a...

books.agiliq.com/projects/django-m...

medium.com/@ashokgelal/a-full-feat...

docs.microsoft.com/en-us/azure/sql...

In general those libs use to handle all the stuff i tried to explain up there.

Regards.

Thread Thread
 
nick profile image
Nick Rameau

Hey, watch out who you're tagging. XD

Thread Thread
 
simo97 profile image
ADONIS SIMO

Yeah sorry !!!

Thread Thread
 
himamegahed profile image
Ibrahim Hasan

Hi @simo97

You really made my day, Thanks for your response and sorry for my late reply.

Actually, I was waiting for confirmation just like that saying that I must handle everything on my own locally before going to the cloud.

I really appreciate your help thanks, dude ❤️

Thread Thread
 
simo97 profile image
ADONIS SIMO

you are welcome !!! ;)

Collapse
 
simoami profile image
Simo Moujami

Hi @simo97 ,
Thanks for the article. I wanted to touch base on the tenant detection approach. I did consider the subdomain approach but I got burned in the past for embracing it. The issue with it is that you need wildcard certificates to support a secure *.app.domain.com and those don't come cheap. Also, we're deploying to Google Cloud and they don't support wildcard certificates as managed certificates, which means we have to manually update them every year. Finally supporting subdomains requires running scripts that modify the dns records which is cloud platform specific. For example the way to do it with Route53 (AWS) is different from Google or Godaddy.

Additionally we have a requirement to support accounts that can manage other accounts. For example, Deloitte might be managing several clients and when they log in, they could manage any specific client. So there must either be some kind of selection post login or a way to differentiate the emails or usernames. To recap, here's the few options I had considered:

  1. subdomains, like *.app.domain.com. I already mentioned the disadvantages of this options.
  2. Using account-level email addresses as shown in the model above, your account email is user@client1.com. The app sees that your email is specific to client1 ***@client1.com and identifies the account. But it means an account email has to be setup for you each time you need access to an account. perhaps it also means you couldn’t set up an account on behalf of a client since you need an email set up with them first.

  3. during the login process, we ask you to first enter the organization name so we can identify which org you want to logon to, then we request your email address in step 2. the issue here is if you mistyped the org name, like Pandora vs Pandora inc, vs Pandora, inc, not sure how we can correctly map it to the correct tenant

  4. Let the user log in with the email set in the users table. If they have membership with more than one account, prompt them to select the account they wish to access. So now this single email approach raises a question. How do you sign up multiple times using the same email address so you can sign up multiple clients.

Collapse
 
simo97 profile image
ADONIS SIMO • Edited

Hi @simoami

Thank for sharing your process, it looks interesting but i think a lot of points really depends on what you're building.

1. For sub-domains

It's more likely to be useful for users's confidence that their data are not merged with others client's data (peoples thinks like that sometimes, when a SaaS is designed like that, maybe weird but it is what it is). And from what i tried in the past, i discoverd that you can define a CNAME with * as value and target your server with it then you web server (NGINX, or any proxy) will be in charge of indentifying the request informations and will handle the certificate (with server block in nginx you can load differents SSL certificated depending on the domain server_name directive ) and everything accordingly. Please check this out :

2-3. User identification

The way to design this really depends on what your system does and how it does it. It can be difficult to do if your users can be shared across multiple organizations, in that case you may need to store some user's meta data (about what organizations they are into actually for example) and either propose them to choose one when login in or redirecting them into a "default" organization and they can change it later or something (king of how AWS manage everything with Regions).

In other design if your users a totally separated per organizationa and there is no reason for a user to have the same account with multiples organization it become simplier... you just need to store the org ID in the User informations (table, or whatever you use to store them).

  1. When you say "single email approach", i think visitors can create accounts on your system with their proper email (@gmail, @outlook, etc) but you will certainly have to restrict someone to create multiple account with the same email. But it really depends on your system. May be setting up a king of external auth system is a good and simplier solution for you (OAuth, or something). But i think you may have to make a difference between organization's owners and organization's members in someway.

Sorry for responding with so much delay... i totally missed the notification. I help this will be helpful in some way.

Just ping me a message if you want more discussions on this topic.

Collapse
 
alainlandry profile image
Alain Landry Noutchomwo

Thank you for your article