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)
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 Django there is some package as :
django-tenants-schemas django-tenant-schemas.readthedocs....
django-tenants : django-tenants.readthedocs.io/en/l...
for laravel (php) Laravel-tenancy : larvel-tenancy.com
for symfony (PHP) swp/multi-tenancy-bundle , vivait/tenant-bundle - Packagist
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.
Hey, watch out who you're tagging. XD
Yeah sorry !!!
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 ❤️
you are welcome !!! ;)
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.comand 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:
*.app.domain.com. I already mentioned the disadvantages of this options.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.comand 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.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
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.
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_namedirective ) and everything accordingly. Please check this out :How to create sub-domain automatically when users register on my SaaS application ?
ADONIS SIMO ・ Aug 5 '19 ・ 1 min read
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).
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.
Thank you for your article