If there's one common issue that all SaaS companies face, it's isolation. How are customers and their data logically separated from each other? Well, there's no one answer. And best practices are rapidly changing as companies are becoming more cloud native.
A tour of the most common SaaS isolation deployment patterns.
Single-tenant account, full-stack isolation.
The provider sets up a separate cloud account for each customer. The cloud account runs an entirely isolated and dedicated software stack, just for that customer. The data company dbt offers a solution like this for its enterprise customers.
Benefits:
- Easy to calculate costs per tenant
- Compliance concerns. It is usually easier to spin up a new account than get security clearance to integrate or move data into an existing production environment.
Drawbacks
- Difficult to scale to a large number of customers. Especially when each customer may have dozens of accounts.
- Customers can be running vastly different versions of your software, as well as different versions of cloud infrastructure and APIs. This can make it difficult to ship new features, and slow teams down with the need to support legacy features.
- Hard to track and collect metrics across a variety of accounts.
Single-tenant VPC, network-defined isolation.
The next model is similar to the first but uses network-defined isolation by using a separate VPC for each account.
- Large customers can still exhaust region-wide quotas for your cloud environments. Slightly easier to manage in a single account.
- Same drawbacks as the account-based isolation, but allows for slightly more product velocity.
You can also theoretically apply this model at the subnet level, but I haven't seen any startups do that.
Single-tenant, service-level isolation.
I'm not sure if there's a term for this, so I'll call this hybrid mode bridged. It's simply applying either the single-tenant account or VPC isolation at the service level. That means you have an architecture where some components might be shared across tenants, such as the frontend, but each tenant has dedicated application and database isolation.
Multi-tenant, private.
Multi-tenant with hard infrastructure connections is a new model popularized by Snowflake. The application itself is multi-tenant, running on shared resources, but allows for private connections between the provider and customer or customer and other customers.
This is available through AWS or Azure Private Link. Combined with VPC Peering, it allows accounts to talk to each other directly without going over the internet.
For Snowflake, this is done so that customers can share their data warehouses securely.
But I think it's an exciting model for infrastructure companies to offer their customers, who might have security concerns accessing SaaS services over the internet.
Multi-tenant, application-level isolation.
Finally, there's the true SaaS model of multi-tenant. Isolation is done through code, through some sort of identity access management system. There still may be some infrastructure related safeguards in place, but it all takes place inside the SaaS provider's own accounts and VPCs.
Some other considerations ...
Isolation runs counter to velocity. Duplication of stacks means that customers can stay on old versions longer. Testing, feature development, and account management all become more complicated as isolation increases. Yet, isolation is and will remain an important buying consideration for SaaS purchasers.
The landscape is changing,, and startups stuck with sub-optimal deployment patterns will have difficulty scaling. Maybe there's enough money to fix issues at scale, but tricky isolation patterns are notoriously difficult to fix at any point.
My bet is that we'll trend towards application-level isolation patterns. After all, VPCs are virtual private clouds. The network is the obvious place to start isolation, but it doesn't end there.