6 ms·

I read multiple articles on the topic years ago, dealt with and designed multi-tenant systems, and my approach is very simple for small developer teams: separat

I read multiple articles on the topic years ago, dealt with and designed multi-tenant systems, and my approach is very simple for small developer teams: separate databases, separate app instances running on separate domains for every tenant. This is the least technically complex to implement and there are very few mistakes you can make (only deployment). There are a lot of tools nowadays which can help you automate and isolate the environment for these (Docker, Ansible, whatever). Also it can be the most secure architecture of all.

treeman79 6y ago
Run several thousand tenants at a few places. Common usage 95% of of tenants is 20% of your traffic. 1% is 60% of traffic. Rest is the Rest. Balancing is always weird. 4000 tenants can share a 3 servers and be fine. 1 client might actually need dedicated hardware. Turns out AWS gets painful to manage beyond 1000 tenants. You start running into various account limits.
- sirkarthik 6y ago
  The limits on tenants are soft limits and should be extendable by reaching out to them.
  - treeman79 6y ago
    Responses have ranged from, your doing it wrong to “no” At one point we had a dozen different Amazon accounts to keep everything separate. Thankfully the business model was crap, so if resolved itself.
    - sirkarthik 6y ago
      LoL, for the way you finished your point. Good to know your experience :) Did Amazon mere said, "you are doing it wrong", without an explanation? In retrospective, do you think you could have done better? I'm looking to hear the lessons you learned, so may be, I don't end up making that mistake ;)
      - treeman79 6y ago
        For dynamodb it was “you need to rethink your data structure” S3, I think they did up the bucket limit on request, but maxed out at 1,000. That was years ago though.
        dkersten 6y ago
        I guess the way they want you to do it in S3 is using a per tenant key prefix with security policy set? AWS roles and security policies are quite flexible so I guess in theory you would get the desired isolation that way. Separate buckets are still easier, though...
    - zzzeek 6y ago
      Self-destructing business model is the most effective scalability strategy for developers by far. Just make sure you do net 30.
- coding123 6y ago
  Or move to K8S and put your low volume tenants on cluster A, and high volume tenants on cluster B. Devops it so that you can create new tenants with a script (in fact a script that is run by the signup codebase) that starts them out in cluster A. Migration to cluster B would definitely be involved if you're not using a shared database - so potentially be ready to know your potential clients up front to get them on the correct cluster ahead of time.
  - treeman79 6y ago
    K8s has proven to be a massive endeavor everywhere I’ve seen it implemented. I’ve often had teams of 2-6 to handle every technical aspect of a company with millions of visits. That includes feature development and support. K8 seems to need a large team just to keep it running.
    - coding123 6y ago
      I've had the opposite experience with K8S and docker in general. What was once pretty much always failing deployments, keeping software up to date incorrectly, K8s and docker in general keeps the burden of keeping a site running at an all time low in my lifetime of development. Like from teams to just 1 guy.
sirkarthik 6y ago
I second that..except for the security part though ;)
saberdancer 6y ago
How is that multitenant? That's just running a separate instance of application for each tenant. I agree that it is a completely valid approach, especially if you can afford it, but in my opinion it is just a single tenant application that can be easily spun up. For example, what if you want to manage all of your "tenants" within an admin interface. With a separate instance for all your tenants this is not really possible without additional development or a completely separate admin application.
- social_quotient 6y ago
  I agree with you here. We typically only advocate for this if the budget/time is low and the likelihood of a next tenant is not soon. Then we learn all we can on the first couple clones and then move to a real multi tenant design while also handling some tech debt we created the first time around. What tends to happen is a first immediate client is needed along with a couple of sales demo clients. This buys time for the business to see if it’s viable before we bring on complexity. But I agree clones of a core system isn’t multi tenancy. For what it’s worth I tend to tell clients we won’t be sustainable after 4-5 of these such clones. For people considering the clone approach let me caution one issue that comes up about 90% of the time. A client will as for a custom feature and be willing to pay for it for that “one” clone. These divergences are allowed to happen because we aren’t multi-tenant yet. You need to work hard to educate during this phase so you don’t create too much work down the line when you finally consolidate and refactor.
- kissgyorgy 6y ago
  > How is that multitenant? That's just running a separate instance of application for each tenant. Exactly! That's the point.
nogabebop23 6y ago
This strategy is really hard to make work with 100's or 1000's of tennants because of the resource overhead and scaling issues, even with virtualization. It makes integration a hard problem if you sell a modular or component-based suite of options as well.

treeman79 6y ago

Run several thousand tenants at a few places. Common usage 95% of of tenants is 20% of your traffic. 1% is 60% of traffic. Rest is the Rest. Balancing is always weird. 4000 tenants can share a 3 servers and be fine. 1 client might actually need dedicated hardware. Turns out AWS gets painful to manage beyond 1000 tenants. You start running into various account limits.

sirkarthik 6y ago
The limits on tenants are soft limits and should be extendable by reaching out to them.
- treeman79 6y ago
  Responses have ranged from, your doing it wrong to “no” At one point we had a dozen different Amazon accounts to keep everything separate. Thankfully the business model was crap, so if resolved itself.
  - sirkarthik 6y ago
    LoL, for the way you finished your point. Good to know your experience :) Did Amazon mere said, "you are doing it wrong", without an explanation? In retrospective, do you think you could have done better? I'm looking to hear the lessons you learned, so may be, I don't end up making that mistake ;)
    - treeman79 6y ago
      For dynamodb it was “you need to rethink your data structure” S3, I think they did up the bucket limit on request, but maxed out at 1,000. That was years ago though.
      - dkersten 6y ago
        I guess the way they want you to do it in S3 is using a per tenant key prefix with security policy set? AWS roles and security policies are quite flexible so I guess in theory you would get the desired isolation that way. Separate buckets are still easier, though...
  - zzzeek 6y ago
    Self-destructing business model is the most effective scalability strategy for developers by far. Just make sure you do net 30.
coding123 6y ago
Or move to K8S and put your low volume tenants on cluster A, and high volume tenants on cluster B. Devops it so that you can create new tenants with a script (in fact a script that is run by the signup codebase) that starts them out in cluster A. Migration to cluster B would definitely be involved if you're not using a shared database - so potentially be ready to know your potential clients up front to get them on the correct cluster ahead of time.
- treeman79 6y ago
  K8s has proven to be a massive endeavor everywhere I’ve seen it implemented. I’ve often had teams of 2-6 to handle every technical aspect of a company with millions of visits. That includes feature development and support. K8 seems to need a large team just to keep it running.
  - coding123 6y ago
    I've had the opposite experience with K8S and docker in general. What was once pretty much always failing deployments, keeping software up to date incorrectly, K8s and docker in general keeps the burden of keeping a site running at an all time low in my lifetime of development. Like from teams to just 1 guy.

sirkarthik 6y ago

I second that..except for the security part though ;)

saberdancer 6y ago

How is that multitenant? That's just running a separate instance of application for each tenant. I agree that it is a completely valid approach, especially if you can afford it, but in my opinion it is just a single tenant application that can be easily spun up. For example, what if you want to manage all of your "tenants" within an admin interface. With a separate instance for all your tenants this is not really possible without additional development or a completely separate admin application.

social_quotient 6y ago
I agree with you here. We typically only advocate for this if the budget/time is low and the likelihood of a next tenant is not soon. Then we learn all we can on the first couple clones and then move to a real multi tenant design while also handling some tech debt we created the first time around. What tends to happen is a first immediate client is needed along with a couple of sales demo clients. This buys time for the business to see if it’s viable before we bring on complexity. But I agree clones of a core system isn’t multi tenancy. For what it’s worth I tend to tell clients we won’t be sustainable after 4-5 of these such clones. For people considering the clone approach let me caution one issue that comes up about 90% of the time. A client will as for a custom feature and be willing to pay for it for that “one” clone. These divergences are allowed to happen because we aren’t multi-tenant yet. You need to work hard to educate during this phase so you don’t create too much work down the line when you finally consolidate and refactor.
kissgyorgy 6y ago
> How is that multitenant? That's just running a separate instance of application for each tenant. Exactly! That's the point.

nogabebop23 6y ago

This strategy is really hard to make work with 100's or 1000's of tennants because of the resource overhead and scaling issues, even with virtualization. It makes integration a hard problem if you sell a modular or component-based suite of options as well.