To elaborate on patio11's point: I actually do spin up an ec2 instance per customer, and even then it's not really a relevant cost compared to the cost of acquiring customers.
Why would I do such a wasteful thing? It's totally not worth the engineering effort right now to switch to a more efficient multitenant architecture. Even a single new customer is worth more to me than I'd save in a year.
Twenty-first century rule of thumb: If the single-tenant architecture is the thing that you build first, because it's less effort, you should probably never bother with multi-tenant, unless a truly compelling rationale appears. VPSes are cheap and they will keep getting cheaper.
Multi-tenant is such a pain. Your customers become coupled on so many axes: Security, performance, downtime, resource management, versions of software in production, retirement of obsolete hardware. Everything one customer does effects others; you can't touch one customer's setup without potentially affecting others; if you try and coordinate the customers via email or phone, deadlocks will happen and progress will grind to a halt.
I worked on a product that launched multi-tenant and swiftly pivoted to single-tenant; it saved our bacon. Before that the support team was working overtime issuing lame apologies: "Uh, sorry about your lost sales due to slow performance; your
neighbor has no idea how SQL works."
Counter point to this was a recent client who is working to consolidate the seperate VPS' because the combined data of different clients is so much more valuable - insights About customer data even when gleaned from competitors is useful.
(Talking about terabytes of usage data in aggregate here btw). YMMV
Any rule of thumb as general as the one I proposed is bound to have exceptions. For one, when the tenants know each other and have formed a consortium to allow their data to be aggregated, it's not the kind of "multi-tenant" I had in mind. Now, instead of a bunch of independent renters, we have a condo association.
My first instinct in a situation like this would be to ask: "Why not build a separate data warehouse and have some worker processes copy the clients' usage data over there, in batches or in a stream, raw or pre-processed as you prefer? Then the data can be be indexed however you want and JOINed with wild abandon, without further perturbing the individual client systems and their existing, presumably working architecture." Isn't that the old-school IT way? Yeah, I know, terabytes, but a terabyte isn't as scary as it used to be. Of course, the devil is in the details and I'm sure there are reasons.
To be fair those were some of the to and fro arguments we had - mostly I think it came down to the pain of data transfer (by then it had moved three disks iirc). A Hadoop cluster was being built when I left. I guess I should catch up and see how it's going.
But yes - definitely not the typical SaaS use case
Comments
To elaborate on patio11's point: I actually do spin up an ec2 instance per customer, and even then it's not really a relevant cost compared to the cost of acquiring customers.
Why would I do such a wasteful thing? It's totally not worth the engineering effort right now to switch to a more efficient multitenant architecture. Even a single new customer is worth more to me than I'd save in a year.
Twenty-first century rule of thumb: If the single-tenant architecture is the thing that you build first, because it's less effort, you should probably never bother with multi-tenant, unless a truly compelling rationale appears. VPSes are cheap and they will keep getting cheaper.
Multi-tenant is such a pain. Your customers become coupled on so many axes: Security, performance, downtime, resource management, versions of software in production, retirement of obsolete hardware. Everything one customer does effects others; you can't touch one customer's setup without potentially affecting others; if you try and coordinate the customers via email or phone, deadlocks will happen and progress will grind to a halt.
I worked on a product that launched multi-tenant and swiftly pivoted to single-tenant; it saved our bacon. Before that the support team was working overtime issuing lame apologies: "Uh, sorry about your lost sales due to slow performance; your neighbor has no idea how SQL works."
Counter point to this was a recent client who is working to consolidate the seperate VPS' because the combined data of different clients is so much more valuable - insights About customer data even when gleaned from competitors is useful.
(Talking about terabytes of usage data in aggregate here btw). YMMV
Any rule of thumb as general as the one I proposed is bound to have exceptions. For one, when the tenants know each other and have formed a consortium to allow their data to be aggregated, it's not the kind of "multi-tenant" I had in mind. Now, instead of a bunch of independent renters, we have a condo association.
My first instinct in a situation like this would be to ask: "Why not build a separate data warehouse and have some worker processes copy the clients' usage data over there, in batches or in a stream, raw or pre-processed as you prefer? Then the data can be be indexed however you want and JOINed with wild abandon, without further perturbing the individual client systems and their existing, presumably working architecture." Isn't that the old-school IT way? Yeah, I know, terabytes, but a terabyte isn't as scary as it used to be. Of course, the devil is in the details and I'm sure there are reasons.
To be fair those were some of the to and fro arguments we had - mostly I think it came down to the pain of data transfer (by then it had moved three disks iirc). A Hadoop cluster was being built when I left. I guess I should catch up and see how it's going.
But yes - definitely not the typical SaaS use case