Hosting a Multi-Tenant Application on Windows Azure : Selecting a Single-Tenant or Multi-Tenant Architecture

2/25/2011 11:26:55 AM
This section introduces some of the criteria that an architect would consider when deciding on a single-tenant or multi-tenant design.The relative importance of the different criteria will vary for different application scenarios.

You can always have one tenant in a multi-tenant application, but you can’t have multiple tenants in a single-tenant application.

1. Architectural Considerations

The architectural requirements of your application will influence your choice of a single-tenant or multi-tenant architecture.

1.1. Application Stability

Application Stability A multi-tenant application is more vulnerable to instance failure than a single-tenant application. If a single-tenant instance fails, only the customer using that instance is affected, whereas if the multi-tenant instance fails, all customers are affected. However, Windows Azure can mitigate this risk by enabling you to deploy multiple, identical copies of your application into multiple Windows Azure role instances (this is really a multi-tenant, multi-instance model). Windows Azure load balances requests across those role instances, and you must design your application to ensure that it functions correctly when you deploy multiple instances. For example, if your application uses Session state, you must make sure that each web role instance can access the state. Windows Azure will monitor your role instances and automatically restart any failed role instances.

In Windows Azure, the preferred way to scale your application is to scale out by adding additional nodes instead of scaling up by using larger nodes. This enables you to add or remove capacity as and when it’s needed.

1.2. Making the Application Scalable

The scalability of an application running on Windows Azure depends largely on being able to deploy multiple instances of your web and worker roles to multiple compute nodes while being able to access the same data from those nodes. Both single-tenant and multi-tenant applications use this feature to scale out when they run on Windows Azure. Windows Azure also offers various sizes of compute nodes that enable you to scale up or scale down individual instances.

For some applications, you may not want to have all your customers sharing a single, multi-tenant instance. For example, you may want to group your customers based on the functionality they use or their expected usage patterns, and then optimize each instance for the customers who are using it. In this case, you may need to have two or more copies of your multi-tenanted application deployed in different Windows Azure accounts.

1.3. Service Level Agreements

You may want to offer a different Service Level Agreement (SLA) with the different subscription levels for the service. If subscribers with different SLAs are sharing the same multi-tenant instance, you should aim to meet the highest SLA, thereby ensuring that you also satisfy the lower SLAs for other customers.

However, if you have a limited number of different SLAs, you could put all the customers that share the same SLA into the same multi-tenant instance and make sure that the instance has sufficient resources to satisfy the requirements of the SLA.

1.4. The Legal and Regulatory Environment

For certain applications, you may need to take into account specific regulatory or legal issues. This may require some differences in functionality, specific legal messages to be displayed in the UI, guaranteed separate databases for storage, or storage located in a specific region. This may again lead to having separate multi-tenant deployments for groups of customers, or it may lead to requiring a single-tenant architecture.

1.5. Handling Authentication and Authorization

You may want to provide your own authentication and authorization systems for your cloud application that require customers to set up accounts for the users who will interact with the application. However, customers may prefer to use an existing authentication system and avoid having to create a new set of credentials for your application. In a multi-tenant application, this would imply being able to support multiple authentication providers, and it may possibly require a custom mapping to your application’s authorization scheme. For example, someone who is a “Manager” in Microsoft® Active Directory® directory service at Adatum might map to being an “Administrator” in Adatum’s Tailspin Surveys application.


For more information about claims-based identity, see the book, A Guide to Claims-Based Identity and Access Control. You can download a PDF copy of this book from http://msdn.microsoft.com/en-us/library/ff423674.aspx.

2. Application Life Cycle Management Considerations

Your choice of a single-tenant or multi-tenant architecture will affect how easy it is to develop, deploy, maintain, and monitor your application.

2.1. Maintaining the Code Base

Maintaining separate code bases for different customers will rapidly lead to escalating support and maintenance costs for an ISV because it becomes more difficult to track which customers are using which version. This will lead to costly mistakes being made. A multi-tenant system with a single, logical instance guarantees a single code base for the application. You can still maintain a single code base with a multi-instance, single-tenant model, but there could be a short-term temptation (with long-term consequences) to branch the code for individual customers in order to meet specific customer requirements. In some scenarios, where there is a requirement for a high-degree of customization, multiple code bases may be a viable option, but you should explore how far you can get with custom configurations or custom business rule components before going down this route. If you do need multiple code bases, you should structure your application such that custom code is limited to as few components as possible.

2.2. Handling Application Upgrades

A multi-tenant application makes it easy to roll out application updates to all your customers at the same time. This approach means that you only have a single, logical instance to upgrade, which reduces the maintenance effort. In addition, you know that all your customers are using the latest version of the software, which makes the support job easier. Windows Azure upgrade domains facilitate this process by enabling you to roll out your upgrade across multiple role instances without stopping the application. If a client has operational procedures or software that are tied to a specific version of your application, any upgrades must be coordinated with that client.

To mitigate the risks associated with upgrading the application, you can implement a rolling upgrade program that upgrades some users, monitors the new version, and when you are confident in the new version, rolls out the changes to the remainder of the user base.

2.3. Monitoring the Application

Monitoring a single application instance is easier than monitoring multiple instances. In the multi-instance, single tenant model, any automated provisioning would need to include setting up the monitoring environment for the new instance, which will add to the complexity of the provisioning process for your application. Monitoring will also be more complex if you decide to use rolling upgrades because you must monitor two versions of the application simultaneously and use the monitoring data to evaluate the new version of the application.

2.4. Using .NET Providers and Third-Party Components

If you decide on a multi-tenant architecture, you must carefully evaluate how well any third-party components will work. You may need to take some additional steps ensure that a third-party component is “multi-tenant aware.” With a single-tenant, multi-instance deployment where you want to be able to scale out for large tenants, you will also need to verify that third-party components are “multi-instance aware.”

2.5. Provisioning for Trials and New Customers

Provisioning a new client or initializing a free trial of your service will be easier and quicker to manage if it involves only a configuration change. A multi-instance, single-tenant model will require you to deploy a new instance of the application for every customer, including those using a free trial. Although you can automate this process, it will be considerably more complicated than changing or creating configuration data in a single-instance, multi-tenant application.

3. Customizing the Application

Whether you choose a single-tenant or multi-tenant architecture, customers will still need to be able to customize the application.

3.1. URLs to Access the Application

By default, Windows Azure gives each application a Domain Name System (DNS) name like this: <yourappname>.cloudapp.net. You can use a DNS CNAME record to map a custom DNS name to your application. For example, if the Tailspin Surveys application is named tailspin.cloudapp.net, Tailspin could use a CNAME entry to map the URL https://surveys.tailspin.com to the application. If each customer has its own, separate, single-tenant instance of the application running in a separate Windows Azure account, you could map a custom DNS name to each instance of the application. For example, you could map https://surveys.adatum.com and https://surveys.fabrikam.com to separate instances.

Because Internet Information Services (IIS) can have only one SSL certificate associated with a port, a multi-tenant application can use only a single domain name on the default port 443. Therefore, in a multi-tenant application, you can use an addressing scheme like this: https://<azureaccount>.cloudapp.net/<app>/<tenant>. Adatum, a subscriber to the Tailspin Surveys application, would access the Surveys application at https://services.tailspin.com/surveys/adatum.

If you don’t need to use SSL, you can use custom domain names for each tenant in a multi-tenant application. Each tenant can create a CNAME record to map his or her domain name to the Windows Azure application.

3.2. Customizing the Application by Tenant

Customers will want to be able to style and brand the site for their own users. You must establish how much control customers will want in order to determine how best to enable the customization. At one end of the scale, you might provide the customer with the ability to customize the appearance of the application by allowing them to upload cascading style sheets and image files. At the other end of the scale, you might enable the customer to design complete pages that interact with the application’s services through a standard API.

This is, of course, nothing new. Microsoft Dynamics® CRM is a great example of an application that has these levels of customization available.

For some applications, you may want to provide customers with the ability to enable or disable certain functionality. For example, in the Surveys application, customers can choose whether to integrate the application’s identity infrastructure with their own infrastructure, and they can choose the geographic location for their surveys. This type of configuration data can easily be stored in Windows Azure table storage.

Other applications may require the ability to enable users to customize the business process within the application to some degree. Options here would include implementing a plug-in architecture so that customers could upload their own code or using some form of rules engine that enables process customization through configuration.

You may also want to provide customers with ways to extend the application without using custom code. Users of the survey application may want to capture additional information about a survey respondent that the standard application does not collect. This means that users must have a mechanism for customizing the UI to collect the data and a way of extending the data storage schema to include the new data.

4. Multi-Tenant Data Architecture

Your architecture must ensure that a customer’s data is kept private from other customers. Your application may also need to support customized data storage.


For more information about multi-tenant data architectures, see “Multi-Tenant Data Architecture” (http://msdn.microsoft.com/en-us/library/aa479086.aspx) and “Architecture Strategies for Catching the Long Tail” (http://msdn.microsoft.com/en-us/library/aa479069.aspx) on MSDN®.

Allowing tenants to upload their own code increases the risk of application failure, because you have less control over the code that is running in the application. Many Software as a Service (SaaS) systems apply limits to this. Most simply disallow it. Allowing tenants to upload code or scripts also increases the security risks associated with the application.

4.1. Protecting Data from Other Tenants

The perceived risk of either accidental or malicious data disclosure is greater in a multi-tenant model. It will be harder to convince customers that their private data is safe if they know they are physically sharing the application with other customers. However, a robust design that logically isolates each tenant’s data can provide a suitable level of protection. This type of design might use database schemas where each tenant’s tables are in a separate schema, database security features that enable you to use access control mechanisms within the database, a partitioning scheme to separate tenant’s data, or a combination of these approaches.

The security considerations just described apply to both Windows Azure storage and SQL Azure™ technology platform. However, they each have a different billing model. Usage of Windows Azure storage is billed by the amount of storage used and by the number of storage transactions, so from a cost perspective it doesn’t matter how many separate storage accounts or containers you have. SQL Azure is billed based on the number of databases you have, so it makes sense from a cost perspective to have as many tenants as possible sharing each instance.

4.2. Data Architecture Extensibility

There are a number of ways that you can design your data storage to enable tenants to extend the data model to include their own custom data. These approaches range from each tenant having a separate schema, to providing a set of pre-defined custom columns, to more flexible schemas that enable a tenant to add an arbitrary number of custom fields to a table.

If you use SQL Azure, much of the application’s complexity will result from having to work within the constraints of fixed data schemas. If you are using Windows Azure table storage, the complexity will arise from working with variable schemas. Windows Azure table storage allows records in the same table to have completely different structures, which allows for a great deal of flexibility at the cost of more complexity in the code.

You are billed for SQL Azure based on the number of databases you have, and the size of the databases. If you transfer data in and out of SQL Azure from within the same data center, there’s no data transfer cost, but if you transfer data in and out of SQL Azure from outside the data center, you’ll be charged for the data transfer.

Custom extensions to the application’s data model should not require changes to application code. To enable the application’s business logic and presentation logic to integrate with the data model extensions, you will require either a set of configuration files that describe the extensions or code that can dynamically discover the extensions.

4.3. Data Architecture Scalability

If you can partition your data horizontally, you will be able to scale out your data storage. In the case of SQL Azure, if you decide that you need to scale out, you should be able to move all of an individual tenant’s data to a new SQL Azure instance.


Partitioning data horizontally, also known as sharding, implies taking some of the records in a table and moving them to a new table. Partitioning data vertically implies taking some fields from every row and placing them in a different table. For a discussion of partitioning strategies in SQL Azure, see the paper, SQL Azure Considerations Guide; you can download it at http://wag.codeplex.com.

Microsoft SharePoint® is an example of an application with a fixed schema database that is made to look extremely flexible.

The key factor that determines the scalability of Windows Azure table storage is the choice of partition key. All queries should include the partition key to avoid scanning multiple partitions.

5. Financial Considerations

Your billing and cost model may affect your choice of single-tenant or multi-tenant architecture.

5.1. Billing Customers

For an application deployed to Windows Azure, Microsoft will bill you each month for the services (compute, storage, transactions, and so on) that each of your Windows Azure accounts consumes. If you are selling a service to your customers, like the Tailspin Surveys application, you need to bill your customers for the service.

One approach to billing is to use a pay-per-use plan. With this approach, you need to monitor the resources used by each of your customers, calculate the cost of those resources, and apply a markup to ensure you make a profit. If you use a single-tenant architecture and create a separate Windows Azure account for each of your customers, it’s easy to determine how much an individual customer is costing in terms of compute time, storage, and so on, and then to bill the customer appropriately. However, for a single-tenant instance running in a separate Windows Azure account, some costs will effectively be fixed; for example, paying for a 24x7 compute instance, or a SQL Azure instance, may make the starting cost too high for small customers. With a multi-tenant architecture, you can share the fixed costs between tenants, but calculating the costs per tenant is not so straightforward and you will have to add some additional code to your application to meter each tenant’s application usage. Furthermore, customers will want some way of tracking their costs, so you will need to be transparent about how the costs are calculated and provide access to the captured usage data.

It is difficult to predict exactly what usage an individual subscriber will make of the service; for the Surveys application, Tailspin cannot predict how many surveys a subscriber will create or how many survey answers the subscriber will receive in a specified period. If Tailspin adopts a billing model that offers the Surveys service for a fixed monthly fee, the profit margin will vary between subscribers (and could even be negative in some cases). By making Surveys a multi-tenant application, Tailspin can smooth out the differences in usage patterns between subscribers, making it much easier to predict costs and revenue, and reduce the risk of making a loss. The more customers you have, the easier it becomes to predict aggregate usage patterns for a service.

From the customer’s perspective, charging a fixed fee for the service means that the customer knows in advance exactly what their costs will be for the next billing period. This also means that you have a much simpler billing system. Some costs, like those associated with storage and transactions, will be variable and depend on the number of customers you have and how they use the service. Other costs, such as compute costs or the cost of a SQL Azure instance, will effectively be fixed. To be profitable, you need to sell sufficient subscriptions to cover both the fixed and variable costs.

If your customer base is a mixture of heavy users and light users, a standard monthly charge may be too high to attract smaller users. In this scenario, you’ll need a variation on the second approach and offer a range of packages for different usage levels. For example, in the Surveys application, Tailspin might offer a light package at a lower monthly cost than the standard package. The light package may limit the number of surveys a customer can create or the number of survey responses that a customer can collect each month.

Offering a product where different customers can choose different features and/or quotas requires that you architect and design the product with that in mind. Such a requirement affects the product at all levels: presentation, logic, and data. You’ll also need to undertake some market research to determine the expected demand for the different packages at different costs to try to estimate your expected revenue stream and costs.

5.2. Managing Application Costs

You can divide the running costs of a Windows Azure application into fixed and variable costs. For example, if the cost of a compute node is $0.12/hour, the cost of running two compute nodes (to gain redundancy) 24x7 for one month is a fixed cost of approximately $180. If this is a multi-tenant application, all the tenants share that cost. To reduce the cost per tenant, you should try to have as many tenants as possible sharing the application, without causing a negative impact on the performance of the application. You also need to analyze the application’s performance characteristics to determine whether scaling up by using larger compute nodes or scaling out by adding additional instances would be the best approach for your application when demand increases.

Variable costs will depend on how many customers you have or how those customers use the application. In the Tailspin Surveys application, the number of surveys and the number of respondents for each survey will largely determine monthly storage and transaction costs. Whether your application is single-tenant or multi-tenant will not affect the cost per tenant; regardless of the model, a specific tenant will require the same amount of storage and use the same number of compute cycles. To manage these costs, you must make sure that your application uses these resources as efficiently as possible.

  •  SharePoint 2010 :Implementing a Partner Extranet Solution (part 2) - Configuring Authentication Providers
  •  SharePoint 2010 :Implementing a Partner Extranet Solution (part 1) - Creating the Extranet Web Application & Creating an Extranet Site Collection
  •  SharePoint 2010 : Implementing Authentication Scenarios
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Installation (part 3)
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Installation (part 2)
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Installation (part 1)
  •  Hosting a Multi-Tenant Application on Windows Azure : Single-Tenant vs. Multi-Tenant & Multi-Tenancy Architecture in Azure
  •  Understanding SharePoint 2010 Extranet Security
  •  Sharepoint 2010 : Outlining Common Extranet Scenarios and Topologies
  •  Sharepoint 2010 : Virtual Machine Management with System Center Virtual Machine Manager
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Architecture (part 3)
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Architecture (part 2)
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Architecture (part 1)
  •  Designing and Configuring Unified Messaging in Exchange Server 2010 : Unified Messaging Features
  •  Exploring Sample Virtualized SharePoint 2010 Architecture
  •  Virtualizing SharePoint Components : Virtualization of SharePoint Roles
  •  Monitoring a SharePoint 2010 Environment : Establishing Maintenance Schedules for SharePoint
  •  Using System Center Operations Manager to Simplify Management of SharePoint 2010
  •  Designing and Implementing Mobility in Exchange Server 2010 : Working with Windows Mobile Pocket PC and Smartphone Editions
  •  Designing and Implementing Mobility in Exchange Server 2010 : Working with ActiveSync Policies
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)