Cloud-Oriented Platforms: Bearing on Application Architecture and Design Patterns

2012 IEEE Eighth World Congress on Services
Cloud-Oriented Platforms: Bearing on Application
Architecture and Design Patterns
Balwinder Sodhi and T.V. Prabhakar
Dept. of Computer Science and Engineering, IIT Kanpur, UP 208016 India
{sodhi, tvp}@cse.iitk.ac.in
important architectural properties of the computing platform
and that of its constituent components? c) How can the above
properties be leveraged systematically to address different
business problem scenarios?
In this paper we address the above mentioned points. We
bring out architecturally significant properties of various computing platforms and their key underlying components. Also,
we bring out the implications of such properties for the design
and architecture of the applications. We then demonstrate
how this knowledge can be used to device design patterns
which address certain commonly occurring business problem
scenarios.
This paper is organized into five sections. In Section II we
discuss related work pertaining to the area of presented work.
Various computing platforms are examined in detail, from the
application architecture viewpoint, in Section III. In Section
IV we propose a novel architectural design pattern called
Platform Level Aspect-Orientation and describe an example
implementation of it. We conclude this paper in Section V.
Abstract—The business problems that are handled by today’s
computing systems have grown much in complexity. Handling
data volumes in excess of peta-scale are no longer restricted to
few narrow application areas. Computing platforms ecosystem
has also advanced with virtualization based and cloud oriented
platforms emerging as most disruptive ones. Unique characteristics of such platforms have important implications for how the
architecture of business applications is designed – particularly
the ability to achieve certain non-functional requirements. In
this paper we first bring out properties of the said computing platforms that are architecturally significant from business
applications’ view point. We then bring out implications that
such properties have for software design and architecture. We
demonstrate the use of this knowledge about platform properties
by devising a novel architectural design pattern “Platform Level
Aspect-Orientation” which can be used to address a variety of
application scenarios.
Index Terms—Software Architecture Design, Non-functional
Requirements, Design Patterns, Quality Attributes, Cloud Computing, Virtualization
I. I NTRODUCTION
Experience shows that the design and analysis skills alone
are not sufficient for evaluating and synthesizing the application architectures. It is critical to deeply understand the
key properties of target computing platforms and impact of
such properties on functional and non-functional aspects of
the system.
It has been observed that the computing devices have
continuously improved in their abilities over past several
years. Virtualization and cloud oriented platforms have made it
possible to harness the improved hardware capabilities. From
perspective of the consumers, monetary and operational factors
have been the major drivers for accelerated adoption of cloud
oriented computing platforms. The argument of converting
capital expenditure to operational expenditure by enterprises
is now well known in this regard. On the other hand, primary
concerns of the providers have been around optimization of
different resources (both software and hardware) in a virtualized and multi-tenant environment like cloud. Majority of the
literature in this area today is centred around one of these two
extremes. From perspective of the application architect and
other technical stakeholders who are seeking to design, build
and maintain software systems on/for cloud and virtualized
platforms, there are questions that still remain inadequately
answered. For example: a) Is designing the architecture of
a software system same as for a non-cloud environment?
b) From the viewpoint of a candidate application, what are
978-0-7695-4756-5/12 $26.00 © 2012 IEEE
DOI 10.1109/SERVICES.2012.49
II. R ELATED W ORK
Majority of the reported work in literature deals with very
specific aspects of cloud and virtualization based computing
platforms. For instance, the architectural requirements of various types of cloud platforms have been discussed by Rimal
et. al. [1]. They have attempted to classify these platforms
according to the requirements of different stakeholders and
also analyse the architectural features of cloud computing.
A decomposition of the cloud into main five layers, and
exploration of the interrelations between these layers as well
as their inter-dependency on its constituent components has
been discussed by Youseff et. al. [2]. Oliveira et. al. [3] apply
taxonomy techniques in the cloud computing domain from an
e-Science perspective.
On the other end of spectrum are cloud vendors who
provide white papers and other technical literature about their
specific offerings. For instance Amazon Web Services (AWS)
has a range of documentation [4], [5] that describes how
to solve different types of business problems by using their
different offerings. Particularly, [4] illustrates different aspects
of building applications by leveraging the services available
in the Internet cloud.
Similarly literature exists for others such as Azure [6], [7].
An interesting discussion of application types that are suitable
409
278
is a software representation of a physical computer. Virtualization decouples the OS from physical hardware resulting in
better operational flexibility and utilization of the underlying
hardware. A VM is executed by the Virtual Machine Monitor
(VMM) on a physical hardware shared with other VMs. Often
the applications running on a VM cannot tell (or care) whether
they are running inside a VM instead of a dedicated physical
machine.
From implementation standpoint, there are two main types
of virtualization: a) OS based as in Solaris containers [15],
and b) Virtual Machine Monitor (VMM) based as in Xen
[16]. There are further sub-categories of the VMM based
virtualization: bare metal (a.k.a Type-1) and hosted (a.k.a
Type-2) [17]. Then there can also be VMMs that are designed
to take advantage of special purpose hardware features such
as of recent Intel processors [18].
We examined the internals of major virtualized platforms
such as [15], [16], [18]–[21] and brought out their key architectural properties. Among such properties some are common
across different kinds of virtualized platforms whereas some
are platform specific. The properties that are common to
different kinds of virtualized platforms are as below:
i. Abstraction of physical hardware resources as software
entities.
ii. Abstraction of the hardware interface APIs (e.g.
VMware’s products export an x86-based computer).
iii. Coarse grained computing environment isolation and VM
level multi-tenancy.
iv. Poor performance isolation, i.e., VMs sharing an underlying hardware fabric can interfere with each other’s
performance.
v. Encapsulation of all software that runs on the physical
hardware
vi. Limited hardware control capabilities for VMs (e.g. cannot control host power management).
vii. VM check-pointing via snap shots.
viii. VM migration (both live and offline).
OS based virtualized platforms have the following important
properties:
i. Isolation of VMs is defined in software under a shared
OS/kernel instance.
ii. Root privileged tasks (e.g. loading a device driver, changing IP in a VM) need to be performed in the host OS, or
the application has to be modified to work in a VM.
iii. Applications use the OS’s normal system call interface
instead of emulation or via VMMs.
iv. A VM cannot have a guest OS (or in some cases even
kernel) different from the host one.
v. Often it uses file-level copy-on-write mechanisms instead
of the block-level copy-on-write schemes common on
VMM based environments.
As discussed in the Section III-B, most of the above
properties of the virtualized computing platforms have found
innovative application in the development of cloud oriented
computing platforms. They also allow for very interesting
for cloud computing, and also some patterns and scenarios
have been described in [6].
All of these works present interesting treatment of different
but focussed areas related to cloud computing platforms. To
an architect or a software designer, who seeks to leverage
the unique technical capabilities offered by such computing
platforms, they do not provide adequate insights about architecturally significant aspects of these platforms. For instance,
they do not adequately discuss the architecturally significant
properties of different types of resource virtualization which
forms the heart of entire cloud computing ecosystem. The said
works also do not address issues of how to leverage such
properties of the platforms for solving variety of software
architecture problems. In this regard, there are questions
without adequate and clear answers. Some of the important
ones are:
i. From perspective of an application, what are the architecturally significant properties of a computing platform
and that of its constituent components?
ii. What application design paradigms a computing platform
encourages and is designed for?
iii. How do the above two points impact various functional
and non-functional aspects of a candidate application?
iv. Does existing software design and architecture body of
knowledge applies as-is to cloud and virtualized computing platforms?
The aim of the presented work is to address the above
mentioned gaps.
III. A RCHITECTURAL P ROPERTIES OF C OMPUTING
P LATFORMS
The set of concepts, components and design paradigms
which forms the core of an application’s development and
deployment environment is termed as a computing platform
in this paper. We are primarily focussing on two categories
of computing platforms viz. Virtualized and Cloud oriented.
Each of these platforms have further sub-categories and they
all have unique properties. In sections that follow, we bring
out the such architectural properties of the said platforms.
These properties have important implications from application
architecture and deployment perspective; concept map shown
in Fig. 1 depicts this context. We examined in detail the
software architecture and best practices knowledge from [8]–
[14] for determining the implications of such properties for
the application architecture.
In Section IV, we demonstrate the use of this knowledge
about architecturally significant properties of computing platforms in devising a novel architectural design pattern for
addressing certain types of application scenarios.
A. Virtual Machine Based
The term virtualization is applicable to a broad set of
entities such as hardware resources like devices, servers and
networks, and to software entities like operating systems and
applications. Central entity is a Virtual Machine (VM) which
279
410
Fig. 1.
Computing platforms and bearing on architecture: Problem context
viii. Sub-optimal billing mechanisms. Users are billed on asused basis.
ix. Sub-optimal metering techniques. Related to performance
isolation limitations of the VMMs.
x. Lack of detailed and fine grained resource monitoring
mechanisms. A limited set of log traces generated by the
VMM while executing your VM are provided.
xi. Difficult to assess software licensing structure, especially
in complex deployment scenarios where multiple licenses
of different software are used in a single environment.
xii. Potential to abuse the relative anonymity behind acquiring
and usage models for cloud services.
and useful applications in modern data centres as well as in
personal computing environments.
B. Cloud Oriented
Virtualization technologies form the core of entire cloud
computing ecosystem. Hence all the properties of virtual
computing platforms that we brought out in Section III-A
are also available on the cloud oriented computing platforms.
There are additional properties such as self service and automation of resource provisioning and management etc. that
cloud oriented computing platforms provide. Therefore, the
computing platform capacity can be elastic in nature and
can expand without manual intervention in response to the
application’s changing demands.
The manageability and operational aspects of the cloud
oriented platforms are the key differentiators w.r.t. the plain
virtualized computing platforms. [22], [23] provides the
detailed treatment of the definition and highlights of an
Infrastructure/Platform/Software as a Service (XaaS) delivery
models. It also explains that what is commonly understood
by various deployment models such as private, public, hybrid
and community of the cloud computing. Therefore, the focus
in this paper is mainly on those architectural properties of such
models as are relevant from the viewpoint of an application
which one is seeking to build for cloud deployment. In the
presented work, various features and available implementation details of different cloud platforms [24]–[31] have been
explored to identify their key properties. The resultant list of
such properties of the cloud oriented computing platforms, as
relevant for an application’s design is:
i. Elastic nature of computing resources.
ii. Ability to automate provisioning tasks.
iii. Self-service provisioning.
iv. Measured service.
v. Computing as a utility accessible over the network.
vi. Lack of standards for key services such as security, VM
control and management among others.
vii. Lack of absolute control on data and computing assets
custody.
Please note that only those properties that are not specific to
any particular service or deployment model of cloud oriented
platform are shown in the above list. The model specific
properties are discussed as below.
IaaS Cloud Specific: An IaaS cloud platform provides raw
computing infrastructure in the form of a VM, some virtual
storage and networking.
i. Cloud user is responsible for installing and managing all
the software on the VM.
ii. Allows resource utilization monitoring and reacting to
different types of platform level events.
iii. Applications running in the VM are responsible for
dealing with the reactions to above mentioned events.
For instance, a configured reaction for a “CPU utilization
threshold reached event” may be to add more instances
of the VM. It is then expected that the architecture of the
application(s) running on the VM allows to harness the
newly added VM’s capacity.
iv. Limited control on networking components, e.g. host
firewalls.
v. Concerns, such as of security and isolation guarantees,
arising out of shared underlying components (e.g. virtualization layer).
PaaS Cloud Specific:
i. No control of underlying infrastructure (network, servers,
operating systems, or storage).
280
411
We brought out important architectural properties of different platforms in Section III. For instance, the most important
property of virtualization based platforms is their ability to
provide software abstractions for hardware resources. Among
other things, this property allows the VMs to be programmatically examined, controlled and saved like a file. It helps
achieve isolation and multi-tenancy at platform level. Fig.
2 makes this point more clear where it is shown side-byside with the process and thread level isolation semantics.
Such properties of virtualization based platforms have greatly
influenced the architecture of cloud based platforms.
We would like to note that some of the properties of various
platforms are very fundamental to that platform and are permanent, while there are few properties that may change with
advancements in respective state-of-the-art. For instance, the
software abstraction of hardware resources is a fundamental
property. On the other hand, properties like poor performance
isolation and limited hardware control, may eventually become
less significant with advances in respective state-of-the-art. As
such, the leverage that an application architect can derive from
different properties will vary in purpose and effect.
1) Implications for an Architect: It is important to note
that, except in cases of special purpose VMMs, an application
itself is often unaware of the fact that the underlying hardware
resources that it is using are virtual. Therefore, the application
architects have to design application architecture in such a
manner so as to leverage the unique properties afforded by
such computing platforms. He/she needs to follow the usual
architecture design methods to ensure that the system’s functional and non-functional requirements are properly addressed.
The main difference is that now the said platforms have
brought in more properties that the architect may exploit
and/or have to consider during design decisions.
For instance, the architect can possibly leverage elastic
nature of computing resources on an IaaS cloud to throw in
more capacity dynamically at runtime when the application
demands it, thus making the scaling easier. However, merely
deploying an application on a cloud based platform will not
automatically make it scalable. Suitable architectural patterns
that harness the properties of target cloud oriented computing
platform, have to be utilized (or crafted) by the architects in
order to achieve desired QAs.
We observe that best benefits from the said virtualization
and cloud based platforms can be derived if applications
exhibit the following characteristics:
i. Parallelism to allow partitioning the computation work.
ii. Business logic is stateless and have semantic interoperability with collaborating components.
iii. Have loosely coupled and modular components.
iv. Designed to be service oriented.
Clearly, the architectural properties of platforms as discussed in previous sections can serve as additional building
blocks for software architects to exploit. In the following we
leverage our findings about the platform properties for devising
an architectural design pattern which addresses a variety of
application scenarios.
ii. Can control deployed applications and possibly its hosting environment configurations.
iii. Allows only provider supported programming languages,
tools, APIs and components to build applications.
SaaS Cloud Specific:
i. No control of underlying infrastructure (network, servers,
operating systems, storage, or individual application capabilities).
ii. Allows control of a limited set of user-specific application
configuration settings.
Private Cloud Specific:
i. Operated solely for one organization.
ii. Total ownership, control and custody of applications, data
and computing assets.
iii. Allows custom configurations of cloud infrastructure.
iv. Often has a homogeneous virtualization environment.
Public Cloud Specific:
i. Cloud infrastructure is made available to the general
public for a fee.
ii. Ownership of cloud infrastructure lies with the organization who is selling cloud services.
iii. Cloud service provider has the custody and control of
applications, data and computing assets hosted on cloud.
iv. Often has homogeneous virtualization environment.
Community Cloud Specific:
i. Cloud infrastructure is shared by several organizations.
ii. Supports a specific community that has shared
goals/concerns.
iii. Member organizations have total ownership, control and
custody of applications, data and computing assets.
Hybrid Cloud Specific:
i. A logical arrangement that combines two or more disparate clouds (private, community, or public).
ii. Each constituent cloud remains a unique entity retaining
its own properties.
In the subsequent sections we discuss implications of the
above said platforms’ properties from software architecture
perspective.
IV. B EARING ON A PPLICATION A RCHITECTURE AND
D ESIGN PATTERNS
The ability of any software system to achieve certain quality
is determined by a) Properties of the underlying platform on
which the system is built b) How the said properties have
been harnessed (or mitigated) when designing architecture of
the system.
Clearly, if a host platform on/for which an application
is being built, does not possess the properties required for
ensuring a QA, then that QA in the application gets adversely
impacted. For instance, if multitasking (e.g. via threads) is
not supported on a platform, performance of applications
built on/for that platform will suffer. Therefore, host platform
properties influence the architecture of an application which
is built on such a platform.
281
412
Coarse
Finer
Isolation granularity
A single threaded process
VM
Data
VM
Applications
Disk
Files
Registers
VM
Process
Files
Process
CPU
Threads in a process
A single threaded process
Stack
Process
Network
Data
Files
Registers
Registers
Stack
Stack
Code
Code
Memory
Virtual
Hypervisor
Disk
NIC
Processor
Memory
Physical Hardware
Fig. 2.
Multi-tenancy and isolation models
actions has been a limitation of the physical systems. For
example, one cannot programmatically add a new application
server instance when the capacity of the existing application
server farm has peaked out.
Forces:
In keeping with the space requirements and readability of
this paper, we have used a concise format to describe only the
key elements of the pattern. The pattern description explains
the problem context, forces and the solution.
Platform Level Aspect-Orientation
– Cross-cutting concerns exist at computing platform level.
For example, software and hardware resource monitoring
and automatic control.
– In a physical computing platform it is difficult to programmatically monitor and react to the events arising at
platform level.
– The corrective and control actions for physical computing
platforms can be slow or even impossible in some cases.
Problem Context: There are software design and implementation concerns which apply at the coarse-grained computing
environment/platform level, and they cut across the applications. Examples of such cross cutting platform level concerns:
– Monitoring and reacting to the attacks happening on a
computing environment.
– Auditing, logging and monitoring of critical system indicators including the application level ones and reacting
to them.
– Resource billing and quota enforcement.
– System level management and operations policy compliance.
– Auto-scaling events for computing resources.
– Automated disaster/failure recovery.
The concerns listed above are valid or applicable at the
entire computing environment level. Primary issue is that
with most physical computing environments it is difficult to
programmatically react to the events arising at the platform
level. Some of the examples of such events are: CPU, memory,
disk and processing load on a system etc. reaching certain
threshold. Other examples of such scenarios include specialized system level monitoring and control requirements. Even
though the abilities to monitor such events has existed since
long, the lack of capabilities that allow reacting to such events
in an automatic/programmatic manner so as to take corrective
Solution: Closer examination of the problem context and
forces reveals that, conceptually, the problem scenario has
similarities with the Aspect Orientation (AO) paradigm [32].
Focus in case of AO paradigm is mainly on the crosscutting
concerns at individual program level. The strength of AO
paradigm lies in encapsulating the crosscutting artifacts and
completely keeping them separated from business logic to
enable their reuse. However, in the scenario at hand, the crosscutting concerns are applicable at a much coarser level and
across applications. Clearly, the natural direction to look for
a solution here is to identify platform properties which may
allow addressing the said issues.
Examining the platform properties as discussed in Section
III and IV, we find that one can utilize the property “software
abstraction of hardware resources” that virtualized platforms
offer, for examining and controlling the computing resources.
Being software entities, the virtual hardware resources and
entire VMs are much easier to examine, configure and control
282
413
Aspect
definitions
Platform aspects
service
VM management
APIs of VMM
VM snapshot store
controls
Aspect agent
VM control agent
Applications
Aspect agent
VM control agent
VM management
APIs of VMM
VM
Applications
calls
VM-1
VM-n
Application
Fig. 3.
Platform Level Aspect-Orientation Implementation
Monitoring agent
notify
Check-point
monitoring service
uses
programmatically.
Logical architecture for the proposed solution is shown in
Fig. 3. The dotted arrow lines indicate the VM control interactions, whereas the solid arrow lines depict the interactions
between aspect service and agent. The key components of this
solution are:
Checkpointing
policies
Fig. 4.
– Aspect agent. It is deployed on each VM and its main
responsibility is to examine and monitor the system as
specified by the aspect definitions.
– Platform aspects service. It monitors the aspect agents
and reacts according to the aspect definitions by possibly
sending out VM control commands.
– Aspect definitions. They specify in a structured manner
the system indicators/state to be examined and monitored.
– VM control agent. It is deployed on the VM and allows
controlling the VM.
Example Scenario Implementation
Platform-level Aspect Orientation pattern as described in Section IV-1 can be employed to address this problem. An outline
of the solution is depicted in Fig. 4. In this particular case, the
long running jobs can be deployed in VMs. These VMs are
check-pointed by periodically taking snapshots based on some
policy/aspect definition. On detecting failures, the VM can be
restored to a previously known good state thus preventing the
loss of partially completed work.
An added benefit of such an approach is that this solution
can be generic in nature, that is, it need not have application
specific failure recovery implementation. Hence a common
VM monitoring and control mechanism can be used to checkpoint different applications/VMs, thus saving the development
maintenance costs. One may observe that this solution is a
specialized version of the generic solution shown in Fig. 3.
The monitoring agent periodically notifies the application’s
status to a check-point monitoring service. Existing standards
and technologies such as Java Management Extensions (JMX)
API or similar can be used to build the monitoring agent and
the check-point monitoring service components. The conditions under which to check-point and restore a VM’s state are
handled by specifying check-pointing policies or rules. The
check-pointing and restore of VM is carried out via the VM
management APIs exposed by the VMM.
This solution can be viewed as a fusion of three ideas:
a) Observer pattern b) The feedback-and-control tactics and
c) Abstracting out system level cross-cutting concerns. The
aspect agent and service roughly correspond to the observable
and observer. The reactive commands are sent to the VMs by
the aspect service via VM control agent.
Implementation Scenario Example: A common business
application scenario is the execution of long running tasks
with chain or pipeline type of dependencies. For instance,
in investment banking industry it is common to find nightly
cron jobs which download large volumes of daily stock
markets data and feed it into different kinds of analytics and
learning algorithms or transformations of varying kinds. Often
such jobs are long running and failures in the middle are
costly. Impacts of such failures get further compounded when
multiple applications have dependencies forming a chain. To
handle the failures without losing partially completed work
requires complex programming solutions which are expensive
to develop, debug, test and maintain. Such solutions are
often implemented in application specific manner and are not
reusable across applications. It is desirable to have simpler,
cheaper and reusable solution to handle failure recovery in
the said scenario.
It is easy to observe that the concern of failure monitoring
and recovery cuts across different applications. Solution like
V. C ONCLUSION
We have presented an in-depth study of cloud oriented and
virtualized computing platforms. Most existing literature on
this subject deals either with only a narrow aspect of the
said platforms, or it is vendor’s offering specific in nature.
In this paper, we have approached the said platforms from an
application’s design and architecture perspective. That is, we
examined the said platforms to bring out their key architectural
283
414
properties and their implications for the design of an application. For instance, the most important and useful property
of the platforms is the software abstraction of hardware
which allows for a fluid computing environment. Such a fluid
computing environment can be examined, compared, saved,
moved around over the wire and monitored by programmatic
means. Properties such as this can be exploited to achieve
certain QAs. In the presented worn we have shown the efficacy
of our findings by exploiting the said platform properties
to devise a novel architectural design pattern. This design
pattern addresses commonly occurring application scenarios
across business domains. Solving those application scenarios
in the past was limited by the purely physical nature of the
computing environments. We believe that our findings can be
useful in the evaluation of architectural design decisions.
[19] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, “kvm: the
linux virtual machine monitor,” in Proceedings of the Linux Symposium,
vol. 1, 2007, pp. 225–230.
[20] J. Watson, “Virtualbox: bits and bytes masquerading as machines,”
Linux J., vol. 2008, February 2008. [Online]. Available: http:
//dl.acm.org/citation.cfm?id=1344209.1344210
[21] B. des Ligneris, “Virtualization of linux based computers: The linuxvserver project,” High Performance Computing Systems and Applications, Annual International Symposium on, vol. 0, pp. 340–346, 2005.
[22] P. Mell and T. Grance, “The nist definition of cloud computing,”
National Institute of Standards and Technology, vol. 53, no. 6, 2009.
[23] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwinski,
G. Lee, D. Patterson, A. Rabkin, I. Stoica et al., “Above the clouds:
A berkeley view of cloud computing,” EECS Department, University of
California, Berkeley, Tech. Rep. UCB/EECS-2009-28, 2009.
[24] Amazon, “Amazon web services documentation,” https://aws.amazon.
com/documentation/, Amazon Inc., August 2011.
[25] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, and D. Zagorodnov, “The eucalyptus open-source cloud-computing
system,” in Proceedings of the 2009 9th IEEE/ACM International
Symposium on Cluster Computing and the Grid, ser. CCGRID ’09.
Washington, DC, USA: IEEE Computer Society, 2009, pp. 124–131.
[26] K. Keahey, M. Tsugawa, A. Matsunaga, and J. Fortes, “Sky computing,”
Internet Computing, IEEE, vol. 13, no. 5, pp. 43 –51, 2009.
[27] OpenNebula, “Opennebula 2.2 documentation,” http://www.opennebula.
org/documentation:documentation, OpenNebula Project, retrieved: August 2011.
[28] C. . Xen, “Xen cloud platform - open source software to build private and
public clouds,” http://xen.org/products/cloudxen.html, Citrix Systems
Inc., retrieved: August 2011.
[29] Microsoft, “Develop applications - code and configure applications to
run in windows azure.” http://www.microsoft.com/windowsazure/learn/
develop/, Microsoft Inc., retrieved: August 2011.
[30] Google, “Google app engine developer’s guide,” http://code.google.com/
appengine/docs/, RaceLab, UCSB, retrieved: August 2011.
[31] N. Chohan, C. Bunch, S. Pang, C. Krintz, N. Mostafa, S. Soman,
and R. Wolski, “Appscale: Scalable and open appengine application
development and deployment,” Cloud Computing, pp. 57–70, 2010.
[32] G. Kiczales, J. Lamping et al., “Aspect-oriented programming,”
ECOOP’97Object-Oriented Programming, pp. 220–242, 1997.
R EFERENCES
[1] B. Rimal, A. Jukan, D. Katsaros, and Y. Goeleven, “Architectural requirements for cloud computing systems: An enterprise cloud approach,”
Journal of Grid Computing, pp. 1–24, 2011.
[2] L. Youseff, M. Butrico, and D. Da Silva, “Toward a unified ontology of
cloud computing,” in Grid Computing Environments Workshop, 2008.
GCE’08. IEEE, 2008, pp. 1–10.
[3] D. Oliveira, F. A. Baio, and M. Mattoso, “Towards a taxonomy for
cloud computing from an e-science perspective,” in Cloud Computing,
ser. Computer Communications and Networks, N. Antonopoulos and
L. Gillam, Eds. Springer London, 2010, vol. 0, pp. 47–62.
[4] J. Varia, “Cloud architectures,” http://d36cz9buwru1tt.cloudfront.net/
AWS Cloud Architectures.pdf, Amazon Web Services, retrieved:
February 2012.
[5] AWS, “Aws cloud computing whitepapers,” http://aws.amazon.com/
whitepapers/, Amazon Web Services, retrieved: February 2012.
[6] J. Joseph, “Patterns for high availability, scalability, and computing
power with windows azure,” http://msdn.microsoft.com/en-us/magazine/
dd727504.aspx, Microsoft Inc., retrieved: February 2012.
[7] MSDN, “Msdn magazine topics: Azure platform,” http://msdn.microsoft.
com/en-us/magazine/ee532094.aspx?sdmr=azure&sdmi=topics,
Microsoft Inc., retrieved: February 2012.
[8] E. Gamma, R. Helm, R. Johnson, J. Vlissides et al., Design patterns.
Addison-Wesley Reading, MA, 2002, vol. 1.
[9] L. Bass, P. Clements, and R. Kazman, Software architecture in practice.
Addison-Wesley Longman Publishing Co., Inc., 2003.
[10] D. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Pattern-Oriented
Software Architecture: Patterns for Concurrent and Networked Objects,
Volume 2. Wiley, 2000.
[11] M. Kircher and P. Jain, “Pattern-oriented software architecture volume
3: Patterns for resource management,” 2004.
[12] F. Buschmann, K. Henney, and D. Schimdt, Pattern-Oriented Software
Architecture Volume 5. Wiley-India, 2007, vol. 5.
[13] D. Alur, J. Crupi, and D. Malks, Core J2EE patterns: best practices and
design strategies. Prentice Hall PTR, 2003.
[14] G. Abowd, L. Bass, P. Clements, R. Kazman, L. Northrop, and
A. Zaremski, Recommended best industrial practice for software architecture evaluation. Citeseer, 1997.
[15] Oracle,
“Consolidating
applications
with
oracle
solaris
containers,” http://www.oracle.com/technetwork/server-storage/solaris/
documentation/consolidating-apps-163572.pdf, Oracle, May 2010,
retrieved: August 2011.
[16] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, “Xen and the art of virtualization,”
SIGOPS Oper. Syst. Rev., vol. 37, pp. 164–177, October 2003.
[17] I. Systems, “Virtualization (version 2 release 1),” http://publib.boulder.
ibm.com/infocenter/eserver/v1r2/topic/eicay/eicay.pdf, IBM, retrieved:
August 2011.
[18] A. Chobotaro, E. Eduri, S. Garg, L. Janz, C. Klotz, M. Ramachandran,
R. Rappoport, N. Smith, J. Stanley, and M. Wood, “New client virtuR
R
virtualization technology,” Intel
alization usage models using intel
Technology Journal, vol. 10, no. 3, August 2006.
284
415