This is the first of a three-part series on multi-tenancy within Windows Azure applications. Here is a breakdown of the topics for this post as well as the final two posts.
Post 1 – Tenants and Instances
Post 2 – Combinations of Instances and Tenancy
Post 3 – Tenant Strategy and Business Application
Part 1 – Tenants and Instances
One of the prime economic motivations to running your application in a Cloud environment is the ability to distribute the cost of shared resources among multiple customers. At least that’s what all the evangelists and marketing folks like to tell us, right? But the harsh reality of life in the Cloud is that an application’s ability to run safely and efficiently with multiple customers does not just magically ‘happen’ simply by deploying it to Azure. An application’s architecture must be explicitly and carefully designed to support running with multiple customers across multiple (VM) virtual machines. Its’ implementation must prevent customer-specific processing from negatively affecting processing for other tenants.
Here I will attempt to simplify the concept of tenancy in Windows Azure by first defining tenants and instances. There are deeper levels this discussion could be taken as entire books have been written on multi-tenancy in shared computing/storage environment (which is what the Cloud is after all). So we will only touch the tip of the iceberg when it comes to the science of instance allocations per tenant and multi-tenant data access. We will look at various configurations of instances and tenancy and how to structure your application and data. And finally we will wrap up with some strategies for multi-tenancy and how business models relate to tenancy.
Let’s first agree upon a definition for the term tenancy and how it applies to single- and multi-tenancy. There are a few different definitions of this concept that can cloud (no pun intended) one’s understanding. Some define it as the relationship of clients to application instances. Wikipedia defines it as “…a single instance of the software runs on a server, serving multiple client organizations (tenants)”. While I appreciate this definition for the sake of practicality I want to expand upon it if I may. There are architectures where you can also have “more than one instance of the software running on a server”. How you provision tenants to those multiple instances is your choice. You could have one tenant (customer or company) per instance and all the users from that company dedicated to that instance. Or you could have more than one customer sharing that one instance but logically partitioned from each other’s data and processing. Each of those customers (or tenants) can have one or more users accessing the application.
So for the sake of this paper let’s agree that tenancy refers to a “customer/billing” relationship. Suppose we have a SaaS Azure application that we sell to ten different companies (our “customers”). Each company has 5,000 employees using our Cloud application. Using our billing-relationship definition if we sell that service to 10 different companies we don’t have 5,000 tenants. Rather we have 10 tenants because of our 10 customer/billing relationships. Later in this paper we will look at more about this type of relationship in the Business Model and Tenancy section.
There are two types of tenant environments we will need to consider. The simplest type is a single-tenant application where one customer has 100% dedicated access to an application’s process space. A single tenant application is much more predictable and stable by its nature since there will never be more than one dedicated customer at any point in time in that VM. That customer has all of its users accessing that dedicated instance of the application.
Contrast that with a multi-tenant environment where more than one customer shares the application’s process space and data. Due to requirements of security and performance isolation, it’s more difficult to build a multi-tenant application. You may have to plan for added complexity and development/test time to synchronize access to shared data and resources. For a Windows Azure multi-tenant application similar complexity is required to ensure data and resources do not get corrupted with multiple tenants in the same or multiple process spaces.
Realize there are variations on this theme. You could theoretically have only one user per instance of a VM. So if a company had 2000 users it would need 2000 VMs. Not a very practical application of resources or costs. More realistically, with our tenancy definition of customer/billing relationship, you would have 2000 users from that same company sharing the same VM instance. So if you have 20 companies you’d have 20 VMs. Each VM would handle one or more users for that specific company only. Getting more complex in tenancy we could have more than one company sharing an instance. So if you had 100 companies, you could provision 10 of them per instance and thus use 10 VMs. Each company would share a VM with 9 other companies, and you would have 10 VM instances of this. Confused? Hold that thought. We will break this down with picture and stick figures (okay… maybe no stick figures!) as we progress in this article.
Why would one want to go through the trouble of making a Windows Azure application multi-tenant? Wouldn’t it just be so much easier to make an application single-tenant and not have to worry about complicated synchronization and a more complex billing model? From an infrastructure and development standpoint, it’s the difference in cost vs. simplicity. Whether making the choice of the simplicity of driving your own private car to work or reducing your commuting cost with other riders using the public mass-transit system you have to decide what’s right for you. For various reasons you may decide not to share your ride with others and pay more for your own custom commuting environment. Maybe your schedule is unique, or you are scared of what could happen health-wise or crime-wise being sharing a commuting vehicle with strangers. Or you don’t want your commute time to be affected in any way by other riders and like to leave your briefcase in the car each night when you get home. So you choose to pay more and have a dedicated way to work.
But for those commuters who can’t or won’t spend the increased cost of private commuting the choice of shared public transportation is their best option. It offers a simple pay as you go model where the cost you pay is minimized since it is distributed across many customers. So there is no right or wrong answer – it depends upon the rider requirements.
Compare this to a software standpoint where there could be various requirements – government regulations or demanding SLAs – that you need to support for your customers. It’s a tradeoff, right? You want the benefits of operation isolation and simplified design found with a dedicated single-tenant application. But it will cost you more since you aren’t sharing the cost of the resources over many customers. So the choice when deciding to use a multi- or single-tenant environment depends upon your application requirements.
Instances and Tenancy
In the case of Windows Azure a new instance means running on a new VM instance isolated from the other instances. These instances can communicate with each other typically through queues or WCF calls. Let’s see how these terms combine to define the different types of applications running under Windows Azure.
There are four possible combinations of instances and tenancy. The standard convention is “INSTANCE-TENANT” format when describing these combinations. These are listed in approximate complexity of architecture with SIST being the simplest.
- SIST (single-instance, single-tenant)
- SIMT (single-instance, multi-tenant)
- MIST (multi-instance, single-tenant)
- MIMT (multi-instance, multi-tenant)
A quirky way that helps me remember these in terms of Windows Azure is to equate the following:
“Instance” = “Azure virtual machine (VM) instance”
“Tenant” = “Customers sharing of the VM”
So in my personal Azure terms, I like to define the remaining combinations as follows. These are listed in order of increasingly complex development.
1. SIST (Single-Instance, Single-Tenant)
- “Only one Azure VM dedicated to one company”
2. SIMT (Single-Instance, Multi-Tenant)
- “Only one Azure VM shared among multiple companies”
3. MIST (Multi-Instance, Single-Tenant)
- “Many Azure VMs each dedicated to one company”
4. MIMT (Multi-Instance, Multi-Tenant)
- “Many Azure VMs shared among multiple companies”
In the next post we will look in detail at all four of these combinations of tenancy.