All About Multi-Tenancy: Part 1

This is the first post in the series “All About Multi-Tenancy.” Here, I plan to share with you many of my thoughts about multi-tenancy that stem from several years of research and practical experience implementing multi-tenant, cloud-based application and platform designs.

My Background with Multi-Tenancy

Before reading this series, it might be useful to understand a little about my experiences with multi-tenancy.

• As a contributor to the Oracle Technology Network, I wrote a lengthy tutorial that shows the reader how to build a simple metadata-driven, multi-tenant application using Oracle Application Express and Oracle Database.
• While CTO/Architect of SaaS at CSC, I designed a straightforward, virtualization-based cloud architecture that the company could use to easily SaaS-enable existing single-tenant applications. Unfortunately, the project was a bit ahead of its time, lost funding, and I moved on.
• While Director of SaaS Technology at BEA Systems, I conceived, built, and benchmarked a high-performance, scalable, database-portable multi-tenant database tier for BEA’s Genesis SaaS platform. The design was particularly interesting in that it obfuscated multi-tenant data structures from the application, thus allowing for traditional application development and turnkey migration from single-tenancy to multi-tenancy.
• As an independent contractor, I researched and worked with Salesforce.com’s CTO to write a technical white paper and DreamForce presentation that explains the internal plumbing of the Force.com multi-tenant, Internet application platform architecture.

Who Should Read This?

People that fall into the following categories will be most interested in this series of posts.

• You are an experienced software developer or architect.
• You understand how to build traditional single-tenant applications.
• You need to understand how to build cloud computing applications.
• You know that multi-tenancy is an important concept to understand and consider as you learn how to build cloud-based apps.
• You have cursory knowledge about multi-tenancy, but not a deep, practical understanding of how to implement multi-tenancy in applications.

Today’s Topics

Every post in this series will have two or three primary topics of discussion. The first few posts in the series will be conceptual introductions to topics surrounding multi-tenancy. Subsequent posts will be more hands-on, technical posts that show how to design and build multi-tenant software.

In today’s introductory post, the questions I’ll be addressing include:

• What initial terms must I understand to begin learning about multi-tenancy?
• Why is multi-tenancy relevant to cloud computing?
• What levels of system architecture can be multi-tenant?

Basic Terms Related to Multi-Tenancy

To start, let’s all get on the same page by defining some key terms.

• single-tenancy and single-tenant applications
• multi-tenancy and multi-tenant applications

Single-Tenant Applications

Single-tenancy is a situation where a single user or set of related users makes use of a dedicated resource. The long-standing analogy for single-tenancy is the relationship between a homeowner and their single-residence house. Homeowners can customize their house and yard to their liking, enjoy their privacy, etc. However, the homeowners are solely responsible for maintaining their property, paying for all costs related to the house, etc.

Single-tenancy is a situation where a single user or set of related users makes use of a dedicated resource.

Traditional on-premise software applications are single-tenant applications. For example, in your home, you might purchase and install an office application suite such as Microsoft Office for your PC or Mac. You are the only one that uses this instance of the app. In the enterprise, data center personnel might purchase, install, and configure a customer relationship management (CRM) application such as Oracle Siebel CRM on dedicated servers in the company’s data center. The company is the only one using this instance of the app.

Some people consider the following items as benefits of single-tenant applications:

• You can customize the app to meet your specific needs, often without limitation.
• You can feel secure that no one else can access the data that the application maintains because the application executes on your dedicated machine(s) behind a firewall.
• You can control everything related to the application, including the maintenance schedule, backups, etc.

Conversely, the following items are some drawbacks to the use of single-tenant applications.

• You must learn how to install and configure the application for yourself. With PC software, this is usually not much of a concern. However, with enterprise software such as Oracle, it is expensive to hire and train a staff of administrators to manage operating systems, databases, application servers, and web servers.
• Once installed, you have to maintain the application yourself. Software maintenance includes tasks such as the installation of software updates and patches. Again, this can be a complex, time-consuming, and expensive proposition for enterprise software.
• You are responsible for backing up your data, and recovering it when problems arise. Again, think money for the enterprise.
• The unused CPU cycles, dedicated storage space, and power necessary to keep the application up-and-running go wasted, money down the drain that you’ll never recover.

Multi-Tenant Applications

Multi-tenancy is a situation where many users, typically unrelated, make use of a shared resource. Continuing with our previous analogy, you can easily think of multi-tenancy by considering the relationship between an apartment building and its tenants. In the apartment building, each tenant can customize their own apartment to a certain degree and feel secure behind their door. Because the building owner can distribute the costs of property maintenance among its tenants, the owner can keep rents reasonable for the tenants while still making a profit.

Multi-tenancy is a situation where many users, typically unrelated, make use of a shared resource.

Many modern, commercial, on-demand applications are multi-tenant applications. A multi-tenant, web-based application serves the needs of multiple application users. For example:

• In the home, you might access Google Apps using a web-browser for your word processing, spreadsheet, and presentation software needs. At the same time, many other people around the world are also using Google Apps to do their work, all without ever having to download, install, and maintain applications and data.
• In the enterprise, you might use the web-based Salesforce CRM application for customer relationship management requirements. At the same time, other companies are also using the very same Salesforce CRM application instance for business purposes, again, without having to maintain applications and data for themselves.

From the application provider’s perspective, the benefits of multi-tenancy mostly relate to operational and cost efficiencies. That’s because one instance of the application can meet the needs of many tenants/customers, thus allowing consolidation of system administration tasks such as monitoring, performance tuning, software maintenance, and data backups. The key drawback of multi-tenancy is that application providers must learn and implement new design patterns that are very complex. This process can retard the timeliness of software releases and introduce problems that affect not just one, but all tenants using an on-demand service.

Should users of applications care if an application is multi-tenant? The answer depends on the quality of the application design. The answer would be “no” when the design of a multi-tenant application meets the following conditions.

• The application scales and continues to perform well as the user population grows.
• The work of one tenant does not adversely affect the work of other tenants.
• Each tenant can customize the application to meet their requirements.
• The application maintains the security and privacy of each tenant’s data, even though multiple tenants share one or more system resources such as database, application, and web servers.

However, when any of the above conditions are not met, application users would definitely become disenchanted with the fact the application is multi-tenant.

Multi-Tenancy and Cloud Computing

Assuming we think that Amazon Web Services (AWS), Force.com, Google App Engine, Microsoft Azure, and others like them are “clouds,” then I cannot think of a cloud computing application that is not multi-tenant at some level. You might not agree unless you understand how I view the different levels at which multi-tenancy can take place in the stack of a software system’s architecture. And with this thought in mind …

Extreme Multi-Tenant Designs

… allow me to explain how I look at things by introducing two different extremes that I consider as multi-tenant.

Virtual Multi-Tenancy

The first extreme multi-tenant design is what I refer to as virtual multi-tenancy. This design happens whenever virtualization is at the foundation of the system architecture. In this scenario, I consider applications multi-tenant that concurrently execute within virtual machine (VMs) on top of the same virtual infrastructure.

Virtual multi-tenancy exists whenever virtualization is at the foundation of the system architecture.

To illustrate virtual multi-tenancy, consider the following example applications that use Amazon Web Services (AWS).

Now some readers will no doubt argue with me that this architecture is not multi-tenant. However, I see this as multi-tenant at two different levels in the stack.

• Each AMI shares CPU resources made available by Amazon EC2.
• Each AMI shares storage device resources made available by Amazon S3.

If you still don’t agree with me that that the above applications are multi-tenant, consider the following scenario. Suppose that the virtualization layer doesn’t do its job correctly in managing shared resources – for example, a security hole in the virtualization software allows nefarious types to gain access to data inside VMs they do not own. From a tenant’s perspective, how is this problem any different than data leakage in a multi-tenant architecture that shares a deeper resource such as a database?

Organic Multi-Tenancy

The other extreme design is what I refer to as organic multi-tenancy, a design in which every component within the system architecture of a single software instance is shared among all tenants. By every component, I mean the hardware, the operating systems, the database, the database schema, the tables within the database schema, the database servers, the application servers, the web servers, the load balancers, the firewalls, etc. I use the description organic because this design, unlike with virtual mult-tenancy, requires software developers to explicitly consider multi-tenant design patterns and code them into the application.

Organic muli-tenancy exists whenever developers explicitly consider and code multi-tenant design patterns into the fabric of an application.

To illustrate organic multi-tenancy, consider the following application that uses Force.com.

Which multi-tenant application design is better? I’m cringing as I write this because there are many people out there reading this right now that I know have strong opinions one way or the other. I’m flexible because there are advantages and disadvantages to both extremes.

• Virtual multi-tenancy allows you to easily SaaS-ify an existing single-tenant application will very little work because a minimal amount of application redesign is necessary. And with virtual multi-tenancy, a instance outage affects only the tenant using that particular VM. However, as the user population grows for the application, management of individual VMs will become more and more cumbersome. Also, virtual multi-tenancy is not the most cost-efficient approach due to the overhead required for each additional VM.
• In the long run, organic multi-tenancy is the most operationally efficient and cost-efficient approach for new applications. However, a failure in the system affects all tenants. And learning how to build organic multi-tenant applications has proved difficult for many firms, which this series of posts is meant to help alleviate.

In conclusion, based on my experience implementing solutions for clients and talking with many other colleagues and SaaS vendors, I know for a fact that both extreme designs work effectively when utilized in the appropriate situation. I discuss more about this can of worms later in the series.

Both virtual and organic multi-tenant designs work effectively when utilized in the appropriate situation.

Additional Reading

If you want to read more about multi-tenancy concepts from a different source, take a look at these links:

• June 2006 post on MSDN, Multi-Tenant Data Architecture
• May 2009 post on IBM developerWorks, Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 2: Approaches for enabling multi-tenancy

What’s Next?

I hope you enjoyed this first post on multi-tenancy. Hopefully you have a better understanding of some key terms surrounding multi-tenancy, understand the benefits of multi-tenancy, and how multi-tenancy relates to cloud computing. Please come back soon for my next post in this series, which dives deeper into some concepts about multi-tenancy.

I encourage constructive feedback to all posts, so please drop me a note if you have something to contribute.