This article discusses some of the issues that surround architecting and building multi-tenant applications to run on Windows Azure™ technology platform. A highly scalable, cloud-based platform offers a compelling set of features for building services that many users will pay a subscription to use. A multi-tenant architecture where multiple users share the application enables economies of scale as users share resources, but at the cost of a more complex application that has to manage multiple users independently of each other.
1. Single-Tenant vs. Multi-Tenant
One of the first architectural decisions that the team at Tailspin had to make about the Surveys application was whether it should be a single-tenant or multi-tenant application to best support multiple customers. Figure 1 shows the difference between these approaches at a high-level. The single-tenant model has a separate, logical instance of the application for each customer, while the multi-tenant model has a single logical instance of the application shared by many customers. It’s important to note that the multi-tenant model still offers separate views of the application’s data to its users. In the Surveys application, ClientB must not be able to see or modify ClientA’s surveys or data. Tailspin, as the owner of the application, will have full access to all the data stored in the application.
Figure 1. Logical view of single-tenant and multi-tenant architectures
2.2. Multi-Tenancy Architecture in Azure
In Windows Azure, the distinction between the multi-tenant model and the single-tenant model is not as straightforward as the model in Figure 1 because an application in Windows Azure can be made up of multiple components, each of which can be single-tenanted or multi-tenanted. For example, if an application has a user interface (UI) component, a services component, and a storage component, a possible design could look like that shown in Figure 2.
| This diagram shows logical instances of the Surveys application. In practice, you can implement each logical instance as multiple physical instances to scale the application |
Figure 2. Sample architecture for Windows Azure
This is not the only possible design, but it illustrates that you don’t have to make the same choice of either single-tenancy or multi-tenancy model for every component in your application.
Should you design your Windows Azure application to be single-tenant or multi-tenant? There’s no right or wrong answer, but as you will see in the following section, there are a number of factors that can influence your choice.
