Difference between revisions of "CloudScale Architectural Templates"

From CloudScale
Jump to: navigation, search
Line 4: Line 4:
   
 
==SPOSAD CAT==
 
==SPOSAD CAT==
The SPOSAD architectural style~\cite{koziolek_sposad_2011} provides a structure for SaaS applications that are (1) able to serve multiple tenants and (2) have support for scalability.
+
The SPOSAD architectural style TODO(cite koziolek_sposad_2011) provides a structure for SaaS applications that are (1) able to serve multiple tenants and (2) have support for scalability.
 
SPOSAD is based on a 3-tier architecture with presentation, middle, and data tier.
 
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.
 
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.
 
State is either stored at a tenant's browser (cookies) or in the database component.
Data is exchanged either synchronously via REST~\cite{Fielding_Taylor_2000} or asynchronously.
+
Data is exchanged either synchronously via REST TODO(cite Fielding_Taylor_2000) or asynchronously.
 
Application logic accesses the database synchronously for short queries (specified by a timeout) and asynchronously otherwise.
 
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~\cite{koziolek_sposad_2011}, and (2)~a metadata manager in the middle tier that queries tenant-specific data from the database.
+
For multi-tenancy, SPOSAD requires (1) a multi-tenant database, for example, by using distributed databases TODO(cite koziolek_sposad_2011), 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.
 
Tenants transmit their tenant IDs via REST to the metadata manager.
 
Tenant-specific data can be used for customized UI and application logic.
 
Tenant-specific data can be used for customized UI and application logic.
Line 20: Line 20:
   
 
===Example===
 
===Example===
 
 
SPOSAD targets Web applications that should provide multi-tenancy and/or be scalable.
 
SPOSAD targets Web applications that should provide multi-tenancy and/or be scalable.
Therefore, the example of Sec.~\ref{sec:scenario} is a typical scenario for using SPOSAD (like we argued in Sec.~\ref{sec:scenario}).
+
Therefore, the example for the Simplified SPOSAD CAT TODO(add ref) is a typical scenario for using SPOSAD as well.
For this scenario, Fig.~\ref{fig:SPOSAD} shows an instantiation of a SPOSAD \arch.
+
For this scenario, Fig. TODO shows an instantiation of a SPOSAD CAT.
   
Note that this instantiation extends the simplified SPOSAD instantiation of Sec.~\ref{sec:scenario}.
+
Note that this instantiation extends the Simplified SPOSAD CAT TODO(add ref) 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.
 
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.
Our example in Sec.~\ref{sec:scenario} abstracts from SPOSAD's capability to serve multiple tenants, however, the descriptions of the latter section also hold here.
+
The Simplified SPOSAD CAT TODO(add ref) example abstracts from SPOSAD's capability to serve multiple tenants, however, the descriptions for this example also hold here.
   
 
===Context===
 
===Context===
 
 
A 3-tier architecture that requires multi-tenancy and/or scalability.
 
A 3-tier architecture that requires multi-tenancy and/or scalability.
   
 
===Problem===
 
===Problem===
 
 
Assume a classical 3-tier system that has to cope with increasing or spiking load scenarios.
 
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.
 
For instance, a book shop implemented via a classical 3-tier architecture may face a suddenly increasing load before Christmas.
Line 56: Line 53:
 
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).
 
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 provide so guidance for designing a scalable book shop for multiple tenants.
 
Similarly, the 3-tier style provide so 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.\footnote{The same holds for option two and three as well.}
+
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:
 
In summary, we need to balance the following forces:
\begin{itemize}
+
* The system should be able to cope with increasing and decreasing load.
\item The system should be able to cope with increasing and decreasing load.
+
* The system should always be able to serve its customers.
\item The system should always be able to serve its customers.
+
* The system should be cost-efficient.
\item The system should be cost-efficient.
+
* The system can serve multiple tenants.
\item The system can serve multiple tenants.
+
* Cloud computing environments have pre-defined characteristics that should be optimally utilized.
\item Cloud computing environments have pre-defined characteristics that should be optimally utilized.
 
\end{itemize}
 
   
 
===Solution===
 
===Solution===
 
 
Implement the system as a 3-tier architecture with stateless middle tier.
 
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 client site by follow the REST architectural style.
Line 76: Line 72:
   
 
===Structure===
 
===Structure===
 
 
In Fig. TODO, we provide the CAT type for SPOSAD.
 
In Fig. TODO, we provide the CAT type for SPOSAD.
   
 
===Dynamics===
 
===Dynamics===
 
 
The following scenarios describe typical dynamic behaviors of systems implemented according to SPOSAD.
 
The following scenarios describe typical dynamic behaviors of systems implemented according to SPOSAD.
   
\paragraph{Scenario I: Multi-Tenancy} A tenant issues an initial request to the presentation tier by passing its tenant ID.
+
====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.
 
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.
 
For this customization, the presentation tier passes the tenant ID to the metadata manager.
Line 90: Line 84:
 
The presentation tier then shows the tenant name on the login screen.
 
The presentation tier then shows the tenant name on the login screen.
   
\paragraph{Scenario II: Scalability} Suddenly a high amount of tenants begin to use a SPOSAD system operating in a cloud computing environment.
+
====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 can begins to load-balance these.
 
The cloud environment duplicates application logic components can begins to load-balance these.
 
This allows the system to cope with the high load.
 
This allows the system to cope with the high load.
Line 105: Line 99:
   
 
===Variants===
 
===Variants===
In Sec.~\ref{sec:scenario}, we describe a simplified SPOSAD \arch.
+
We also describe the Simplified SPOSAD CAT TODO(add ref).
   
 
===Known Uses===
 
===Known Uses===
Line 112: Line 106:
 
===Consequences===
 
===Consequences===
 
We identified the following benefits for SPOSAD:
 
We identified the following benefits for SPOSAD:
\begin{itemize}
+
* The system becomes scalable by design.
\item The system becomes scalable by design.
+
* The system can serve multiple tenants by design.
\item The system can serve multiple tenants by design.
 
\end{itemize}
 
   
 
We are aware of the following liabilities for SPOSAD:
 
We are aware of the following liabilities for SPOSAD:
\begin{itemize}
+
* The middle tier becomes highly restricted because it forbids statefull components. Therefore, legacy systems may have problems to conform to SPOSAD.
\item 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.
\item Handling multiple tenants increases system complexity.
 
\end{itemize}
 
   
 
===See Also===
 
===See Also===

Revision as of 08:18, 10 July 2013

CloudScale Architectural Templates (CATs) are the set of Architectural Templates (ATs) we collected for CloudScale.

As illustrated in Fig. TODO, our CATs Repository provides CATs for designing and analyzing scalable SaaS applications. On this page, we list and describe the CATs we collected in this repository. For our descriptions, we follow the description template of Buschmann et al. ("A System of Patterns: Pattern-Oriented Software Architecture: 1"; Wiley Software Patterns; 1996) but use our AT notation where feasible.

Contents

SPOSAD CAT

The SPOSAD architectural style TODO(cite koziolek_sposad_2011) provides a structure for SaaS applications that are (1) able to serve multiple tenants and (2) have support for scalability. 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 TODO(cite Fielding_Taylor_2000) 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 TODO(cite koziolek_sposad_2011), 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.

Also Known As

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

Example

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

Note that this instantiation extends the Simplified SPOSAD CAT TODO(add ref) 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 TODO(add ref) 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 provide so 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 Fig. TODO, we provide the CAT type for SPOSAD.

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 can 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 TODO(add ref).

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.

SAP HANA Cloud CAT