The last decade or so has seen a rapid move away from on-premise installed COTS products to cloud-based SAAS products. This shift has provided significant savings to their end users, partly due to the fact that the SAAS provider can take advantage of economies of scale brought by providing a service to many customers at once. The most common way SAAS companies achieve these economies of scale is by adopting a multi-tenancy approach to the design of the system.

With a multi-tenancy system, multiple customers are serviced by the same underlying software and machines, such as in this simple example:

To understand why this model can be more efficient, imagine that the above Accounts service is JVM-based. We pay a cost in terms of CPU and memory in starting the JVM and keeping it running. If each customer needs it's own JVM, we pay that cost multiple times. But if each customer runs on the same JVM, we only pay that per-JVM cost once, reducing the overall resource consumption.

When thinking more starkly about the cost of the underlying resources, going for larger machines can often more more efficient (to a point). This means that by scaling a service up onto larger hardware, the overall cost per customer may reduce, yielding more savings.

Multi-tenancy systems can be more vulnerable to some sorts of security breach. As all customer's data is co-located in the same service, then it is possible that one breach could access all customer's data. It may also be possible for a malicious party to issue a confused identify attack, where while logged on as one user, they attempt to trick the system into asking for data they shouldn't be able to. Multi-tenancy systems may require more complex security around authorization and authentication as a result.

Such systems may not be suitable for all workloads. For example you may have concerns about the security of individual customers data, and not like the fact that data for Customer A and Customer B live in the same system. If you have these concerns you should consider either a Hybrid Tenancy or Single Tenancy model.

Likewise it can be difficult to take existing applications designed for single tenancy on-premise installation to be converted for multi-tenancy. If the short-term play is simply to SAASify an existing product, then starting with a single tenancy approach may help you get to market more quickly, however it may be unlikely to lead to an efficient solution in the longer term. Depending on the economics of your particular business, you may need to move to multi-tenancy to achieve profitability, which is especially likely as many see some SAAS product categories as being in a race to the bottom.

See more patterns.