Hacker News Reader

Comment by kissgyorgy | Hacker News Reader

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.

View on HN

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.

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.

> How is that multitenant? That's just running a separate instance of application for each tenant.

Exactly! That's the point.

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.

The limits on tenants are soft limits and should be extendable by reaching out to them.

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.

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 ;)

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.

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...

Self-destructing business model is the most effective scalability strategy for developers by far. Just make sure you do net 30.

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.

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.

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.

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.

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

Reply on news.ycombinator.com