Does anyone have resources they recommend for architectures where 1 org --> multiple tenants makes sense vs. 1 org --> 1 tenant? Anyone have stories about going down one path only to realize it was the wrong one?

In the context of hosting a SaaS or PaaS product, such as Confluent Cloud? And what do you mean specifically by "org"...is that like an AWS Cloud account? Generally, if you can re-use physical resources (such as EC2 Instances, databases, etc) across multiple tenants, you reduce your physical cloud costs. If you can reuse accounts or virtual resources across tenants, you can reduce your management/operational overhead and architecture complexity. But both come at the price of less isolation for your customers, which many clients care about.

Nice question. I've seen both work. And like everything in engineering, if you go down the wrong route, you can always add another level of indirection. So companies that have "1 org == 1 tenant" end up adding "account with multiple orgs" to solve cases where they need a way to handle multiple related tenants. See: AWS with their Account/orgs change in the last few years.

The question needs a bit of clarification, is this about cloud provider accounts, identity provider user pools, silo vs pool deployments, or something else? In general, the pros and cons of pool (sharing resources amongst tenants) and silo (pool where n=1) apply regardless of where they're implemented. Pool scales better for ops/costs at the expense of complexity, silo is simple but has overhead at scale. The main takeaway is that you shouldn't lock yourself into one way. If you do pool now, then maybe silo in the future where customers (or architecture) demands, and vice versa. You're on a SaaS journey and your architecture will change through out.

Thanks for the responses everyone. Will try to clarify my question a bit.

I’ve worked with teams going in both directions: companies with pool deployments who need to build silo in order to sell to more demanding enterprise buyers; as well as companies who have saturated their enterprise market and need to build a pool or bridge model to reduce onboarding costs so they can open up the mid market.

Retweet 👆 Sometimes for very silo’ed on-premise installations it can make sense to get a systems integrator to help out so that you can focus on your core product. For example, there are many SI’s that specialize in setting up Salesforce.

I would strongly suggest against on-premises installations these days. Even the most previously cloud-phobic organisations are now happy to see a single-tenant deployment of a SaaS application, delivered into a single AWS account on their behalf.

On-prem can be a necessity (think manufacturing, or high-impact operations like security doors in a secure facility), so SaaS Anywhere/SaaS@Edge should be an option. Though, I'd avoid it unless there is a good business need.

I'm interpreting this to mean "don't run v1.0.0.0 in silo #1 and v2.0.0.0 in silo #2". Is that right?

Likewise, don’t be tempted to deploy unique versions of everything for every silo tenant

I'm interpreting this to mean "don't run v1.0.0.0 in silo #1 and v2.0.0.0 in silo #2". Is that right?

Exactly. A core tenet of SaaS is running a single version of the application across all tenants. Of course, you may have a deployment for new release testing, etc., but the core deployment is all the same deployment. Else, you're doing MSP (which has it's place).

I'm in the healthcare space and seeing (at least via indirect feedback from our Sales team) that LOTS of our customers want an on-premise option

Yes, on-premise or in-account (where the SaaS provider runs in the customer account, so they customer can get better discounts or count towards their EDP) is becoming more common. Adhering to customer security and networking standards can be challenging there.

Good point re SaaS vs MSP. Btw I love the correct usage of “tenet” and “tenant”, well done 👏