2 – Hosting a Multi-Tenant Application on Windows Azure

On this page:	Download:
Goals and Requirements | The Tenant's Perspective | The Provider's Perspective | Single Tenant vs. Multiple Tenant | Multi-Tenancy Architecture in Windows Azure | Selecting a Single-Tenant or Multi-Tenant Architecture | Architectural Considerations - Application Stability, Making the Application Scalable, Resource Limitations and Throttling, Geo-location, Service Level Agreements, The Legal and Regulatory Environment, Handling Authentication and Authorization, The Command Query Responsibility Segregation (CQRS) Pattern | Application Life Cycle Management Considerations - Maintaining the Code Base, Handling Application Updates, Monitoring the Application, Using Third-Party Components, Provisioning for Trials and New Subscribers | Customizing the Application - Customizing the Application by Tenant, URLs to Access the Application | Financial Considerations - Billing Subscribers, Pay per Use Plans, Fixed Monthly Fee Plans, Different Levels of Fixed Fees, Managing Application Costs, Engineering Costs | More Information

This chapter discusses some of the issues that surround architecting and building multi-tenant applications to run on Windows Azure. 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.

This chapter does not focus specifically on Tailspin or the Surveys application, but it uses the scenario described in the previous chapter to illustrate some of the factors that you might consider when choosing how to implement a multi-tenant application on Windows Azure.

This chapter provides a conceptual framework that helps you understand some of the topics discussed in more detail in the subsequent chapters of this guide.

Goals and Requirements

This section outlines some of the goals and requirements that are common to many multi-tenant applications. Some may not be relevant in some specific scenarios, and the importance of individual goals and requirements will differ in each scenario. For example, not all multi-tenant applications require the same level of customizability by the tenant or face the same regulatory constraints.

It is also useful to consider the goals and requirements for a multi-tenant application from the perspective of both the tenant and the provider.

The Tenant's Perspective

Multiple tenants share the use of a multi-tenant application, but different tenants may have different goals and requirements. A tenant is unlikely to be interested how the provider implements the multi-tenancy, but will expect the application to behave as if the tenant is its sole user. The following provides a list of the most significant goals and requirements from a tenant's perspective.

• Isolation. This is the most important requirement in a multi-tenant application. Individual tenants do not want the activities of other tenants to affect their use of the application. They also need to be sure that other tenants cannot access their data. Tenants want the application to appear as though they have exclusive use of it.
• Availability. Individual tenants want the application to be constantly available, perhaps with guarantees defined in an SLA. Again, the activities of other tenants should not affect the availability of the application.
• Scalability. Even though multiple tenants share a multi-tenant application, an individual tenant will expect the application to be scalable and be able to meet his level of demand. The presence and actions of other tenants should not affect the performance of the application.
• Costs. One of the expectations of using a multi-tenant application is that the costs will be lower than running a dedicated, single-tenant application because multi-tenancy enables the sharing of resources. Tenants also need to understand the charging model so that they can anticipate the likely costs of using the application.
• Customizability. An individual tenant may require the ability to customize the application in various ways such as adding or removing features, changing colors and logos, or even adding their own code or script.
• Regulatory Compliance. A tenant may need to ensure that the application complies with specific industry or regulatory laws and limitations, such as those that relate to storing personally identifiable information (PII) or processing data outside of a defined geographical area. Different tenants may have different requirements.

The Provider's Perspective

The provider of the multi-tenant application will also have goals and requirements. The following provides a list of the most significant goals and requirements from a provider's perspective.

• Meeting the tenants' goals and requirements. The provider must ensure that the application meets the tenants' expectations. A provider may offer a formal SLA that defines how the application will meet the tenants' requirements.
• Profitability. If the provider offers the application as a commercial service, the provider will want to obtain an appropriate rate of return on the investment it has made in developing and providing the service. Revenue from the application must be sufficient to cover both the capital and running costs of the application.
• Billing. The provider needs a way to bill the tenants. This may require the application to monitor resource usage if the provider does not want to use a fixed rate charging approach. An example of a fixed rate approach would be if Tailspin charges each tenant a monthly fee for using the Surveys application. An alternative is that Tailspin charges each tenant based on the number of survey responses it collects, or on some other usage metric.
• Multiple service levels. The provider may want to offer different versions of a service at different monthly rates, such as a standard or a premium subscription. These different subscription levels may include different functions, different usage limitations, have different SLAs, or specify some combination of these factors.
• Provisioning. The provider must be able to provision new tenants for the application. If there are a small number of tenants, this may be a manual process. For multi-tenant applications with a large number of tenants, it is usually necessary to automate this process by enabling self-service provisioning.
• Maintainability. The provider must be able to upgrade the application and perform other maintenance tasks while multiple tenants are using it.
• Monitoring. The provider must be able to monitor the application at all times to identify any problems and to troubleshoot them. This includes monitoring how each tenant is using the application.
• Automation. In addition to automated provisioning, the provider may want to automate other tasks in order to provide the required level of service. For example, the provider may want to automate the scaling of the application by dynamically adding or removing resources as and when they are required.

Single Tenant vs. Multiple Tenant

One of the first architectural decisions that the team at Tailspin had to make about how the Surveys application could best support multiple subscribers was whether it should be a single-tenant or multi-tenant application. Figure 1 shows the difference between these approaches at a high-level. The single-tenant model has a separate physical instance of the application for each subscriber, while the multi-tenant model has a single physical instance of the application shared by many subscribers.

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, Client B must not be able to see or modify Client A’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 multiple tenant architectures

Bharath Says:
	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.</td>

Multi-Tenancy Architecture in Windows Azure

In Windows Azure, the distinction between the multi-tenant model and the single-tenant model is not as straightforward as that shown in Figure 1 because an application in Windows Azure can consist of many elements, each of which can be single tenanted or multiple tenanted. For example, if an application has a user interface (UI) element, a services element, and a storage element, a possible design could look like that shown in Figure 2.

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 a single-tenancy or a multi-tenancy model for every element in your application. In practice, a Windows Azure application consists of many more elements than shown in Figure 2 such as queues, caches, and virtual networks that might have a single-tenant or a multi-tenant architecture.

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.

Selecting a Single-Tenant or Multi-Tenant Architecture

This section introduces some of the criteria that an architect would consider when deciding on a single-tenant or multi-tenant design. The guide revisits many of these topics in more detail, and with specific reference to Tailspin and the Surveys application, in later chapters. The relative importance of the different criteria will vary for different application scenarios.

This chapter focuses on application architecture, management, and financial considerations. Chapter 3, “Choosing a Multi-Tenant Data Architecture,” explores the topics you must consider when choosing a suitable data architecture for a multi-tenant application.

Architectural Considerations

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

The focus of this guide is on building a multi-tenant application using Windows Azure cloud services: web and worker roles. However, the architectural considerations addressed in this chapter, and many of the design decisions that Tailspin faced during the implementation of the Surveys application discussed in subsequent chapters, are equally relevant to other hosting choices for your multi-tenant application. For example, if you decide to build your multi-tenant application using Windows Azure Web Sites or to deploy it to Windows Azure Virtual Machines you will face many of the same challenges that Tailspin faced building the Surveys application for deployment to Windows Azure Cloud Services.

For a detailed discussion of the Infrastructure as a Service (IaaS) approach offered by Windows Azure Virtual Machines, you should read Chapter 2, “Getting to the Cloud,” in the guide “Moving Applications to the Cloud.” Chapter 3, “Moving to Windows Azure Cloud Services,” in that guide discusses using Windows Azure Web Sites to host your application in the cloud.

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 user of that instance is affected. If the multi-tenant instance fails, all users are affected. However, Windows Azure can help to mitigate this risk by enabling you to deploy multiple, identical instances of the Windows Azure roles that make up your application (this is really a multi-tenant, multi-instance model).

Windows Azure load balances requests across those role instances, and you must design your application so 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 for any user. In addition, the tasks that a worker role performs must function correctly when Windows Azure can select any instance of the role to handle a particular task. Windows Azure monitors your role instances and automatically restarts any that have failed.

For the Windows Azure SLA to apply to your application, you must have at least two instances of each role type running. For more information, see “Service Level Agreements.”

Windows Azure can throttle access to resources, making them temporarily unavailable. Typically, this happens when there is high contention for a resource. Your Windows Azure application should detect when it is being throttled, and take appropriate action such as retrying the operation after a short delay.

Bharath Says:
	The <a href="hh680918(v=pandp.50).md">Transient Fault Handling Application Block</a>, available as a separately installable part of the Enterprise Library 5.0 Integration Pack for Windows Azure, can handle in a standard and configurable way the transient faults that may occur because of throttling. </td>

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, while being able to access the same data from those instances. Both single-tenant and multi-tenant applications use this feature to scale out when they run on Windows Azure. Windows Azure also offers various instance sizes that enable you to scale up or scale down individual instances.

Figure 3 shows how you can scale out the application by running a variable number of instances. In Windows Azure cloud services, these would be multiple instances of your web and worker roles.

Figure 3

Scaling out a multi-tenant application

Bharath Says:

In Windows Azure, the preferred way to adapt your application to manage varying load is to <em>scale out </em>by adding additional nodes, rather than <em>scale up </em>by using larger nodes. This enables you to add or remove capacity as and when it’s needed without interruption to services. You can use frameworks or scripts to automatically add and remove instances based on a schedule, or in response to changes in demand. The <a href="hh680918(v=pandp.50).md">Autoscaling Application Block</a>, available as part of the Enterprise Library 5.0 Integration Pack for Windows Azure, is an example of such a framework. </td>

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

Figure 4 illustrates a scenario where premium subscribers share one instance of the application, and standard subscribers share another instance. Note that you can scale each instance independently of the other.

Figure 4

Using multiple multi-tenant instances

Bharath Says:

Although the model shown in Figure 4 makes it easy to scale the application for premium subscribers independently of standard subscribers, it is not the only way to handle different subscription levels. For example, if both premium and standard subscribers shared the same instance you could implement an algorithm that gives preference to premium users, ensuring that their workload and tasks are given priority within the instance. By providing configuration parameters, you could adjust the algorithm dynamically.</td>

If you use an autoscaling solution when your application has multiple tenants, you need to consider any limits that you want to place on the scalability of your application because each running role instance will accrue charges. It’s possible that the activities of a tenant could cause a large number of instances to automatically start. With fixed rate charging, this could result in high costs for the provider. With usage based charging, this could result in high costs for the tenant.

You may want to consider using Windows Azure Caching and Windows Azure Traffic Manager to enhance the scalability of your application. In addition to providing output caching and data caching, Windows Azure Caching includes a highly scalable session provider for use in ASP.NET applications. Traffic Manager enables you to control the distribution of traffic to multiple Windows Azure deployments, even if those deployments are running in different data centers.

Chapter 4, “Partitioning Multi-Tenant Applications,” of this guide contains more information about how you can use Windows Azure Caching. Chapter 5, “Maximizing Availability, Scalability, and Elasticity,” of this guide discusses scalability and related topics, including using Windows Azure Traffic Manager and how you can automatically scale instances of your application using the Enterprise Library Autoscaling Application Block.

Resource Limitations and Throttling

Individual elements of your application architecture will have specific limitations, such as the maximum throughput of the message queuing element (Windows Azure storage queues or Windows Azure Service Bus), or the maximum number of transactions per second supported by the data storage system used in your application. These resource limitations may place constraints on the number of tenants who can share a particular instance. You must understand the resource limitations and quotas in relation to the likely usage patterns of your tenants so that these resource limitations do not affect overall performance of the application.

Furthermore, many resources in the cloud, such as message queues and storage systems, may throttle usage at certain times when they are under high load or encounter spikes of high activity. You should try to design your application so that it is unlikely to be throttled, but it must still be resilient if it does encounter throttling.

Bharath Says:
	Remember that Windows Azure is itself a multi-tenant service, and one of the ways that it manages contention for resources by its tenants is to use throttling.</td>

Geo-location

If your application has tenants from multiple geographic locations, giving them access to resources in their country or region can help to improve performance and reduce latency. In this scenario, you should consider a partitioning scheme that uses location to associate tenants with specific resource. In Windows Azure, whenever you create a resource such as a storage account, a cloud service, or a service namespace you can specify the geographic location where the resource will be hosted.

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 subscribers.

However, if you have a limited number of different SLAs, you could put all the subscribers 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.

The Legal and Regulatory Environment

For some 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 county or region. This may again lead to having separate multi-tenant deployments for groups of subscribers, or it may even require a single-tenant architecture.

Handling Authentication and Authorization

You may want to provide your own authentication and authorization systems for your cloud application that require subscribers to set up accounts for the users who will interact with the application. However, subscribers may prefer to use an identity they have already established with an existing authentication system (such as a Microsoft or a Google account, or an account in their own Active Directory) and avoid having to create a new set of credentials for your application.

In a multi-tenant application, this implies 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 Active Directory at Adatum might map to being an “Administrator” in Adatum’s Tailspin Surveys application.

Chapter 6, “Securing Multi-Tenant Applications,” of this guide discusses topics such as authentication and authorization in multi-tenant applications in more detail.

The Command Query Responsibility Segregation (CQRS) Pattern

The CQRS pattern is an architectural design pattern that enables you to meet a wide range of architectural challenges such as managing complexity, managing changing business rules, or achieving scalability in some portions of your system. It's important to note that the CQRS pattern is not a top-level pattern, and should only be applied in the specific areas of a system where it brings clearly identifiable benefits.

Many of the multi-tenant considerations listed in this chapter relate to architectural challenges that CQRS can help you to address. However, you should not assume that multi-tenancy necessarily implies that you should use the CQRS pattern. For example, although the Tailspin Surveys application must be highly scalable to support many subscribers with different usage patterns, it is not an especially complex application. In particular, it is not a collaborative application where multiple users simultaneously edit the same data, which is one of the scenarios specifically addressed by the CQRS pattern. Furthermore, Tailspin does not expect the business rules in the Surveys application to change much over time.

Application Life Cycle Management Considerations

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

Maintaining the Code Base

Maintaining separate code bases for different subscribers will rapidly lead to escalating support and maintenance costs for an ISV because it becomes more difficult to track which subscribers 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. If your multi-tenant application uses some single-tenant elements, there could be a short-term temptation (with long-term consequences) to branch the code in those elements for individual subscribers in order to meet the specific requirements of some subscribers.

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.

Bharath Says:

Many ISVs find that, when they move to hosting applications in the cloud instead of hosting them at client sites, release cycles become shorter. This means that they can much more quickly incorporate as part of a standard release a customization or enhancement requested by one client. This can benefit all subscribers while preventing unnecessary forking or multiple versions of the source code.</td>

Handling Application Updates

A multi-tenant application that has a single code base makes it easy to roll out application updates to all your subscribers at the same time. This approach means that you have only a single logical instance to update, which reduces the maintenance effort. In addition, you know that all your subscribers are using the latest version of the software, which makes the support job easier. Windows Azure update domains facilitate this process by enabling you to roll out your update across multiple role instances without stopping the application. However, you must still carefully plan how you will perform a no-downtime update to your application, taking into consideration the fact that during the update process you may temporarily have instances with different versions of your software running simultaneously.

Poe Says:
	You should carefully test your update procedures before performing the update in your production environment, and ensure that you have a plan to revert to the original version if things don’t go as planned.</td>

If a client has operational procedures or software tied to a specific version of your application, any updates must be coordinated with that client. To mitigate the risks associated with updating the application, you can implement a rolling update program that updates 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.

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 updates because you must monitor two versions of the application simultaneously and use the monitoring data to evaluate the new version of the application.

Chapter 7, “Managing and Monitoring Multi-Tenant Applications,” of this guide contains more information about implementing efficient management and monitoring practices for multi-tenant applications.

Using 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.”

Provisioning for Trials and New Subscribers

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 subscriber, 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.

Chapter 7, “Managing and Monitoring Multi-Tenant Applications,” of this guide contains more information about provisioning for new subscribers in multi-tenant applications.

Customizing the Application

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

Customizing the Application by Tenant

Subscribers will want to be able to style and brand the site for their own users. You must establish how much control subscribers will want in order to determine how best to enable the customization. This may vary from just the ability to customize the appearance of the application, such as by allowing subscribers to upload cascading style sheets and image files, to enabling subscribers to design complete pages that interact with the application’s services through a standard API.

Markus Says:
	Customization is, of course, nothing new. Microsoft Dynamics CRM is a great example of an application that has these levels of customization available.</td>

You can implement simple customizations through configuration values that tenants can change and that the application stores in its data store, such as custom logo images, welcome text, or switches to enable certain functionality. For example, in the Surveys application, subscribers 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 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 subscribers could upload their own code, or using some form of rules engine that enables process customization through configuration. To implement a plug-in architecture, you could consider hosting the PowerShell runtime (see System.Management.Automation Namespace on MSDN) in your application, or using the Managed Extensibility Framework (MEF).

Bharath Says:

Allowing tenants to upload their own code increases the risks of introducing a security vulnerability or 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.</td>

Another alternative to consider is enabling your application to call a service endpoint provided by the tenant, which performs some custom logic and returns a result.

You may also want to provide tenants with ways to extend the application without using custom code. Subscribers to the survey application may want to capture additional information about a survey respondent that the standard application does not collect. To achieve this you must implement a mechanism for customizing the UI to collect the data, and a way of extending the data storage schema to include the new data.

Jana Says:

If you need to provide extensive customizations per tenant, it may become impractical to handle this in a shared multi-tenant instance. In this case you should consider using a multi-instance, single-tenant architecture, but beware of the potential running costs of this approach and the difficulties in maintaining the application if there are multiple versions of the source code. This approach is usually appropriate only if you have a small number of tenants.</td>

Chapter 7, “Managing and Monitoring Multi-Tenant Applications,” of this guide contains more information about customizing applications for multiple tenants, and establishing an efficient on-boarding mechanism.

URLs to Access the Application

There are several different URL schemes that you could adopt in a multi-tenant application to enable tenants to access their data. The following describes some possible options for the Tailspin Surveys scenario where a subscriber can publish public surveys, and where public users do not need to sign in to access the survey:

• http://surveys.tailspin.com/{unique-survey-name}. All surveys are available on the same domain, and subscribers must choose a unique survey name for every survey.
• http://surveys.tailspin.com/{subscriber-name}/{survey-name}. Again all surveys are made available on the same domain, but subscribers now only need to ensure that their own survey names are unique.
• http://{subscriber-domain-name}.tailspinsurveys.com/{survey-name}. Each subscriber is allocated its own unique sub domain, and subscribers only need to ensure that their own survey names are unique.
• http://{subscriber-domain-name}/{survey-name}. Each subscriber has its own domain, and subscribers only need to ensure that their own survey names are unique.

The following describes some possible options for the Tailspin Surveys scenario where a subscriber can design and manage their surveys, and where the subscriber must sign in:

• https://surveyadmin.tailspin.com/. After the subscriber logs on, they can design and manage their own surveys.
• https://surveyadmin.tailspin.com/{subscriber-name}. A subscriber must still log on to design and manage their surveys.
• http://{subscriber-domain-name}.tailspinsurveys.com/admin. Each subscriber is allocated its own unique sub domain, and the admin path requires the subscriber to log on.
• https://{subscriber-domain-name}/. Each subscriber has its own domain for accessing the administrative functionality, and subscribers must still log on.

In this case, the first option may be acceptable. There is no significant benefit in including the subscriber’s name anywhere in the URL.

In both scenarios, as well as considering the preferences of the subscribers you also need to consider how the choice of URL scheme might affect other parts of the application, such as the provisioning process and the authentication mechanisms in use. For example, custom domain names take time to propagate through the Domain Name System (DNS). In addition, if you support multiple authentication schemes, you must consider how to select the correct authentication mechanism for a subscriber if the subscriber name is not included in the URL. If you need to use SSL, you also need to consider how to install the necessary certificates.

Chapter 4, "Partitioning Multi-Tenant Applications," discusses the URL scheme adopted by Tailspin to work with the two web roles in the Surveys application.

Financial Considerations

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

Billing Subscribers

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 subscribers, such as in the Tailspin Surveys application, you need to bill your subscribers for the service.

Poe Says:
	Stress testing your application can help you to determine what resources you need to support a given number of tenants. This can help you decide how much to charge your subscribers. </td>

Pay per Use Plans

One approach to billing is to use a pay-per-use plan. With this approach, you monitor the resources used by each of your subscribers, 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 subscribers, it’s easy to determine how much an individual subscriber is costing in terms of compute time, storage, and so on, and then bill the subscriber 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 Windows Azure SQL Database instance may make the starting cost too high for small subscribers. 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, subscribers 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.

Fixed Monthly Fee Plans

A second approach is to adopt a billing model that offers the Surveys service for a fixed monthly fee. 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. Therefore, 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 total costs and revenue, and reduce the risk of taking a loss. The more subscribers you have, the easier it becomes to predict average usage patterns for a service.

Bharath Says:
	If your application can scale out and scale back automatically, it will directly affect your costs. Autoscaling can reduce your costs because it can help to ensure that you use just the resources you need. However, with an autoscaling solution you will also want to put some upper limits on the resources that your application can use to place a cap on potential costs.</td>

From the subscriber’s perspective, charging a fixed fee for the service means that subscribers know, 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, such as those associated with storage and transactions, will be variable and will depend on the number of subscribers you have and how they use the service. Other costs, such as compute costs or the cost of a Windows Azure SQL Database instance, will effectively be fixed. To be profitable, you need to sell sufficient subscriptions to cover both the fixed and variable costs.

Different Levels of Fixed Fees

If your subscriber 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 will need a variation on the second approach to 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 subscriber can create or the number of survey responses that a subscriber can collect each month.

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

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 per 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 application’s performance. 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 when demand increases. Chapter 5, “Maximizing Availability, Scalability, and Elasticity,” discusses the pros and cons of scaling out by adding more instances compared to scaling up by using larger instances.

Variable costs will depend on how many subscribers you have, and how those subscribers 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.

Engineering Costs

Windows Azure bills you for the cost of running your application in the cloud. You must also consider the costs associated with designing, implementing, and managing your application. Typically, multi-tenant application elements are more complex than single-tenant application elements. For example, you must consider how to isolate the tenants within an instance so that their data is kept private, and consider how the actions of one tenant might affect the way the application behaves for other tenants. This additional complexity can add considerably to the engineering costs associated with both building a multi-tenant application, and managing it.

More Information

For more information about working with the Windows Azure platform including planning, designing, and managing, see “Windows Azure Developer Guidance.”

For more information about designing multi-tenant applications for Windows Azure, see “Designing Multitenant Applications on Windows Azure.”

For more information about the costs associated with running a Windows Azure application, see “Estimating Cost Of Running The Web Application On Windows Azure” and “Windows Azure Cost Assessment.”

For more information about ALM considerations, see “Testing, Managing, Monitoring and Optimizing Windows Azure Applications.”

For more information about continuous delivery and using Team Foundation Service with Windows Azure, see “Continuous Delivery for Cloud Services in Windows Azure.”

Next Topic | Previous Topic | Home | Community