3 ms·

In my experience there is no point developing multi-tenant software nowadays, because operating large number of isolated environments is a solved problem and re

by Walkman 10y ago

In my experience there is no point developing multi-tenant software nowadays, because operating large number of isolated environments is a solved problem and really cheap nowadays. You can buy VPS-es for less then 5$ today, you can automatically create them, deploy the instances easily. You can scale either horizontally or vertically (Docker can help both). It's not much more work, but much more secure and more scalable and almost as cheap as a multi-tenant solution would be.

cakes 10y ago
Multi-tenancy solves some problems around maintenance and upgrade paths that are hugely beneficial when you are managing multiple deployments. If you have even more than just 1 deployment of a thing and scale to 2 (or N), you now also have to manage the software level of those N containers (without multi-tenancy) vs. just 1 deployment for everywhere.
- mason55 10y ago
  > If you have even more than just 1 deployment of a thing and scale to 2 (or N), you now also have to manage the software level of those N containers (without multi-tenancy) vs. just 1 deployment for everywhere. Sometimes this is a feature. If you're doing managed enterprise SaaS then you frequently need to have different customers running on different releases for whatever reason (maybe one customer has a difficult data migration that has to take place before you can upgrade, maybe another customer has something custom that needs to be upgraded in sync).
  - cakes 10y ago
    Entirely agree. Sometimes it is a feature (and sometimes a curse). Even uptime is a good point for why you couldn't "upgrade everyone" together. At the same point if I were hosting something for a group of parties (at my own expense/will/etc.) and I want everyone to just be at version X.Y.Z - having to upgrade each deployment itself is definitely a pain. Not all software needs to be multi-tenant but it also isn't something that is no longer needed or without thought.
rpedela 10y ago
On the surface, you are right. However you often still need custom code to handle the business logic. If a new customer joins you have spin up a new instance. If a customer leaves then you have to delete the instance. How do you automate backup and restore? Is there a central repo for record keeping and how does that updated? Sometimes multi-tenancy is a simpler solution because no instance fleet management code needs to be written. With everything there are downsides to multi-tenancy too so you have to weigh the pros and cons for the specific project.
- Walkman 10y ago
  You are right. Without multitenancy, you have to write the automation code, however, it's much better IMO, because with multitenancy, you have to think about tenancy ALL THE TIME not just that one time. So I think overall it's a better trade off and still less code and less problems to solve and easier to solve.

by Walkman 10y ago

cakes 10y ago

Multi-tenancy solves some problems around maintenance and upgrade paths that are hugely beneficial when you are managing multiple deployments. If you have even more than just 1 deployment of a thing and scale to 2 (or N), you now also have to manage the software level of those N containers (without multi-tenancy) vs. just 1 deployment for everywhere.

mason55 10y ago
> If you have even more than just 1 deployment of a thing and scale to 2 (or N), you now also have to manage the software level of those N containers (without multi-tenancy) vs. just 1 deployment for everywhere. Sometimes this is a feature. If you're doing managed enterprise SaaS then you frequently need to have different customers running on different releases for whatever reason (maybe one customer has a difficult data migration that has to take place before you can upgrade, maybe another customer has something custom that needs to be upgraded in sync).
- cakes 10y ago
  Entirely agree. Sometimes it is a feature (and sometimes a curse). Even uptime is a good point for why you couldn't "upgrade everyone" together. At the same point if I were hosting something for a group of parties (at my own expense/will/etc.) and I want everyone to just be at version X.Y.Z - having to upgrade each deployment itself is definitely a pain. Not all software needs to be multi-tenant but it also isn't something that is no longer needed or without thought.

rpedela 10y ago

On the surface, you are right. However you often still need custom code to handle the business logic. If a new customer joins you have spin up a new instance. If a customer leaves then you have to delete the instance. How do you automate backup and restore? Is there a central repo for record keeping and how does that updated? Sometimes multi-tenancy is a simpler solution because no instance fleet management code needs to be written. With everything there are downsides to multi-tenancy too so you have to weigh the pros and cons for the specific project.

Walkman 10y ago
You are right. Without multitenancy, you have to write the automation code, however, it's much better IMO, because with multitenancy, you have to think about tenancy ALL THE TIME not just that one time. So I think overall it's a better trade off and still less code and less problems to solve and easier to solve.