loading...

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

github logo ・1 min read

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/

twitter logo DISCUSS (8)
markdown guide
 

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.

 

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.

 

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.

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 ❤️

 

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.

Classic DEV Post from May 7 '19

The newly announced future of .NET - unifying all the things

Microsoft announces .NET 5

Ibrahim Hasan profile image