Multi-tenancy is an old concept that dates back to machine sharing. It got a new life with the rise of SaaS and the need to share infrastructure and databases across many tenants. Still, with the rise of lightweight virtualization, the idea of managing multi-tenancy with high code complexity has lost its appeal.
Modern multi-tenancy leans into the ease of allocating dedicated instances to customers, improving isolation, reducing the risk of data leaks, and making it trivial to charge a fair price based on use (instead of subsidizing the noisy neighbors with a volume of under-utilizers).
Watch the episode
You can watch the episode below, or read on to find some of the key discussion points.
Watch Continuous Delivery Office Hours Ep.7
Moving away from tenanted applications
There are 3 primary architectural approaches to multi-tenancy.
- A shared application instance and database: Many customers are using the same running instance, with the application taking care of isolating their use and data.
- A shared application instance and a dedicated database: While customers all use the same running instance, their data is stored in a dedicated database, which the application connects to based on the tenant.
- Fully isolated infrastructure: Every tenant has a dedicated instance and database running on an allocation of compute.
The shared approach comes with many drawbacks. The application’s code is more complex and requires more testing to reduce the risk of data being displayed to someone who shouldn’t see it. Having a dedicated database limits the complexity and risk to the mechanism that selects the appropriate connection string.
When tenants share application instances, databases, or database servers, one tenant can disrupt service for others, for example, by running a resource-intensive operation. It’s difficult to pinpoint where the increased load is coming from, and mechanisms for charging based on use often rely on proxy metrics that don’t reflect actual use.
With modern hosting options, like containers, it becomes far easier to achieve high resource use at the infrastructure level, removing the need for applications to be made tenant aware. You can avoid all the complexity by giving each tenant their own application and database.
If you have a customer with high resource needs, their use doesn’t slow down other customers or cause an outage. If they need a more powerful instance, they can pay to have one.
Shifting tenants to deployment-time
To make modern multi-tenancy work, you need to be able to deploy many more instances and apply the correct configuration when you do so. Modern CD tools take care of this, so you can share a single deployment process with hundreds or thousands of tenants.
When CD tools push a software version out, they can install tenant-specific instances by applying configuration variables. If you have 100 tenants, 3 environments, and 5 settings, the CD tool eliminates the need to manage 1,500 configuration files. They can also help you progressively roll out a new version based on tags so that customers can opt for early access or only the most stable versions.
Multi-tenancy has effectively shifted out of your code and is now managed by your deployment pipeline.
A tenant isn’t always a customer
We often think of tenants as “customers,” but they can just as easily be physical locations, like a hospital, restaurant, or retail store, that need a dedicated instance. Any time you need a dedicated instance, a tenanted deployment can provide it.
If you want to learn more, we also have a white paper on modern multi-tenancy available for download.
Happy deployments!
Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.
You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.
