Learn to love the multi-tenant cloud
- 25 November, 2021 05:00
Can customers trust the public cloud? The answer, of course, is yes. The public cloud is, in many ways, safer than their own data centre.
But doesn’t the fact that multiple customers share the same physical hardware create a safety concern? Isn’t any multi-tenant system inherently less secure?
What is multi-tenancy?
First, we should discuss what we mean by multi-tenant environments and what we mean by single-tenant environments. As you might suspect, the answer is not as clear-cut as it might seem.
Let’s take a look at a basic non-cloud application running in a data centre. Figure 1 shows such a system.
Here you see two customers, each running a distinct instance of an application on distinct and separate physical servers. The two servers may be in the same data centre, and share the same network infrastructure, but they don’t share any other physical resources.
Because they are both running distinct computer instances (with separate CPU, memory, and storage hardware), it’s very difficult, essentially impossible, for the information from the customer on the left side to interfere with the customer on the right side.
However, if users want to add a third customer to this set-up, they need a third instance of the application, and that requires purchasing and setting up a third physical server, with the appropriate hardware setup and software installed, updated, and configured.
Generally, adding a new customer is a task that is slow, cumbersome, and extremely expensive. On the plus side, customers are separated by physical hardware walls.
This is the single-tenant application model.
Compare the above single-tenant model to the model shown in Figure 2.
In Figure 2, users 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 multi-tenancy using server virtualisation, 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, they don’t need to set up a whole new physical server with the right hardware and software. All users 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, they 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 virtualisation 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 virtualisation 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 multi-tenant, 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 multi-tenant).
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 multi-tenant, virtual multi-tenant 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, users 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 multi-tenant safe?
Is single-tenant any safer than multi-tenant? 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 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 multi-tenant 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 multi-tenant 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 virtualisation 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 virtualisation that could have caused this type of exposure, but that flaw was quickly found and fixed.
In a true multi-tenant 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 virtualisation. In theory, a software bug could expose another customer’s data unexpectedly.
This is a risk users take. But in reality, when they 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 multi-tenant?
If single-tenant is theoretically safer than multi-tenant, why use multi-tenant at all?
First, as users can deduce from the above use cases, multi-tenant 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, set-up, configuration, maintenance, software, upgrades, etc.
By contrast, the incremental cost for a new customer in a true multi-tenant SaaS system is almost zero; on-boarding can literally be as easy as adding a single row to a database. Multi-tenant 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 multi-tenant system also makes it much easier to add resources to a running application when it must handle additional load. If an application requires a certain number of servers to handle the load, and users have a spike in traffic, what do they do?
For a system with virtual multi-tenant hardware, they 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, users need to plan for capacity months in advance. They have to guess what their needs will be, and they have to have enough excess capacity just “lying around” to satisfy any unusual or unexpected spikes they might have. This excess capacity is left idle most of the time, increasing application operating costs.
With a multi-tenant system, users can add additional capacity on the fly, only when needed, by spinning up more virtual servers. Because the hardware in a multi-tenant infrastructure is shared, the excess capacity is amortised out across multiple customers.
The future is multi-tenant
The future of modern applications is multi-tenant applications running in multi-tenant virtual environments on multi-tenant hardware environments.
Single-tenant applications will become fewer and farther between, and will be left mostly for on-premises data centre environments. The security concerns of multi-tenant systems are simply part of the overall security framework for all applications.
Multi-tenancy 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.