Staff+ Engineer in the SaaS World - The Multitenancy Spectrum

If you’re working in an organisation that delivers software using a SaaS business model, one of the words that dominates (not only) architectural discussions is “multitenancy” (the other is probably “operations”). That’s not surprising, because defining what your tenant is and how that tenant is reflected in your solution architecture is tied to all the important aspects of your product: what is the complexity of delivering features, what is the complexity of operations, what is the profitability. That’s why it’s important to understand the basics of the multitenancy spectrum before you enter the SaaS world as a staff+ engineer.

Let’s start at the beginning, what is a tenant?

What Is a Tenant?

Tenant is about how you want to conceptually define the isolation boundaries between the entities to which your product provides services.

When a product provides services to organisations, it’s quite common for the tenant to be the customer, with multiple users. But it doesn’t have to be that way. At a certain scale, organisations are often no longer homogeneous. They are still a single customer, but they may want isolation (and have different requirements) between departments or regions. In this case, a single customer becomes several different tenants. The need to provide multiple tenants to a single customer may also be a result of the nature of your product. For example, if it’s an integration-heavy solution, customers may require multiple tenants to treat them as development, test, and production environments from their perspective.

When a product provides services directly to the consumers, the tenant is often thought of in terms of as a single user. But this can also be a narrow way of thinking. What if the consumers are not just individuals, but also families, groups of friends, or some kind of association? Then your tenant will sometimes be a single user account, but sometimes it will be multiple.

Having the right understanding of what a tenant is in the case of your product is a necessary prerequisite for considering different tenancy models.

Tenancy Models

Different tenancy models are about how you share resources between your tenants. It’s a spectrum defined by two extremes.

The first extreme is the “share nothing” (fully isolated) tenancy model. It’s exactly what it sounds like - each tenant gets its own infrastructure. This means it has its own domain name, networking, compute, database, queues, and anything else you might have. It’s great from a privacy perspective, as the risk of accidental data leakage between tenants is minimised. It also usually comes with a better performance promise, as there are more options to make the infrastructure “big enough” for specific customers, and there is no impact from other tenants (the legendary “noisy neighbours”). This model also allows you to have unique versions of your product for specific tenants. But all this comes at a price, and I mean price in the literal sense of cost. Having multiple isolated deployments of the entire infrastructure (especially if some deployments are highly customised) quickly becomes a costly challenge from an operations perspective (it requires an ever growing, highly skilled operations team). There’s also no way to take advantage of economies of scale because tenants don't reuse anything. Which brings us to the other extreme.

At the other end of the tenancy models spectrum is the “share everything” (fully shared) model. And it’s the exact opposite of the previous model. Here, your tenants share all the infrastructure resources. This allows infrastructure costs to be minimised by provisioning only what is needed. With the right design, it also allows unit costs to fall as the number of customers grows. It also simplifies the operations because the environment and application are now unified. This means that all the heavy lifting in terms of isolation and customisation now falls on the application code. It’s the code’s responsibility to properly manage identities and prevent data leakage. It’s also the code’s responsibility to handle customisation through per-tenant configuration and feature flags. And that unit cost, which is supposed to come down as the number of customers grows, will eventually be challenged at some point by certain customers eating up all the resources and starving others. This is why every mature product tends to end up somewhere on the spectrum between these two extremes.

Yes, regardless of where your product starts its SaaS journey, it will most likely evolve into a mix of shared and dedicated resources. However, the journey has to start somewhere.

Choosing a Tenancy Model

The first aspect that will affect your choice of tenancy model, is the history of your product. If you’re moving an existing product to the SaaS business model, you’ll probably need to start at the “share nothing” end of the spectrum, as the application code will lack the isolation mechanisms (although there may be specific cases, usually in the B2C space, where this is not the case). If your context is startup, the “share everything” approach is more likely.

In general, it is often more advantageous to start with “share everything”. If your product is designed to share all its resources, it’s easier to evolve it into more isolated models than the other way around. But a product that can share all its infrastructure is harder to design and implement properly. It’s going to be an investment and it’s important to consider whether there are aspects that will prevent a return on that investment.

The “share everything” model may not be a viable option if you're targeting the B2E space. The enterprise customer will often be too large, or simply will not accept sharing infrastructure with others. This will force you to start closer to the “share nothing” extreme and look for opportunities to share something to minimise the costs (perhaps the user interface tier). There may also be compliance or privacy requirements (in case of both B2E and B2C) that will force the data tier to be dedicated, but depending on the legal details, they may allow the application and user interface tiers to be fully shared.

Properly defining your tenant, understanding your business objectives, and the nature of your customers will enable you to find the right place on the multitenancy spectrum.