SPOSAD CAT

From CloudScale
Jump to: navigation, search

The SPOSAD CAT (based on [1]) provides a structure for SaaS applications that are (1) able to serve multiple tenants and (2) are scalable. SPOSAD is based on a 3-tier architecture with presentation, middle, and data tier.

For scalability, SPOSAD requires presentation and application logic components to be stateless, thus, allowing a PaaS to clone these components and to use load balancers for providing access to them. State is either stored at a tenant's browser (cookies) or in the database component. Data is exchanged either synchronously via REST [2] or asynchronously. Application logic accesses the database synchronously for short queries (specified by a timeout) and asynchronously otherwise.

For multi-tenancy, SPOSAD requires (1) a multi-tenant database, for example, by using distributed databases [1], and (2) a metadata manager in the middle tier that queries tenant-specific data from the database. Tenants transmit their tenant IDs via REST to the metadata manager. Tenant-specific data can be used for customized UI and application logic.

Contents

Also Known As

Shared, Polymorphic, Scalable Application, and Data (SPOSAD)

Example

Example CloudScale Architectural Template instantiation for SPOSAD.

SPOSAD targets Web applications that should provide multi-tenancy and/or be scalable. Therefore, the example for the Simplified SPOSAD CAT is a typical scenario for using SPOSAD as well. For this scenario, the figure on the right shows an instantiation of a SPOSAD CAT.

Note that this instantiation extends the Simplified SPOSAD CAT instantiation. For instance, the middle tier is now subdivided into "Application Logic" and "Metadata Management" roles that put SPOSAD's additional constraints on the middle tier area. The Simplified SPOSAD CAT example abstracts from SPOSAD's capability to serve multiple tenants, however, the descriptions for this example also hold here.

Context

A 3-tier architecture that requires multi-tenancy and/or scalability.

Problem

Assume a classical 3-tier system that has to cope with increasing or spiking load scenarios. For instance, a book shop implemented via a classical 3-tier architecture may face a suddenly increasing load before Christmas. When additionally requiring that the shop needs to find customer-specific data, the situation gets even more complicated.

To cope with high load, the shop could simply reject incoming requests. However, this is problematic as the shop provider potentially looses the opportunity to make profit from additional customers.

As a second option, the shop provider could over-provision the book shop such that the shop can cope with unexpected high load scenarios. However, in times with lower load, the provider has to pay additional money for maintaining the shops' infrastructure while making less profit because of fewer customers.

A third option for the provider is to add additional hardware resources once observing load peaks and removing it again when load decreases. For this approach, the provider has to setup and maintain additional resources. This setup may take too long such that the high load situation could already be over (and customers are unsatisfied). Removing hardware resources after high load situations requires additional effort and costs.

To cope with the latter disadvantages, a fourth option is to move the whole book shop to a cloud computing environment. This environment could then take care of automatically and effectively adding and removing resources on demand.

While cloud computing environments can cope with the before-mentioned disadvantages, they still do not guarantee that the book shop will actually scale. The reason for this lack is that the classical 3-tier style does not provide information how additional resources can be utilized (on a software level). Similarly, the 3-tier style provides no guidance for designing a scalable book shop for multiple tenants. Therefore, the shop provider cannot be sure that cloud computing enables the shop to cope with a higher load at all. (The same holds for option two and three as well.)

In summary, we need to balance the following forces:

  • The system should be able to cope with increasing and decreasing load.
  • The system should always be able to serve its customers.
  • The system should be cost-efficient.
  • The system can serve multiple tenants.
  • Cloud computing environments have pre-defined characteristics that should be optimally utilized.

Solution

Implement the system as a 3-tier architecture with stateless middle tier. You can store state on the client site by follow the REST architectural style. You can store state on the data tier by using a normal database.

However, this database should have dedicated support for multi-tenancy based on tenant IDs. Tenants transmit their IDs via REST to the middle tier. On this tier, a metadata manager is responsible to customize the middle tier to the tenants' needs as well as to store and receive tenant-specific data from the database.

Structure

In the following figure, we provide the CAT type for SPOSAD:

SPOSAD CloudScale Architectural Template type.

Dynamics

The following scenarios describe typical dynamic behaviors of systems implemented according to SPOSAD.

Scenario I: Multi-Tenancy

A tenant issues an initial request to the presentation tier by passing its tenant ID. The presentation tier contacts the metadata manager to receive a tenant name for a tenant-specific login screen. For this customization, the presentation tier passes the tenant ID to the metadata manager. The metadata manager contacts the database on the data tier to query the tenant name based on the given tenant ID. Subsequently, the metadata manager returns the tenant name as a result to the presentation tier. The presentation tier then shows the tenant name on the login screen.

Scenario II: Scalability

Suddenly a high amount of tenants begin to use a SPOSAD system operating in a cloud computing environment. The cloud environment duplicates application logic components and begins to load-balance these. This allows the system to cope with the high load. After a while, the load decreases again. The cloud environment, therefore, removes duplicated components again and stops load-balancing.

Implementation

For realizing the REST style, using HTTP should be used.

Example Resolved

Note that SPOSAD does not only describe SaaS applications. It also relates to PaaS environments that host SaaS applications. For example, the database can be a PaaS service that is used by the data tier of the SaaS application.

Variants

We also describe the Simplified SPOSAD CAT.

Known Uses

Several PaaS can be described in terms of SPOSAD: Force.com, Windows Azure, Google App Engine, and SAP HANA Cloud.

Consequences

We identified the following benefits for SPOSAD:

  • The system becomes scalable by design.
  • The system can serve multiple tenants by design.

We are aware of the following liabilities for SPOSAD:

  • The middle tier becomes highly restricted because it forbids statefull components. Therefore, legacy systems may have problems to conform to SPOSAD.
  • Handling multiple tenants increases system complexity.

See Also

SPOSAD includes the 3-tier architecture, REST, and Pipes-and-Filters architectural styles.

References

  1. 1.0 1.1 Koziolek, Heiko. “The SPOSAD Architectural Style for Multi-tenant Software Applications.” In Proc. 9th Working IEEE/IFIP Conf. on Software Architecture (WICSA’11), Workshop on Architecting Cloud Computing Applications and Systems, 320–327. IEEE, 2011.
  2. Fielding, R, and R Taylor. Principled Design of the Modern Web Architecture. Vol. 2. 2. ACM, 2000.