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.
Note:
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.
Note:
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.
Note:
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.
