Hosting multiple interrelated multi-tenant applications

This paper proposes a solution to the problem of creating a programmable web platform open to third party developers that supports multiple interrelated multi-tenant applications.

Besides a concrete design there is also a brief reference to why it is important to consider adhering to “productizable” and scale independent design principles when implementing this solution.

For an introduction to parts of the storage service and rendering pipeline click here. Some comments about the future of web portals is here. 

Several different designs solve the problem of implementing a web application. The traditional 3-tier model (Browser-ISS-Data) has been successfully used by the industry and it might be the most cost effective model for simpler, self-hosted scenarios including some types of multi-tenant applications.

Some problems arise when the number of applications hosted in the same environment increases. When the front-end servers host a large number of different applications we have to deal with to resource allocation issues, the lack of real process isolation also makes it hard to debug and understand the applications behavior, managing changes to one application is difficult as it might affect other applications on the server and usually requires replicating many different files to all front end servers.

Another problem of many complex web applications is the lack of separation between layers. Even on initially well thought applications, the Presentation logic and Business logic tend to get mixed as the application evolves and time constrains force developers to take shortcuts.  The virtues of separating Presentation, Business and Data layers have been explained at length in other papers so this will not be covered here. The architecture proposed acts as a forcing function making it very difficult for developer to make these mistakes.

When we say “interrelated applications” what we mean is that we are not talking about disconnected applications. Even when the applications might have dedicated storage and very distinct functionality, the platform discussed here makes it possible to leverage and manage shared components, such as low level UI components, UI standards, CSS files, etc. This makes is possible to enforce the same look and feel for a set of applications.

As mentioned before there are many ways to address these problems. This paper proposes one practical solution; it is by no means the only possibility, just one alternative that is based on already proven and tested concepts.

The major goals of this platform are:

• Support running multiple multi-tenant applications in the same datacenter environment.
• Allow customers a high degree of UI customization.
• Offer a common framework for developing and deploying web applications.
• Integrated support for multiple devices. Such as mobile, smart phones, different browser flavors, XAML, etc.
• Lower application development and maintenance costs.
• Expose applications functionality via a rich web service (SOAP) stack to internal/external developers.
• Provide common mechanism to establish access/storage quotas. Automated systems to monitor and enforce quotas.
• Establish common versioning rules for all web services.
• Common and integrated documentation/SDK support documentation.

In the proposed model, we define a web application as a set of UI components that utilize a set of well defined SOAP web services from the platform stack.

It is not in the current scope to address the problem of hosting customer/partner web services. The assumption is that the web services are under the control of our data centers and the code is completely trusted. As the OS evolves to support sandbox or virtualized secure environments the scope of this platform will be expanded to include these scenarios.

In order to satisfy the goals/requirements we have determined that a 4-tier architecture offers the flexibility and robustness we need. We refer to the first tier as the client tier, typically a browser or a desktop application.

Requests made by clients are initially processed by the second tier, hosted in generic web front ends. We will refer to this tier as the Web Tier. This tier does not have any application specific knowledge it is designed to handle and forward the client requests to the third tier, the application tier. The process of forwarding these requests and keeping the load properly distributed across the application tier is discussed in the description of the Load Balancing and Distribution module.

What follows is a brief description of the four tiers and the most important server types.

Clients can access the storage service via external web services or take advantage of a high performance rendering pipeline that make it possible to support different types of devices (mobile, browser,  silverlight, etc.).

The complete UI experience can be modeled using XML/XSL transformations. The data required for building a shell, page or UI gadget is stored in an XML document. The logic that converts this data into a content (including navigation and other static elements) is generated using XSL transforms.

Although XSL are sometimes more complex that traditional web pages, this architecture enforces a clear separation of content and layout making it possible to redesign a site or application by simple creating new XSL transforms.

When a client makes a request for content, the front-end server receives the request, determines the device type and then sends a request to the rendering service to generate the content. The rendering service contains logic that can select the proper XSL given the device, site and the type of document. There is also logic to support A/B testing scenarios.

All requests are received by a cluster of front-end servers. A front-end server runs generic code that is common to all applications. It has two primary purposes:

• Send to a Client (browser, mobile device, XAML, etc) the UI components required to build the presentation layer.
• Routes SOAP web service calls to internal application clusters via a load balancer and distribution module.

These servers also run code that tracks and monitors user access. They enforce quotas and perform the first authentication steps by translating an external user token into an internal user identifier that will used by other layers to perform authentication.

The server does not run application specific UI components (apsx, ascx) and does not accept postbacks. The only means of transferring data or initiating action for a web application is via the web service layer.

A key component for this service is the load balancer and distribution module. In the next paragraph we outline the major goals of this module.

The goal of the LBD module is to distribute the load to application servers in a way that is most efficient for a given application and takes in consideration application performance as well as data center operations costs.

The most common way to balance a cluster is to incorporate a hardware load balancer that intercepts and routes traffic to a pool of servers. We have generalized and expanded some of the concepts; also the idea is to implement this functionality in software eliminating the need for expensive hardware or complex WLBS implementations. The solution proposed here does not replace the hardware LB that is behind the front end servers. This is only intended for distribution load to internal application servers.

Some of the more specific goals are:

• Client-Server Affinity Management
• Eliminate the need for creating clusters balanced by WLBS or hardware.
• Handling failover scenarios
• Server Load Throttling
• Support for Web Service Versioning and A/B Testing
• Handling overload scenarios
• Automatic Rebalancing
• Minimize hardware costs by eliminating the need for hardware LB’s.
• Minimize operation costs. The LB will have enough information to determine when to turn on/off a server based on load patterns and configuration parameters.

You can read about this module here.

All business logic and high level functionality executes in the application tier. These servers are behind the front end servers and are not directly accessible via the internet. The servers expose functionality only via WCF services and might have dedicated storage or used global storage services depending on the application requirements. The application services leverage a set of shared platform services, including configuration, authentication libraries, etc.

Some examples of these web services could be commerce services, CRM services and financial services.

In a large deployment scenario it is possible to grant access to different product groups to specific application services. Because these services are isolated from the rest of the platform we can minimize and control the impact changes to a given application might have on the entire system. Also, because these servers aren’t accessible directly from the internet the exposed attack surface is reduced and a configuration mistakes on an application server are not likely to leave the platform open to external attacks.

In the application tier also run some core platform services, the most important are: The UI Application service, a SQL based semi-structured storage service, event tracking services and application catalog management service.

The purpose of this service is to assemble the presentation layer required for an application, page or UI component.  In order to achieve high performance and flexibility, the platform makes it possible to balance a pull (AJAX) model  as well as the more traditional push model where the HTML + Data is assembled at the server.

In a typical 3-tier web application the UI is created on the front-end by the aspx page. As we have mentioned, one of the problems in an environment where we host a large number of multi-tenant applications is that the aspx code base becomes unmanageable. Code deployment, versioning, localization and UI customization becomes very difficult and extremely expensive.

You can read more about a personalized gadget based UI here and a demo (silverlight 2 is required for the demo) here.

The purpose of this service is to allow customers and applications to store and retrieve simple XML documents. The service makes it possible for customers to define an XSD schema and then create documents based on this schema. The service handles dynamically handles changes to the schemas and provides simple ways to index and relate documents to build simple data models. This makes it possible to store things such as application configuration parameters, localization strings and custom entities such as blogs.

Although the word “productizable” does not exist, the concept is clear. We should consider building most of this platform in such way that could be converted and sold as a product. The reason is that many of our customers have to solve the exact same problems we have addressed. For many a hosted service might be a good way to try the technology, at some point, because of the level of customization required, the security restrictions or the integration with existing systems makes it necessary for the customer to host the platform on their own premises. By offering both, a hosted service and a product we give our customers a much broader range of possibilities. This isn’t a new idea; some of our products are already available in these two flavors.

The “scale independent” term refers to designing the components and the platform to scale from a single computer to large multi-cluster environments. There are many techniques to do this, adopting web services, working with loosely coupled components, pluggable storage concepts. There are limitations to this idea but in general it has huge benefits because it makes it possible for our customers to adopt/test a small set of functionality and easily reconfigure the system, without losing past investments to accommodate higher loads.