Cloud architecture: The end of multi-tenancy?

Multi-tenant systems are a common pattern in enterprise software. Multi-tenant systems are designed to provide every tenant a dedicated share of a single system instance (Wikipedia). The key benefit of a multi tenant system is the immediacy of a new (logical) customer instance. In a sense, it's a bit like an apartment building: you don't need to build a new building for each new tenant, but rather house many tenants in a single building, aided by common infrastructure like hallways and shared plumbing.

No Software

In the recent world of IT, the company whose success was most directly based on a multi-tenant architecture was Salesforce. Salesforce employed a Software-as-a-Service model well before it became a popular term for cloud computing platforms. Essentially, Salesforce ran a large database that it segregated by customer. The model proved enormously successful, aided by an effective "no software" marketing campaign that capitalized on enterprises' belief (and often experience) that software takes a long time to deploy and causes all sorts of problems along the way. Instead, Salesforce could sign up new customers almost instantaneously.

Challenges

While multi tenant systems have apparent advantages for customers, they pose several architectural challenges. To make a single system appear like a set of individual systems, data, configuration, as well as non-functional characteristics, such as performance, have to be isolated between the tenants. This isolation introduces complexity into the application and the database schema, for example by propagating the tenant identity through the code and data.

Recent advantages in computing infrastructure allow us to have a fresh look at this type of architecture. Oddly, the path to insight leads past water fowl...

Duck Architecture

The object-oriented world has a notion of "duck typing", which indicates that instead of classifying an object by a global type hierarchy, it's classified by its observable behavior. So, instead of defining a duck as being a waterfowl, which is bird, which in turn is part of the animal kingdom, you define a duck by its behavior: if it quacks like a duck and walks like a duck, it's considered a duck.

In software design this means that the internal make-up or type hierarchy of a class takes a back seat to the object's observable behavior: if an object has a method to get the current time, perhaps it's a Clock object.

Let's apply the same notion of typing by behavior to a large-scale system architecture. We can then get a fresh look at multi-tenancy, which is traditionally considered an architectural property of a system that describes how it's constructed, e.g. by segmenting database and configuration by user. Following the "duck-like" logic, multi-tenancy should be an observable property, i.e. if a system is able to create new and isolated user instances virtually instantaneously, it could be considered multi-tenant capable.

Structure follows Behavior

If we go with the latter point of view, we can accept that the purpose of a system's architecture is to exhibit specific set of observable behaviors, meaning it's structure is driven by desirable behavior. Following this logic, once we see a system structure we are bound to ask why the structure is that specific way, which is one of the most important questions to ask of any architecture. 

Revisiting Constraints

Asking the "why" of architecture is particularly useful because specific constraints that have shaped architectural decisions may have changed or disappeared, perhaps invalidating the motivation for past architectural decisions. 

In the case of multi-tenant systems, the key constraint driving the design is that instantiating a new system instance is a complex and time consuming process. This implies that if you want to give independent users near-instant access to their own logical instance, you need to build a system that's based on a single existing instance, but is logically segmented into seemingly isolated instances. Such a system doesn't have to create a new instance for each new customer and can therefore setup new customers easily.

A secondary constraint is that having many separate system instances on separate virtual or physical machines is inefficient. Each instance carries the overhead of an operating system, storage, monitoring etc., which would be duplicated many times, wasting compute and storage resources.

Enter Cloud Computing 

I previously stated that Cloud computing is not (only) an infrastructure topic: it is as much about software delivery and automation as it is about run-time infrastructure. And this aspect of automation is the one that allows us to question multi-tenancy as a structural system property. Thanks to cloud automation, deploying and configuring new systems instances and databases has become quite easy and fast. A system can therefore exhibit the properties of a multi-tenant system simply by creating new instances and thus avoid the complexity of a multi-tenant architecture. So, it behaves like a multi-tenant system (remember the duck?) without it being a structural property.

Additionally, container technology significantly reduces the overhead associated with each individual instance because it doesn't duplicate the complete operating system for each instance. It's also easier to manage many instances thanks to Container Orchestration like Kubernetes. It's not uncommon to run several thousand container instances on a Kubernetes Cluster. Therefore, the second major architecture constraint can also be addressed.

In combination, this means that cloud automation and containers allow a traditional system with a multi-tenant architecture to be replaced with a multi-single-tenant system, which exhibits comparable properties but follows a much simpler application architecture. Naturally, a cloud run-time also follows a multi-tenant design by isolating containers from each other, but that complexity has been absorbed by the cloud provider so there's no reason to reinvent it for each application.

Efficient Single Family Homes

To (ab)use the building metaphor from the beginning, cloud computing allows us to move away from apartment buildings into easily replicated and efficient single-family homes: they are easier to build and each tenant gets its own building. Luckily we can do this quite efficiently in cloud computing as compared to the real world, so we don't have to worry about urban sprawl.

Like what you read?

If you like what you read, please share with your network. You can find more thoughts and anecdotes about IT Transformation on my new site ArchitectElevator.com and in my book 37 Things One Architect Knows About IT Transformation.