Introduction to Multi-Tenant Architecture | Hacker News Reader

Introduction to Multi-Tenant Architecture

engineeringatscale.substack.com

19 pointsanimesh371g6 comments

Multitenant architectures are valuable in that you can reuse a lot of the same resources e.g shared infrastructure but they also come with caveats. Much more complex to create, harder to manage and reason about. When things go wrong they affect a bigger subset of users. There's potential to mess something up and expose one tenants data to another. I mean just hosts of problems. When it works it works well but not without a lot of overhead. Having built and run it from scratch and the alternative of serving isolated deployments per customer I can't say one is better than the other. It's that they're used for varying scale just like different algorithms or monolithic vs microservices. It's not one size fits all. You have to understand what you're getting yourself into. Saying that I think more software will start to bake in the concept of multitenancy so we might just start getting it for free.

Indeed, most of the cloud providers such as AWS, Azure, GCP use the concept of multi-tenant architecture. It hides lots of details from the end user and efficiently utilises computing resources.

Another CON is that it's very hard to apply compliance to a specific tenant. Let's say you have a customer with HIPAA or PCI requirements. If they are co-mingled with your customer pool (shared app servers, network, DB) , you won't be able to meet those compliance requirements unless you apply it to all customers.

You'll notice cloud providers host their government customers on a separate tier for this reason. But it takes a lot of work to segregate the traffic.

Single-tenant isn't all bad– just a design decision with tradeoffs. With virtualization you can often make those tradeoffs more easily than before.

> You'll notice cloud providers host their government customers on a separate tier for this reason. But it takes a lot of work to segregate the traffic.

the primary reason for this is that nobody but us citizens can touch these services, including the service operators.

there are similar requirements in other business regulations

probably, but not HIPAA or PCI or many of the other ones people care about. Even for FedRAMP there is a distinction between the lower-tier of compliance which is applied to us-east and us-west (whose only interesting requirement is "do you have a FIPS cipher-suite only endpoint?") vs. the high-tier of compliance which necessitates govcloud.

EDIT: you may be talking about compliance regimes that necessitate that only certain operators have access to certain data (or in some cases have no access at all). while that may be a compliance requirement, that's also stuff aws just does /anyways/ and fits along normal operating procedure of least privilege and defense in depth. what doesn't align with normal operating procedure is something like only americans can look at these logs, because most companies don't built teams by nationality.

otherwise, almost all compliance regimes don't necessitate tiering. and by avoiding tiering and building your multitenant services on top of all of the other multitenant services that aws offers that are XYZ compliant (https://aws.amazon.com/compliance/services-in-scope/), it becomes very straightforward to get your service compliant. this is what makes tractable for every one of those pages to have just about every aws service that matters marked as compliant.

and this isn't just conjecture; i've sat through several of these reviews personally and so long as you build your service in the aws way you spend about a day or two of your team and then a little bit later your service is certified, save for FedRAMP where you spend some amount of time setting up new loadbalancers and any artifacts that need to use to switch to a FIPS-compliant ciphersuite.

Reply on news.ycombinator.com