1owords bes

8eIec|e
CIou

s| roc|i
ed oers
d Comu
OrIond
lors
ku
Arne


ices in C


s |rom w
u|inq o| O
o, U8A, 2


Ldi|ors:
s Arne 8kr
u|b lennon
!rqen 8err
CIoud C
orksbos
OOI8lA0
2009
re

Comu|
s on
09,
|inq








































ISBN: 978-82-997938-1-0
Publisher: Unipub, Norway - an academic publishing house that publishes scholastic books,
prints dissertations and compendiums.
Publication date: October 2009
Copyright 2009. Reproduction of any of the workshop papers requires the author's written
authorization.


Preface

The explosion of Cloud computing propaganda has motivated many companies and people to
quickly move towards this new technology. Particularly given the current economic climate it
seems like a prudent way to dynamically increase and decrease infrastructure at low cost.
However, past experience with SOA and other recent technologies has taught us that lack of
commercial adoption and a proliferation of unusable standards may hinder this technology.
Support from vendors like IBM and Microsoft for cloud computing is promising and leads to the
need for strong design of cloud based systems to ensure quality and productivity. Already
established cloud computing vendors such as Amazon and Google are continually enhancing and
extending their services. Issues already identified in Grid Computing and SOA will certainly
prove important in the design of cloud based systems. An increasing level of importance must be
placed on the design to regulate issues such as: instance access control, regulatory issues,
development practices, security and practical operational issues. Capturing and discussing best
practices on these subjects will contribute to a healthy movement in the right direction for those
who will develop the Service Cloud.

Still at an early stage in adoption, we believe it is important to bring together practitioners and
researchers to workshops to collect best practices, discuss challenges and opportunities so that we
can create ideas and shape the future development of cloud computing to be something that truly
improves our profession and our ability to deliver computing based solutions. Other technology
fads have come and gone, and some have even started to preach the demise of cloud computing
given that the popularity is so strong already. Will Cloud computing be able to cross the chasm
beyond the early adopters? A possible evidence of this could be the fact that cloud computing is
already in widespread use, and healthy business models are already established. Although the
definitions of cloud computing is both unclear and ambiguous, the fact that we already can show
and demonstrate what it is, makes this less of a problem. History has often times shown that
practical use is more sustainable than theory and original intentions.

We have been running 2 workshops on cloud computing at OOPSLA09. One focusing on design
aspects: Best practices in Cloud Computing: Designing for the cloud on October 25, 2009 and
the other on operational aspects: Best Practices in Cloud Computing: Implementation and
Operational Implications for the Cloud on October 26, 2009. From the workshop submissions
we have selected a set of highly qualified papers in these proceedings.

Enjoy the papers in these proceedings and we encourage you to continue the effort in exploring
how cloud computing can be utilized, designed for and tamed.




Acknowledgements

On behalf of the organizing committee of the cloud computing workshops at OOPSLA09 we
would like to thank the contributing authors, keynote speakers, reviewers and participants. We
also thank the community at large actively seeking out best practices, design and implementation
techniques and technologies for the successful implementation of cloud computing.

We would also like to thank Miles, SINTEF and Letterkenny Institute of Technology for
supporting the publishing of these proceedings, as well as the organizations behind the members
of the organizing and program committee for supporting the time spent on reviewing papers as
well as preparing and running the workshop.

Lars Arne Skr, Amir Zeid, Ruth Lennon, Morten Udns, Arne Jrgen Berre, Einar Landre,
Dumitru Roman, Willem-Jan van den Heuvel
Organizing Committee of the workshops on Cloud Computing at
OOPSLA09, Orlando, Florida, USA, October 2009

Organizing Committee

- Lars Arne Skr, Miles Consulting
- Amir Zeid, American University of Kuwait
- Ruth Lennon, Letterkenny Institute of Technology
- Morten Udns, Miles Consulting
- Arne Jrgen Berre, SINTEF
- Einar Landre, StatoilHydro
- Dumitru Roman, STI, University of Innsbruck
- Willem-Jan van den Heuvel, European Research Institute in Services Science


Program committee (reviewing papers)

- Prof. Fabio Casati, University of Trento, Italy
- Mr Marin Dimitrov, Ontotext Lab, Bulgaria
- Prof.Elizabeth Di Nitto, Politecnico di Milano, Italy
- Dr. Daniela Grigori, Universit de Versailles, France
- Mr. Nigel McKelvey, Sita, Ireland
- Prof. Cesare Pautasso, University of Lugano, Switzerland

Contents
Cloud Standards Roadmap Process 1
Eclipsing High Prole Open Source Cloud Initiatives 7
Model-Driven Design and Operations for the Cloud 17
Cloud Computing Web-Services Offering and IT Management Aspects 27
A Best Practice Model for Cloud Middleware 41
Leveraging Cloud Infrastructure for Life Sciences Research Laboratories 53
Migrating Legacy Applications to the Service Cloud 59
Cloud Standards Roadmap Process
Robert Marcus
Emerging Technology Strategies, 4501 134 PL SE, Bellevue, Wa. 98006, USA
robert.marcus@et-strategies.com
Abstract. Cloud computing technology is being rapidly deployed by enterprises
and governments. There are many benefits including increased flexibility and
reduced costs for individual projects. However it will be necessary to plan
carefully for future interoperability and portability across multiple clouds (i.e.
hybrid cloud architecture). This paper outlines an approach for creating
roadmaps to guide procurements and deployments for large organizations that
need to integrate multiple clouds. Application Programming Interfaces (APIs)
for Infrastructure as a Service (IaaS) resources in the U.S. government Cloud
Storefront is used as an example.
1 Introduction
Cloud Computing in its many incarnations is rapidly gaining support for the next
generation of IT deployments. Unfortunately there are many different incompatible
implementation of Cloud Computing technology. This diversity might not hinder
individual projects but will create serious challenges for future portability and
interoperability in enterprises. Similar problems have occurred with previous
promising technology e.g. distributed objects.
During the past year, there has been an attempt to proactively address the issues of
Cloud interoperability and portability in a series of meetings. Representatives of
government, industry, and standards groups are evolving a collaborative process for
moving towards needed standards. The goal of this process are roadmaps that
describe the dependencies and schedule for the Cloud standards required for planned
deployments. The roadmaps will provide value to enterprises, cloud resource
vendors, and standards groups.
In this paper, the Cloud Standards Roadmap Process will be presented and the
individual steps in the Process will be described. For the purpose of brevity, the focus
will be on harmonizing Application Programming Interfaces (APIs) for Infrastructure
as a Service (IaaS) Cloud resources.


1
2 Cloud Computing Standards Roadmap Process
The steps and transitions in the standards roadmaps process are illustrated in Figure 1.
Fig. 1. Cloud Standards Roadmap Process
The transitions include:
Analysis of the technology being provided by vendors and open source suppliers
is used in the preliminary planning of enterprise initiatives.
These initiatives define scenarios that determine Cloud use cases.
Mappings can be documented between Cloud use cases and related Cloud
standards.
The coordinated creation of the Cloud standards can be assigned to standards
groups who publish Cloud Standards Roadmap including dependencies and
schedules.
3 Cloud Standards Roadmap Process for Infrastructure as a
Service (IaaS)
Infrastructure as a Service can be defined as "on demand processing, storage,
network capacity, and other fundamental computing resources in which costs are
assigned based usage"[1]. This technology is one of the main drivers of Cloud
computing. Some others include Platform as a Service (PaaS) and Software as a
Service (SaaS).
The key foundation for IaaS is virtualization of computing, storage, and other
resources. Virtualization enables the elastic allocation and de-allocation of
resourcesin responses to shifting demands. Within enterprises, IaaS is perceived as a
way to improve reuse of data center resources. On the Internet, IaaS resources have
been used to handle Web site resource spikes for small companies (e.g. Animoto [2])
and short-term large computing tasks for enterprises (e.g. New York Times [2]).
The initial IaaS vendor was Amazon Web Services (AWS) based on Amazon's
experience in running Internet scale Web sites. Their offering called Elastic Cloud
Computing (EC2) had a major impact in introducing awareness of the technology
possibilities. The underlying virtualization in AWS is the open source Xen software.
Amazon modified Xen and added enhancements to produce Amazon Machine
2
Images (AMI). The APIs
several other Amazon We
APIs. See Figure 2.
At the same time as E
virtualization was being
for enterprise virtualizati
started by providing virtu
demand, VMware has pro
Recently they introduced
Figure 3. This specific
Rackspace, Terremark, Sa

s to EC2 are created and maintained by Amazon. There
eb Services (e.g S3 for Storage) that have Amazon defin
Fig. 2. Amazon Web Services [2]
EC2 was moving forward on the public Internet, VMw
widely deployed in enterprise data centers. The motivat
ion was flexible efficient resource utilization. VMw
ual machines (VM) and hypervisors. Driven by custom
oduce products for managing dynamically distributed VM
a vCloud specification for elastic resouce allocation. S
cation has been endorsed by several IaaS vendors (e
avvis)
Fig. 3. vCloud Framework [3]
are
ned
ware
tion
ware
mer
Ms.
See
e.g.
3
4 U.S. Governmen
The U.S. Government r
Cloud Resources. Vendor
and standards to be mad
provides an interface for a
Figure 4.
The U.S. General Serv
deployment of different
interoperability and porta
described as "a hybrid clou


nt Cloud Storefront Initiative
recently launched a Cloud Storefront initiative for procur
rs must satisfy government requirements for SLAs, secur
de available through the Storefront.The initial installat
agencies to review and purchase IaaS Cloud resources. S
Fig. 4. GSA Cloud Storefront [4]
vices Agency (GSA) has created a schedule for the pha
Use Case resources [4]. One of the future goal is
ability across multiple Clouds. This Use Case is of
ud".
Fig. 5. Hybrid Cloud Use Case [5]
ring
rity,
tion
See
sed
for
ften
4
5 Standards Coordination for Hybrid Clouds
The key standards for implementing hybrid clouds are the APIs to IaaS resources.
During the past year, there have been several meetings of Cloud standards groups
focused on coordination of Cloud standards activities. These include a Cloud
Interoperability Workshop in March 2009 [6] and a Cloud Standards Summit in July
2009 [7]. As an outgrowth of these meetings, a Cloud Standards Coordination
Working Group was initiated (http://www.cloud-standards.org) including the Open
Grid Forum (OGF), Distributed Management Task Force (DMTF), Storage
Networking Industry Association (SNIA), Cloud Security Alliance (CSA), and the
Object Management Group (OMG).
In December 2009 [8], there will be meeting to discuss Harmonization of APIs to
Cloud IaaS Resources. The invitees to the meeting will include standards groups,
industry, and government representatives. The goal is to develop a roadmap for
increasing interoperability and portability across multiple Clouds.


References:
1. NIST White Paper. http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-
v15.doc (2009)
2. Amazon Presentation,
http://federalcloudcomputing.wik.is/@api/deki/files/2/=JeffBarr09172008.pdf
(2008)
3. VMware Web site, http://www.vmware.com/technology/cloud-os/index.html (2009)
4. GSA Cloud
Presentationhttp://www.usaservices.gov/intergovt/documents/StateWebPres6-18.ppt
(2009)
5. Cloud Use Cases White Paper, http://groups.google.com/group/cloud-computing-use-
cases/files (2009)
6. Cloud Interoperability Workshop,
http://federalcloudcomputing.wik.is/March_23%2c_2009 (2009)
7. Cloud Standards Summit, http://federalcloudcomputing.wik.is/July_15%2c_2009
(2009)
8. OMG Technical Meeting http://www.omg.org/news/meetings/tc/ca/info.htm
(2009)
5
6
Overcast: Eclipsing High Prole Open Source
Cloud Initiatives
Chris Matthews
1
, Stephen Neville
2
, Yvonne Coady
1
, Je McAer
3
, and Ian
Bull
3
1
University of Victoria {cmatthew,ycoady}@cs.uvic.ca
2
University of Victoria sneville@ece.uvic.ca
3
EclipseSource{irbull,jeff}@eclipsesource.com
Abstract. Can Cloud Computing be used without the traditional clus-
tered, high-availability and highly complicated software stacks from big
vendors or high prole open source initiatives? This paper presents the
position that by leveraging the virtualization that is inherent in the
cloud, we can recompose cloud systems out of more simple building
blocks, breaking the dependancy on complicated software stacks and
creating more secure and reliable systems than at present.
1 Introduction
One of the challenges of cloud computing is the complexity of composing ser-
vices in ways that will ultimately be not only be ecient, secure, and robust, but
also scalable and sustainable in the face of system evolution. Virtualization has
provided critical leverage within this domain. However, current coarse grained
virtualization is arguably a mismatch in terms of cloud service compositions.
Cloud infrastructure as a service (IaaS) providers all support the same gran-
ularity for system decomposition, consisting of a full operating system and a
complete software stack.
In this position paper we discuss the possibility of composing cloud based
systems out of a collection of smaller components. The ultimate goal being more
maintainable, scalable systems, which break our dependence on the current large
brittle software stacks used in IaaS and ultimately make IaaS a bit more like
platfrom as a service (PaaS) computing.
In [1] we presented MacroComponents, designed specically to combine the
power of the isolation currently provided by virtualization with software en-
gineering qualities borrowed from component systems for scalability and sus-
tainability in cloud environments. In systems composed of MacroComponents,
components run in isolation from the rest of the system, but without the full
foundations of their more traditionally virtualized counterparts.
In this paper we discuss how MacroComponents would change the way cloud
software is built, and what dierences we could expect to see in systems built
out of MacroComponents. We start with a discussion of current techniques for
decomposing cloud systems in Section 2, then in Sections 3 and 4 we introduce
7
some technologies of interest: OSGi, P2 and CloudClipse, then in Section 6 we
describe how these technologies might be used to make MacroComponents more
potent in the cloud. In Section 7 we detail how MacroComponents might make
cloud software systems better, and in Section 8 we describe some of the problems
that could be encountered.
2 Decomposition and Virtual Appliances
Outside of the cloud, there are several reasons to split up a full software stack
across separate virtual machines. The isolation imposed by virtualization pro-
vides a mechanism with which a systems engineer can decompose the system.
This decomposition could be done to help bring the system closer to the con-
ceptual model it is based on. It could also be done to reduce the cost of building
or maintaining the system [2, 3].
Concretely, prior to the acceptance of virtualization, to ensure good hardware
and utilization a company might have installed a web server and e-mail server
on the same physical host. In a virtualized setup, that company might put their
e-mail server in one virtual machine and their web server in a dierent virtual
machine on the same physical host. This could have been motivated by several
dierent reasons: rst, to match the conceptual understanding of the system,
second to separate the stakeholders of the system, third to separate proprietary
modules from the rest of the system.
Matching the conceptual understanding of the system is something that is
done to enhance the mental modeling of the system. Since e-mail and web servers
are separate services, having them running on separate containers makes sense
from that perspective. When the maintainers of the system are thinking of the
services the system provides, it would be nice for them not to have to think about
where the services are instantiated. For example, if the maintainers of the system
wanted to move the e-mail server behind a rewall or to a new physical location,
but keep the web server in its currently is, the conceptual understanding of the
system is that the e-mail server can just be moved; however, that is not the case
if the e-mail server and the web server are running on one operating system. In
this particular example, if the web server and e-mail server were running on a
virtualized platform in separate virtual machines there would be no dependency
between the two, and the e-mail server could be moved without any consideration
for the web server.
Sometimes it makes sense to decompose the system to separate the stake-
holders involved in the system. For example, the Microsoft documentation warns
strongly against running a domain controller and exchange e-mail server on the
same Windows 2003 instance [4]. Statements like this can be motivated by sev-
eral dierent issues of compatibility:
legal: the license that software is written under,
technical: two software products do not interact well after installed on the
same system, based on several isolation properties:
8
Conguration Isolation: Conguration of one entity eects the other,
Temporal Isolation: One entity steals execution time from another,
Spacial Isolation: One entity interferes with anothers memory or cache,
security: software does not trust other software products on the system and
quality of service: software cannot guarantee it will work well with other
software installed.
2.1 Making it Easy
These are all motivating factors for the notion of the virtual appliance. A virtual
appliance is a virtual machine with software pre-packaged and pre-congured
within it. All the user of the virtual appliance has to do is download the vir-
tual appliance and start it. Virtual appliances also tend to carry a full OS in
their virtual machine, although often they have their non-essential services and
applications removed. Libra [5] is an attempt to build a minimal library OS to
support even smaller virtual machines. Libra provides a composable operating
system that was shown to run a Java Virtual Machine (JVM). MinOS a minimal
OS that is included with Xen [6]. It lacks some of facilities that are found in a
typical OS such as a scheduler, or network stack. MinOS has been used to build
small virtual machines that are built for a specic purpose, for example, running
a simple C program, running an OCaml interpreter, or even providing an iso-
lated domain builder for Xen [7]. These are all examples of eorts to reduce the
size and complexity of virtual machines to make the system as a whole better in
some way.
In Amazons EC2 [8], users are presented with a large variety of free and
paid precongured Amazon Machine Images (AMIs). Many of these could be
considered virtual appliances, with common prebuilt software stacks in them.
These images reduce the time it takes for clients to get their applications into
the cloud, eectively reducing the setup to just application specic setup.
2.2 Building Monolithic Systems
Virtual appliances tend to be monolithic systems, a large collection of software all
tuned to work together to perform the virtual appliances task. But prefabricated
virtual appliances have limits to their customizability.
The need for custom software stacks has been made evident by the success
of products like rPaths rBuilder [9] or openQRM [10]. Both create customized
images for virtual machines and the cloud. All the user has to do is provide the
application, and these systems prepare the image for you.
One thing that is interesting about these systems is the interface that they
present to their users. The interfaces make the virtual machine appear as though
it is a collection of components. The user selects a kernel, some software packages,
and perhaps a web server, and these systems compose them for you. At the end
you are presented with a software system ready for the cloud. In this case these
systems are building a monolithic software system on your behalf.
9
3 OSGi and P2
OSGi is a component model that has gained some popularity in the Java pro-
gramming world [11]. Although not specied in Java, all the current implemen-
tations of the OSGi framework are for Java. OSGi provides a model in which
components (bundles) and services can be dened and accessed along with some
associated component lifecycle and composition operations.
Equinox is the reference implementation of the OSGi model. Equinox is part
of the Eclipse project, and provides the implementation of OSGi that the Eclipse
IDE uses. OSGi can even be used in distributed systems. R-OSGi [12] can be
used to have OSGi components communicate with each other even when they
are on dierent physical or virtual machines.
Because of the dynamic nature of OSGi components, and the ease with which
modules in the system can be added, removed and upgraded, a natural addition
to the OSGi world is P2, a provisioning platform [13]. P2 is the mechanism
behind the newest version of the Eclipse IDEs update system, and provides
a general purpose means for installing and updating an OSGi system. P2 was
conceived out of the need to keep complex systems of versioned component which
come from dierent places. P2 is designed to be extensible and exible, and can
do more than just adding and removing components from OSGi systems. P2
comes with a set of native operations that can perform many dierent common
tasks, but P2 also provides the ability to extend itself as it is running with new
operations.
4 CloudClipse
CloudClipse is a framework for helping get software into the cloud. It was a
prototype system created as a Google summer of code project for the Eclipse
Foundation. The initial version of CloudClipse provided an extra set of P2 oper-
ations which allowed an installer to create virtual machine image that could then
have software installed into it. The rst version provided support for fetching
a compressed virtual machine image, mounting a virtual machine image, doing
a RPM install into an image, and performing arbitrary commands inside the
image via Linuxs chroot facility. Currently, CloudClipse downloads one of sev-
eral small linux distributions as the base to work from. Then that image can be
customized by the P2 installer. Once the image is present on the local machine,
P2 can install software from local RPMs or from another P2 repository. P2 can
also congure the image by doing things such as setting up services to run on
boot, changing the default root password, and installing ssh keys.
4.1 Future of CloudClipse
The ease with which P2 was adapted to make virtual machines images indicates
it might be a good candidate to dynamically congure and install software in the
cloud. We think that P2 is particularly well suited for installing and conguring
10
Fig. 1. Creating a new virtual machine with the Eclipse CloudClipse plugin.
11
the nodes from inside the cloud. CloudClipse could be used to set up a simple
P2 system inside a cloud image; then, dynamically, P2 could nd the software it
needs from repositories inside the cloud and install them. CloudClipse provides
a simple way of producing virtual machines with a small installation of base
software to get the rest of the P2 installer going. CloudClipse can congure the
operating system and kernel versions of installed libraries, then, once in the cloud
P2 would be able to dynamically congure and install the rest of the software
in the system. Ideally, P2 actually nds the software from within the cloud.
The ease with which CloudClipse, and other tools like openQRM and rBuilder
build base images for the cloud, makes it almost a mechanical process.
5 MacroComponents
MacroComponents is a proposed approach to software compostion that aims to
alleviate the burden of creating lightweight virtual machines [1]. With lightweight
virtual machines, there is no need to keep an entire monolithic software stack in
each virtual machine. The goal of MacroComponents is to decrease the size of
virtualizable entities in the system to the point that small software components
can be run in isolated virtual machines. Each virtual machine is merely a con-
tainer for a single software component of the system. Because of the decrease
in complexity of the software in each virtual machine, much of the traditional
supporting software stack can be removed from the virtual machine as well.
To support the ne grained decomposition of a software system across virtual
machines, MacroCompents would have to provide several facilities. Some of the
most important of which are:
programatic creation and conguration of virtual machines,
fast communication between virtual machines,
scalable, simple composition of virtual machines,
programatic control over other virtual machines.
We believe with all these and other properties satised, software systems
could be distributed as components across virtual machines.
Cloud computing heavily utilizes virtualization; so the question remains,
would ne grained decomposition of cloud software into virtual machines be
benecial? We investigate this question in the following sections.
6 Leveraging Current Component Systems
OSGi could lend an interesting compent model to MacroComponents. There is
some eort to use OSGi in the cloud already [12]. Its model for dynamic service
binding maps well to cloud software, but also could map well to MacroCompo-
nents. In systems built with OSGi, components can be added and removed from
the running system. Using R-OSGi, it was shown that the failure of distributed
12
communication can map directly onto the OSGi services failure modes [14]. Ex-
tensive tooling already exists for OSGi; for example, the Eclipse PDE is designed
for OSGi development [15]. Furthermore, there are several popular implementa-
tions of the OSGi runtime which already exist.
P2 and CloudClipse also could provide mechanisims to assist in the complex
creation of virtual machines. P2 could prepare a MacroComponents virtual ma-
chine images, and prestock them with the simple runtimes they would need.
Furthermore, an instance of P2 could be used inside the virtual machine, to load
that virtual machines component(s) dynamically. This alleviates some of the
per-MacroComponent setup that would need to be done.
7 The Case for Fine-grained Cloud Compositions
Section 2 listed many reasons to decompose a software stack, and MacroCom-
ponents as described in Section 5 allow us to decompose a system in a more ne
grained manner. If this decomposion took place, we could expect to see many
benets to the software system as a whole.
The dynamic nature of OSGi systems makes it easy to swap one service
for another similar service. This makes the system easier to evolve. Componet
version dependencies can be explicitly noted, live upgrades are possible and
maintance can replace smaller parts of the system.
Because each component is isolated in its own virtual machine, the compo-
nent has explicit conguration isolation, temporal isolation and spacial isolation.
It should be nearly impossible for other elements of the system to interfere with
the expected operation of a component.
In an OSGi service based architecture, components bind dynamically and
only temporarily, so redundancy is easily inserted into the system. Multiple
instances of important componets can be used, and failover can be automatic.
There is a lower cost to keeping hot standbys for important components because
a smaller part of the system (just the component) is all that has to be kept ready.
Furthermore, new instances of components can be brought up much faster than
starting a whole new version of the software stack. Both of these properties have
good implications for the robustness and scalability of the system. The need for
traditional high availability software mechanisms is reduced.
In the event of a security compromise, only one component will initially
be exposed to the attacker. If the attacker wants to compromise more of the
system they have to also nd a vulnerability in the hypervisor or the inter
virtual machine communication.
The hypervisor provides a good generic base runtime. They allow many dif-
ferent sizes and types of operating systems and runtimes to be used. Almost
anything could be used inside each macro component. It is also transparent to
swap one component runtime for another. This breaks the dependence on large
standard software stacks. Each component can run the base system that best
suits it, with no worry for what other parts of the system need. Developers are
not locked into one OS, but rather can select based on the needs of a component.
13
8 The Challenges of Fine-grained Cloud Compositions
There are also signicant barriers to ne grained composition. The rst barrier
is the decomposition of systems themselves. It would be nieve to think that
systems engineers would rewrite their software to t this model. Existing software
system are complex, and decomposing them as a whole is a tremendous task.
However, new systems are built, which could be designed with a component
model in mind. Further more, MacroComponents are not an exclusive choice,
the parts of a system that could most benet from the benecial properties of
MacroComponents could be extracted, and the rest of the system could run
along side in typical monolithic system. It remains to be seen if the engineering
eort is worth the benets to existing systems.
One issue that is already pertentant in the cloud is that of information secu-
rity and privacy [16]. Increasing the number of virtual machines and that amount
of communication and coordination in cloud systems surely will not help these
problems. We hope that general solutions proposed in this space will apply to
MacroComponent type systems as well. Also, because of the systems decomposed
state, things that might not have otherwise need to be transmitted between vir-
tual machines may have to be. One other practical issue of system decomposition
is the overheads of communication between modules and in the creation of com-
ponents (and their resident virtual machines). To produce a useful system, both
these overheads have to be addressed.
Finally, compostion of components in large systems may become a complex
task. Some of the features of OSGi like explicit versioning and dependancy dec-
laration help with this, but it is still a problem suered by all complex systems.
9 Conclusion
Fine grained virtual components show promise as dierent way of decomposing
cloud software systems. There are a miryaid of benets and disadvantages to
building software with a model like this; but, current technologies like OSGi and
P2 could help make this approach more feasible. In the future we intend to build
a MacroComponent based system and test it in the cloud.
References
1. Matthews, C., Coady, Y.: Virtualized recomposition: Cloudy or clear? In: CLOUD
09: Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges
of Cloud Computing, Washington, DC, USA, IEEE Computer Society (2009) 3843
2. Collier, G., Plassman, D., Pegah, M.: Virtualizations next frontier: security. (2007)
3436
3. Bellino, J., Hans, C.: Virtual machine or virtual operating system? In: Proceedings
of the workshop on virtual computer systems, New York, NY, USA, ACM (1973)
2029
4. : XADM: How to congure exchange server 5.5 to run on a domain controller that
is a global catalog (2008) http://support.microsoft.com/kb/275127.
14
5. Ammons, G., Appavoo, J., Butrico, M., Silva, D.D., Grove, D., Kawachiya, K.,
Krieger, O., Rosenburg, B., Hensbergen, E.V., Wisniewski, R.W.: Libra: a library
operating system for a JVM in a virtualized execution environment. In: VEE 07:
Proceedings of the 3rd international conference on Virtual execution environments,
New York, NY, USA, ACM (2007) 4454
6. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauery,
R., Pratt, I., Wareld, A.: Xen and the art of virtualization. In: SOSP03. (2003)
114
7. Murray, D.G., Milos, G., Hand, S.: Improving Xen security through disaggregation.
In: VEE 08: Proceedings of the fourth ACM SIGPLAN/SIGOPS international
conference on Virtual execution environments, New York, NY, USA, ACM (2008)
151160
8. Amazon.com Inc: Amazon elastic compute cloud. Website http://aws.amazon.
com/ec2/.
9. rPath: rBuilder Online. Website (2009) http://www.rpath.org.
10. openQRM: openQRM: Open source data-center-management-platform. Website
(2009) http://www.openqrm.com.
11. : Open Service Gateway Initiative. Website (2009) http://www.osgi.org.
12. Rellermeyer, J.S., Duller, M., Alonso, G.: Engineering the cloud from software
modules. In: CLOUD 09: Proceedings of the 2009 ICSE Workshop on Software
Engineering Challenges of Cloud Computing, Washington, DC, USA, IEEE Com-
puter Society (2009) 3237
13. : Equinox P2. Website http://wiki.eclipse.org/Equinox/p2.
14. Rellermeyer, J.S., Alonso, G., Roscoe, T.: R-osgi: distributed applications
through software modularization. In: Middleware 07: Proceedings of the
ACM/IFIP/USENIX 2007 International Conference on Middleware, New York,
NY, USA, Springer-Verlag New York, Inc. (2007) 120
15. : Eclipse PDE. Website (2009) http://www.eclipse.org/pde/.
16. Pearson, S.: Taking account of privacy when designing cloud computing services.
In: CLOUD 09: Proceedings of the 2009 ICSE Workshop on Software Engineering
Challenges of Cloud Computing, Washington, DC, USA, IEEE Computer Society
(2009) 4452
15
16
ModelDriven Design and Uperations for tbe Cloud
Position Paper for tbe UUPSLA Worhsbop on
Best Practices in Cloud Computing
Designing for tbe Cloud

Stuait Chailton
Elastia Coipoiation
Pacific Avenue Suite
San Fiancisco CA
0SA
Tel
Email stuaitcelastiacom
httpwwwelastiacom
In touays age of onuemanu access to applications compute stoiage anu netwoiks mouein IT
applications anu seivice management has many complications
Applications can be deployed across organizationally geograpbically distributed
data centers The technology in these uata centeis fiom viitualization platfoims to host
stoiage anu netwoik infiastiuctuie is typically heteiogeneous anu not necessaiily
manageu with unifoim policies anu inteifaces
Tbe performance scalability and availability cbaracteristics of an application are due
to a complex combination of design and operational decisions The gieatest impacts on
these factois aie uue to uecisions in the aichitectuie anu uevelopment of the application
befoie configuiing the uata centei infiastiuctuie
Application and infrastructure management is complex and interdisciplinary Its
unlikely a system can be uiagnoseu anu maintaineu by one peison to keeping the system
uesign configuiation in theii heau Application uesign auministiation anu management
typically is a collaboiative activity acioss specialists theie is no onesize fits all uesign tool
management tool oi application platfoim
Enteipiise IT management challenges have been tackleu thiough a vaiiety of moueling languages
mouels piotocols APIs foimats anu methouologies to uate each of which
tackles a poition of the pioblem But to uate theie has not been an enutoenu appioach foi
uesciibing an application fiom uesign thiough configuiation anu opeiations It is oui opinion that
an enutoenu moueluiiven appioach to IT seivice uesign management anu automation pioviues
gieat potential foi uiastically ieuuceu leau times to cieate anu maintain the next geneiation of clouu
applications
Thiee uesign goals foi an enutoenu clouu uesign appioach incluue
Separated Applications from Infrastructure thiough moueling the application in teims of its
aichitectuie anu infiastiuctuie iequiiements without tying the application to a specific set of
unueilying infiastiuctuie
17
Enabling ComputerAssisted Modeling and Control Automation pioviueu by a set of contiol
agents anu useiguiueu by giaphical uesign tools This coulu help IT aichitects anu opeiatois
ueteimine uesign constiaints on the application match the uesign to the unueilying infiastiuctuie
anu enable goaluiiven automation to ueploy scale oi iecovei theii IT systems on uemanu

Explicit Collaboration To Enact Cbanges thiough mouels that couify ielate anu analyze the
constiaints anu piefeiences that aie appiopiiate to stakeholueis acioss enteipiise IT fiom
aichitects anu uevelopeis thiough opeiatois auministiatois anu manageis
Cbaracterizing an Integrated Design Management Approacb for Cloud Computing

We have uefineu a set of moueling languages a iefeience aichitectuie anu built an implementation
which integiates both existing anu emeiging IT automation anu management seiveis This woik is
baseu on a set of eigbt desirable cbaracteristics that uesciibe an infoimation system that
auuiesses clouu application uesign anu opeiations pioblems holistically
The eight chaiacteiistics aie
Distributed Autonomous Control

A clouu uesign anu management system must be able to scale iemain ieliable anu inteiopeiable
acioss an unpieuictable numbei of oiganizations anuoi locations This iecognizes that
infiastiuctuie iesouices uesign infoimation anu ueployments aie noimally uecentializeu
Upen DocumentExcbange

Inteiactions among useis agents anu management seivices must be visible anu peisistent if they aie
to be manageu Its common foi example that auministiatois wish to exploie whatif scenaiios
that expiess the uesiieu state of an IT system compaiing to its cuiient state befoie enacting a
change APIbaseu piotocols while open uo not uiiectly suppoit such abilities
In piactice touay peisistent visible inteiactions aie usually manageu via piopiietaiy centializeu oi
feueiateu configuiation management uatabases CNBBs While paitly effective the CNBB limits a
numbei of the uesiiable chaiacteiistics listeu heie CNBBs aie oiienteu towaius centializeu oi at
best feueiateu uata management insteau of uistiibuteu uata management Anu the CNBB schema
limits visibility uue to its typical piopiietaiy natuie although queiy stanuaius aie emeiging
To contiast the exchange of uocuments whethei via netwoik tiansfei poitable stoiage uevice oi
email attachment enables fieeuom foi useis to sepaiate the moue of inteiaction with the content of
the inteiaction Foi example a uocument may uesciibe a scaleout plan foi a ueployment In a
uocumentcentiic system the uocument isnt weuueu to any paiticulai intent anu can be useu foi a
vaiiety of puiposes collaboiation among colleagues aichive foi seaich anu analysis oi foi actually
peifoiming an automateu scaleout
Hyperlinhed Web Arcbitecture

The aichitectuie of the Woilu Wiue Web baseu on the REST aichitectuial style shoulu be
the uefault netwoik aichitectuie foi exchanging uocuments among seivices agents anu useis
A woiiisome tienu among uocument foimats is the uesiie to shove eveiy possible item of uata anu
metauata into a single monolithic entity This leaus to monolithic specifications anu incompatibility
among uiffeient IT management technologies Piactically speaking laige ueployment uesciiptois
manifests etc aie haiu to inteipiet uebug anu shaie oi collaboiate with
18

Bypei
infoim
peopl
techn
foi ue
stanua
compl
inteic
Mo

Applic
inteii
softwa
compo
Nouel
piosci
easiei
langua
Nouel
inciea
such a
the W
Co

An IT
pioviu
aichit
bettei
IT ma
IBNs
sepaia
fiom t
state
expres
on the
lifecyc
specif
for eve
admin
modify
autom

Tiauit
sciipt
wellt
techn
pioce
ueclai
anu p
ieason
ilinks extenu t
mation anu an
e anu othei u
ologies such a
esciibing appli
aiuizeu ueplo
lex IT system
connecteu uoc
odelDriven
cation manage
ielateu techno
aie such as m
ose oi extenu
ls on the othe
iiptive anu ca
i to compose t
age anu textu
ls also have th
ase the visibili
as SPARQL
Web Aichitectu
oal and Policy
management
ues infoimatio
tects anu aum
i uecisions A g
anagement ue
Autonomic Co
ates the uesii
the potential m
A policy-driv
sses certain p
e system as it
cle, without req
fy the complet
ery contingenc
nistrators can i
y the automati
mated plan gen
tional automa
ts oi iunbook
tiouuen pieui
ology uoesnt
sses themselv
iative piogiam
olicyuiiven m
ning anu uelib
the potential o
n active noue o
uocuments It
as the 0pen Se
ication lifecyc
oyment uesciip
uesciiption ca
cuments whic
ement autom
ologies anu ue
anagement sy
the iesults to
ei hanu aie ex
an be inteipie
than executab
ually as foi e
he benefit of b
ity anu inteiop
RBF a
uie
yDriven
system ultim
on anu suppoi
inistiatois to
goaluiiven ap
sciibeu foi ex
omputing visi
eu state of the
means of achie
en approach,
preferences or
is transitioned
quiring admini
e maintenance
cy. Both des
inspect, diagn
ion processes
neration.
ation baseu aio
piocesses exe
ictable path b
help impiove
ves To contia
mming such a
mouels enable
beiation on be
of the uocume
on a netwoik
t enables tiace
eivices foi Lif
cle mouels oi
ptoi anu pack
an be bioken u
h can be secui
ation anu con
sign uecisions
ystem plugins
o contexts beyo
xpiesseu as ua
eteu in uiffeien
les anu can b
xample a uom
being able to ta
peiability of th
nu 0WL b
ately
it to
make
ppioach to
xample by
ion
e system
eving that
meanwhile,
constraints
d through its
strators to
e process
signers and
ose, and
s through
ounu
ecutes a
but the
e the
ast
as with goal
es machine
ehalf of system
ent exchange
A uocument
eability betwe
fecycle Collabo
the Bistiibute
kage foi viitua
uown into a w
iely seaicheu
ntiol actions m
s Typically th
s sciipts oi iu
onu why the s
ata not just
nt contexts N
e piesenteu b
mainspecific l
ake auvantage
he infoimatio
biings logical
m auministiato
it tuins a uocu
t can link to ot
een uiffeient u
oiation 0SLC
eu Nanagemen
al machine ima
web of continu
inuexeu anu
must occui wit
hese assumpti
unbook pioce
softwaie was o
coue aie uesc
Nouels aie ea
both visually a
language
e of logic anu s
n conveyeu S
queiy iepies
ois Axioms a
ument into bo
thei iealwoi
uocument foim
C a set of
nt Task Foice
ages 0ltimate
ually evolving
u piocesseu
thin the conte
ions aie encou
sses with lim
oiiginally ciea
ciiptive iathe
siei to change
as a visual mo
semantic ieas
Semantic Web
sentation anu
anu pioceuuia
oth an item of
lu iesouices
mats anu
f specification
s 0vF a
ely the most
ext of many
ueu in
iteu ability to
ateu
i than
e than coue ai
oueling
oning to
technology
u moueling to
al uesciiption
ns
ie
s
19
can be captuieu into opeiational knowleuge mouules that contain the vaiious states events
conuitions composite tasks anu actions in a paiticulai uomain This computeiassisteu appioach to
uesign anu opeiations can assist auministiatois anu aichitects optimal guiuance foi ceitain uesign
uecisions oi foi a plan to enact changes This goal anu policyuiiven appioach is implementable
thiough an automateu plannei which can inteipiet the goal mouel anu policy in the context
of a set of opeiational knowleuge mouules which uesciibe the planning uomain

ViewpointBased

Application anu infiastiuctuie aichitectuies typically involve multiple stakeholueis each with theii
own unique view on the impoitant conceins anu notable elements of the system The systems
aichitectuie anu softwaie engineeiing communities have coineu the teim viewpoint to
uesciibe a ieusable language set of constiaints anu piactical guiuance to uesciibe an enutoenu
system that auuiess a paiticulai set of conceins Foi example a secuiity viewpoint may focus on
vectois of attack anu policy enfoicement uecision anu auministiation points in the aichitectuie
wheie a peifoimance viewpoint may view the system as a queuing mouel to analyze enutoenu
iesponse times
A viewpointbaseu appioach to moueling aichitectuie pioviues the founuation foi the intelligent
automation configuiation of auministiative goals acioss the ueclaieu opeiational knowleuge in the
aichitectuie Biffeient aspects of the system can be moueleu in the teiminology most familiai to the
uomain expeit with conflict anu pieceuence evaluateu by the contiol plane in pait by tiansfoiming
the vaiious viewpoints into a founuation mouel such as a component anu connectoi viewpoint
Collaborative

As the scale of an IT application oi system giows collaboiation is essential as multiple people will be
maintaining uiffeient paits of the system simultaneously Communicating anu shaiing mouels
change plans anu histoiical effects can ieuuce configuiation conflicts anu opeiatoi eiiois
Bypeilinkeu mouels can take auvantage of the web aichitectuies iich suppoit foi social computing
anu collective intelligence incluuing aggiegation synuication via feeus anu the inheient ability to
bieak uown a uifficult pioblem into uisciete uistiibuteu hypeilinkeu chunks of infoimation that can
be shaieu anu euiteu
Covernable

The incieaseu fieeuom that is giowing in automateu viitualizeu IT enviionments caiiies a cost the
incieaseu amount of viitual infiastiuctuie that will be cieateu anu neeus to be manageu anu whose
costs anu iisks neeu to be goveineu
0ui iefeience aichitectuie specifies natuial entiy points foi contiol agents to evaluate anu enfoice of
IT goveinance policies uoveinance may span the lifecycle of anu access contiol to featuies of an
application secuiity policy configuiation iesouice buugeting anu license compliance iepoiting
20

1 L

The E
enuto
config
While
langua
uevelo
lightw
on uev
the m
}S0N

Beclai
uiive
uesign
moie
uiven
consti
can co
much
moue
othei
specif
The E
machi
The th
ECML
langua
EDML
capab
EMML
annot
ECNL
iesou
L M
lastic Nouelin
oenu uesign i
guiations iequ
e the founuatio
ages is in 0WL
opeis can inte
weight web int
velopeifiienu
oueling langu
colloquia
iative mouels
complexity ou
n anu configui
concise statem
a ueclaiation
iaints an IT m
ompose multip
moie effectiv
ls weie pieuo
hanu not eve
fy the last mil
lastic Nouelin
ineieasonabl
hiee cuiient E
L Tbe Elastic
age
L Tbe Elasti
bilities of IT so
L Tbe Elasti
tations ENN
Luesciibeu ue
ice oi the vei
L
ng Languages
iequiiements
uiieu to enable
on of the moue
L anu RBF
eiopeiate thio
teifaces aie b
uly seiializatio
uages incluuin
al XNL oi
aie useful wa
ut of IT applica
iation in favo
ments of inten
n of piefeience
management sy
ple mouels tog
vely than if the
ominantly pioc
eiything can b
le of piovisio
ng Languages
e policy anu p
Elastic Nouelin
c Computing
c Deploymen
oftwaie anu ha
ic Manageme
L uesciibes th
esign is cuiien
ision histoiy o

aie a set of m
contiol anu o
e automateu a
eling
ough
aseu
ons of
ng
Tuitle
ays to
ation
i of
nt
es oi
ystem
gethei
e
ceuuial anu a
e ueclaiative
on installation
pioviue a bala
pioceuuial kn
ng Languages
Modeling La
nt Modeling L
aiuwaie infias
ent Modeling
he context sta
ntly ueployeu
of eithei
ouulai langua
opeiational sp
application ue
also foimally v
at some point
n oi configuia
ance between
nowhow foi c
aie
nguage a mu
Language a co
stiuctuie
Language a m
ate anu uepen
the state of th
ages uefineu in
pecifications a
eployment m
veiify foi conf
t pioceuuies
ation
enabling usei
configuiation o
ultiviewpoint
ollection of ele
mouel of conf
nuencies amon
hat ueploymen
n 0WL v tha
anu uata centi
management
flicts oi mistak
aie usually ie
is to expiess u
oi piovisionin
aichitectuie u
ements foi ue
figuiation item
ng items such
nts EBNLues
at expiess the
ie iesouices
kes 0n the
equiieu to
ueclaiative
ng
uesciiption
sciibing the
ms anu
as whethei an
sciibeu

n
21

ECML

ECNL
multi
uescii
stiuct
conne
piima
coiies
tiansf
stiuct
The st
Comp

Conne

Comp
slots
The li
its tia
Finally

Resou


Scalab

EDML

EBNL
applic
L
L pioviues an e
viewpoint aic
iption languag
tuial oi comp
ectois view
aiy view to wh
sponu usually
foiming oi con
tuie of the sys
tiuctuial view
ponents

ectors


ponents anu Co
fecycle of the
ansitions anu
y ECNLs exte
urce Allocatio

bility


L
L pioviues a la
cations
extensible
chitectuie
ge The
onents
is the
hich othei view
y by
nstiaining the
stem
w consists of
Abstia
which
Abstia
which
iequii
onnectois can
component oi
vaiious iequi
ensible views
on The m
iesoui
The po
Into ti
aie ie
anguage to ues
ws
e
act units of sof
expose inteif
act units of com
also may cont
iements anu e
n be assembleu
i connectoi ue
iements foi a
captuie highe
mapping of com
ices
olicy of specify
ieis wheie co
plicateu uepe
sciibe the vaii
ftwaie config
faces foi comm
mmunication
tain softwaie
expose inteifa
u thiough inte
esciibes the v
component o
eilevel policie
mponents to v
fying compone
mponents anu
nuing on a sca
ious elements
uiation anu c
munication
anuoi meuia
configuiation
ces foi binuin
eifaces that ai
vaiious states a
oi connectoi to
es such as
viitual hosts st
ents connect
u connectoi bi
aling factoi
s of IT infiasti
capability iequ
ation between
n anu capabili
ng component
ie uesciibeu o
available foi t
o be in that sta
toiage netw
tois
inuings
iuctuie that en
uiiements
n components
ity
s togethei
on ueclaieu
that element
ate
woik
nable

22
Resou
that m
pools
centei
uata c
entitie
Bypei
Config
packa
up the
aie in
Categ
pioviu
eleme
Config
Comp
Capab
that a
oi net
piovis
just ue
qualit
Exam

A Byb
contai
uescii
capab
bunul
The b
oigan
policie
expie
urce elements
must be piovis
oi zones Ty
i iesouices an
centei mouel t
es such as Bos
ivisois etc
guration elem
ages oi configu
e bits of a co
stalleu anu sta
gories pioviue
ue seaichable
ents in both EB
guiation elem
ponents Conn
bilities captui
ie available fi
twoik capacity
sioning anu co
ecomposition
tative symbol
mple
biiu infiastiuc
ins public anu
ibeu by EBNL
bilities of each
les in a synuic
unules can the
nizational quot
es anu biokei
sseu in an ECN
s mouel scaice
sioneu anu tia
pically iesoui
nu EBNL inclu
to iepiesent c
sts Stoiage v
ments mouel s
uiation metau
omponent oi c
aiteu on a set
e a taxonomy o
uesciiptive m
BNL Resouic
ents anu ECN
nectois etc
ie the featuie
iom an enteip
y Capabilitie
onfiguiation fo
s of physical a
lic measuies
ctuie clouu on
u piivate iesou
L by expiessin
clouu anu pub
ateu feeu
en be assigneu
tas anu access
ieu against th
NL uesign
e infiastiuctui
ackeu in vaiiou
ices aie uata
uues a viitual
ommon
LANs
softwaie
uata that make
connectoi anu
t of iesouices
of concepts to
metauata foi
ces anu
NL

s anu function
piises shaieu
es aie gioupeu
oi application
attiibutes Th

ne that
uices can be
g the
blishing the
u
s contiol
e capabilities
ie
us
e
u

o
ns
infiastiuctuie
u into bunules
ns to consume
hey can iepies
e such as chip
s to expose sta
Capabilities a
sent a vaiiety
p aichitectuie
anuaiuizeu un
aie extensible
of quantitativ
anu stoiage
nits of
e anu aie not
ve oi
23

EMML

ENNL
config
system
oi sta
be ues
iesou
inuep
state o
ENN
queiy
the co
they e
A C

0ui cl
sets o
The th
Appli

The A
contai
eleme
applic
aichit
compo
conne
lifecyc
ielatio
iequii
config
the in
any po
consti
piefei
eleme
applic
eleme
applic
uescii
L
L pioviues ele
guiation items
m anu theii ie
tes Eveiy ele
sciibeu as som
ice item anu
enuent Beplo
of a ueployeu
L pioviues a C
ying analyzing
onfiguiation st
evolve ovei tim
k
louu iefeience
f shaieu seivi
hiee planes ai
ication Plane

Application Pla
ins the abstia
ents of an
cations
tectuie its
onents anu
ectois theii
cles the
onships anu
iements of
guiation anu o
fiastiuctuie a
olicies
iaints oi
iences on the
ents of the
cation The
ents of the
cation plane ai
ibeu by ECNL
ments to uesc
s in an IT man
elationships u
ement in ECN
me kinu of EN
ENNL intiouu
oyeu Item to
application
CNBBlike inte
g veisioning a
tate of IT appl
me
A
e aichitectuie
ices that cioss
ie as follows
ane
ct
of
anu
ie

ciibe vaiious
nagement
uepenuencies
NL oi EBNL ca
NL uesign oi
uces an
uesciibe the
eiface foi
anu aichiving
lications as

e uesciibes thi
scut these pla
n

iee planes of e
anes
elements in a cclouu applicattion anu thieee
24
InterCloud Control Plane

The clouu contiol plane contains the netwoik of uistiibuteu seiveis anu agents that pioviue
automateu management anu configuiation to applications which may span multiple infiastiuctuie
clouus
The contiol plane enables computeiassisteu uesign foi aichitects anu goaluiiven automation foi
auministiatois on aieas such as clouuinuepenuent iesouice allocation configuiation anu
ueployment management usagebaseu meteiing anu automateu scalability anu iecoveiy
Management Plane

The management plane enables piogiammable access to the elements of applicationinuepenuent
viitualizeu haiuwaie anu softwaie infiastiuctuie These viitualizeu iesouices anu softwaie
packages aie exposeu as web seivices wheie they can be piovisioneu iun anu manageu in suppoit
of an application The elements anu ielationships of the management plane aie uesciibeu by EBNL
The thiee shaieu seivices incluue
I I S

Feueiateu iuentity enables a multioiganization tiust mouel acioss the application configuiation its
contiol plane anu into the management plane using stanuaiu feueiateu iuentity anu authentication
piotocols such as SANL v anu emeiging piotocols such 0Auth
A A C S

Seivices that manage an oiganizational authoiity uata stiuctuie oveilaiu acioss the elements of all
thiee planes anu associateu authoiization ioles foi cieating oi mouifying the topology of an
application contiol agents oi infiastiuctuie
S S A SSA S

The contiol plane consists of uecentializeu hypeilinkeu iesouices backeu by seivices oi agents
which in tuin manipulate hypeimeuia iepiesentations of the application anuoi management planes
SSA seivices enable efficient caching seaich anu queiying of cuiient uesiieu anu believeu state
acioss the thiee planes
A

Kiiill Sheynkman Phil NcNahon Natthew Teschei anu Chiistophei Reiu aie contiibuting authois to
EBNL ECNL anu ENNL
References

Panuit B Popescu v anu Smith v WC Seivice Noueling Language v
bttpwwwworqTRsml
Bistiibuteu Nanagement Task Foice Web Seivices foi Nanagement WSNanagement
Specification veision bttpwwwJmtforqstonJorJspublisbeJJocuments0SPpJf
vNWaie Inc vNWaie vClouu API v Specification
25
bttpcommunitiesvmworecomstoticvclouJopivClouJAPlSpecificotionvpJf
0pen uiiu Foium 0pen Clouu Computing Inteiface Woiking uioup 0pen Clouu
Computing Inteiface Specification Biaft bttpwwwocciwqorqJokupbpiJspec
Bistiibuteu Nanagement Task Foice Common Infoimation Nouel CIN veision
bttpwwwJmtforqstonJorJscim
Bistiibuteu Nanagement Task Foice 0pen viitualization Foimat 0vF Specification
veision bttpwwwJmtforqstonJorJspublisbeJJocuments0SPpJf
0niteu Kinguom 0ffice of uoveinment Commeice Infoimation Technology Infiastiuctuie
Libiaiy ITIL Coie Titles veision bttpwwwitilofficiolsitecomPublicotionsCoreosp
Bistiibuteu Nanagement Task Foice Configuiation Nanagement Batabase CNBB
Feueiation Specification veision
bttpwwwJmtforqstonJorJspublisbeJJocuments0SPpJf
}acobs I Walsh N WC Aichitectuie of the Woilu Wiue Web volume 0ne
bttpwwwworqTRweborcb
Fieluing R Aichitectuial Styles anu the Besign of Netwoikbaseu Softwaie Aichitectuies
PhB Bisseitation 0niveisity of Califoinia Iivine
bttpwwwicsucieJufielJinqpubsJissertotiontopbtm
IBN Coipoiation anu otheis 0pen Seivices foi Lifecycle Collaboiation 0SLC Wiki
bttpopenservicesnetbinviewHoinWebhome
Piuuhommeaux E Seaboine A WC SPARQL Queiy Langauge foi RBF
bttpwwwworqTRrJfsporqlquery
NcBiiue B anu otheis WC Resouice Besciiption Fiamewoik RBF Concepts anu
Abstiact Syntax bttpwwwworqTRrJfconcepts
Ncuuinness B van Baimelen F anu otheis 0WL Web 0ntology Language 0veiview
bttpwwwworqTRowlfeotures
Kephait } Chess B The vision of Autonomic Computing IEEE Computei }anuaiy
bttpwwwreseorcbibmcomoutonomicreseorcbpopersACvisionComputerjonpJf
The 0pen uioup The 0pen uioup Aichitectuie Fiamewoik veision Enteipiise
Euition Chaptei Beveloping Aichitectuie views
bttpwwwopenqrouporqorcbitecturetoqofJocorcbcbopbtml
Ciockfoiu B }S0Noig The applicationjson Neuia Type foi }avaSciipt 0bject Notation
}S0N Inteinet RFC bttpwwwietforqrfcrfctxt
SpeibeigNcQueen C N Nillei E 0n mapping fiom colloquial XNL to RBF using XSLT
Pioceeuings of the Extieme Naikup Languages Confeience
bttpconferencesiJeollionceorqextremebtmlSperberqHcueenFHlSperberq
Hcueenbtml
Beckett B BeineisLee T Tuitle Teise RBF Tiiple Language WC Team Submission
bttpwwwworqTeomSubmissionturtle
Nau B uhallab N Tiaveiso P Automateu Planning Theoiy anu Piactice Noigan
Kaufmann Publisheis ISBN
Siivastava B Kambhampati S The Case foi Automateu Planning in Autonomic
Computing Pioceeuings of the Seconu Inteinational Confeience on Autonomic Computing IEEE
Computei Society bttprokoposbieososueJuicoclonqversionpJf
Clements P anu otheis Bocumenting Softwaie Aichitectuies views anu Beyonu
AuuisonWesely Publisheis ISBN
0ASIS Secuiity Seivices Technical Committee Secuiity Asseitions Naikup Language
SANL veision Technical 0veiview
bttpwwwoosisopenorqcommitteestcbomepbpwqobbrevsecurity
Atwoou N anu otheis 0Auth Coie Revision A Specification bttpooutbnetcoreo
26
Cloud Computing Web-Services Offering and IT
Management Aspects
1
CA Labs, CA Inc. Herzeliya, Israel, ethan.hadar@ca.com
2
CA Labs, CA Inc. Islandia, NY, USA, carrie.gates@ca.com
Abstract. Cloud computing is an emerging distributed computing solution that
combines utility computing, software-, platform- and hardware-as-a-service.
Vendors in this domain offer web-services based transient utilization of
computing resources, reducing the need for permanent IT investments and
associated labor. However, the new infrastructure of cloud computing raises
several management and architectural concerns for IT organizations. Lack of IT
management capabilities in design, transition, and operation of these web
services generates hesitation in adopting the cloud solutions. Moreover, lack of
uniformity amongst the cloud vendors generates additional complexity. Thus,
abstracting the cloud management aspects and seamlessly integrating them into
the IT management workflows is important. In this paper, we present a
theoretical solution in the form of a reference architecture that captures the
gap between Cloud Computing and ITIL 3.0. We conceptually discuss the
architectural aspects of these components, as well as the possible advantages of
an implementation framework.
Keywords: cloud computing, utility computing, SaaS, architecture, ITIL, C3A,
EITM, IT management
1 Introduction
Cloud computing is one of the latest paradigms in computing technology, gaining
considerable popularity within the past year
1
. Cloud computing Infrastructure as as
Service (IaaS) consists amongst other things from the next-generation datacenters.
These datacenters are characterized by dynamic infrastructure, of optimized
computing resources, being frequently allocated and de-allocated using server
virtualization technology in order to provide, scalable, reliable on-demand and
pay-per-use services [14]. From an IT department (the cloud consumer)
perspective, the primary concept behind cloud computing is that of renting computing
resources, without permanent investments in equipment and related relative labor.
Vendors such as Google [12] and Amazon [9] are therefore able to leverage their IT
investments into cloud computing infrastructures. In return, the cloud customers can

1
As of February 2009
27
utilize the offered hardware and platforms for the required length of time, rather than
purchasing equipment for short-term projects.
This has implications for application providers who develop solutions targeted for
internal deployment (local) or within the enterprise datacenters (near), rather than
using remote web-services of third-party datacenters (the cloud). An example for a
composite solution is the ability to deploy web servers, load balancers and front end
interfaces on the cloud, while keeping the database part of the application local.
This has further impact on ITIL (Information Technology Infrastructure Library)
[13] processes. Many large organizations are implementing the ITIL approach,
performing well-defined automated processes. Since ITIL is agnostic to platform and
technological tools, it is the responsibility of management tools implementers to bind
Enterprise IT Management (EITM) practices and advances in technology, such as the
new cloud offerings.
The cloud solution is similar in many ways to traditional system architectures in its
resemblance to internal grid computing, where all the grid architectural characteristics
are under full consumer control. Yet, in the cloud, which is based on web services, it
is not the case for hardware utilization, security management, change management,
roaming concerns, e-discovery, nor many other IT operational and management
aspects.
Considering it all, the requirements for merging the two domains are:
1. Can we present and map the deficiencies of the Cloud according to ITIL
needs, and thus define a set of high-level components that address specific
issues?
2. What will be the structure of a conceptual bridging architecture that integrates
these components and connects them to the cloud web services as well as to
the ITIL implementation components?
In this paper, we present a theoretical model that captures the proposed gap
between Cloud and ITIL in the form of a reference architecture. The benefits from
this conceptual architecture are embedded in the description of capabilities of each
high-level component; thus defining functional and structural requirements for a
comprehensive bridging technology.
The reference architecture is presented using the C3A methodology [5], where
each level 1 component is described in some detail. We particularly focus on the
integration points between components, identifying the requirements that are unique
to a cloud environment and ensuring ITIL 3.0 compatibility.
The remainder of this paper is structured as follows. In Section 2 we provide a
brief description of the C3A methodology that we employ throughout this paper. In
Section 3 we provide some background on cloud computing. In Section 4 we describe
our reference architecture for application providers, focusing on those areas that are
different from traditional architectures and highlighting ITIL integration points. We
then provide some discussion on related work in Section 5 and conclude in Section 6.
28
2. C3A Methodology
The C3A (CA Agile Architecture) methodology, developed by Hadar and Silberman
[5], can be used to represent both a high-level reference architecture and an
implementation architecture that drills down to the desired depth. In general, this
approach uses only three abstraction levels, although in principle n-levels are
available. This restriction is in recognition of the fact that architects often do not have
the resources to develop their architecture fully, but rather require an agile process
whereby updates can be done quickly and dependencies are easily identified.
The C3A architecture is typically represented using four layers: external business
integration, functional architecture, system architecture and cross-concerns system
architecture. As an example, figure F-2 shows 2 layers, the integration and system.
These layers cater to different stakeholders: external integrators, functional and
system architects, and common components managers, respectively.
There are three levels that can be represented inside each layer. Figure F-1 shows
the three levels of components. Level 0 (presented in blue, and symbolized by a UML
package notation) represents the modules, identifying the high-level sub-systems.
Level 1 (presented in green, and symbolized by a UML Component notation) consists
of deployable components, which can be thought of as independent entities such as jar
files or MS-DLLs. The basic premise is that a level 1 component can be removed and
replaced with a similar component without affecting the rest of the system or
requiring the replacement of a full module. Level 2 (orange, and symbolized by a
UML Class notation) contains an internal cohesive set of components that usually will
not be deployed or managed separately.
3 Cloud Computing
Cloud computing is an emerging distributed computing solution that combines utility
computing, software-, platform- and hardware-as-a-service. Vendors in this domain
offer transient utilization of scalable computing resources, reducing the need for
permanent IT investments and the associated labor. However, the new infrastructure
of cloud computing raises several management and architectural concerns for large IT
enterprises.
Figure F-1 conceptually represents, using some of the C3A format [5], the key
components in a cloud computing environment. It presents the cloud architectural
stack with five key Level 0 modules: consumers, client technology, software (SaaS),
platform (PaaS) and utility computing. Naturally, each vendor might offer a partial set
of the stack, and may have different inner implementations. For example, a consumer
can run an application on a platform without requiring a particular service, however it
will still require some computing power. Consumers (Module 1) of cloud technology
can span many verticals, including government, health, finance, etc. All should be
supported by the underlying cloud infrastructure regardless of their particular vertical
origin.
Consumers are dependent upon client web technology (Module 2) in order to
connect into the cloud web services. Such client technology includes, but is not
limited to, browsers and web 2.0 access points. The client technologies may have
29
access to either or all of the three modules: services (SaaS), platform (PaaS), and
utility computing.
The services (SaaS, or Software-as-a-Service) module (Module 3) consists of
components representing compliance and governance, social networks (e.g., FlickR,
FaceBook), e-commerce (e.g., eBay), banking (e.g., credit card services) and project
management (e.g., CA's Clarity product [10]), as well as potentially other components
such as ERP portals.
In a similar way to SaaS, there now exists PaaS, or Platform-as-a-Service (Module
4). This module offers various platform components (servers) such as web servers,
web 2.0 and java (JSR 168 or 286) portlets and web 2.0 gateways. Customers can
install direct applications on those servers, without managing the actual underlying
platform.
The utility computing module (Module 5) consists of both computing power and
storage components. Given the cloud environment that this architecture represents,
the computing power component can be thought of as hardware-as-a-service (HaaS),
where a consumer rents time on that hardware, while the storage component can be
thought of as data-as-a-service (DaaS), where a consumer rents disk space or database
storage. The computing power component (HaaS) consists of several level 2
technologies, complete with dependencies between these components. Some cloud
providers utilize virtualization technologies, and some use clusters. As a result we
have technologies at level 2 representing both virtual hosting (providing readymade
operating systems) and hardware virtualization (that requires the installation of an
operation system). The result is that consumers do not need to be concerned with the
underlying hardware, but rather need only to provide an image to the cloud vendor,
which can then be deployed across various hardware implementations (e.g., using
VMWare or Zen hypervisors).
4 The Cloud Management Reference Architecture
In this section, we present a reference architecture interweaving ITIL 3.0 management
modules with the cloud computing environment. We are specifically concerned with
providing a generic architecture that represents the two forms of cloud computing
from a stakeholders perspective:
1. the IT owners who are utilizing cloud web-services and who thus need to
integrate the cloud offerings with their own IT organization, and
2. the cloud computing providers who need to provide appropriate cloud
business-services and ITIL integration points to the IT owners.
Figure F-2 provides the high-level (Level 0) C3A reference architecture for the
cloud and ITIL 3.0 modules. It focuses on two layers of the C3A. The first is the
external integrations architecture, which contains all the parts that do not belong to
the reference architecture, either from the ITIL or from Cloud perspectives. These
identified and mapped modules are 3 to 5 (representing the cloud interaction points
defined in the previous section) and Modules 6 to 9 for ITIL 3.0. The remaining
modules are located inside the system architecture layer, containing the conceptual
components of the bridging technology (modules 10 to 15) that provides the
adaptation system between ITIL and the Cloud systems.
30
Fig F-1: Cloud Architectural Stack
4.1 The ITIL External Integration Architecture Components
In order to demonstrate the requirement for bridging, we define here part of the
ITIL process and definitions, captured as modules (noted as UML package symbols)
and inner functions (noted as UML components). The relevant high-level architecture
elements that need to interact with the cloud are presented in figure F-3 and defined
ahead.
x Service Strategy (module 6) contains the project and portfolio (PPM) component
that enables the organization of the IT strategies and ongoing initiatives, and the
financial management component, which contributes commercial value to the IT
investments and resources. This module connects to the cloud via module 12
(Cloud e-commerce Arena) for evaluating costs of the initiatives as well as
to module 11 (Benchmarking Manager) for evaluating alternative cloud
vendors.
x Service Design (module 7) consists of five separate components. The service
level management component sets and monitors agreements based on service
requests, negotiates with supply chain managers, sets agreements for operations
and services, and catalogues the results. Analytical modeling captures the
defined and offered services. Service capacity management compares
alternatives for IT resources by analyzing costs and quality, conducting load
tests, and accordingly adjusting the definitions. Information security
management defines the needed associations and limitations in order to reduce
the threat of information inappropriate usage. Finally, IT service continuity
management performs continuous analysis in order to evaluate service trends for
optimization.
Consequently, as with any other service, the cloud services quality attributes
should be measured and evaluated by the service design components,
31
specifically comparing cloud vendors, as well as internal datacenter offerings. It
connects to the cloud using module 10 (Cloud Security Management) and
module 11 (Benchmarking Manager).
Fig F-2: Level 0 reference architecture for the Cloud ITIL integrations
x Service Transition (module 8) is responsible for ensuring the deployment of the
designed services. It consists of five key components. The asset management
component is responsible for tracking and reporting the deployed assets within
an organization. The configuration management system maintains information
on the topology and system infrastructure. The life cycle for design changes is
controlled by the change management component. Release management is
responsible for testing a changed item prior to releasing it into the system. Thus,
this component builds and organizes the deployed packages, rolls out the change
and evaluates the success of the change. Finally, the knowledge management
component is responsible for gathering, analyzing, storing and sharing the
knowledge and information within an organization.
In terms of the cloud offering, the provisioning element is the most relevant one
for abstracting the actual deployment, as well as controlling the management
access permits. The transition module interacts with the cloud using module 15
(Cloud Change Management) and module 13 (Portability Manager).
x Service Operation (module 9) measures the services provided on an ongoing
basis with the goal of ensuring a high level of quality is maintained across the IT
32
investments. In order to achieve this goal, six different components are
required. IT operations management deals with the definition and monitoring of
the availability and performance of deployed IT assets. It provides an operations
dashboard that displays the overall status and health of the system to the
consumer. Business continuity management is responsible for ongoing
provisioning, recovery, backup and redundancy of the IT assets within the
datacenter, as well as countermeasures and remedy. The problem management
component provides proactive planning capabilities through the analysis of IT
behavior, detecting utilization patterns and change history. This information is
then used to compare actual versus estimated costs, to determine if Service
Level Agreements (SLAs) are being met, if there are any indicators that
performance is deteriorating, etc. The end goal is to alert the consumer that a
problem is starting to appear, providing the consumer with the possibility of
mitigating the issue before it becomes critical. Governance and compliance
requirements are achieved through the identity and access management
component, which manages users and controls their access to the resources in
the system based on, for example, their organizational role. The storage
management component manages the distributed data stores for the
organization. It is additionally responsible for provisioning and allocating
storage resources. A service desk and incident management component provides
the ability to restore IT services back to operation through a workflow and life
cycle of incidents that concludes with incident resolution.
Fig F-3: the ITIL 3.0 service management modules
33
The affect of this module on cloud management is extensive, since it fulfills the
need of the information systems deployed externally to the organization to keep the
lights on, without any means of enforcement or regulation. Delegation of its
responsibility is delivered to the cloud using modules 14 (Cloud Performance and
Availability Management), module 15 (Cloud Change Management) and module 13
(Portability Manager).
4.2 The Cloud Computing System Conceptual Architecture Components
Within the system architecture layer, there are six modules that need to connect the
cloud with ITIL: cloud security management (module 10), benchmarking manager
(module 11), cloud ecommerce arena (module 12), portability manager (module 13),
cloud performance and availability management (module 14), and cloud change
management (module 15). Figure F-4 presents modules 11, 12, and 13. Figure F-5
presents modules 14 and 15. Each module is described in more detail below.
It is important to note that these six high level modules contain the sub-system
requirements and capabilities that form the main contributions of this paper as they
represent capabilities that are unique to the cloud environment.
In what follows, we capture the requirements of each component, dividing the
responsibility according to both ITIL needs and the Cloud offering.
The cloud security management module (10) consists of two components. It is
generically responsible for providing the security aspects of controlling the entry
points to the cloud. It uses a cloud security sentry component and a security SLA
requests component. The cloud security sentry component delegates requests for
access control enforcement, as well as collects observations of actual behavior by
providing interception mechanisms on service calls. This component provides a
guarded call mechanism that prevents access to the customer IT environment by cloud
applications, thus protecting the customer IT systems from the cloud. The security
SLA requests component acts as a remote proxy for compliance access control tools.
It is responsible for mediating requests to deploy security and access control policies
on roaming users, hosts and servers.
The benchmarking manager (11) module is responsible for comparing the
published capabilities of cloud vendors by generating a comparative list of vendor
attributes (e.g., provided hardware, cost for storage, etc.). Thus, the attributes
extractor component accesses the non-functional characteristics of the clouds
attributes (e.g., pricing, supported hardware and more). These attributes are provided
to the cloud attributes aggregator component, which evaluates and composes
accumulated values for each vendor, comparing them against the customer quality
attributes. This provides customer specific prioritization of the cloud vendors. The
attributes are passed to the alternatives comparator component, which presents the
selected benchmarked vendors using a consistent set of ITIL metrics. The run-time
performance of each vendor offering is tested by the deployment performance
component for the installation and removal of an image.
The portability manager (13) is responsible for the portability of deployed images
from one cloud vendor to another. For example, should one cloud vendor not be
meeting the SLA requirements, this module can automatically repack the deployed
34
entity according to the new vendor definitions and port it to a new cloud platform. In
order to achieve this, the module consists of six components. The first component,
image design and modeling, defines a configuration model of the entities that need to
be packaged. The package description component generates the packaging
instructions and configuration descriptions for a specific vendor. The image
provisioning and deployment component enables the actual rollout of a certain
configured image for a specific cloud vendor. The removal of deployed images (or the
inner elements of an installed application) from a specific cloud vendor is controlled
by the image decommission and rollback component. The status of the images is
monitored by the change status monitor component, while the image backup and
replication component uses the portability mechanism to provide backup and
replication functionality as part of normal business processes.
The cloud e-commerce arena module (12), consisting of only two components,
provides the capability to negotiate costs and comparisons. This allows computing
resources to be treated as a commodity. The cloud interface broker component, which
connects to several cloud providers, enables the selection of vendors, the orchestration
of several options, and billing for the services of managing external SLAs inserted on
top of the vendors. The cloud billing-monitoring component is responsible for the
actual consumption of the billed payments.
The cloud performance and availability management (14) module is responsible
for monitoring the status of applications, hosts and services on the cloud. It is further
responsible for providing this information to Enterprise IT Management (EITM) [11]
operation tools. Six components are required in order to achieve these goals. The first
component, the SLA enforcer, inserts penalties (or triggers a search for alternative
vendors) upon the services specified in the SLA not being met. The quality attributes
real time monitor component monitors the quality settings of the IT manager.
Fig F-4: System Architecture modules: Benchmarking Manager (11), E-commerce Arena (12)
and Portability Manager (13)
35
For example, this component might monitor energy measurements for the
equipment being used within the cloud for purposes of compliance with GreenIT
initiatives. The cloud logging manager component is responsible for extracting
aggregated logs and events to the customer so that the customer can integrate this
information into a centralized repository containing the logs from all the IT systems,
both cloud and non-cloud. Performance metrics (e.g., availability, maximum
utilization) are measured by the cloud performance monitoring component. The
virtual load-balancing component enables distributed load balancers and automated
failover (between cloud and non-cloud). It achieves this through the provisioning of
one or more of the participating servers in a grid, which is then managed as an image
on the cloud. This server acts as a backup to provide high availability through
redundancy. Finally, the supply change manager component is responsible for
measuring the efficiency of the supply chain. It achieves this by providing an
extended service desk adaptor that facilitates the delegation of service desk requests
from the ITIL workflow into the cloud vendor.
The cloud change management module (15) consists of seven components. This
module abstracts the cloud to a CMDB (configuration management database),
managing transitions and changes to the cloud application, and capturing its structure
configuration. The first component, the transient deployment manager, provides a
fail-over management capability that can deploy a temporary solution on the cloud
enabling high availability even when the price might be high by providing a
transient replacement for regular IT systems. The agile change manager component
enables incremental and measurable changes by comparing attributes of service
quality between different implementations. The cloud provisioning manager
component enables the rollout of particular images for a particular cloud vendor. The
virtual configuration monitor component maintains snapshots of physical
configurations over time with the goal of enabling diagnostics, discovery of assets on
the cloud or cloud offerings, root cause analysis, and e-discovery requirements. This
is part of CMDB history images and is used by information management and e-
discovery. Cloud offerings are extracted as managed configuration items (CI) by the
virtual CI manager component, which maintains this information for service
availability. The cloud roaming model component defines a service configuration
over virtual CIs from different cloud vendors, displaying their measured values over
time, regardless of the underlying roaming structure. It automatically adjusts service
performance based on the (changing) underlying structure. The roaming sentry
component constrains roaming capabilities within the cloud as determined by
governance and compliance requirements. For example, this component might be
used to overcome the non-location' dependency in cases of e-discovery where
location is of importance.
5 Comparison to Related Work
In their keynote address, Buyya et al. [2] argue that market-oriented resource
management is required for cloud computing in order to regulate supply and demand
and promote service differentiation (e.g., based on quality of service and other
standard SLA clauses). They provided an architecture for such a system in their
paper; however, this architecture does not address the individual modules or
36
components required in order to achieve their vision, nor does it demonstrate its
relationship to ITIL requirements. Moreover, the architecture that we have presented
in this paper addresses the requirements that were identified by Buyya et al., such as
modules that are responsible for monitoring services, negotiating SLAs, and
determining appropriate pricing. In fact, the architecture that we have presented
automates more of the process than originally envisioned by Buyya et al. (such as
automated migration between cloud vendors and automated comparisons between
vendor offerings).
Fig F-5: System Architecture modules: Cloud Performance and Availability Manager (14) and
Cloud Change Management (15)
Aymerich et al. [1] also provide a very high-level architectural view of cloud
computing, along with a discussion of the advantages that cloud computing provides
to consumers. The authors focus more on individual users rather than on the
advantages to large-
scale businesses. Further, the architectural views they provide are conceptual in
nature, and do not provide the level of detail presented in this paper.
Wang et al. [8], who provide architecture and system requirements, describe
Cumulus, a scientific cloud for a data center. Specifically, they identify on-demand
services (hardware, software, and data) along with on-demand service provisioning,
quality of service guarantees and autonomy as requirements, all of which we have
37
addressed in our architecture. As with the previous two papers, the architecture
presented in this paper is provided at a very high level and does not address the
components or modules required to provide the services required (e.g., quality of
service guarantees).
Frince and Petcu [4] also provide an architecture that can support cloud
computing, with a focus on mathematical-described problems. However, the
architecture they present concentrates on providing a low level platform for
controlling the distribution of clients tasks and message passing infrastructure. In
contrast, we have described the components required for a complete, and generic,
system that meets ITIL requirements for large-scale organizations.
Vouk [7] describes the architecture for a cloud system at NC State University. He
identifies several non-functional requirements, such as usability, substitutability,
extensibility and scalability, customizability, reliability, availability, and security.
However, the paper does not provide details on the architecture capabilities. Thus, it
is difficult to determine if, for example, the system described meets ITIL compliance.
Kesanav et al. [6] present Active CoordinaTion (ACT), which is a resource
management application for cloud environments. However, this application focuses
on managing virtual machines and so only addresses a subset of the management
functions identified in our architecture. Further, it focuses on the technology
requirements and does not address the business requirements, such as ITIL
integration.
Deelman et al. [3] examined the cost of using the cloud for a scientific application
that was data intensive. They found that there were significant savings to using the
cloud environment assuming that the consumer provisioned correctly for the
application. However, this example application did not investigate any of the other
aspects of cloud computing, such as the time required to setup virtual images,
although it did acknowledge that these costs should be studied and included.
6 Discussion and Conclusions
In this paper, we presented the conceptual requirements, captured within separate
architectural components, that serve as adapters between ITIL 3.0 and the Cloud web
services. The architecture is structured as a separate layer that intercepts ITIL
management requests and the Cloud web services. It can be merged into either of the
extremes, e.g. inserted as a hybrid within different ITIL implementations, or as part of
the web services offering of the cloud vendors, depending on deployment definitions.
The proposed structure maintains separation of responsibility; thus, it is currently
detached from both ITIL and the Cloud.
The description of each of the inner components maintains scope of
responsibilities and indicates the needed solutions on these bounded areas. Based on
previous research that detected difficulties with the usage and implementation of the
cloud, we mapped the discrepancies between the context and ITIL, proposing scoped
requirements that are aggregated within a framework. The modules themselves are
the cloud security management, portability manager, benchmarking manager, cloud e-
commerce arena, cloud performance and availability management, and cloud change
management.
38
These classifications of modules, and the cross-dependency amongst them and the
ITIL and Cloud boundaries, constitute the reference architecture of this paper. Thus,
this proposed architecture enables simplified and unified management of the IT
department offering, which maximizes the cloud offering and extends these web
services capabilities.
References
1. Aymerich, F.M., Fenu, G., Surcis, S.: An approach to a cloud computing network. In:
Proceedings of the First International Conference on Applications of Digital Information
and Web Technologies, Ostrava, Czech Republic (2008)
2. Buyya, R., Yeo, C.S., Venugopal, S.: Market-oriented cloud computing: Vision, hype, and
reality for delivering it services as computing utilities. In: Proceedings of the 10th IEEE
International Conference on High Performance Computing and Communications, Dalian,
China (2008)
3. Deelman, E., Singh, G., Livny, M., Berriman, B., Good, J.: The cost of doing science on the
cloud: The montage example. In: Proceedings of the 2008 ACM/IEEE International
Conference for High Performance Computing, Networking, Storage and Analysis, Austin,
Texas (2008)
4. Frince, M.E., Petcu, D.: On designing an asynchronous and dynamic platform for solving
single task requests of remote applications. In: Proceedings of the Third International Multi-
Conference on Computing in the Global Information Technology, Athens, Greece (2008)
5. Hadar, E., Silberman, G.: Agile architecture methodology: Long term strategy interleaved
with short term tactics. In: Proceedings of the International Conference on Object Oriented
Programming, Systems, Languages and Applications (OOPSLA), Nashville, US (2008)
6. Kesavan, M., Ranadive, A., Gavrilovska, A., Schwan, K.: Active CoordinaTion (ACT) -
toward effectively managing virtualized multi-core clouds. In: Proceedings of the 2008
International Conference on Cluster Computing, Tsukuba, Japan (2008)
7. Vouk, M.A.: Cloud computing - issues, research and implementations. In: Proceedings of
the ITI 2008 30th International Conference on Information Technology Interfaces, Cavtat,
Croatia (2008)
8. Wang, L., Tao, J., Kunze, M.: Scientific cloud computing: Early definition and experience.
In: Proceedings of the 10th IEEE International Conference on High Performance
Computing and Communications, Dalian, China (2008)
9. Web Site: Amazon Elastic Compute Cloud, http://aws.amazon.com/ec2, last accessed on
Nov. 29, 2008.
10. Web Site: Clarity, http://www.ca.com/us/project-portfolio-management.aspx, last accessed
on Dec. 1, 2008.
11. Web Site: Enterprise IT Management, http://www.ca.com/us/enterprise-it-
management.aspx, accessed on Dec 1, 2008.
12. Web Site: Google App Engine, http://code.google.com/appengine/, accessed on Nov. 29,
2008.
13. Web Site: ITIL 3.0, http://www.itil-officialsite.com/home/home.asp, accessed on Nov. 29,
2008.
14. Weiss, A.: Computing in the clouds. netWorker 11(4) (2007) 16-25
39
40
A Best Practice Model for Cloud Middleware
Systems
Ajith Ranabahu
1
and E. Michael Maximilien
2
1
Knoesis Center,Wright state University, Dayton OH 45435, USA,
ajith@knoesis.org
2
IBM Almaden Research Center, San Jose CA 95120, USA
maxim@us.ibm.com
Abstract. Cloud computing is the latest trend in computing where the
intention is to facilitate cheap, utility type computing resources in a
service-oriented manner. However, the cloud landscape is still maturing
and there are heterogeneities between the clouds, ranging from the ap-
plication development paradigms to their service interfaces and scaling
approaches. These dierences hinder the adoption of cloud by major en-
terprises. We believe that a cloud middleware can solve most of these
issues to allow cross-cloud inter-operation. Our proposed system is Al-
tocumulus, a cloud middleware that homogenizes the clouds. In order to
provide the best use of the cloud resources and make that use predictable
and repeatable, Altocumulus is based on the concept of cloud best prac-
tices. In this paper we briey describe the Altocumulus middleware and
detail the cloud best practice model it encapsulates. We also present ex-
amples based on real world deployments as evidence to the applicability
of our middleware.
1 Introduction
Cloud computing is resulting in very cheap, on-demand, seemingly unlimited
compute resources. Any enterprise can easily provision, manage, and sustain
(keep up to date and scale) their entire operations on a compute cloud for a
fraction of the cost of owning the resources. In essence, cloud computing results
in commoditization of typical computing resources which are now, via compute
clouds, available as a service.
While most enterprises could make use of such cheap resources to deploy
their applications, there remains various concerns to address and that could
help accelerate that transition. These challenges can be summarized into three
categories: 1) quality of service, 2) security and privacy, and 3) dynamic scaling
to meet application customer demands.
The current state of the art in the industry is to capture or dene best
practices. Best practices are known good patterns of software congurations
and setup (with appropriate updates) that are known to be reliable or that
address some of the specic issues listed above. For example, a common best
practice to scale a relational database to a large number of (predominantly read)
41
requests is to use an in-memory cache such as memcached[1]. By running a
properly congured memcached process, database query results can be saved
in the memory cache so that frequently repeated queries are not served from
the database but rather fetched from the cache. Naturally, adding a memory
cache alone does not solve the entire scaling issue and other steps need to be
taken to truly scale the system. However, adding a memory cache is a known
scaling solution for read intensive database applications and is considered a best
practice.
Making ecient use of a cloud computing environment in order to reap the
benets while trying to address the key concerns listed above can be done using
best practices. However, such best practices are typically tacit knowledge and
they evolve and change over time. The ideal situation would be to try to auto-
mate best practice-based cloud deployments for the dierent cloud frameworks
available, as well as having a means to allow such best practices to evolve and
new ones to be added.
The IBM Altocumulus research project is a new kind of cloud platform and
middleware that attempts to address exactly this issue. In addition to enabling
deployments addressing some of the quality, security, and scaling issues that are
common in Web applications development, IBM Altocumulus allows such deploy-
ments to be done in a cloud-agnostic fashion. Finally, it also enables migrations
of deployments across compatible clouds.
1.1 Organization
The remainder of this paper is organized as follows. Section 2 discusses related
work such as software patterns and cloud middleware. Section 3 gives an ar-
chitectural overview of our middleware and explains some of the key use cases.
Section 4 gives a detailed description of our notion of a cloud best practice along
with some specic examples around several key pain points cloud users expe-
rience. We discuss where the project currently stands and initial results of our
deployment of the platform inside IBM in Section 5 and conclude after describing
some ongoing and future work in section 6.
2 Related Work
2.1 Middleware
Middleware, in the context of distributed computing systems, was rst described
by Bernstein et al. [2] as a set of intermediaries for the components in a dis-
tributed computing system. This concept has been extensively utilized during
the uprising of the Service-Oriented Architecture (SOA) where the services in
question were in fact provided by middleware systems. Middleware in general
is used to abstract the dierences between heterogeneous systems and expose a
uniform interface.
42
2.2 Cloud Computing
Cloud computing is dened as both the applications delivered as services over
the Internet and the hardware and systems software in the data centers that
provide those services [3]. The landscape for computing clouds is still evolving
and there are three major paradigms of cloud services available today.
Infrastructure as a Service (IaaS) : The raw computing resources are
exposed to the consumers. There are options for including support software
but usually there is no abstraction over the system complexities. This is in
fact exactly the same as getting access to a physical computer attached to
the Internet. Amazon EC2 [4] is the leading IaaS provider and the most
prominent cloud service provider today.
Platform as a Service (PaaS) : Consumers get access to an application de-
velopment platform possibly hosted on a infrastructure cloud. The platform
completely abstracts the complexities of the underlying host system. The
platform also guarantees load balancing and scaling in a transparent man-
ner to the cloud consumer. However these platforms typically are restrictive
and requires the hosted applications to strictly adhere to certain specialized
Application Programming Interfaces (API), frameworks, and programming
languages. Google AppEngine [5] is an example of a PaaS.
Software as a Service (SaaS) : Consumers get access to specialized soft-
ware suites hosted in a cloud environment. Unlike the platform oering, there
is no room for custom application development. However the oered software
suites are generally extensively customizable. The SalesForce.com Customer
Relationship Management(CRM) solution is an example where software is
oered as a service.
In this work, we primarily focus on the Infrastructure and Platform service
clouds (IaaS and PaaS). In the subsequent uses of the word cloud we refer to
either a IaaS or PaaS unless otherwise stated.
2.3 Patterns
Patterns in software engineering (or Design Patterns) was pioneered by Beck
et al. [6] and has gained popularity due to the applications in the widely used
Object-Oriented Programming (OOP) languages [7]. Patterns are well accepted
in the industry and deemed essential for a software engineer, primarily to avoid
inecient programming practices and stop reinventing the wheel. For example
when constructing a user interface driven application, the best known way to
engineer it is to follow the Model View Controller (MVC) pattern [7]. Following
the MVC pattern not only simplies the construction but also improves reuse
and maintainability of the application. Use of patterns can also be seen in the
higher layers of software engineering such as for enterprise applications [8].
Middleware for clouds has been discussed even during the earliest days of the
cloud [9]. However in terms of functionality, a cloud middleware was expected
43
to either manage or congure the respective cloud itself. The work described in
this paper deviates from that idea signicantly by positioning the cloud middle-
ware in the perspective of the cloud consumer. In other words the middleware
and the best practice model described in this paper is aimed at homogenizing
the cloud interfacing in the perspective of the cloud consumer. We believe that
such a perspective change is necessary since the service interfaces for clouds are
signicantly dierent and vastly complex.
3 Middleware Architecture
3.1 Overview
The primary service that IBM Altocumulus provides to cloud users is convenient
deployment of applications (primarily Web applications) to a variety of clouds.
Additionally, IBM Altocumulus allows other services such as backup and restore
of database content as well as cloud image creation and cloud image migration.
The Altocumulus middleware consists of three major components that inter-
act with each other, as illustrated in gure 1.
1. Core: The primary functional component of the middleware. The Core man-
ages the interactions with dierent cloud providers and exposes a private
RESTful API.
2. Dashboard: The primary user interaction component. The dashboard pro-
vides a comprehensive web based user interface for human users. The dash-
board also provides credential and artifact management facilities and uses
the Core via the private API.
3. Core-API: The public API for the core. Core-API exposes a well docu-
mented RESTful API for applications and acts as a fa cade to the Core.
Core-API facilitates the controlled exposure of the middleware functionali-
ties for external applications.
Apart from these three components, there is a support component that man-
ages images for various clouds called the image repository. The term image is
used in this context to represent a serialization of the artifacts of a working
system, in accordance to the use of the term Amazon Machine Image (AMI)
by Amazon. The function of the image repository is to store and manage such
images. While the role of the image repository is not considered central to the
Altocumulus platform, it is indeed useful and acts as a support component.
All IBM Altocumulus deployments are done via the utilization of cloud best
practices that attempt to provide pre-packaged software stack and related cong-
urations for a specic type of application. For example, using IBM Altocumulus,
a deployment of an IBM WebSphere sMash application on a public cloud (such
as the Amazon EC2) can be done repeatably including all necessary software
congurations. If the target cloud needs to be changed, the change to the de-
ployment is minimal and users are shielded from the complexities that arise from
such a dierence.
44
Fig. 1. High level view of the Altocumulus Middleware Platform
IBM Altocumulus currently supports Amazon EC2 and Amazon clones such
as Eucalyptus [10], Google AppEngine [5] and the IBM HiPODS Cloud comput-
ing solution.
We use adapters to interface dierent clouds. The current implementation
uses manually programmed adapters. We discuss the possibility of generating
these adapters by a semi-automated process in section 6.
45
4 Best Practice Model
4.1 Overview
Our best practice model is designed around three principles.
1. Provide logically arranged place holders for dierent types of data required
for a cloud deployment.
2. Be applicable to dierent cloud paradigms.
3. Have a reasonable balance between completeness and complexity.
The rst design principle caters for the fact that there are signicant number
of dierent data items that is needed for a deployment. Although these data
items may vary signicantly between dierent deployments, they can be logically
grouped and arranged.
The second principle states that such a grouping needs to be compatible with
the dierent cloud paradigms described in section 2.2.
The third principle states that this grouping needs to be reasonably complete but
not overly complex since it is meant ultimately for a human. This is especially
important considering that various components of a best practice would evolve
over time, i.e. will have dierent versions. The goal here is that a user would be
able to redeploy a cloud application with an updated best practice using a one-
click action. This can be signicantly important when a new version of a best
practice component is released for security and privacy purposes, e.g. a patch
solving a security vulnerability.
We now describe the details of the Altocumulus Best Practice (BP). A BP
in its simplest form is a particular sequence of process steps (selected either
automatically or manually) that best suits the cloud management task at hand.
A BP however, diers from a simple workow since it may additionally include
provisions to dene other aspects of a deployment such as scaling. A BP consists
of two primary components.
Topology : An indication of the structure of a particular deployment. In
the simplest form, the topology can be a single instance or an application
space. However the topologies can be arbitrarily complex. In section 4.2 we
discuss several common topologies.
Scaling Strategy : Encapsulates the process for scaling. For some clouds,
such as platform clouds, the scaling strategy would be empty. However for
infrastructure clouds (IaaS providers) the scaling strategy includes details on
what resources to manage when a scale-out or scale-in operation is required.
The scaling strategy is tightly coupled with the topology.
The Scaling Strategy includes customizable rules that can be used to control the
behavior of the scaling process. For example, for a strategy of scaling horizontally
by replicating, the rules would control the load limit to spawn a new replication
and the maximum number of replications allowed. These limits may be set by a
user or a process.
46
The Topology is based on instance groups. An instance group refers to a set of
functionally equal compute nodes or a cluster. Each instance group attaches to
a conguration bundle that in turn includes an ordered set of congurations. A
conguration represents a single step in a simplied work ow of setting up the
node. For example installing a database software is a conguration. Congura-
tions (optionally) have parameters, most of them user tunable. To use the above
example, the default user name and password for the database would be part of
the user tunable conguration parameters.
Figure 2 illustrates the structure of a Best Practice in UML notation.
Fig. 2. Structure of a Best Practice
While some simple BPs have only on instance, advanced BPs allow deploy-
ments to be spread across groups of instances that can grow and shrink according
to some rules. Due to the complexity of building a custom BP from scratch how-
ever the Altocumulus platform contains a number of pre-built BP templates for
the most common cases. Regular users are allowed to customize these BP tem-
plates and only privileged users can construct them from scratch. We further
discuss the issues involved in custom BPs in section 5.1.
4.2 Example Best Practices
Now we present three examples that clearly illustrate the exibility of the best
practice model and its coverage of the design principles stated in section 4.1.
We also describe some of the pain points these BPs try to overcome.
A Single Instance Best Practice This is the most simplistic BP where all
the congurations apply to a single instance. There is no scaling strategy. The
47
topology is in its simplest form where one instance contains everything. To cater
for such simple scenarios, the Altocumulus platform includes an empty scaling
strategy and a xed topology.
A Fixed Cluster Best Practice A popular use of compute clouds, especially
among the scientic researchers, is to use them for parallelizable computations
using the map-reduce paradigm [11]. Apache Hadoop [12] is one of the popu-
lar map-reduce computation frameworks used for large computations. Typically
when setting up a map-reduce task the major pain point is setting up the man-
agement nodes and the worker nodes (worker nodes are generally large in num-
bers). The number of nodes for a computation task is generally xed and does
not uctuate during a computation.
The xed cluster BP supports this type of set up where the nodes may
be heterogeneous but xed in number. Currently this BP supports only the
Hadoop framework and includes a multi-instance star topology with 1) A central
management node and 2) A number of worker nodes. The scaling strategy is
empty since there is no dynamic scaling involved. This type of setup is illustrated
in gure 3(a).
A Horizontally Replicating Best Practice Todays typical framework based
Web sites are two tiered, i.e. they have a presentation front-end that displays
content fetched from a database back-end. Majority of public Web sites such as
wikis, forums or blogging platforms are structured this way. The popular open
source multi purpose Web platform Drupal [13] is one of the prominent examples
for a two tiered Web application platform. Scaling strategies for such two tiered
Web applications have been well studied and one of the accepted strategies is to
replicate the presentation component under a load balancer [14]. The pain points
in such a scaling process includes 1) replicating the complete conguration of the
presentation component which is typically a script language based application.
and 2) updating the load balancer conguration with the details of newly added
(or removed) instances.
This BP includes a multi-instance layered topology that includes 1) load
balancing layer 2) presentation / Application Server (AS) layer and 3) database
layer. The scaling strategy is horizontal replication and includes rules that trigger
replications. Figure 3(b) illustrates this architecture.
5 Discussion
IBM Altocumulus is a new kind of cloud middleware: a cloud broker that facil-
itates cloud agnostic deployment and management tasks. The primary goal of
this project is to attempt to homogenize clouds with a layer and API that would
allow higher-level services to be created. From our Altocumulus deployment in
the IBM Technology Adoption Program (TAP) (An internal portal of emerging
technologies with access only to IBM employees) we have learned that there is
48
(a) Star Topology for Hadoop (b) Layered Topology for Hori-
zontal scaling
Fig. 3. Dierent Best Practice Topologies
indeed a demand for this type of a cloud abstraction middleware. Recent devel-
opments in the hybrid cloud deployments, even across dierent paradigms [15]
underscores the importance of cloud homogenization.
5.1 Custom Best Practices
Ultimately the intention of the best practice model is to provide cloud users
with reasonable power and exibility in cloud application management. How-
ever creating an advanced BP template needs a signicant level of knowledge
and testing. For example creating the xed cluster BP described in section 4.2
requires in depth understanding of the Hadoop framework. Due to this reason
we have limited the BP creation capability only to privileged users. The regular
users can always customize existing templates. We believe this is not a seri-
ous limitation since majority of the use cases are covered by our existing BP
templates. Our TAP deployment experience also conrms this fact.
5.2 Other Lessons learned
Apart from the above mentioned experiences, we also learned important lessons
in applying a middleware platform in the cloud context.
1. Some clouds, especially platform services, mandate the use of certain libraries
for application development. Thus these applications become locked-in to
the specic cloud provider. Our middleware cannot solve this lock-in yet. A
dierent and completely new application development paradigm is needed
to generate portable cloud applications. Although such an eort is out of
scope for this research, we believe cloud agnostic application management is
the rst step in truly portable cloud applications.
49
2. Hybrid cloud deployments are deemed important amidst the mounting pri-
vacy and data protection considerations. Although Altocumulus doest not
provide hybrid deployments yet, we consider this to be the most important
next step.
6 Future Work
In terms of improving the middleware capabilities, we plan to expand the support
for application frameworks and relational databases as well as other clouds.
Supporting hybrid cloud deployments is our key next step.
An interesting avenue of research we plan to investigate is the use of seman-
tic web technologies to enhance the functionality of this cloud middleware. We
believe that some of the semantic web techniques can be used to help facilitate
the creation of cloud adapters as well as discovery and usage of best practices.
An interesting case would be a system capable of suggesting a suitable best prac-
tice given an application. Similar scenarios have been investigated heavily in the
context of semantic Web services and we anticipate further research can yield
the adaptation of such technologies in the cloud context.
The experience gained in semantic annotations can also be used in the con-
text of assembling user dened BPs. A possible line of future research includes
using meta data annotations to provide assistance to users for assembling BP
components and hence may provide a solution for the dilemma discussed in
section 5.1.
References
1. Fitzpatrick, B.: Distributed caching with memcached. Linux journal (124) (2004)
2. Bernstein, P.A.: Middleware: a model for distributed system services. Commun.
ACM 39(2) (1996) 8698
3. Armbrust, M., Fox, A., Grith, R., Joseph, A.D., Katz, R.H., Konwinski, A., Lee,
G., Patterson, D.A., Rabkin, A., Stoica, I., Zaharia, M.: Above the clouds: A
berkeley view of cloud computing. Technical Report UCB/EECS-2009-28, EECS
Department, University of California, Berkeley (Feb 2009)
4. Inc, A.: Amazon Elastic Compute Cloud (Amazon EC2) (2008)
5. Sanderson, D.: Programming Google App Engine: Rough Cuts Version (2008)
6. Beck, K., Cunningham, W.: Using pattern languages for object-oriented pro-
grams. Specication and Design for Object-Oriented Programming (OOPSLA-87)
67 (1987)
7. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: elements of
reusable object-oriented software. (1995)
8. Fowler, M.: Patterns of enterprise application architecture. Addison-Wesley (2004)
9. Babaoglu, O., Jelasity, M., Kermarrec, A.M., Montresor, A., van Steen, M.: Man-
aging clouds: a case for a fresh look at large unreliable dynamic networks. SIGOPS
Oper. Syst. Rev. 40(3) (2006) 913
10. Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youse, L.,
Zagorodnov, D.: The eucalyptus open-source cloud-computing system. In: Pro-
ceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Com-
puting and the Grid-Volume 00, IEEE Computer Society (2009) 124131
50
11. Dean, J., Ghemawat, S.: MapReduce: Simplied Data Processing on Large Clus-
ters. OSDI (2004) 1
12. Bialecki, A., Cafarella, M., Cutting, D., OMalley, O.: Hadoop: a framework for
running applications on large clusters built of commodity hardware. Wiki at
http://lucene. apache. org/hadoop (2005)
13. Mercer, D.: Drupal: Creating Blogs, Forums, Portals, and Community Websites.
(2006)
14. Talwar, V., Wu, Q., Pu, C., Yan, W., Jung, G., Milojicic, D.: Comparison of
approaches to service deployment. In: 25th IEEE International Conference on
Distributed Computing Systems, 2005. ICDCS 2005. Proceedings. (2005) 543552
15. Chohan, N., Bunch, C., Pang, S., Krintz, C., Mostafa, N., Soman, S., Wolski, R.:
AppScale Design and Implementation. Technical report, UCSB Technical Report
Number 2009 (2009)
51
52
Leveraging Cloud Infrastructure for Life
Sciences Research Laboratories:
A Generalized View
Nirav Merchant
1
, John Hartman
2
, Sonya Lowry
1
, Andrew Lenards
1
, David
Lowenthal
2
, and Edwin Skidmore
1
1
iPlant Collaborative, University of Arizona, Tucson, Arizona, USA,
http://www.iplantcollaborative.org
nirav@email.arizona.edu
(sonya,lenards,edwin}@iplantcollaborative.org
2
Department of Computer Science, University of Arizona, Tucson, Arizona, USA,
http://www.cs.arizona.edu/
{jhh,dkl}@cs.arizona.edu
Abstract. The Cloud is proving to be a valuable complement to the
compute resources traditionally used by research laboratories, with the
timely and scalable access to compute cycles being the primary benet.
The relative ease of marshalling and provisioning storage and compute
cycles is changing the way research applications are architected and ex-
ecuted, this presents new opportunities as well as new challenges. Aug-
menting traditional infrastructure with cloud capabilities facilitates tasks
that require signicant upfront infrastructural resources in a relatively
short time frame. But, the new model does not t well into the estab-
lished way of using computing resources with regards to nancial as well
as potential portability and interoperability issues.
Key words: Cloud, Research, Academia, Bioinformatics, Infrastructure
1 Introduction
Access to large-scale compute resources is the norm for most research labora-
tories, especially in the life sciences [1]. These research laboratories use in-silico
experiments based on models and simulations to drive the design of in vivo bio-
logical experiments [2][3][4]. The in-silico experiments are comprised of multiple,
complex and loosely coupled analysis workow steps[5][6]. The computational re-
quirements for these tasks range from large muti-core shared memory machines
to commodity clusters, in many cases by compromising the overall performance
signicant tasks in the workow can be o loaded on to commodity clusters. For
example the denovo genome annotation pipeline RAST(Rapid Annotation us-
ing Subsytems Technology) [7] that integrates tasks requiring high performance
computing resources along with equally compute and data intensive pre and post
processing tasks.
53
2 Merchant et al.
2 Cloud Computing in Research Environments
Obtaining compute resources in a timely and agile manner for the complete
analysis workow is frequently a challenging task for most academic research
groups. Often, resource availability decides the nal outcome of an intricate and
expensive biological experiment. This makes it increasingly important to provide
accessible, exible, scalable infrastructure to tackle compute intensive life science
research questions that require varied computational capabilities [8][9][10].
The Cloud opens the door for a fundamental change in how research applica-
tions are designed, deployed and benchmarked in academic research laboratories
[11][12]. The Clouds on-demand resource availability and seemingly innite scal-
ability can augment traditional in-house compute and storage capacity.
While in-house infrastructures have advantages that make them unlikely to
be replaced by the Cloud entirely, a potential synergy exists that supports the
varied computing workload of a life science research laboratory. For example,
experiments that require high-speed, low-latency interconnects can run on a tra-
ditional in-house cluster designed for that purpose, while large-scale experiments
that are compute-bound and time sensitive can run in the Cloud [13]. Some ex-
periments may have characteristics that require both an in-house cluster and
the Cloud and may span the two or even integrate with allocations provided
by national centers on highly specialized compute capabilities. This delicate in-
tegration between in-house, national centers and Cloud based resources can be
attained in theory by utilizing existing systems such as Condor Glide-in[14] and
Eucalyptus[15], in reality implementing a reliable solution using these options is
a technical challenge.
3 Challenges When Using the Cloud for Research
For all of its advantages, the Cloud does come at a price. In particular, relying
on the Cloud for scientic computation may result in a lack of portability and
performance, and the Clouds pay-as-you-go cost model may not be appropriate
for all experiments [16]. Reproducibility of research results in scientic comput-
ing is paramount[17]. The Cloud does oer the necessary compute and storage
infrastructure to easily reproduce results in a consistently identical execution
environment, but the customer wanting to perform similar calculations faces
technical hurdles leading to portability issues such as the need for custom vir-
tual images per vendor. This hinders the integration eorts for customers seeking
solutions where the workow spans multiple Cloud vendor implementations.
Portability is required to protect customer options. Service providers can
fail; customer service or pricing issues can lead to customer dissatisfaction. The
customer must maintain the freedom to do business elsewhere. Often, however,
vendors adopt a lock-in strategy [18] that makes it dicult to exercise that free-
dom. Dierent Cloud service providers are likely to have dierent capacities,
characteristics, and pricing models. The overall evaluation process and criterion
should be agnostic of the service provider and not tailored to specic feature set
54
Leveraging Cloud Infrastructure for Life Sciences Research Laboratories 3
of the specic service providers. It should be possible to stage the same eval-
uations and retrieve performance metrics from multiple provider with relative
ease.
The Clouds pay-as-you-go cost model is a double-edged sword for scientic
computation. On the one hand, current in-house computing resources do not
generally adopt this model, so that the true cost of running an experiment is
hidden from the researcher. For example, the CPU cost might not be apparent
to a researcher using an in-house facility. In the Cloud, resources such as CPU
time, bandwidth, and storage are billed directly. This may lead to unexpected
excessive costs for experiments that were not designed with this price model in
mind.
On the other hand, the Cloud can provide ne-grain reporting of resource
consumption necessary to eectively calculate the relative costs of the experi-
ment including network, storage and compute costs. Furthermore, the required
resources can be tailored to meet the needs of the specic workow steps in
the experiment, avoiding inecient provisioning. This reporting instrument can
foster realistic application proling and design considerations while supporting
informed quantitative decision making at all levels. Extracting and incorporating
similar information from existing distributed infrastructures is dicult.
The eective integration of Cloud resources raises issues and concerns that
are often encountered when resources use multiple vendor prescribed standards.
Making educated evaluations across Cloud service providers (in-house or exter-
nal) requires industry-wide standards that not only allow eective evaluation of
Cloud service providers through benchmarking and validation of their metering
of services, but also the ability to migrate and integrate between multiple Cloud
service providers with the same ease and transparency as Cloud computing oers
for scalability and control.
4 Conclusion
The Cloud is already proving its potential as an environment of choice for solv-
ing many of todays scientic problems, but many of the logistics are yet to
be resolved. While inroads have been made to integrate cloud resources with
local resources through Virtual Private Cloud (VPC) and systems such as Eu-
calyptus and Condor, there is still a pressing need for a robust solution that
integrates in-house, national centers and Cloud providers. For broader adoption
of Cloud computing in academic laboratories, concerns related to portability,
comprehensive cost models, and cross-implementation integration need to be
eectively addressed. A cautious and enthusiastic approach towards options of
Cloud computing can enable research laboratories with limited resources to ef-
ciently address the rapidly growing on-demand computational needs of the
community, bridging the digital divide for the much needed user-provisioned
scalable compute infrastructure to facilitate their research endeavors.
55
4 Merchant et al.
Acknowledgments. The authors would like to acknowledge the assistance and
patience of the workshop organizors and Lars Arne Skar, in particular, without
whom the world would have had to wait a bit longer to hear our opinions.
References
1. Dinov ID, Van Horn JD, Lozev KM, et al. Ecient, Distributed and Interactive
Neuroimaging Data Analysis Using the LONI Pipeline. Front Neuroinformatics.
2009;3:22. Epub 2009 Jul 20.
2. Justin Permar, Sivaramakrishnan Narayanan, Yolanda Gil, et
al. HPC and Grid Computing for Integrative Biomedical Re-
search. http://hpc.sagepub.com/cgi/content/abstract/23/3/252 DOI:
10.1177/1094342009106192 International Journal of High Performance Com-
puting Applications
3. Kirchmair J, Distinto S, Schuster D, et al. Enhancing drug discovery through
in silico screening: strategies to increase true positives retrieval rates. Curr Med
Chem. 2008;15(20):2040-53. Review.
4. Zoete V, Grosdidier A, Michielin O. Docking, virtual high throughput screening
and in silico fragment-based drug design. J Cell Mol Med. 2009 Feb;13(2):238-48.
Epub 2009 Jan 21. Review.
5. Raicu, Ioan and Zhang, et al. (2008). Toward loosely coupled programming on
petascale systems. SC 08: Proceedings of the 2008 ACM/IEEE conference on
Supercomputing: 1 - 12. IEEE Press. Piscataway, NJ, USA
6. Waltz, David and Buchanan, Bruce G. (2009). COMPUTER SCIENCE: Automat-
ing Science. Science. 324:5923, 43 - 44, http://www.sciencemag.org
7. Meyer F, Paarmann D, DSouza M, et al. (2008). The metagenomics RAST
server - a public resource for the automatic phylogenetic and functional analysis
of metagenomes. BMC Bioinformatics. 2008 Sep 19;9:386.
8. Arnon Rosenthal, Peter Mork, Maya Hao Li, et al. (2009). Cloud Computing: A
New Business Paradigm for Biomedical Information Sharing. Journal of Biomedi-
cal Informatics, http://www.sciencedirect.com/science/article/B6WHD-4X378DX-
1/2/e66d9108cb8e310d38f4df97734ebe9b
9. Giupponi G, Harvey MJ, De Fabritiis G. The impact of accelerator processors
for high-throughput molecular modeling and simulation. Drug Discov Today. 2008
Dec;13(23-24):1052-8. Epub 2008 Sep 16. Review.
10. Vera G, Jansen RC, Suppi RL. R/parallelspeeding up bioinformatics analysis
with R. BMC Bioinformatics. 2008 Sep 22;9:390.
11. Bateman A, Wood M. Cloud computing. Bioinformatics. 2009 Jun
15;25(12):1475. Epub 2009 May 12
12. Halligan BD, Geiger JF, Vallejos AK, et al. Low cost, scalable proteomics data
analysis using Amazons cloud computing services and open source search algo-
rithms. J Proteome Res. 2009 Jun;8(6):3148-53.
13. Ian Foster. Whats fastera supercomputer or EC2?. August 05 2009.
http://ianfoster.typepad.com/blog/2009/08/whats-fastera-supercomputer-or-
ec2.html
14. Thain D, Tannenbaum T, Livny M Distributed computing in practice: the Condor
experience. Concurrency - Practice and Experience 17(2-4): 323-356 (2005)
15. Nurmi D, Wolski R, Grzegorczyk C. et al. The eucalyptus open-source cloud-
computing system. Proceedings of 9th IEEE International Symposium on Cluster
Computing and the Grid, 2009
56
Leveraging Cloud Infrastructure for Life Sciences Research Laboratories 5
16. Edward Walker. Benchmarking Amazon EC2 for High-Performance Scientic
Computing. ;login:The USENIX Magazine October 2008, Volume 33, Number 5
17. Gentleman RC, Carey VJ, Bates DM, et al. Bioconductor: open software develop-
ment for computational biology and bioinformatics. Genome Biol. 2004;5(10):R80.
Epub 2004 Sep 15.
18. Liebowitz, S. J., Margolis, Stephen E. (1995). Path dependence, lock-in
and history. Journal of Law, Economics, and Organization 11: 205-226.
http://www.utdallas.edu/ liebowit/paths.html.
57
58
Migrating Legacy Applications to the Service Cloud
Weiqing.Zhang, Arne.J.Berre, Dumitru.Roman, Hans.Aage.Huru,


1
SINTEF, Pb. 124 Blindern, NO-0314 Oslo, Norway
{ davidzhang.job@gmail.com, Arne.J.Berre@sintef.no, Dumitru.Roman@sintef.no,
hansaage@gmail.com}
Abstract. An important challenge in todays software development domain is
the migration of monolithic legacy applications to be provided as Software as a
Service (SaaS) in the Service cloud, potentially with execution support through
a Platform as a Service (PaaS) cloud computing platform. We present a generic
methodology which shows how to migrate legacy applications to the service
cloud computing platform. A case study for scientific software from the oil spill
risk analysis domain is described, with highlights of current challenges.
Keywords: Legacy systems, Web service, Cloud Computing, MAD, ADM
1 Introduction
Legacy systems are software systems that have been built for more than decades with
old technologies and methodologies. These systems are continued to be used today
and play critical roles in their domain. When new requirements come to these legacy
systems, people find they are hard to maintain and update [1].
As a principle we can talk about 3 layers in a service cloud architecture, Software
as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service
(IaaS). The legacy system we focus on in this paper is in the SaaS level, which
features a complete application offered as a service on demand. A single instance of
the legacy software runs on the cloud and services multiple end users or client
organizations. These SaaS level service clouds runs above the PaaS clouds like
Amazon EC2. Compared to traditional way of deploying a system, cloud computing
has advantages like incremental scalability, agility, high reliability, high fault-
tolerance, service-oriented, and etc [2]. For the above reasons, many IT departments
consider to migrate legacy application into the cloud computing, hope can keep the
functionalities of legacy system without too much modifications of legacy code, and
also take the advantages of cloud computing. Most of these migrations focus on
specific technologies like Java or .Net [3], so a generic methodology to guide how to
migrate legacy system to cloud platform is necessary and important in scientific
software development domain.
This paper presents a generic methodology, which helps developers migrating a
legacy system to a SaaS cloud computing platform. This seven-step methodology will
guide developers through the migration details step by step and improve the
59
development and delivery of higher quality scientific software with higher
productivity and effectiveness.
The rest of the paper is organized as follows: Section 2 gives an overview of the
methodology, and briefly introduces each step of the methodology. In Section 3,
detailed descriptions of each step are presented. We will discuss how this
methodology works in sequential steps like architectural representation, architecture
redesign, model transformation, Web service generation, cloud platform selection,
and Web service deployment. Then Section 4 will take the OSCAR example system
in the SINTEF SiSaS project as an example to apply this methodology and
demonstrate how it works. Section 5 concludes the paper.
2 Methodology Overview
We design a generic methodology for the migration of legacy system to Cloud
Platform, which is depicted in Figure 1.

Fig. 1. Methodology Overview.
This generic methodology follows the following steps:
1) Architectural representation of the legacy application: Based on the source
code and text descriptions, we can analyze the legacy system and reconstruct
an architectural model of the legacy application.
2) Redesign the architecture model: redesign the original architecture model and
in particular identify services that can be provided in a SaaS architecture,
specified in a SoaML model [4];
3) MDA transformation: with MDA transformation technology [5], we can
easily transform the architecture model like SoaML , SysML [6], UML [7] to
target code like WSDL, JEE Annotation;
4) Web service generation: We can generate the target Web service based on the
WSDL or JEE Annotation;
60
5) Web service-based invocation of legacy functionalities: The service-base
application invokes the functionalities from identified function and service
points in the legacy application;
6) Selection of suitable Cloud Computing Platform: According to the specific
requirements of target system, the most suitable cloud computing platform
will be chosen to support the execution of the Web services;
7) Web service deployment in the service cloud: End users can consume the
legacy functionalities through the Web services that run on the cloud.
The ideal result is a new Web service application that looks, behaves and maintains
workflows just like the old legacy system but will be provided as a SaaS in the cloud.
3 Methodology Guidance
3.1 Representation and Redesign with ADM
Most of legacy systems lack original design documents because of historical reasons,
and the only valuable content is the legacy code itself. How to represent the legacy
code is a key issue in our methodology. According to the SEI horseshoe model
shown in Figure 2, the ADM (OMG , Architecture Driven Modernization)
reconstruction follows a bottom-up design view and starts from source text to code
structure, to function-level, and then to architecture representation.

Fig. 2. SEI Horseshoe Model [8].
The legacy applications are usually written with old programming languages like
FORTRAN, LISP, and C. These languages are not object-oriented and hard to
maintain and re-structure from code level directly. Also we consider how to extract
some valuable information, such as business entities and metadata, from legacy
system. Figure 3 shows the steps involved in the refactoring.
61

Fig. 3. Refactoring with ADM.
The ADM approach has the following steps: obtain the overview model, select
strategy, define target architecture, derive an AST (abstract syntax three) [9] of the
source code, create models and profiles (e.g. SoaML, SysML, UML).
For the purpose of running a service in the cloud, we have chosen SoaML as a
central modeling language for exemplification. SoaMLs target is to help architects
and developers to better describe the services at the heart of SOA. The SoaML
supports the range of modeling requirements for service-oriented architectures,
including systems of services, individual service interfaces, and service
implementations. This is done in such a way as to support the automatic generation of
derived artifacts following an MDA based approach. With SoaML, we can connect
business and technology easily. Beside SoaML, other UML architectural models like
SysML are also considered in our methodology, according to specific requirements.
After the representation of legacy system with architecture diagrams, it is
necessary to redesign the architecture and rearrange legacy code to meet a service
oriented approach. One primary redesign principle is to make the target architecture
more service oriented or component-based, which would bring features like high
cohesion and low coupling to the target architecture and make it more structural.
Different software design patterns, like the GRASP (General Responsibility
Assignment Patterns) can be considered in this step.
3.2 Model Transformation and Web Service Generation
In these two steps, we would like to use the redesigned model to create a Web service.
The redesigned models like SoaML will be transformed to Web services through
MOFScript [10] or transformation tools like ModelPro [11].
ModelPro is an open source MDA provisioning engine form ModelDriven.org
community. It is able to read models, and "provision" source code, documents web
pages automatically. The current Version of ModelPro is integrated with MagicDraw
UML with the Cameo SOA+ Plug-in. SoaML is the first plug-in provisioning
cartridge for ModelPro which automates the design and development of Service
Oriented Architectures, initially on Java Platforms. With SoaML and ModelPro,
enterprise class service oriented architectures can be up and running quickly and
62
efficiently, ready to integrate new and existing capabilities into coherent solutions
based on the enterprise requirements, services and processes.
3.3 Invoke Legacy Functionalities from Web service
A conceptual architecture of how legacy applications is provided as Web service is
depicted in Figure 4.

Fig. 4. Legacy Applications to Web service [12].
We can see three main components of Web services in this architecture: service
provider, service request, and service broker. When service user requests a service,
the WSDL description will be sent to find out the service. Once the service is found,
the WSDL description will generate SOAP request message and send to service
provider. The service to be deployed on the Web server exposes a number of methods
callable from the SOAP client. The service residing on the Web server acts as a client
to a legacy application that resides on a different server. The legacy client code that
resides on the Web service has a wrapper layer over it. This will facilitate a clean
separation from the legacy calls. A Web service adapter (wrapper) is built over the
legacy application to expose it as Web service. The legacy client code can be isolated
with this kind of design. The wrapper invokes the methods from the legacy
application through SOAP.
3.4 Migration to Cloud
In this step we consider to choose a most suitable cloud computing platform to run the
generated Web services. The legacy system will run on the cloud at the Platform as a
Service level. The most popular PaaS level Cloud Computing Platforms today
include: Sun Open Cloud Platform [13], Microsoft Azure [14], Amazon EC2 [15],
and Google App Engine [16]. The EU project RESERVOIR [17] is also a good choice
for providing service on cloud.
63
To run an application on the cloud is more or less like renting a virtual server and
managing code in other organization's platform. We can take other advantages of
cloud technologies to make our application more scalable and effective to use. The
generic processes of configuring and running a Web service on different clouds are
quite similar. Take Sun Open Cloud Platform as an example, the implementation
steps include [13]:
1) Choose the running environments from a pre-defined virtual machine images,
like load balancer, web server, database server appliances;
2) Configure the running environments to make a custom image, like
configuring the load balancer, uploading static content to storage cloud,
loading web content from Web Server, deploying database server to generate
dynamic content;
3) Program with the redesigned architecture to satisfy specific application
requirements;
4) Choose a pattern that takes the images for each layer and deploys them. Also
we handle networking, security, and scalability issues.
With this kind of migration steps, it is possible to move the legacy systems to cloud.
Moving the Web service to cloud platform doesn't take much modification of legacy
code generally.
Different popular cloud platforms are compared in [18]. We could see that it is
easier to move a legacy system to Amazon EC2 than to Google App Engine (GAE).
Amazon EC2 nearly supports most of the environment, applications, programming
languages, runtimes, database servers etc. It offers much more freedom to developers.
While with GAE, developers have to use either Python or a JVM-language (like Java),
and also have to use the database system provided by Google itself, and communicate
with Google database query language. Some tools like Cloud Foundry are used to
help us migrating legacy system to Cloud more easily and effectively.
4 Case Study
We applied the methodology we presented in section 2 to the OSCAR system in oil
spill risk analysis area. OSCAR (Oil Spill Contingency and Response) is specifically
designed to support oil spill contingency and response decision-making. We migrated
and rebuilt this legacy application from Client/Server to Browser/Server architecture,
and provided this legacy application as a Web service.
Figure 5 shows a screenshot of the OSCAR legacy application with its detail
processes description. The "Oil spill processes" contains four main surface processes:
oil drift, oil weathering, biological effects, and response options. The OSCAR legacy
application simulates how these processes work and how they affect each other.
64

Fig. 5. OSCAR Screenshot.
In step 1, we analyzed the OSCAR legacy code structure, and represented the
OSCAR system with a three-layer architecture diagram. The most important business
logic is all in the logic layer FATES calculation. FATES engine gives the calculation
and simulation supports to the processes like oil drift or oil weathering. The
output of step 1 is the architectural representation of OSCAR application, which we
can see from the Figure 6.

Fig. 6. Overview of OSCAR System Architecture.
Then we redesigned the architecture model in step 2. The target architecture should
be service-oriented. The ideal model can separate different modules and provide
different modules as a service to each other. We modeled the OSCAR system with
SoaML diagrams like Service Architecture and Participant Architecture (See Figure
7). A Services Architecture is a network of participant roles providing and consuming
services to fulfill a purpose. The output of step 2 is the redesigned architecture model.
65

Fig. 7. OSCAR Service Architecture.
In step 3, we generated WSDL with the MDA transformation technology
MOFScript according to the redesigned SoaML models. And in coming step 4 we
used these WSDL to generate target Web service. The outputs of these two steps are
the WSDL, which are addressed in Figure 8.

Fig. 8. Model Generated WSDL.
The service-based OSCAR application invokes the functionalities from legacy
system modules like oil drift and oil weathering in step 5, which gives the OSCAR
Web service application the abilities to provide the functionalities of the legacy
application.
We are currently experimenting with different cloud platforms for the execution of
this, with an initial trial using Amazon EC2. We intend to compare with other
platforms in the future, and also evaluate how the MDA approach can support the
adaptation that might be required for different cloud platforms.
66
5 Conclusion
This paper discussed a generic methodology for migrating legacy systems to the
service cloud. It included the following steps: representation of the legacy application,
redesign the architecture model with identified services, MDA transformation, Web
service generation, invocation of legacy functionalities, selection of a suitable cloud
computing platform, and provision of cloud Web service to the end users. We used
the OSCAR legacy system as an example to explain how to apply this methodology.
Challenges we see in this approach is how to best provide automated tool support for
the migration methodology for the different types of legacy systems and programming
languages, and for the identification of service-oriented refactoring and migration
points. There are also separate challenges associated with the market mechanisms
and discovery of SaaS offerings, as well as for the selection and use of appropriate
cloud platforms.
References
1. David Woollard, Chris Mattmann, Nenad Medvidovic: Injecting software architectural
constraints into legacy scientific applications, pp. 65--71, SECSE (2009)
2. Rajkumar Buyya, Chee Shin Yeo, Srikumar Venugopal, James Broberg, Ivona
Brandic. :Cloud Computing and Emerging IT platforms: Vision, Hype, and Reality for
Delivering Computing as the 5th Utility, Vol. 25, pp. 599--616, Elsevier Science (2009)
3. Yu Ping, Jianguo Lu, Terence C. Lau, Kostas Kontogiannis, Tack Tong, Bo Yi: Migration
of legacy web applications to enterprise Java environments net. data to JSP
transformation, pp. 223--237, IBM Press (2003)
4. Object Management Group (OMG). Service oriented architecture Modeling Language
(SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS) (2008)
5. M. B. Kuznetso, UML model transformation and its application to MDA technology, Vol
33, pp. 44--53, Programming and Computing Software (2007)
6. Edward Huang, Randeep Ramamurthy, Leon F. McGinnis, :System and simulation
modeling using SysML, pp. 796--803, Winter Simulation Conference (2007)
7. Dan Pilone, Neil Pitman. UML 2.0 in a Nutshell, pp.15--27, O'Reilly Media, Inc, (2005)
8. Robert C. Seacord, Daniel Plakosh, Grace A. Lewis, :Modernizing Legacy Systems:
Software Technologies, Engineering Processes, and Business Practices, 1st edition, pp.58,
(2003)
9. Klaus Meffert, Ilka Philippow,: Supporting Program Comprehension for Refactoring
Operations with Annotations, Frontiers in Artificial Intelligence and Applications, Vol.
147, pp. 48--67 (2006)
10. A. Z. Javed, P. A. Strooper, G. N. Watson, :Automated Generation of Test Cases Using
Model-Driven Architecture, International Conference on Software Engineering (2007)
11. ModelDriven.org. SoaML/ModelPro Tutorials. SoaML Cartridge.
http://portal.modeldriven.org/content/soamlmodelpro-tutorials (2009)
12. Dietmar Kuebler, Wolfgang Eibach, :Adapting legacy applications as Web services, IBM,
(2002)
13. Sun Open Cloud Computing Document, Introduction to Cloud Computing architecture,
Sun Microsystems, Inc.(2009)
14. Azure Service Platform, Micrsoft Corportation,
http://www.microsoft.com/azure/services.mspx
67
15. Rafael Moreno-Vozmediano, Ruben S. Montero, Ignacio M. Llorente, :Elastic
management of cluster-based services in the cloud, pp.19--24, International Conference on
Autonomic Computing (2009)
16. Eugene Ciurana, Developing with Google App Engine, 1 edition, Apress (2009)
17. The RESERVOIR Seed Team, RESERVOIR - An ICT Infrastructure for Reliable and
Effective Delivery of Services as Utilities, IBM Technical Library H-0262 (2008)
18. Radu Prodan, Simon Ostermann, :A Survey and Taxonomy of Infrastructure as a Service
and Web Hosting Cloud Providers, The 10th IEEE/ACM International Conference on Grid
Computing (2009)
68
SINTEF creates value through knowledge generation,
research and innovation, and develops solutions and
technology that are adopted by industry and society.
SINTEF is a broad-based, multidisciplinary research
group with international top-level expertise in techno-
logy, natural science, medicine and social science. Our
aim is to become the most respected contract re search
institution in Europe
The SINTEF Group comprises the SINTEF Foundation,
plus four limited companies and SINTEF Holding. We are
a competitive research group with a significant poten -
tial to make a positive contribution to the develop ment
of society at regional, national and international level.
SINTEF is a non-commercial organisation. Income from
contract research is invested in further research,
scientific equipment and expertise.
Some key figures
At the turn of the year, SINTEF had 2145 employees.
Our colleagues come from 64 different countries, and
in 2008 they generated new knowledge to the value of
NOK 2.6 billion.
More than 90 percent of our earnings come from con-
tracts for industry and the public sector, and from pro-
ject grants from the Research Council of Norway. Our
basic grant from the Research Council accounts for
around eight percent of the total.
Our partners
SINTEF is in partnership with the Norwegian University
of Science and Technology (NTNU) in Trondheim and
also cooperates with the University of Oslo. NTNU
personnel work on SINTEF projects, while many SINTEF
staff teach at NTNU. Our collaboration involves wide -
spread common use of laboratories and equipment,
and more than 500 people are jointly employed by
NTNU and SINTEF.
International activity
In 2008, some 13 percent of our turnover derived from
international contracts. About one third of our inter -
national turnover comes from EU research program-
mes. We give these high priority, because we believe
that it is important to participate in multinational
knowledge-generation efforts, and because such pro-
jects give us access to interesting networks.
The rest of our international turnover comes from con-
tract research projects performed on behalf of over -
seas clients. Our ambition is to grow in other coun tries,
and for this reason we are investing in areas in which
we are particularly strong: oil and gas, energy and the
environment, materials technology and marine tech-
nology.
Commercial spin-offs
SINTEF also acts as an incubator for new industrial
companies. In 2008, we were involved in 15 commer -
cialisation of 13 different SINTEF technologies, through
licensing agreements and the establishment of new
companies. We are active owners of our start-up com-
panies, and we help them to continue to develop.
Selling our shareholdings in successful spin-offs reali-
ses liquid assets that we subsequently invest in the
generation of new knowledge. Nevertheless, the most
important part of our work is the development of exis-
ting industrial companies. Every year, SINTEF supports
the on going development of some 2000 Norwegian and
for eign companies via its research and development
activities.
The SINTEF Group is the largest independent research institution in
Scandinavia. Our vision is Technology for a better society. We aim
to contribute to growth in value creation, improved quality of life
and a sustainable development through research and knowledge.
This is SINTEF