Multi-tenancy vs Single Tenancy
Posted on May 5 2015
Previously, I spoke about a project some of my colleagues are working on, codenamed Asterix. The team are re-implementing a subset of functionality of an existing product on a new platform to create a cloud-based SAAS product. In my last post on the project I talked the thinking that was going on as to whether or not microservices make sense for Asterix, which is ostensibly a greenfield project. One of the things I didn't cover at the time was how decisions about how fine-grained to make your architecture can play into whether or not you go for a multi-tenant or single-tenant setup.
With a full Single Tenancy model, each customer runs on their copy of the system, with their own copies of the processes. The more customers you have, the more copies of the processes you need to manage. The more moving parts your system has, the more processes you'll need for each customer. This can be a reason against having finer-grained architectures - as the more fine-grained you go, the more processes per customer you need to manage. And those processes all need to run somewhere.
Most products, when moving from a traditional download model to a SAAS product offering, end up going with some flavor of multi-tenancy setup. The reason is efficiency. You can support more customers on fewer nodes, and fewer nodes means reduced cost. A single client setup might require lower-powered machines, but with more customers, you can provision higher-powered machines, which tend on the whole to provide more resources (CPU, Memory, IO) per $. A fully multi-tenant setup is more amenable to a microservice architecture than a single-tenant setup as the operational maintenance overhead doesn't scale linearly with customers. But they also allow you to scale individual parts of the system independently, allowing for a more cost-effective scaling too.
Containers have shifted things a bit. More than one SAAS provider has used containers in order to segment individual customers on their own instance of a particular service. Containers allow you to more densely pack isolated operating systems onto larger machines (which may themselves be virtual), albeit in a much cheaper way than standard virtualisation allows. The flip side is that you still have lots of processes running - those processes need to be managed just like any other, and now you have the added complexity of handling the container system itself, all of which have their challenges.
Containers can more easily open up hybrid models , where you might mix multi-tenant services with single-tenant isolated containers. It's far too easy to tell if that's a model that makes sense for Asterix. One aspect where this might come into play is that of data privacy. The issue is that a container-based model to isolate customer data can be problematic depending on the threat model, as most containers cannot be considered to be fully isolated.
Currently, the assumption is that Asterix will be using a standard multi-tenant model, but once we know more about the non-functionals regarding customer data the team may need to look at other options.
I've captured some patterns associated with these ideas, which I'll continue to update over time:
You can find other patterns over in their own section on the site.
Back to Blog.