We had a huge discussion over this in our company but eventually we ended up with a multi-tenant architecture. So far so great though! Multitenancy when combined with load balancers, Reverse proxies and especialy Container Orchestration Engine such as Kubernetes, things go pretty good in saving up some of your Cloud Costs/Resources and reduces the container's management complexity exponentially. Imagine having 10000 customers one day and then fixing a bug for all of them (you'll probably restart them all). The only difficulty that took sometime for us with this architecture was making our services stateless -- which we have somehow achieved using checkpointing, logging and some minor tweaks to the services.
Ahsan Nasir thanks Ahsan for sharing! I bet building multi-tenent services is challenging, there is the statelessness as you said which will give you Secuirty at the service level. How did you implement the database and storage layer any challenging there besides coming up with good schema?
@@hnasr so basically for the database, it might sound crazy but we run an orchestrated (HA) SQL Server with a one DB dedicated for every single customer. Each SQL Server can hold up to 100 databases before we spin up another one if we have more customers. So basically, we use consistent hashing on runtime from our stateless services to identify which database to select (customer DB) at runtime. So every authenticated request to our backend knows where to go regardless of how many replicas of our stateless backend we run. So far works like a charm. Hope it stays that way :D
Ahsan Nasir sounds great! So a single database instance with multiple database still considered multi-tanent on my opinion! And smart and pragmatic decision, each customer can potentially have their own schema if they want to. I saw some people make a single database and host multiple customers in that database tough to build I like your approach better. However you might run into challenges synching those schemas or making changes between databases but thats why scripts exists.. Thats what i love about these discussions you see real production system making great pragmatic decisions to build a real system not a theoretical on paper only. Thanks for sharing again !
@@hnasr I would still call it multitenant, since the CPU/memory etc resources are still 100% shared between customers that help us make great decisions on horizontal scaling and load balancing, which was the real point behind it for us anyway. Your point about synchronizing the schemas is actually very good. We thought of that too, but eventually we ended up with this decision because we don't really expect any huge schemas changes in the future (its because of the kind of system/data we have). But guess what, keeping the databases apart gives us pretty good performance and we don't really have the cost of spending days on further normalization, indexing and such complex topics for our customer's data. So it's kind of a unusual paritioning pre-done for us! :D And yes, Thank you for the good discussion! :)
LawZist awesome !! Share some info that I might missed. I know another property of multi-tenant application is customization.. forgot to mention that in the video
Multitenancy is the key to any cloud deployment. Separate instances would not scale and would be costly to implement. The key is to make the implementation robust in terms of separating everything using qualifiers and namespaces. e.g. every database schema has the tenant prefix, even every single table may have the tenant identifier column, every single functionality first uses and needs a tenant qualifier etc.
Really great video! I know you talked a lot about stateful vs stateless servers and pros and cons of each, but maybe have a video about your personal opinion about when to go stateful and when to go stateless, and when does being stateless is not a good idea!
Good video. I see the benefits for database (or schema) per customer, but it is so much more work. If I had a DBA I'd do it every time. When it's a small team though...
Lewis Campbell i agree! Lots of work. Someone commented a nice workaround they had a single sql server instance with many databases. So less management but high isolation.. You can put your customers on one database but that require quality database modeling skills to get right
@@hnasr When modeling the database to suport multiple vendors in a marketplace, one would unknowingly be modeling a db to support a multi tenancy architecture. I'd imagine it woulnd be much work to design a db that must support only one vendor instead. At least in my country coming out from colledge if i'd build a multi customer application by default i'd be using this architecture because normally in database modelling they don't ecpect you to model for one customer when they expect it to support multiple one, neighter would they be talking about cotainerization as a solution for supporting multiple customers. What i'm trying to say is by default, a beginner is already doing this architecture instead of using containers for the isolations. But thank you for the pros and cons of these approach.
Hussein, how often do you see the system design changing as a whole in your work?Suppose the ROI on one workflow per tenant model start taking a hit, what sort of way would you be dealing it with?I would like to have your take on this.I know I sometimes I start with a model and it seems to be failing but can't go back and thus have to keep improvising
Siddiqui Sarik that is a very good question, changing design midway is extremely expensive and even impossible sometimes. That is why you need to nail things down correctly. And think of the basic use cases really hard and min ship product. Thats a problem of the agile methodology as well where requriements change often and causes design rethinking which slow down projects and introduce a monster app
I think multitenancy is pretty good. Like you said, we need to take care of the security if we are sharing. Sharing db and stuff is pretty common multitenancy stuff? Maybe, it's depend? For me, I am working on multitenancy application which share only specific features. Quite interesting...
YGNCode thanks YG ! It’s interesting what defines a multi-talent app. If your “app” is shared but the database isn’t I would still call your app a multi-tenant app but its not a multi-tenant system hmm
Im assuming you are talking about "Multitennat" but with more than one database? Or in other words, you have a server that serves multiple customers, and you have a dedicated db for each customer, right? There a couple of ways to go about something like that, but a popular one is based on the concept of "access keys". Essentially each customer is assgined an access key, and that access key is sent, in one way or another, with every request from the client to the server. When the request reaches the server, internal app code disects the request and routes any db data fetching to the correct db based on the acces key.
Each customer requires different customisation to the application, we can ofcourse provide shared db and compute, but , how do i have different application versions for different customers.? Eg : one customer wants normal calculator, one customer wants, scientific calculator, one more customer wants a music player while performing calculations, and one more customer wants voice based calculator
You could version your builds and host them all on one server. In the case of IIS ( default windows server) you can host mulitple sites all on the same server, where each site's code would reside in different root directories, and incoming requests would be routed to, or pointed at, the crorrect site (or version of your build). You could host ten slightly differnt versions of your app, or even ten completley different apps all on your one IIS server.
In the long term for almost all applications you are not going to compete unless you build this way. For example, what small or midsize business would have their own email system and email sys admin in 2020. What service provider would build an email service for every customer ... or these days what service provider would even build their own email service at all.
I don't think this architecture suitable for enterprise level application. Maybe can be used for small application. Really worried about the performance and security.
I can see why some VPS providers overselling their instances. If the performance is guaranteed, so that's very good. But it still depends on the customer's security requirements.
Exactly John, a VM is expensive so if you can build a multi-tenant application that serves multiple of your customers and lives in a single VM (or pool of VMS) you save lots of money
Wow 2 videos in every day... Thats dedication !!! 👍
I developed my first multi-tenant application in 2014. Yes, at that time, I didn't know the terminology.
You always makes development more interesting!! The way you explain is awesome!!
No analogies for techs!! Thank you!!!
We had a huge discussion over this in our company but eventually we ended up with a multi-tenant architecture. So far so great though!
Multitenancy when combined with load balancers, Reverse proxies and especialy Container Orchestration Engine such as Kubernetes, things go pretty good in saving up some of your Cloud Costs/Resources and reduces the container's management complexity exponentially. Imagine having 10000 customers one day and then fixing a bug for all of them (you'll probably restart them all).
The only difficulty that took sometime for us with this architecture was making our services stateless -- which we have somehow achieved using checkpointing, logging and some minor tweaks to the services.
Ahsan Nasir thanks Ahsan for sharing! I bet building multi-tenent services is challenging, there is the statelessness as you said which will give you Secuirty at the service level. How did you implement the database and storage layer any challenging there besides coming up with good schema?
@@hnasr so basically for the database, it might sound crazy but we run an orchestrated (HA) SQL Server with a one DB dedicated for every single customer. Each SQL Server can hold up to 100 databases before we spin up another one if we have more customers. So basically, we use consistent hashing on runtime from our stateless services to identify which database to select (customer DB) at runtime. So every authenticated request to our backend knows where to go regardless of how many replicas of our stateless backend we run. So far works like a charm. Hope it stays that way :D
Ahsan Nasir sounds great! So a single database instance with multiple database still considered multi-tanent on my opinion! And smart and pragmatic decision, each customer can potentially have their own schema if they want to.
I saw some people make a single database and host multiple customers in that database tough to build I like your approach better. However you might run into challenges synching those schemas or making changes between databases but thats why scripts exists..
Thats what i love about these discussions you see real production system making great pragmatic decisions to build a real system not a theoretical on paper only.
Thanks for sharing again !
@@hnasr I would still call it multitenant, since the CPU/memory etc resources are still 100% shared between customers that help us make great decisions on horizontal scaling and load balancing, which was the real point behind it for us anyway.
Your point about synchronizing the schemas is actually very good. We thought of that too, but eventually we ended up with this decision because we don't really expect any huge schemas changes in the future (its because of the kind of system/data we have). But guess what, keeping the databases apart gives us pretty good performance and we don't really have the cost of spending days on further normalization, indexing and such complex topics for our customer's data. So it's kind of a unusual paritioning pre-done for us! :D
And yes, Thank you for the good discussion! :)
@@ahsannasir6214 Wow, I like your approach. Can you share the tech stack in which you've implemented it?
Great video Hussein! The company that I work for uses Multitenancy architecture, so this video is very helpful to me :)
LawZist awesome !! Share some info that I might missed. I know another property of multi-tenant application is customization.. forgot to mention that in the video
Multitenancy is the key to any cloud deployment. Separate instances would not scale and would be costly to implement. The key is to make the implementation robust in terms of separating everything using qualifiers and namespaces. e.g. every database schema has the tenant prefix, even every single table may have the tenant identifier column, every single functionality first uses and needs a tenant qualifier etc.
Well said ! Thanks for the insights! 👍
Really great video!
I know you talked a lot about stateful vs stateless servers and pros and cons of each, but maybe have a video about your personal opinion about when to go stateful and when to go stateless, and when does being stateless is not a good idea!
Any other videos about this (multi-tenant architecture)? Would be great to see it in practice.
Great explanation. Really enjoy your video. Your way of explaining is awesome.
Good video. I see the benefits for database (or schema) per customer, but it is so much more work. If I had a DBA I'd do it every time. When it's a small team though...
Lewis Campbell i agree! Lots of work. Someone commented a nice workaround they had a single sql server instance with many databases. So less management but high isolation..
You can put your customers on one database but that require quality database modeling skills to get right
@@hnasr When modeling the database to suport multiple vendors in a marketplace, one would unknowingly be modeling a db to support a multi tenancy architecture. I'd imagine it woulnd be much work to design a db that must support only one vendor instead. At least in my country coming out from colledge if i'd build a multi customer application by default i'd be using this architecture because normally in database modelling they don't ecpect you to model for one customer when they expect it to support multiple one, neighter would they be talking about cotainerization as a solution for supporting multiple customers.
What i'm trying to say is by default, a beginner is already doing this architecture instead of using containers for the isolations. But thank you for the pros and cons of these approach.
Is web server an example of multi-tenancy? Becuase multiple clients (tenants) connect to it. No?
Hussein, how often do you see the system design changing as a whole in your work?Suppose the ROI on one workflow per tenant model start taking a hit, what sort of way would you be dealing it with?I would like to have your take on this.I know I sometimes I start with a model and it seems to be failing but can't go back and thus have to keep improvising
Siddiqui Sarik that is a very good question, changing design midway is extremely expensive and even impossible sometimes. That is why you need to nail things down correctly. And think of the basic use cases really hard and min ship product.
Thats a problem of the agile methodology as well where requriements change often and causes design rethinking which slow down projects and introduce a monster app
You should trademark the greeting line ‘What is going on guys!’ 🙂
Hey Hussein! Love the content on your channel. However, you might wanna invest in a camera stabiliser. Will increase the video quality dramatically.
Aditya Bharti thanks 🙏 will do!
WOW thanks ...u are the best sir ...
Damn these fancy words... Been working for a SaaS product without knowing it was based on a multi tenant architecture...!
I think multitenancy is pretty good. Like you said, we need to take care of the security if we are sharing.
Sharing db and stuff is pretty common multitenancy stuff? Maybe, it's depend?
For me, I am working on multitenancy application which share only specific features. Quite interesting...
YGNCode thanks YG ! It’s interesting what defines a multi-talent app.
If your “app” is shared but the database isn’t I would still call your app a multi-tenant app but its not a multi-tenant system hmm
Thanks very much for this video.
Thanks Roman 🙏
can you talk about Multi-tenant database level ? Single-tenancy or Multi-tenancy
if we have one instance and many databases instance for each customers, how do we can connect to the right database instance for it customer request?
Im assuming you are talking about "Multitennat" but with more than one database? Or in other words, you have a server that serves multiple customers, and you have a dedicated db for each customer, right? There a couple of ways to go about something like that, but a popular one is based on the concept of "access keys". Essentially each customer is assgined an access key, and that access key is sent, in one way or another, with every request from the client to the server. When the request reaches the server, internal app code disects the request and routes any db data fetching to the correct db based on the acces key.
Can you please explain a single tenant in more details.
Each customer requires different customisation to the application, we can ofcourse provide shared db and compute, but , how do i have different application versions for different customers.? Eg : one customer wants normal calculator, one customer wants, scientific calculator, one more customer wants a music player while performing calculations, and one more customer wants voice based calculator
You could version your builds and host them all on one server. In the case of IIS ( default windows server) you can host mulitple sites all on the same server, where each site's code would reside in different root directories, and incoming requests would be routed to, or pointed at, the crorrect site (or version of your build). You could host ten slightly differnt versions of your app, or even ten completley different apps all on your one IIS server.
wait.... do single-tenant applications even exist?? are single-tenant system basically only softwares that you need to install on you device?
Don't we call it SAAS?
Wait, what do you mean by
"They also charge lots of money for a multi-tenant license.."?
Is this from hosting side or server/backend?
I was referring to Oracle container database, multi-tenant license
@@hnasr ahhh, I see.. Thanks to make it clear. Always lookin up server or backend side from you, man. 🍻🍻
In the long term for almost all applications you are not going to compete unless you build this way. For example, what small or midsize business would have their own email system and email sys admin in 2020. What service provider would build an email service for every customer ... or these days what service provider would even build their own email service at all.
Paul Bird well said
@@hnasr Thank you, a possible follow on for this video would be to go the next level up and discuss what white label services are.
Good videos bro but you need better audio / volume
fantastic video
I don't think this architecture suitable for enterprise level application. Maybe can be used for small application. Really worried about the performance and security.
This is actually used all over enterprise. Im not agreeing or disagreeing, but it is quite prevalent and there are many reasons to do so.
I can see why some VPS providers overselling their instances.
If the performance is guaranteed, so that's very good.
But it still depends on the customer's security requirements.
Exactly John, a VM is expensive so if you can build a multi-tenant application that serves multiple of your customers and lives in a single VM (or pool of VMS) you save lots of money
Sounds very expensive.