This chapter examines architectural and implementation issues in the Surveys application from the perspective of building a multi-tenant application. Questions such as how to partition the application and how to bill customers for their usage are directly relevant to a multi-tenant architecture. Questions such as how to make the application scalable and how to handle the on-boarding process for new subscribers are relevant to both single-tenant and multi-tenant architectures, but they involve some special considerations in multi-tenant model.

This chapter describes how Tailspin resolved these questions for the Surveys application. For other applications, different choices may be appropriate.  

Partitioning the Application

Chapter 5, "Data Storage in the Surveys Application," describes how the Surveys application data model partitions the data by subscriber. This section describes how the Surveys application uses MVC routing tables and areas to make sure that a subscriber sees only his or her own data.

The Solution

The developers at Tailspin decided to use the path in the application's URL to indicate which subscriber is accessing the application. For the Subscriber website, users must authenticate before they can access the application, for the public Surveys website, the application doesn't require authentication.

The following are three sample paths on the Subscriber website:

• /survey/adatum/newsurvey
• /survey/adatum/newquestion
• /survey/adatum

The following are two example paths on the public Surveys website:

• /survey/adatum/launch-event-feedback
• /survey/adatum/launch-event-feedback/thankyou

The application uses the first element in the path to indicate the different areas of functionality within the application. All the preceding examples relate to surveys, but other areas relate to on-boarding and security. The second element indicates the subscriber name, in these examples "Adatum," and the last element indicates the action that is being performed, such as creating a new survey or adding a question to a survey.

You should take care when you design the path structure for your application that there is no possibility of name clashes that result from a value entered by a subscriber. In the Surveys application, if a subscriber creates a survey named "newsurvey," the path to this survey is the same as the path to the page subscribers use to create new surveys. However, the application hosts surveys on an HTTP endpoint and the page to create surveys on an HTTPS endpoint, so there is no name clash in this particular case.

Note:
The third example element of the public Surveys website, "launch-event-feedback," is a "sluggified" version of the survey title, originally "Launch Event Feedback," to make it URL friendly.

Markus says:
A slug name is a string where all whitespace and invalid characters are replaced with a hyphen (-). The term comes from the newsprint industry and has nothing to do with those things in your garden!

Inside the Implementation

Now is a good time to walk through the code that handles the request routing within the application in more detail. As you go through this section, you may want to download the Microsoft® Visual Studio® development system solution for the Tailspin Surveys application from http://wag.codeplex.com/.

The implementation uses a combination of ASP.NET routing tables and MVC areas to identify the subscriber and map requests to the correct functionality within the application.

The following code example shows how the public Surveys Web site uses routing tables to determine which survey to display based on the URL.

using System.Web.Mvc;
using System.Web.Routing;

public static class AppRoutes
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(
            "Home",
            string.Empty,
            new { controller = "Surveys", action = "Index" });

        routes.MapRoute(
            "ViewSurvey",
            "survey/{tenant}/{surveySlug}",
            new { controller = "Surveys", action = "Display" });

        routes.MapRoute(
            "ThankYouForFillingTheSurvey",
            "survey/{tenant}/{surveySlug}/thankyou",
            new { controller = "Surveys", action = "ThankYou" });
    }
}

The code extracts the tenant name and survey name from the URL and passes them to the appropriate action method in the SurveysController class. The following code example shows the Display action method that handles HTTP Get requests.

[HttpGet]
public ActionResult Display(string tenant, string surveySlug)
{
    var surveyAnswer = CallGetSurveyAndCreateSurveyAnswer(
        this. surveyStore, tenant, surveySlug);

    var model = new 
        TenantPageViewData<SurveyAnswer>(surveyAnswer);
    model.Title = surveyAnswer.Title;
    return this.View(model);
}

If the user requests a survey using a URL with a path value of /survey/adatum/launch-event-feedback, the value of the tenant parameter will be "adatum" and the value of the surveySlug parameter will be "launch-event-feedback." This action method uses the parameter values to retrieve the survey definition from the store, populate the model with this data, and pass the model to the view that renders it to the browser.

Markus says:
There is also a Display action to handle HTTP POST requests. This controller action is responsible for saving the filled out survey data.

The Subscriber website is more complex because it must handle authentication and on-boarding new subscribers in addition to enabling subscribers to design new surveys and analyze survey results. Because of this complexity, it uses MVC areas as well as a routing table. The following code from the AppRoutes class in the TailSpin.Web project shows how the application maps top-level requests to the controller classes that handle on-boarding and authentication.

public static void RegisterRoutes(RouteCollection routes)
{
    routes.MapRoute(
        "OnBoarding",
        string.Empty,
        new { controller = "OnBoarding", action = "Index" });

    routes.MapRoute(
        "FederationResultProcessing",
        "FederationResult",
        new { controller = "ClaimsAuthentication",
              action = "FederationResult" });

    routes.MapRoute(
        "FederatedSignout",
        "Signout",
        new { controller = "ClaimsAuthentication",
              action = "Signout" });
    }
    …
}

The application also defines an MVC area for the core survey functionality. MVC applications register areas by calling the RegisterAllAreas method. In the TailSpin.Web project, you can find this call in the Application_Start method in the Global.asax.cs file. The RegisterAllAreas method searches the application for classes that extend the AreaRegistration class, and then it invokes the RegisterArea method. The following code example shows a part of this method in the SurveyAreaRegistration class.

Markus says:
MVC areas enable you to group multiple controllers together within the application, making it easier work with large MVC projects. Each area typically represents a different function within the application.

public override void RegisterArea(
                         AreaRegistrationContext context)
{
    context.MapRoute(
        "MySurveys",
        "survey/{tenant}",
        new { controller = "Surveys", action = "Index" });

    context.MapRoute(
        "NewSurvey",
        "survey/{tenant}/newsurvey",
        new { controller = "Surveys", action = "New" });

    context.MapRoute(
        "NewQuestion",
        "survey/{tenant}/newquestion",
        new { controller = "Surveys", action = "NewQuestion" });

    context.MapRoute(
        "AddQuestion",
        "survey/{tenant}/newquestion/add",
        new { controller = "Surveys", action = "AddQuestion" });

    …
}

Notice how all the routes in this routing table include the tenant name that MVC passes as a parameter to the controller action methods.

On-Boarding for Trials and New Customers

Whenever a new subscriber signs up for the Surveys service, the application must perform configuration tasks to enable the new account. Tailspin wants to automate as much of this process as possible to simplify the on-boarding process for new customers and minimize the costs associated with setting up a new subscriber. The on-boarding process touches many components of the Surveys application, and this section describes how the on-boarding process affects those components.

Basic Subscription Information

The following table describes the basic information that every subscriber provides when they sign up for the Surveys service.

Apart from credit card details, all this information is stored in Windows Azure™ storage; it is used throughout the on-boarding process and while the subscription is active.

Authentication and Authorization Information

The section, "Authentication and Authorization," in Chapter 3, "Accessing the Surveys Application," of this book describes the three alternatives for managing access to the application. Each of these alternatives requires different information from the subscriber as part of the on-boarding process, and each alternative is associated with a different subscription type. For example, the Individual subscription type uses a social identity provider, such as Windows Live® ID or Google ID, for authentication, and the Premium subscription type uses the subscriber's own identity provider.

Provisioning a Trust Relationship with the Subscriber's Identity Provider

One of the features of the Premium subscription type is integration with the subscriber's identity provider. The on-boarding process collects the information needed to configure the trust relationship between subscriber's Security Token Service (STS) and the Tailspin federation provider (FP) STS. The following table describes this information.

The Surveys application will use this data to add the appropriate configuration information to the Tailspin FP STS. The on-boarding process will also make the Tailspin FP federation metadata available to the subscriber because the subscriber may need it to configure the trust relationship in their STS.

Jana says:

The application does not yet implement this functionality. Tailspin could decide to use ADFS, ACS, or a custom STS as its federation provider. As part of the on-boarding process, the Surveys application will have to programmatically create the trust relationship between the Tailspin FP STS and the customer's identity provider, and programmatically add any claims transformation rules to the Tailspin STS.

Note:
Note: For more information, see the section, "Setup and Physical Deployment," on page 97 of the book, A Guide to Claims-Based Identity and Access Control. You can download a PDF copy of this book at http://msdn.microsoft.com/en-us/library/ff423674.aspx.

Provisioning Authentication and Authorization for Basic Subscribers

Subscribers to the Standard subscription type cannot integrate the Surveys application with their own STS. Instead, they can define their own users in the Surveys application. During the on-boarding process, they provide details for the administrator account that will have full access to everything in their account, including billing information. They can later define additional users who are members of the Survey Creator role, who can only create surveys and analyze the results.

Provisioning Authentication and Authorization for Individual Subscribers

Individual subscribers use a third-party, social identity, such as a Windows Live ID, OpenID, or Google ID, to authenticate with the Surveys application. During the on-boarding process, they must provide details of the identity they will use. This identity has administrator rights for the account and is the only identity that can be used to access the account.

Geo Location Information

During the on-boarding process, the subscriber selects the geographic location where the Surveys application will host their account. The list of locations to choose from is the list of locations where there are currently Windows Azure data centers. This geographic location identifies the location of the Subscriber website instance that the subscriber will use and where the application stores all the data associated with the account. It is also the default location for hosting the subscriber's surveys, although the subscriber can opt to host individual surveys in alternate geographical locations.

Poe says:
You could automatically suggest a location based on the user's IP address by using a service such as http://ipinfodb.com/ip_location_api.php.

Database Information

During the sign-up process, subscribers can also opt to provision a SQL Azure™ database to store and analyze their survey data. The application creates this database in the same geographical locations as the subscribers' accounts. The application uses the subscriber alias to generate the database name and the database user name. The application also generates a random password. The application saves the database connection string in Windows Azure storage, together with the other subscriber account data.

Note:
The SQL Azure database is still owned and paid for by Tailspin. Tailspin charges subscribers for this service. For more information about how the Surveys application uses SQL Azure, see the section, "Using SQL Azure," in Chapter 5, "Working with Data in the Surveys Application," of this book.

Billing Customers

Tailspin plans to bill each customer a fixed monthly fee to use the Surveys application. Customers will be able to subscribe to one of several packages, as outlined in the following table.

The advantage of this approach is simplicity for both Tailspin and the subscribers, because the monthly charge is fixed for each subscriber. Tailspin must undertake some market research to estimate the number of monthly subscribers at each level so that they can set appropriate charges for each subscription level.

Bharath says:
Tailspin must have good estimates of expected usage to be able to estimate costs, revenue, and profit.

In the future, Tailspin wants to be able to offer extensions to the basic subscription types. For example, Tailspin wants to enable subscribers to extend the duration of a survey beyond the current maximum, or to increase the number of active surveys beyond the current maximum. To do this, Tailspin will need to be able to capture usage metrics from the application to help it calculate any additional charges incurred by a subscriber. Tailspin expects that forthcoming Windows Azure APIs that expose billing information and storage usage metrics will simplify the implementation of these extensions.

Note:

At the time of writing, the best approach to capturing usage metrics is via logging. Several log files are useful. You can use the Internet Information Services (IIS) logs to determine which tenant generated the web role traffic. Your application can write custom messages to the WADLogsTable. The sys.bandwidth_usage view in the master database of each SQL Azure server shows bandwidth consumption by database.

Customizing the User Interface

A common feature of multi-tenant applications is enabling subscribers to customize the appearance of the application for their customers. The current version of the Surveys application enables subscribers to customize the appearance of their account page by using a custom logo image. Subscribers can upload an image to their account, and the Surveys application saves the image as part of the subscriber's account data in BLOB storage.

Tailspin plans to extend the customization options available to subscribers in future versions of the application. These extensions include customizing the survey pages with the logo and enabling subscribers to upload a cascading style sheets (.css) file to customize the appearance of their survey pages to follow corporate branding schemes.

Tailspin are evaluating the security implications of allowing subscribers to upload custom .css files and plan to limit the cascading style sheets features that the site will support. They will implement a scanning mechanism to verify that the .css files that subscribers upload do not include any of the features that the Surveys site does not support.

Poe says:
Cascading style sheets Behaviors are one feature that the Surveys site will not support.

The current solution allows subscribers to upload an image to a public BLOB container named logos. As part of the upload process, the application adds the URL for the logo image to the tenant's BLOB data stored in the BLOB container named tenants. The TenantController class retrieves the URL and forwards it on to the view.

Scaling Applications by Using Worker Roles

Scalability is an issue for both single-tenant and multi-tenant architectures. Although it may be acceptable to allow certain operations at certain times to utilize most of the available resources in a single-tenant application (for example, calculating aggregate statistics over a large dataset at 2:00 A.M.), this is not an option for most multi-tenant applications where different tenants have different usage patterns.

You can use worker roles in Windows Azure to offload resource-hungry operations from the web roles that handle user interaction. These worker roles can perform tasks asynchronously when the web roles do not require the output from the worker role operations to be immediately available.

Example Scenarios for Worker Roles

The following table describes some example scenarios where you can use worker roles for asynchronous job processing. Not all of these scenarios come from the Surveys application; but, for each scenario, the table specifies how to trigger the job and how many worker role instances it could use.

Note:
You can scale the Update Survey Statistics scenario described in the preceding table by using one queue and one worker role instance for every tenant or even every survey. What is important is that only one worker role instance should process and update data that is mutually exclusive within the dataset.

Looking at these example scenarios suggests that you can categorize worker roles that perform background processing according to the scheme in the following table.

Triggers for Background Tasks

The trigger for a background task could be a timer or a signal in the form of a message in a queue. Time-based background tasks are appropriate when the task must process a large quantity of data that trickles in little by little. This approach is cheaper and will offer higher throughput than an approach that processes each piece of data as it becomes available. This is because you can batch the operations and reduce the number of storage transactions required to process the data.

If the frequency at which new items of data becomes available is lower and there is a requirement to process the new data as soon as possible, using a message in a queue as a trigger is appropriate.

You can implement a time-based trigger by using a Timer object in a worker role that executes a task at fixed time interval. You can implement a message-based trigger in a worker role by creating an infinite loop that polls a message queue for new messages. You can retrieve either a single message or multiple messages from the queue and execute a task to process the message or messages.

Markus says:
You can pull multiple messages from a queue in a single transaction.

Execution Model

In Windows Azure, you process background tasks by using worker roles. You could have a separate worker role type for each type of background task in your application, but this approach means that you will need at least one separate worker role instance for each type of task. Often, you can make better use of the available compute resources by having one worker role handle multiple types of tasks, especially when you have high volumes of data because this approach reduces the risk of under-utilizing your compute nodes. This approach, often referred to as role conflation, involves two trade-offs. The first trade-off balances the complexity of and cost of implementing role conflation against the potential cost savings that result from reducing the number of running worker role instances. The second trade-off is between the time required to implement and test a solution that uses role conflation and other business priorities, such as time-to-market. In this scenario, you can still scale out the application by starting up additional instances of the worker role. The diagrams in Figure 1 show these two scenarios.

Figure 1

In the scenario where you have multiple instances of a worker role that can all execute the same set of task types, you need to distinguish between the task types where it is safe to execute the task in multiple worker roles simultaneously, and the task types where it is only safe to execute the task in a single worker role at a time.

To ensure that only one copy of a task can run at a time, you must implement a locking mechanism. In Windows Azure, you could use a message on a queue or a lease on a BLOB for this purpose. The diagram in Figure 2 shows that multiple copies of Tasks A and C can run simultaneously, but only one copy of Task B can run at any one time. One copy of Task B acquires a lease on a BLOB and runs; other copies of Task B will not run until they can acquire the lease on the BLOB.

Figure 2

The MapReduce Algorithm

For some Windows Azure applications, being limited to a single task instance for certain large calculations may have a significant impact on performance. In these circumstances, the MapReduce algorithm may provide a way to parallelize the calculations across multiple task instances in multiple worker roles.

The original concepts behind MapReduce come from the map and reduce functions that are widely used in functional programming languages such as Haskell, F#, and Erlang. In the current context, MapReduce is a programming model (patented by Google), that enables you to parallelize operations on a large dataset. In the case of the Surveys application, you could use this approach to calculate the summary statistics by using multiple, parallel tasks instead of a single task. The benefit would be to speed up the calculation of the summary statistics, but at the cost of having multiple worker role instances.

Jana says:
For the Surveys application, speed is not a critical factor for the calculation of the summary statistics. Tailspin is willing to tolerate a delay while this summary data is calculated, so it does not use MapReduce.

The following example shows how Tailspin could use this approach if it wants to speed up the calculation of the summary statistics.

This example assumes that the application saves survey responses in BLOBs that contain the data shown in Figure 3.

Figure 3

The following table shows the initial set of data from which the application must calculate the summary statistics. In practice, MapReduce is used to process very large datasets; this example uses a very small dataset to show how MapReduce works. This example also only shows the summarization steps for the first multiple-choice question and the first range question found in the survey answers, but you could easily extend the process to handle all the questions in each survey.

The first stage of MapReduce is to map the data into a format that can be progressively reduced until you obtain the required results. Both the map and reduce phases can be parallelized, which is why MapReduce can improve the performance for calculations over large datasets.

For this example, both the map and reduce phases will divide their input into blocks of three. The map phase in this example uses four parallel tasks, each one processes three survey result BLOBs, to build the map shown in the following table.

The next phase reduces this data further. In this example, there will be two parallel tasks, one that processes aggregations 1.X, 2.X, and 3.X, and one that processes aggregation 4.X. It's important to realize that each reduce phase only needs to reference the data from the previous phase and not the original data. The following table shows the results of this reduce phase.

In the next phase, there is only one task because there are only two input blocks. The following table shows the results from this reduction phase.

At this point, it's not possible to reduce the data any further, and the summary statistics for all the survey data that the application read during the original map phase have been calculated.

It's now possible to update the summary data based on survey responses received after the initial map phase ran. You process all new survey data using MapReduce and then combine the results from the new data with the old in the final step.

Scaling the Surveys Application

This section describes how Tailspin designed one functional area of the Surveys application for scalability. Tailspin anticipates that some surveys may have thousands, or even hundreds of thousands of respondents, and Tailspin wants to make sure that the public website remains responsive for all users at all times. At the same time, survey owners want to be able to view summary statistics calculated from the survey responses to date.

Goals and Requirements

In Chapter 3, "Accessing the Surveys Application," you saw how Tailspin uses two websites for the Surveys application: one where subscribers design and administer their surveys, and one where users fill out their survey responses. The Surveys application currently supports three question types: free text, numeric range (values from one to five), and multiple choice. Survey owners must be able to view some basic summary statistics that the application calculates for each survey, such as the total number of responses received, histograms of the multiple-choice results, and aggregations such as averages of the range results. The Surveys application provides a pre-determined set of summary statistics that cannot be customized by subscribers. Subscribers who want to perform a more sophisticated analysis of their survey responses can export the survey data to a SQL Azure instance.