3 ms·

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 al

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

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.