5 ms·

Ask HN: How to scale or rearchitect a single portal site to a multi-tenant SaaS

8 points by chirau 5y ago

I don't even know if I worded that title correctly but here is my case in simple English. I built a site for a school to manage their alumni association. So it's a complete site with a dashboard that exists at say example.com where they can create new campaigns, add pictures, add news posts etc. After a while, some other schools also wanted the same portal as I built for the one school. I don't know how many more will want this kind of site, but many more will it seems. So instead of building out each site individually, I want to build a SaaS of sorts. So that each school can sign up and spin up it's own such alumni association site. All the portals will be accessible from one TLD, so the url will be something like example.com/school1 or school1.example.com. I have never built something like this, so I have several questions: 1) I'm guessing I can use the site I have as a template to spin off new sites in the new SaaS? 2) What is the correct term for this multi-tenant setup so that I know how to speak when I ask questions or do consultations? 3) What resources can I use to learn to build such a multi-tenant infrastructure? I have not seen any literature on such indulgences. I'm looking for books, blog posts, tutorials etc on architecting such kind of software or something close. 4) What technologies am I looking at utilizing to build out such and what expertise should I be looking for? Is this what stuff like Docker/Kubernetes/containerization is used for in isolating stuff? Or I should be looking at something else? 5) What are some potential pitfalls and points of concern that are unique to this endeavor that I should keep in mind when planning this out?

aww_dang 5y ago
Depends on the tech stack you want to work with. What you are describing is often called "white label". The simple way to build this would be to store each customer's data in a database.
mooreds 5y ago
Haha, I'm working on a multi tenant guide for my employer (an identity provider), which will at least cover the login/logout/registration behavior. > What is the correct term for this multi-tenant setup Private label, white label. > I can use the site I have as a template to spin off new sites in the new SaaS? Do you want to update the application to handle multiple tenants? You could also spin up an entirely separate physical application (a new WAR file, if you were building it in java). But this is simpler to start, but will lead to complexity in the end, as you will have to deploy to N sep instances on update. > What technologies am I looking at utilizing to build out such Any tech can do it. Here's the example app I'm building in PHP: https://github.com/FusionAuth/fusionauth-example-symfony-multitenant/ https://github.com/FusionAuth/fusionauth-example-symfony-mul...
- 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.
- 5y ago
pricci 5y ago
One solution would be to dockerize your current setup and then spin a container for each school. Then with nginx, point example.com/school1 to its corresponding container.
- chirau 5y ago
  Thank you. What about data isolation? Would each containerized app have its own database or would all of them be reading from the same master?
  - aliasEli 5y ago
    If you are in the EU I would definitely advise to use separate databases due to privacy laws (GDPR). This also keeps your database and queries simpler because you don't need to use a separate a separate tenant ID column.
  - pricci 5y ago
    That would be your decision to make. It is actually easier to have a separate db for each.
- gtsteve 5y ago
  This is reasonable in the short term. Pros: You can probably make it work in a day or two Cons: You now have to manage resources for each school. With dozens it's no big deal, but with tens of thousands you've got a considerable deployment problem. I have worked at a company that started with a few single-tenant instances and ended up with a thousand. We ended up building software to specifically manage deployments, do healthchecks, ensure isolation etc (it was a long time ago - I expect we'd just run a giant kube farm today). So, this is a reasonable approach with a painful trade-off as you scale. I would do this in the short term whilst working on refactoring this into a multi-tenant app.
aliasEli 5y ago
Like several commenters pointed out, using separate systems seems the best approach for the short term. I suggest that you first implement the system for multiple schools before re-architecting your system. Your will have better understanding about which parts of the system should be customizable and which ones should not. Do not attempt to make your system overly customizable. I have seen several systems where almost everything could be customized. In most cases these were pretty complicated to use, and of when the customer came with some request we had to change the customization code itself, because the request could not be satisfied with a change in customization parameters.
biermic 5y ago
You'd create a table that holds the different tenants. Then add a association between users and tenants. Store the tenant in the authenticated users session. Then you could attach the tenant specific configuration to the session too, or better keep it in an in-memory cache.

8 points by chirau 5y ago

aww_dang 5y ago

Depends on the tech stack you want to work with. What you are describing is often called "white label". The simple way to build this would be to store each customer's data in a database.

mooreds 5y ago

Haha, I'm working on a multi tenant guide for my employer (an identity provider), which will at least cover the login/logout/registration behavior. > What is the correct term for this multi-tenant setup Private label, white label. > I can use the site I have as a template to spin off new sites in the new SaaS? Do you want to update the application to handle multiple tenants? You could also spin up an entirely separate physical application (a new WAR file, if you were building it in java). But this is simpler to start, but will lead to complexity in the end, as you will have to deploy to N sep instances on update. > What technologies am I looking at utilizing to build out such Any tech can do it. Here's the example app I'm building in PHP: https://github.com/FusionAuth/fusionauth-example-symfony-multitenant/ https://github.com/FusionAuth/fusionauth-example-symfony-mul...

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.
5y ago

pricci 5y ago

One solution would be to dockerize your current setup and then spin a container for each school. Then with nginx, point example.com/school1 to its corresponding container.

chirau 5y ago
Thank you. What about data isolation? Would each containerized app have its own database or would all of them be reading from the same master?
- aliasEli 5y ago
  If you are in the EU I would definitely advise to use separate databases due to privacy laws (GDPR). This also keeps your database and queries simpler because you don't need to use a separate a separate tenant ID column.
- pricci 5y ago
  That would be your decision to make. It is actually easier to have a separate db for each.
gtsteve 5y ago
This is reasonable in the short term. Pros: You can probably make it work in a day or two Cons: You now have to manage resources for each school. With dozens it's no big deal, but with tens of thousands you've got a considerable deployment problem. I have worked at a company that started with a few single-tenant instances and ended up with a thousand. We ended up building software to specifically manage deployments, do healthchecks, ensure isolation etc (it was a long time ago - I expect we'd just run a giant kube farm today). So, this is a reasonable approach with a painful trade-off as you scale. I would do this in the short term whilst working on refactoring this into a multi-tenant app.

aliasEli 5y ago

Like several commenters pointed out, using separate systems seems the best approach for the short term. I suggest that you first implement the system for multiple schools before re-architecting your system. Your will have better understanding about which parts of the system should be customizable and which ones should not. Do not attempt to make your system overly customizable. I have seen several systems where almost everything could be customized. In most cases these were pretty complicated to use, and of when the customer came with some request we had to change the customization code itself, because the request could not be satisfied with a change in customization parameters.

biermic 5y ago

You'd create a table that holds the different tenants. Then add a association between users and tenants. Store the tenant in the authenticated users session. Then you could attach the tenant specific configuration to the session too, or better keep it in an in-memory cache.