Difference between revisions of "CloudScale Architectural Templates"

From CloudScale
Redirect page
Jump to: navigation, search
(Redirected page to HowTos)
(32 intermediate revisions by one user not shown)
Line 1: Line 1:
CloudScale Architectural Templates (CATs) are the set of [[Architectural Templates]] (ATs) we collected for CloudScale.
#REDIRECT [[HowTos]]
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.
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.
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~\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~\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)
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}).
For this scenario, Fig.~\ref{fig:SPOSAD} shows an instantiation of a SPOSAD \arch.
Note that this instantiation extends the simplified SPOSAD instantiation of Sec.~\ref{sec:scenario}.
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.
A 3-tier architecture that requires multi-tenancy and/or scalability.
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.\footnote{The same holds for option two and three as well.}
In summary, we need to balance the following forces:
\item The system should be able to cope with increasing and decreasing load.
\item The system should always be able to serve its customers.
\item The system should be cost-efficient.
\item The system can serve multiple tenants.
\item Cloud computing environments have pre-defined characteristics that should be optimally utilized.
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.
In Fig. TODO, we provide the CAT type for 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.
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.
\paragraph{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.
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.
In Sec.~\ref{sec:scenario}, we describe a simplified SPOSAD \arch.
===Known Uses===
Several PaaS can be described in terms of SPOSAD: Force.com, Windows Azure, Google App Engine, and SAP HANA Cloud.
We identified the following benefits for SPOSAD:
\item The system becomes scalable by design.
\item The system can serve multiple tenants by design.
We are aware of the following liabilities for SPOSAD:
\item The middle tier becomes highly restricted because it forbids statefull components. Therefore, legacy systems may have problems to conform to SPOSAD.
\item 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==

Latest revision as of 17:20, 5 November 2013