Learn to love the multitenant cloud

In Figure 2, you have the same two distinct customers using two distinct instances of an application. But, in this case, they are each running on two separate virtual servers, which are in fact on the same physical server. This is an example of multitenancy using server virtualization, which has been in use since the late ’80s and early ’90s. The idea is that each application resides on a separate “logical” server, but the two virtual servers reside on the same physical hardware.

This model improves the ability to port applications and move software around more easily than the single-tenant model. Now, when a new customer comes on board, you don’t need to set up a whole new physical server with the right hardware and software. All you need to do is launch a new instance of a virtual server. This is a simple command or API call, and is typically easy to do. As long as the physical server has enough capacity, you could launch multiple virtual servers with a simple API call. New hardware is necessary only when additional physical resources are required.

In fact, this model is so powerful that it was the basis for the start of cloud computing. Server virtualization allowed cloud providers to sell virtual server instances directly to companies, and enable them to start and stop instances on demand. This was the basis for the EC2 service in AWS, and eventually equivalent services in Microsoft Azure, Google Cloud Platform, and other public clouds. New instances can be leased to customers for a period of time, and then freed up to be made available for other companies to use.

Customers are separated by virtual hardware walls. These are walls that look like hardware walls, but are simulated by virtualization software. And while adding customers is easier, it still requires launching new virtual server instances, which does consume resources.

This model is called the physical multitenant, virtual single-tenant model. The name comes from the fact that each virtual instance is assigned to a single customer with their own instance of software (virtual single-tenant), while the virtual instances all run on shared physical hardware (physical multitenant).

Multitenant software

Now, compare the two models above to Figure 3.

In this model, multiple customers share the same application instance, all running on the same physical servers and the same physical infrastructure. In this case, the software is providing the separation of one customer from another—there is no physical separation. Customers are separated only by software.

This model is called the physical multitenant, virtual multitenant model. It’s better known as the software as a service (SaaS) model.

In this case, adding a new customer is very easy. No virtual or physical hardware is required. As long as the underlying hardware has sufficient resources, you can add an additional customer simply by updating a database, or adding an entry to a configuration file. New customer addition is quick, easy, and inexpensive.

Is multitenant safe?

Is single-tenant any safer than multitenant? This is a common question and a tough question to answer. Both models can be safe and both can be unsafe. When it comes to bad actors—bad people trying to attack your software, one model is as safe as the other model. They both need secure processes and procedures in place to protect against bad actors.

But what about accidental security vulnerabilities? What about, for instance, accidentally exposing data from one customer to another customer? Certainly, a poorly designed multitenant SaaS application does risk data exposure to other consumers who use the same shared environment.

To see this, take a look at Figure 4.

Let’s first look at a true single-tenant application, such as shown in the upper-left side of Figure 4. In order for a customer’s data to be accidentally exposed to another customer, the data has to move between physical servers. This isn’t easy, and it’s hard to imagine how this could happen accidentally. A single-tenant system is less likely to have accidental security problems.

Now let’s look at the virtual server multitenant application, such as shown in the upper right side of Figure 4. In order for data to be accidentally exposed in this model, the data has to traverse a strong virtualization border. While it’s hard to imagine this happening, it isn’t impossible. In fact, a few years ago, the Meltdown and Spectre vulnerabilities exposed a flaw in server virtualization that could have caused this type of exposure, but that flaw was quickly found and fixed.

In a true multitenant application—a SaaS application—such as shown in the bottom of Figure 4, there is a greater chance that a software error could expose data between customers. This is because the separation between customers exists entirely in the application layer, with no separation in the underlying hardware or virtualization. In theory, a software bug could expose another customer’s data unexpectedly.

This is a risk you take. But in reality, when you are using high-quality SaaS applications from reputable companies, this risk is not as big as it might appear. Certainly, any vulnerabilities involved with accidental data exposure across tenants would be fixed very quickly. Lots of attention is given to this specific issue. But it is a concern that customers should consider when they select a SaaS company and decide what data to give to them.

Why use multitenant?

If single-tenant is theoretically safer than multitenant, why use multitenant at all?

First, as you can deduce from the above use cases, multitenant systems are easier to expand and make it easier to add new customers. The incremental cost of adding a new customer in a single-tenant system is very high, as it includes the cost of new hardware, setup, configuration, maintenance, software, upgrades, etc. By contrast, the incremental cost for a new customer in a true multitenant SaaS system is almost zero; on-boarding can literally be as easy as adding a single row to a database. Multitenant SaaS systems allow providers to build “try before you buy” functionality into their applications, and to implement truly free tiers while still maintaining profitability. This is virtually impossible in a full single-tenant application and hardware.

A multitenant system also makes it much easier to add resources to a running application when it must handle additional load. If your application requires a certain number of servers to handle the load, and you have a spike in traffic, what do you do? For a system with virtual multitenant hardware, you can easily add additional server capacity on the fly—within seconds. For a true single-tenant application, it may take days or weeks to purchase, install, and configure physical servers.

Because it takes so long to increase capacity in a single-tenant application, you need to plan for capacity months in advance. You have to guess what your needs will be, and you have to have enough excess capacity just “lying around” to satisfy any unusual or unexpected spikes you might have. This excess capacity is left idle most of the time, increasing your application operating costs.

With a multitenant system, you can add additional capacity on the fly, only when needed, by spinning up more virtual servers. Because the hardware in a multitenant infrastructure is shared, the excess capacity is amortized out across multiple customers.

The future is multitenant

The future of modern applications is multitenant applications running in multitenant virtual environments on multitenant hardware environments. Single-tenant applications will become fewer and farther between, and will be left mostly for on-premises data center environments. The security concerns of multitenant systems are simply part of the overall security framework for all applications.

multitenancy is the basis of the public cloud. It is the backbone of all major production operating environments, and it is defining how applications are built and deployed now and in the future.