2 ms·

Thank you for the response. When you say spinning up separate physical application, I am guessing this is for isolation concerns? What would be the best way to

by chirau 5y ago

Thank you for the response. When you say spinning up separate physical application, I am guessing this is for isolation concerns? What would be the best way to handle especially data isolation? Would each spinoff have its own database or it would just be an application but reading from one master for all the schools? I am trying to think of this from the point of view of a front-end user who graduated from 2 different schools and needs to get notifications/updates from both schools in a single front page. Which isolation approach has a better security vs efficiency balance?

mooreds 5y ago
So you have two different main levels of isolation. The first is physical: For each client, you have: * sep web server * sep database * same codebase The wins with this approach: * can live in different geographies (for compliance or data sovereignty) * downtime for one webserver/app doesn't affect other clients * no intermixing of user data * clients can live on different versions quite happily Downsides: * deployment becomes difficult * more expensive because you scale servers linearly with clients The other option, far more common, is logical isolation. * same web server (filter traffic on hostname or some other attribute) * same database (have a 'tenant' table and a 'tenant_id' FK in every relevant table) * same codebase Wins: * operations are much simpler--it's one application that looks to users like many applications * will be cheaper. Even if you need a bigger server, the price won't scale linearly with # clients Downsides: * can't, except through feature flags or other custom coding, have users on different versions (see what Stripe does: https://stripe.com/blog/api-versioning ) * one client's traffic can affect other clients (the noisy neighbor problem) > I am trying to think of this from the point of view of a front-end user who graduated from 2 different schools and needs to get notifications/updates from both schools in a single front page. That points toward logical isolation, because at that point you can have 'global' logic that spans tenants. That is possible to do with physical isolation (network calls), but much more difficult than with logical isolation (a database call). > Which isolation approach has a better security vs efficiency balance? That's a tradeoff only you can decide. It's more typical to use logical isolation, however.

by chirau 5y ago

mooreds 5y ago

So you have two different main levels of isolation. The first is physical: For each client, you have: * sep web server * sep database * same codebase The wins with this approach: * can live in different geographies (for compliance or data sovereignty) * downtime for one webserver/app doesn't affect other clients * no intermixing of user data * clients can live on different versions quite happily Downsides: * deployment becomes difficult * more expensive because you scale servers linearly with clients The other option, far more common, is logical isolation. * same web server (filter traffic on hostname or some other attribute) * same database (have a 'tenant' table and a 'tenant_id' FK in every relevant table) * same codebase Wins: * operations are much simpler--it's one application that looks to users like many applications * will be cheaper. Even if you need a bigger server, the price won't scale linearly with # clients Downsides: * can't, except through feature flags or other custom coding, have users on different versions (see what Stripe does: https://stripe.com/blog/api-versioning ) * one client's traffic can affect other clients (the noisy neighbor problem) > I am trying to think of this from the point of view of a front-end user who graduated from 2 different schools and needs to get notifications/updates from both schools in a single front page. That points toward logical isolation, because at that point you can have 'global' logic that spans tenants. That is possible to do with physical isolation (network calls), but much more difficult than with logical isolation (a database call). > Which isolation approach has a better security vs efficiency balance? That's a tradeoff only you can decide. It's more typical to use logical isolation, however.