Cloud Multitenancy: More than Meets the Eye

One of the most important characteristics of Public Clouds is multitenancy. Put multiple customers on the same physical infrastructure, sharing the same application. Establish appropriate security measures so that they can’t interfere with each other, or snoop on the other’s data. Presto! Cost savings, efficiency, and scalability are yours!

The good news is, multitenancy is one of the key enablers of the Public Cloud value proposition. But of course, there’s more to multitenancy than meets the eye. There are actually different degrees of multitenancy, with different advantages and disadvantages. And as you might expect, there’s plenty of vendor hype as well. As a result, understanding the various degrees of multitenancy is essential for understanding what you’re paying for when you use a Public Cloud.

First Degree Multitenancy: Shared Schema Approach

With the shared schema approach, all customers share all tiers of the Software-as-a-Service (SaaS) application: presentation, processing tier, and the underlying database. In fact, each table of the underlying database would typically contain data for each SaaS customer. The app keeps these data separate via a customer number or other unique identifier that every table would have to contain.

The advantages of the shared schema approach include:

Simple updates – since there is essentially only the single SaaS application, any application updates automatically apply to every customer at the same time. No configuration differences, no branching code.
Supports social capabilities, analysis, targeted marketing, etc. – the app vendor can easily support any application capabilities that require queries across multiple customers, since all customer data are in the same tables. As a result, building any kind of cross-customer capability, like collaboration or social networking, is straightforward. It’s also simple for the app vendor to analyze information across their customer base.
Simple to manage – simple to update means simple to manage, as there will only be one version in production at any time.
Simple integration with back-end infrastructure – identity management, backups, and other back-end capabilities are straightforward to implement.

The disadvantages of the shared schema approach include:

The vendor must architect the application for multitenancy. Moving a single-tenant app to the Cloud won’t give you first degree multitenancy without a lot of rework.
Relatively vulnerable to certain attacks like SQL injection, etc. – since your data are in the same tables as everyone else’s, any attack that exposes other rows in the tables you can access have a chance of succeeding. Make sure your SaaS provider has addressed these isssues.

Requirements for scaling out a shared schema-based application:

Some vendors deploy duplicate stacks – essentially, they run identical application instances (including all tiers) for different customer segments. As long as the vendor is careful to insure that each application instance is identical, they are still able to achieve the benefits of the shared schema approach. However, this approach does not improve the app’s fault tolerance; if one stack goes down, then all customers on that stack are affected.
Segment the database by customer – instead of every customer putting their data into every table, segment or “shard” the database into multiple database instances, each supporting a different customer segment. Scale out the other tiers as well. This approach provides the greatest fault tolerance but is more difficult to manage than the duplicate stack approach.
Individual infrastructure elements (processors, storage, etc.) can take advantage of the elastic provisioning capabilities of the Cloud.

Second Degree Multitenancy: The Clustered Shared Schema Approach

With the clustered shared schema approach, the SaaS vendor intentionally segments customers onto different application instances running on separate stacks, where the instances are generally not identical to each other.

The advantages of the clustered shared schema approach:

More customer choice – the vendor configures each cluster according to customer requirements, instead of the “one size fits all” limitation of the shared schema approach.
Allows for round robin updates – instead of updating every app instance at once, the vendor can rotate their updates, which requires a smaller administration team.

The disadvantages of the clustered shared schema approach:

Increased maintenance complexity – the vendor may have multiple different versions of their app in production at once, with different release cycles or the potential of branching code. As a result, management is more complicated than the shared schema approach.
Collaboration and analysis across clusters is problematic – any capability that requires data from multiple clusters requires data integration that can deal with the different application versions in each cluster.

Requirements for scaling out the clustered shared schema approach:

Add new clusters – essentially, scalability is built in, because adding new clusters is straightforward.
Individual infrastructure elements (processors, storage, etc.) can take advantage of the elastic provisioning of the Cloud, as with the shared schema approach.

Isolated tenancy approach (sometimes called megatenancy)

Every customer has their own application instance, as though they were running the app on their internal infrastructure. But since the applications are running in the Cloud, the customer is none the wiser—at least in theory.

The advantages of the isolated tenancy approach include:

Maximum customer choice – every customer gets the configuration they want, and the vendor can apply new releases or customizations on the schedule each customer desires.
Minimal rearchitecting of the original app – if the vendor is trying to take an existing application they designed for on-premise installations and move it to the cloud, the isolated tenancy approach requires minimal changes to the internal architecture of the app.

The disadvantages of the isolated tenancy approach include:

Highest management complexity – since every customer has unique configuration, the vendor must manage every application instance as a separate, distinct application, since after all, that’s what they are.
Most expensive – management, integration, updates, customer support, etc. all cost more. With isolated tenancy you lose any cost savings benefits the Cloud might have provided.
Lack of vendor commitment – vendors typically offer isolated tenancy because they’re rushing to offer a SaaS version of their app, and they don’t have the time, money, or will to rearchitect it for the Cloud. But since it’s such a hassle to support, as soon as one of the other approaches is viable, they’ll want to move their customers to it. Then again, they may not wait. They may simply change their mind about supporting the app altogether, leaving customers in the lurch.

Requirements for scaling out the isolated tenancy approach:

Add more application instances – in other words, add more stacks, each of which supports an application instance.
Individual infrastructure elements (processors, storage, etc.) may or may not be able to take advantage of the elastic provisioning of the Cloud, depending on the architecture of the application. In other words, the isolated tenancy approach may not really be SaaS at all. It may simply be a hosted provider model masquerading as SaaS.

The ZapThink Take

The moral of this story, of course, is caveat emptor: let the buyer beware. Not all SaaS offerings have the same type of multitenancy, and each approach has its advantages and disadvantages. And as with all IT decisions, do your homework to make sure your vendor isn’t trying to pull the wool over your eyes.

It’s also important to take the lessons of this ZapFlash to heart when you are planning a Private Cloud. You might think that since Private Clouds are inherently single tenant that you don’t need to worry about multitenancy. Architecturally speaking, however, there may be advantages to a multitenant approach even in a Private Cloud, where instead of multiple customers, you consider multiple users or user types.

Taking a shared schema approach to a Private Cloud can reduce your costs relative to the other approaches, but will give you more of a “one size fits all” set of applications. Ignore the best practices of multitenancy, however, at your peril, as you may not achieve the cost savings and efficiency benefits that led you to consider a Private Cloud in the first place.