Escolar Documentos
Profissional Documentos
Cultura Documentos
Federated Clouds
By
www.cin.ufpe.br/~posgraduacao
RECIFE, FEB/2013
RECIFE, FEB/2013
Catalogao na fonte
Bibliotecria Jane Souto Maior, CRB4-571
Federal
de
MEI2013 051
Dissertao de Mestrado apresentada por Francisco Airton Pereira da Silva PsGraduao em Cincia da Computao do Centro de Informtica da Universidade Federal
de Pernambuco, sob o ttulo Monext: An Accounting Framework for Federated
Clouds orientada pelo Prof. Vinicius Cardoso Garcia e aprovada pela Banca
Examinadora formada pelos professores:
______________________________________________
Prof. Nelson Souto Rosa
Centro de Informtica / UFPE
______________________________________________
Prof. Francisco Vilar Brasileiro
Departamento de Sistemas e Computao / UFCG
_______________________________________________
Prof. Vinicius Cardoso Garcia
Centro de Informtica / UFPE
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.
Acknowledgements
Firstly to God for every blessing, protection, love and strength throughout my life.
To my father Antnio, that has always prayed for me in every step of my life. I would
like to thank him for his reference of love, happiness and father.
To my mother for all support, love and friendship. I am profoundly grateful for her
wisdom in understanding the distance that separates us. Mother, know that even with the
distance we will always be together.
To my sweet girlfriend Patrcia, for all love, affection, support and friendship during
all these years of partnership, in special the two last ones, as well as by welcome and
friendly words in the most adverse moments.
To my friends from the "OsCinFuturo" group for all support and friendship: Lenin
Abadie, Marco Andr, Thiago Vieira, Paulo Fernando, Dhiego Abrantes, Rodolfo Arruda,
Adriano Tito, Hlio Rodrigues and Bruno Felipe. I will never forget the sound of "pxxiiii"
and the "qr naaada!!".
To my other friends Francisco Soares, Edigley Fraga, Sabrina Souto, Josino Rodrigues,
and in special Paulo Silveira who guided me throughout my research.
Last but not least, my sincere thanks to my advisor Vinicius Garcia for all guidance,
support and teachings.
...
iv
Resumo
vi
Abstract
Cloud computing has become an established paradigm for running services on external
infrastructure that dynamically allocates virtually unlimited capacity. This paradigm
creates a new scenario for the deployment of applications and information technology
(IT) services. In this model, complete applications and machine infrastructure are offered
to users, who are charged only for the resources they consume. Thus, cloud resources are
offered through service abstractions classified into three main categories: Software as a
Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).
In IaaS, computing resources are offered as virtual machines to the end user. The aim
to offer such unlimited resources necessitates distributing these virtual machines through
multiple data centers. This distribution makes harder to fulfill a number of requirements
including security, reliability, availability, and accounting. Accounting refers to how
resources are recorded, accounted for, and charged. Even for a single cloud provider
this task is hard, and it becomes more difficult for a federation of cloud computing, or
federated cloud, in which a cloud provider dynamically outsources resources to other
providers in response to demand variation. Thus, a cluster of clouds shares heterogeneous
resources, requiring greater effort to manage and accurately account for the distributed
resources.
Some earlier research has addressed the development of platforms for federated
clouds but without considering the accounting requirement. This dissertation presents
a framework for charging IaaS with a focus on federated cloud. In order to gather
information about this topic area and to generate guidelines for building the framework,
we applied a systematic mapping study. This dissertation also presents an initial validation
of the tool through a case study, showing evidence that the requirements generated
through the mapping study were fulfilled by the framework and presenting indications of
its feasibility in a real cloud service scenario.
Keywords: Cloud Computing, Infrastructure as a Service, Accounting, Billing, Federated Clouds, Domain Specific Language
vii
Contents
List of Figures
ix
List of Tables
List of Acronyms
xi
1
3
4
5
5
6
Introduction
1.1 Motivation . . . . . . . . . . . .
1.2 Problem Statement . . . . . . .
1.3 Out of Scope . . . . . . . . . .
1.4 Statements of the Contributions .
1.5 Dissertation Structure . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
9
10
11
12
15
16
16
17
18
24
28
34
34
35
36
viii
2.5
2.6
2.7
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
39
40
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
47
48
49
52
54
55
56
56
57
58
58
59
62
62
64
67
69
74
.
.
.
.
.
.
.
.
.
.
75
75
75
76
76
76
78
79
81
82
83
ix
4.4
4.5
5
Conclusion
5.1 Research Contributions
5.2 Future Work . . . . . .
5.3 Academic Contribution
5.4 Concluding Remarks .
Bibliography
Appendices
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
84
84
86
86
88
90
91
.
.
.
.
92
92
93
94
94
95
105
A Deploy Instructions
106
A.1 JiTProcessingService Deploy . . . . . . . . . . . . . . . . . . . . . . . 106
A.2 JiTCollectorAgent Deploy . . . . . . . . . . . . . . . . . . . . . . . . 107
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
10
12
13
18
19
Monext Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext General View . . . . . . . . . . . . . . . . . . . . . . . . . . .
The 4+1" view model . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . .
Use Cases: Manage Information of Domain Entities and Manage Customer Information in an expanded way. . . . . . . . . . . . . . . . . .
Monext General Architecture . . . . . . . . . . . . . . . . . . . . . . .
Monext Package Structure . . . . . . . . . . . . . . . . . . . . . . . .
jit_collector_agent package . . . . . . . . . . . . . . . . . . . . . . . .
accounting_manager package . . . . . . . . . . . . . . . . . . . . . . .
pricing_manager package . . . . . . . . . . . . . . . . . . . . . . . . .
charging_manager package . . . . . . . . . . . . . . . . . . . . . . . .
billing_manager package . . . . . . . . . . . . . . . . . . . . . . . . .
financial_clearing_manager package . . . . . . . . . . . . . . . . . . .
user_manager package . . . . . . . . . . . . . . . . . . . . . . . . . .
(a) Accounting Process (Ruiz-Agundez et al., 2010b); (b) RESERVOIR
layered architecture (presented in Section 2.3.2); (c) Monext in Layers,
combining the Ruiz Agundezs accounting process and the RESERVOIR
layered architecture idea. . . . . . . . . . . . . . . . . . . . . . . . . .
RabbitMQ Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext and RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . .
Monext Accounting Process . . . . . . . . . . . . . . . . . . . . . . .
Monext - Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
48
50
20
23
24
36
51
53
54
55
55
56
57
57
58
59
61
64
64
65
67
xi
3.20
3.21
3.22
3.23
67
68
71
73
4.1
4.2
4.3
4.4
4.5
4.6
4.7
77
78
80
81
83
85
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xii
List of Tables
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Search String . . . . . . . . . . . . . . . . . . . . . . . . . . .
Primary Studies . . . . . . . . . . . . . . . . . . . . . . . . . .
Research Type Facet (Wieringa et al., 2005) . . . . . . . . . . .
Taxonomy of Accounting Process (Ruiz-Agundez et al., 2010b)
Pricing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . .
SLA metrics for IaaS (Alhamad et al., 2010) . . . . . . . . . . .
SLA metrics for PasS (Alhamad et al., 2010) . . . . . . . . . .
SLA metrics for SaaS (Alhamad et al., 2010) . . . . . . . . . .
SLA metrics for Storage as a service (Alhamad et al., 2010) . .
Research Type Classification . . . . . . . . . . . . . . . . . . .
Contribution Type Classification . . . . . . . . . . . . . . . . .
Accounting Models Classification . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
14
16
17
26
30
31
31
32
34
35
37
3.1
3.2
3.3
3.4
3.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
60
72
73
4.1
4.2
4.3
4.4
4.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
87
87
88
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xiii
List of Acronyms
xiv
xv
xvi
1
Introduction
When you affirm big, believe big and pray big, putting faith into action,
big things happen.
NORMAN VINCENT PEALE (1898-1993)
In 1969, Leonard Kleinrock (Kleinrock, 2005), one of the chief scientists of the
original Advanced Research Projects Agency Network (ARPANET) project which seeded
the Internet, said As of now, computer networks are still in their infancy, but as they grow
up and become sophisticated, we will probably see the spread of computer utilities which,
like present electric and telephone utilities, will service individual homes and offices
across the country." This vision of computing utilities based on a service provisioning
model anticipated the massive transformation of the entire computing industry in the
21st century whereby computing services will be readily available on demand, like other
utility services available in todays society.
Similarly, computing service users (consumers) need to pay providers only when they
access computing services. In addition, consumers no longer need to invest heavily or
encounter difficulties in building and maintaining complex IT infrastructure. In such a
model, users access services based on their requirements without regard to where the
services are hosted. This model has been referred to as utility computing, or recently as
Cloud Computing (Buyya et al., 2009a; Weiss, 2007).
The Information Technology Laboratory at the National Institute of Standards and
Technology (NIST) has posted a working definition of cloud computing: Cloud Computing is a model for enabling convenient, on-demand network access to a shared pool
of configurable computing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released" (Liu et al., 2012). It achieves
the goals of saving hardware cost and energy by reducing idle cycles in the computing
hardware, which is in turn achieved by packing computing tasks to fill up the capacity of
the underlying hardware. In this context, the NIST also defines three types of delivery
models for cloud computing: Software as a Service (SaaS), Platform as a Service (PaaS)
and Infrastructure as a Service (IaaS).
In the Software as a Service (SaaS) the consumer uses an application, but does not
control the operating system, hardware or network infrastructure on which its running.
With SaaS, clients subscribe to applications offered by providers rather than building or
buying them. Developers can also enrich their applications by integrating SaaS services
into them. Examples of SaaS solutions include Google Apps1 and Salesforce2 .
When the consumer uses a hosting environment for their applications it is called
Platform as a Service (PaaS). The consumer controls the applications that run in the
environment (and possibly has some control over the hosting environment), but does
not control the operating system, hardware or network infrastructure on which they are
running. The platform is typically an application framework which supplies users with
development and administration platforms. Examples of PaaS platforms include Google
App Engine3 and Windows Azure4 .
With Infrastructure as a Service (IaaS) the consumer uses "fundamental computing
resources" such as processing power, storage, networking components or middleware.
The consumer can control the operating system, storage, deployed applications and
possibly networking components such as firewalls and load balancers, but not the cloud
infrastructure beneath them. It represents the base of the pyramid without which the whole
architecture cannot exist. Examples of IaaS providers include Amazon5 , Rackspace6 , and
GoGrid7 .
The cloud computing paradigm is gaining a lot of popularity throughout the research
community and all these three delivery models. It is influencing the development of
Information Technology and changing the way that vendors, providers and end-users
view computation. As a matter of fact, cloud computing makes software available as a
service over the Internet and has changed the way in which hardware is designed and
purchased.
1 http://www.google.com/intl/en/enterprise/apps
2 http://www.salesforce.com
3 http://appengine.google.com/
4 http://www.windowsazure.com
5 http://aws.amazon.com
6 http://www.rackspace.com/
7 http://www.gogrid.com/
1.1. MOTIVATION
Amazon started to sell cloud computing services in 2006, giving birth to the Amazon
Web Services (AWS). AWS allowed individuals and enterprises to utilize Amazons network architecture and software expertise to quickly and easily host their own applications
and services on Amazons hardware. Quickly, many prominent information technology
(IT) companies followed suit. Some immediately differentiated themselves as high-level
niche services, while others developed similar, low-level network clouds. Simultaneously,
scientific research started to investigate the subject called cloud accounting.
Accounting is the art of recording, classifying, and summarizing in a significant
manner and in terms of money, transactions and events which are, in part at least, of
financial character, and interpreting the results thereof " (Wahla, 1941). This general
activity is important for business and commercial purposes, and in recent years, it has
been applied to cloud computing scenario. A cloud provider charges a customer a fee for
the usage of a certain service. The fee can be based on hardware, storage, or network, for
instance, and is provided as a utility service, similar to electricity (Brynjolfsson et al.,
2010). This dissertation focuses on the issues surrounding cloud accounting.
The remainder of this chapter describes the content and organization of this dissertation. Section 1.1 presents the motivations for the work, Section 1.2 states the problem,
and Section 1.3 reviews related topics not directly addressed by this work. Section 1.4
gives an overview of the contributions of this research, and finally, Section 1.5 describes
how this dissertation is organized.
1.1
Motivation
Cloud services are usually sold on demand through a pay-as-you-go model: The customer
only pays for what is used and no more (Narayan et al., 2012). However, behind this
general structure, various other factors influence the final price. The cloud accounting field
encompasses many lines of research, such as service level agreement (SLA) monitoring
(Alhamad et al., 2010), economic models (Ben-Yehuda et al., 2012; Ernemann et al.,
2002), or accounting tools (Park et al., 2012; Pandey et al., 2009).
A few recent studies have addressed accounting in federated cloud scenarios (Buyya
et al., 2010; RESERVOIR, 2012). A federated cloud allows a provider to dynamically
outsource resources to other providers in response to demand variations. This complex
mechanism increases the capacity of a group of data centers. They partner with each
other because no single cloud provider has the necessary infrastructure. They may prefer
to construct a federated cloud infrastructure mixing multiple public and private clouds to
provide better support. This requirement often arises in enterprises with global operations
and applications such as Internet service, media hosting, and Web 2.0 applications. Thus,
there is a need for building technologies and algorithms for federated clouds. Such
evolution aims at provisioning services across different cloud providers, considering in
particular, among others, the accounting requirement.
According to Celesti et al. (2010), the federated cloud area is considered a trend for
the future of the Internet. He called this change the Horizontal Federation Stage":
The near future evolution of the cloud computing can be hypothesized in
three subsequent stages: Stage 1 Monolithic", cloud services are based
on independent proprietary architectures; Stage 2 Vertical Supply Chain",
cloud providers will leverage cloud services from other providers; Stage
3 Horizontal Federation", smaller, medium, and large cloud providers will
federate themselves to gain economies of scale and an enlargement of their
capabilities.
Today, similarities can be seen between Celestis forecast and real-life commercial
solutions such as ComputeNext8 , ScaleUp9 and RightScale10 which aggregate different
providers. This development encouraged us to study this subject more in depth, and
we identified four federated cloud platforms (Kertesz et al., 2012; Celesti et al., 2010;
Distefano et al., 2011; Costa et al., 2010) which do not address the accounting requirement; that is, they do not have a proper accounting system to charge for their provisioned
resources.
1.2
Problem Statement
the framework with a real federated cloud platform developed by a consortium of Brazilian
Universities.
1.3
Out of Scope
1.4
1.5
Dissertation Structure
2
Systematic Mapping Study on Cloud
Accounting
Would you like me to give you a formula for success? Its quite simple,
really. Double your rate of failure.
THOMAS J. WATSON (1874-1956)
Cloud services change the economics of computing by enabling users to pay only
for the capacity that they actually use. In this context, cloud providers have their own
accounting models including their specific billing mechanisms. Thus, it is important to
study this heterogeneity aiming to map out the existing cloud accounting solutions to
become possible new proposals.
This Chapter presents a systematic mapping study. It conducted four research questions, evidencing 580 studies. It applied a formal investigation analysis which highlighted
23 papers. Such research focused on three inherent issues to cloud accounting: accounting
models, pricing schemes and SLA structure. The mapping results can help to understand the cloud accounting constraints by identifying points that still require additional
investigation, since important aspects regarding particular issues have not been addressed
yet.
2.1
Introduction
Cloud computing has become an established paradigm for running services on external
infrastructure, where virtually unlimited capacity can be dynamically allocated. However
this unlimited aspect may become expensive, and research projects have tried to mitigate
2.1. INTRODUCTION
RQ2: What are the existing accounting models for cloud computing?
RQ3: What are the existing pricing schemes for cloud or grid computing?
RQ4: What are the aspects taken into account to compose a SLA in cloud/grid
computing scenario?
The remainder of this chapter is structured as follows: Section 2.2 presents the
systematic mapping study process; Section 2.3 describes the main findings of the study;
Section 2.4 presents the analysis of the results, studies classification and mapping; Section
2.5 introduces some threats to validity; Section 2.6 discusses the results; Finally, Section
2.7 presents a summary of the chapter.
2.2
To help to plan new research, avoiding unnecessary duplication of effort and error;
and
To identify gaps and clusters in a set of primary studies (relevant papers/journals)
and identify topics to perform more complete systematic reviews.
The study follows the Systematic Mapping Process proposed by Kitchenham et al.
(2009) and later used by Petersen et al. (2008). The essential process depicted in Figure
2.1 is composed of five steps with specific outcomes and each phase is discussed in the
next sections (Definition of Research Questions, Conducting Search, Screening of Papers,
Keywording and Data Extraction).
2.2.1
As previously stated, the objective of this study is to understand, characterize and summarize evidences, identifying issues regarding cloud accounting field aiming to substantiate
our project decisions. Thus, four research questions were derived from the objective of
the study. The research questions, and the rationale for their inclusion, are detailed below.
RQ1: Is there any taxonomy for concepts related to accounting process in
cloud computing?
According to Ruiz-Agundez et al. (2010b) some authors refer to the terms pricing,
charging, or billing to represent the complete process of detecting the specific
usage of a service. The accounting process have to be disambiguated, employing a
precise terminology and splitting all the functions involved. The objective of this
question is to identify a formal taxonomy to underpin our proposal.
RQ2: What are the existing accounting models for cloud computing?
Accounting Models are solutions composed by an entire infrastructure which
consider both, engineering and economic aspects. It is essential to dimension
10
the provider infrastructure, make statistical analysis of the usages, among other
activities (Ernemann et al., 2002). The aim of this research question is to elucidate
the existing accounting models on cloud computing, and this way looking for
different architecture proposals.
RQ3: What are the existing pricing schemes for cloud or grid computing?
Pricing is the process of computing the exchange value of resources relative to a
common form of currency (Mihailescu and Teo, 2010a). Pricing schemes represent
the business interface between the provider and the customer. They are used to
achieve different objectives such as maximizing profit, maximizing social welfare,
or defining certain schemes of fairness. A pricing scheme presents the unit of
trade in a specified time period with a certain quality of service for a class of users
(Caracas and Altmann, 2007). The purpose of this question is to know which
pricing schemes exist since every accounting model must implement it somehow.
RQ4: What are the aspects taken into account to compose a SLA in cloud/grid
computing scenario?
Cloud providers supply clients with services and must meet their constraints.
They both need to negotiate the clients request and the providers infrastructure
capabilities agreeing to certain conditions. This agreement is known as Service
Level Agreement (SLA), and it is what the provider conforms to deliver the client
with what he needs (Lindner et al., 2011). According to Sahai et al. (2001), SLA
formalization is a challenged task mainly in terms of precision. In addition it was
observed a wide adoption of SLA in grid computing area. Therefore, this question
aims to identify what items compound a SLA in this context.
2.2.2
Conduct Search
The primary studies are identified by using search strings on scientific databases or
browsing manually through relevant conference proceedings or journal publications. The
strategy used to construct the search terms follows the same approach used in Kitchenham
et al. (2007), since it is systematized in essence and defines steps to derive the search
strings from the questions and the viewpoints of experts in the area and relevant papers.
The strategy steps are described as follows:
Derive major terms from the questions;
11
Identify, by inquiries with experts in the field and/or subject librarians, alternative
spellings and synonyms for major terms; and
Check the keywords in the relevant paper texts identified by the authors.
The complete list of search strings and their combination are presented in Table 2.1.
Table 2.1 Search String
SLA OR Service Level Agreement OR billing OR
pricing OR payment OR accounting AND cloud
computing OR grid computing OR Infrastructure as a Service OR Platform as a Service OR
Software as a Service
2.2.3
Screening of Papers
As the first conducted search includes repeated and low relevant work, filters are necessary
since only unique and relevant primary studies must be included. At this point, the studies
were considered according to Inclusion and Exclusion Criteria.
1 http://www.capes.gov.br/avaliacao/qualis
12
Kitchenham et al. (2004) advocates the use of study quality assessment to remove
the effect of low-quality studies on results. However, given the small number of primary
13
studies we did not wish to exclude papers based on their quality. This phenomenon was
also acknowledged by Staples and Niazi (2007), who found the strict guidelines to be too
restrictive in the study quality assessment.
Table 2.2: Primary Studies
Code
Primary Study
Reference
PS01
PS02
PS03
Yu et al. (2004)
PS04
Computing Environment
PS05
PS06
PS07
PS08
PS09
Jai (2011)
PS10
PS11
PS12
Distributed Systems
(2010b)
PS13
Ruiz-Agundez et al.
(2011)
PS15
PS16
(2010)
PS17
PS18
PS19
14
PS20
Ruiz-Agundez et al.
(2010b)
PS21
PS22
Wee (2011)
PS23
2.2.4
Keywording
15
Description
Validation
Techniques investigated are novel and have not yet been implemented in practice. Techniques used are for
Research
Evaluation
shown how the technique is implemented in practice (solution implementation) and what are the
Research
consequences of the implementation in terms of benefits and drawbacks (implementation evaluation). This
also includes identification of problems in industry.
A solution for a problem is proposed, the solution can be either novel or a significant extension of an
Solution
existing technique. The potential benefits and the applicability of the solution is shown by a small example
Proposal
or a good line of argumentation.
Philosophical
These papers sketch a new way of looking at existing things by structuring the field inform of a taxonomy
Papers
or conceptual framework.
These papers express the opinion of somebody whether a certain technique is good or bad, or how things
Opinion Papers
should been done. They do not rely on related work and research methodologies.
Experience
Experience papers explain what and how something has been done in practice. It has to be the personal
Papers
2.2.5
Data Extraction
A data extraction form was designed to gather the required information and address the
objectives of this study. In this step we read the primary studies carefully and extracted
two information: the (i) research categorization (Contribution Type, Accounting Model
Features and Research Type) and the (ii) required information to answer some of the
research questions.
To organize this information we used a spreadsheet to document the data extraction
process. The table contained each category of the classification scheme and the position
inside the paper which answered some of the four research questions.
The analysis of the results focused on presenting the frequencies of publications for
each category. This makes it possible to see which categories have been emphasized in
past research and thus to identify gaps and possibilities for future research.
2.3
Mapping Results
In this section, each topic presents the findings regarding to a specific research question,
highlighting the evidences gathered from the data extraction process. Hereafter, for the
sake of brevity and clarity, an individual primary study will be referenced by its code,
which is comprised of the letters PS" followed by a number indicating its order. Hence,
in the current work, primary studies range from PS01 to PS23. The primary studies and
16
2.3.1
RQ1 - Is there any taxonomy for concepts related to accounting process in cloud computing?
In our research only one primary study effectively answered this question. The study
PS20 presents a taxonomy of full accounting process and its functions from the resource
usage to the financial clearing. It is not applied only to cloud computing, but other areas
related to services on the internet. The accounting functions are presented in Table 2.4.
Table 2.4: Taxonomy of Accounting Process (Ruiz-Agundez
et al., 2010b)
Concept
Function
Pricing
Metering
Collects raw information regarding the resource usage of a certain service by a consumer and its usage.
Mediation
Is intended to do a first treatment of raw technical data by transforming these metering records into a data
format that can be used for storing and further processing.
Accounting
Has the function of filtering and treat more accurately the records passed by mediation function.
Roaming
Allows using more than one provider while maintaining a formal, customer-vendor relationship just with one.
Billing
Also called of invoicing, is the process of transforming charge records into the final bill, summarizing the
charge records of a certain time period and indicating the amount of monetary units to be paid by the customer.
Charging
Is the process of calculating the cost of a resource usage, the function that translates technical values into
monetary units by applying a pricing function to the session records.
Financial
Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,
Clearing
The process flow is expressed by Figure 2.4. First, resource usages (also called
metering records) are registered by the Metering function. Afterwards, the Mediation
function intercedes by treating the raw data and sending accounting records for the
Accounting function (it is important to highlight that accounting process means the whole
process and the accounting function refers to one step of accounting process). The
Accounting creates session records, which are an appropriate format to be used by the
functions Charging, Pricing and Roaming. The Pricing function generates a formula
defining how to price the session records. The Charging function generates monetary
information called charging records to be aggregated later by the Billing function. There,
17
the final bill is generated and sent to the Financial Clearing function (Ruiz-Agundez
et al., 2010b).
Although it was found only this taxonomy formally defined, other terms are used with
similar meanings. For example, monitoring has the same sense of metering. According
to Lindner et al. (2011) the metrics generated by the monitoring function can be used
both for accounting purposes as for performance analysis. Ruiz-Agundez et al. (2010b)
also uses the term monitoring but as a sub-function of metering to collect the usage
information as raw data.
2.3.2
RQ2 - What are the existing accounting models for cloud computing?
When performing the analysis, five primary studies were found (PS14, PS06, PS05, PS04
and PS23) that proposed some kind of accounting model, summarized following:
1) Flexible Accounting Model (PS14) - This paper proposes a flexible accounting
model suitable for any service of cloud computing. This model is based on the accounting
process of the Internet identified by RQ1 (Ruiz-Agundez et al., 2010b) and uses basically
two technologies: an accounting platform called jBilling and a protocol called IPDR
(Internet Protocol Detail Record).
jBilling is an open accounting platform responsible for payment tasks. Considering
the accounting process proposed by Ruiz-Agundez et al. (2010b) it encompasses mainly
the financial clearing function. According to this primary study, the jBilling platform
enabled the operators to apply different pricing schemes (e.g. usage-based, volume-based,
18
2) A Model for Federated Clouds (PS06) - This primary study presents a solution
for an accounting and billing architecture for use in federated cloud environments and built
by an European Cloud project called RESERVOIR (funded by the European Union). The
idea of federated cloud is that a single entity serves as a gateway to different independent
solutions, and this is one way to solve the limited interoperability, as different technologies
can be unified and abstracted towards the consumers.
The model is organized in layers (Accounting, Billing and Business Layer). The
Accounting Layer, focused on collecting and managing the data which components
in the Billing Layer use as their input. The Business Layer forms a link between the
19
technical system and the Service Provider in terms of, e.g., pricing, invoicing, and service
management. An overview of the different layers and their components can be seen in
Figure 2.6.
Figure 2.6 Architecture in Layers for Accounting and Billing within the RESERVOIR Service
Manager. (Elmroth et al., 2009)
The Figure 2.6 shows the main components of the suggested architecture. It includes
the connectors indicating the main interactions between components. Components with a
dashed border in the figure handle the communication with other parts of the RESERVOIR
system. As this dissertation focuses on the accounting and billing aspects, only these
parts are following explained in more detail.
The accounting layer is responsible for the interaction with the surrounding infrastructure. It collects usage records and SLA violations from other components. The primary
component is the SM Accounting Manager (SMAM) that together with the underlying
Accounting Database (ADB) offers persistent storage and management of usage records
and violations. The SMAM is supplied with data regarding SLA violations from the SLA
Violation Assessment component, and these SLA violations are taken into account by
components at the Billing layer. Similarly, the VEEM Accounting Manager (VAM) is
responsible for collecting usage data from the local site, mark them with an identification,
and supply this to the SMAM at regular intervals.
The billing layer is primarily made up of the post-paid engine and the pre-paid
engine, supported by the Service Configuration Analyzer (SCA) and the Service Lifecycle Manager (SLM) that are part of both the business and billing layers. SCA is
responsible for validating the deployment of services and generate unique identifiers for
these particular services. This identifier is referred to as the Accounting, Billing, and
20
Compensation(ABC) identifier, and all usage records and SLA violation concerning this
service will contain such identifier. Using this approach, it is possible to address all
services without knowing where they are running or how many they are. Finally, the
SLM monitors the consumed services while it communicates with pre-paid engine to
probably break off the provisioning when the pre-paid credits exceeds.
Another contribution of the RESERVOIR project in the accounting field is related to
a kind of guide which dictates what characteristics an accounting system must be based
in. They outlined usage scenarios with challenges that are typical for federated clouds
and derived eight principles listed following:
Location Unawareness: Account for the VMs as a service, running locally or
remotely no matter where it is running.
Flexible Data Format: It should be possible to include additional usage information metrics.
Service Elasticity: The number of VMs underlying and fulfilling a service can
scale due to service elasticity. The accounting system must be designed to handle
such scenario.
Service Accounting: The accounting system must be suitable for long running
services, and not limited to tasks with a limited execution time.
Compensations: Both usage and compensations (due to breaking SLAs) must be
accounted for.
Service Billing: Billing must be managed on a per service basis and not just for
each VM.
Adaptable Design: The accounting system must be open for modifications to cope
with future changes and enhancements.
Complex Pricing: The function that calculates prices from the accounting information must be able to incorporate complex pricing rules.
3) ABS for SOA (PS05) - This primary study presents an accounting model focused
on Software as a Service (SaaS) provisioning. Mainly the functions authentication of the
clients and billing of services are carried out.
Models proposed by different researchers earlier used different servers for billing and
security (Authentication and Authorization). This needs more running and maintenance
cost. Moreover high level of synchronization is also needed so that same entries are
21
processed on both servers simultaneously. Also two different databases have to be run on
both servers.
In this context, they have integrated both the servers functionalities in a single server
called ABS (Authentication and Billing server) which is capable of performing certain
functions:
Authentication and Authorization of user;
Communicates with the Application server for generating service instances for
particular users, and provides user the direct address of the instance.(user does not
need to contact the application server);
This instance is generated for a particular time period ordered by user. Billing is
done on the basis of this time period.
4) THEMIS (PS04) - This model proposed a mutually (provider and user) verifiable
billing system called THEMIS to cloud computing scenario. It has as main requirements
the transparency, security and low latency in billing transactions.
The system introduces the concept of a Cloud Notary Authority to supervise billing
transactions, using a level of security that is identical to that of a Public Key Infrastructure
(PKI). THEMIS generates mutually verifiable binding information that can be used to
resolve future disputes between a user and a cloud service provider.
Figure 2.7 shows the overall architecture THEMIS billing infrastructure, highlighting
the major components of the architecture (Cloud Service Provider (CSP), Users and
Cloud Notary Authority (CNA)):
Cloud Service Provider (CSP): The CSP enables users to scale their capacity
upwards or downwards in accordance with their computing requirements and to
pay only for the capacity that they actually use.
Users: They assume that users are thin clients who use services in the cloud
computing environment. To use services in such an environment, each user makes
a request to the CSP with a billing transaction.
Cloud Notary Authority (CNA): The cloud notary authority provides a mutually
verifiable integrity mechanism to combat the malicious behaviour of users or the
CSP. The cloud notary authority investigates billing transactions and generates
mutually verifiable binding information
22
5) Cloud Supply Chain (PS23) - This model proposes the Cloud Supply Chain
concept, which represents a network of interconnected businesses in the cloud computing
area. It involves end-to-end provision of services required by the end customers. The
delivered product is along the way enriched and in parallel the functions supporting
monitoring, accounting and billing are performed.
Although this primary study focus on how IaaS Providers improve their services in a
supply chain, it proposes a architecture directed to collect and aggregate multiple usage
records and Key Performance Indicators (KPI).
This model distinguishes the concepts of producers and consumers. Producers collect
monitoring data from the overall environment, in the form of usage measurements. This
is achieved typically via software probes, which provide the necessary mechanisms to
interact with the infrastructure or service, formulating for example appropriate queries
on a regular basis. This measurement data can come from numerous sources; this may
be raw data gathered from probes in the underlying infrastructure, data gathered from
probes embedded in the application, data which is the combination of the raw data into
composed KPIs, or data derived from the analysis of historical raw data and KPI data held
in a data store. Consumers on the other hand will read the monitoring data and will enact
some form of action, depending on the rules determined by the service or infrastructure
provider. The Figure 2.8 shows the whole structure of the Monitoring data flow.
23
2.3.3
RQ3 - What are the existing pricing schemes for cloud or grid
computing?
24
new IT service or repositioning an existing IT service. Weinhardt et al. (2009) argue that
a commercial success with cloud services can only be achieved by developing adequate
pricing schemes.
Osterwalder (2004) differentiates between three main categories of pricing schemes:
Fixed, Differential and Market Pricing. Fixed Pricing mechanisms produce prices that
do not differentiate in function of customer characteristics, are not volume dependant,
and are not based on real-time market conditions. Differential Pricing refers to pricing
schemes that produce prices that are either based on customer or product characteristics,
are volume dependant, or are linked to customer preferences, but not based on real-time
market conditions. Market Pricing stands for pricing schemes that produce prices based
on real-time market conditions.
Cloud computing literature discusses some of the pricing schemes (Cai et al., 2009;
Weinhardt et al., 2009; Buyya et al., 2009b; Youseff et al., 2008) discuss pay per use2
mechanism, which is widely hyped to be one of the key changes that cloud computing
brings to IT services business. With pay per use mechanism, capacity units such as
number of transactions, gigabytes of storage or memory or units per time such gigabytes
of memory per hour are associated with resources and assigned fixed price values and
customer pays according to his metered usage of resources.
The capacity unit may be also artificial as Amazon-AWS (2012), that sells instances"
of their capacity pool. Pay per use pricing is typically used with IaaS and PaaS services
and its benefit is that it allows customization to specific application needs. Ouyang et al.
(2007) note that quantification of resources and measurement of dynamic usage may be
challenging task with cloud services. Denne (2007) discusses various advanced ways to
implement pay per use pricing mechanism.
Denne (2007), Prodan and Ostermann (2009) and Buyya et al. (2009b) discuss
advance pricing. In this pricing mechanism, customers prepay for a certain amount
of capacity units that have to be consumed usually in a certain period of time and
overcharging is applied if the customer exceeds the quota of prepaid units.
Youseff et al. (2008) and Weinhardt et al. (2009) discuss subscription pricing in
cloud and Denne (2007) mentions pricing based on pre-purchase of services. With
subscription mechanism, customer subscribes (i.e., signs a contract) for using a preselected combination of service units with a fixed price for a fixed time period such as a
month. In subscription model, pricing is per unit of time and not per unit of consumption.
2 Also
pricing.
25
Subscription pricing is most used with SaaS services and it allows prediction of customers
periodic expenses but lacks the accuracy of charging users what they have used.
Therefore, a lot of work mention some type of pricing scheme and as a result of
our investigation the Table 2.5 summarizes all the pricing schemes found with their
respective concepts and in which study they were discussed. Despite this heterogeneous
nomenclature, it was collected 31 different types of pricing schemes, distributed on
10 primary studies (PS14, PS07, PS18, PS09, PS10, PS12, PS15, PS19, PS03 and
PS22). Among these, the most referenced were Time-Based, Flat-Rate, Usage-Based,
Competitor-Oriented Pricing, Supply and Demand Based and Auction Based Model.
The Supply and Demand Model can be divided into three other pricing schemes:
Real-Time Pricing (RTP), Derivative Follower Model and Hybrid Pricing Model. While
Auction Based Model can be divided into English Auction, First-Price Sealed-Bid Auction,
Vickrey, Dutch Auction and Double Auction.
Table 2.5: Pricing Schemes
Pricing Scheme
Definition
Time-based
Studies
PS21, PS14,
PS07
Paris-Metro
Used for shared resources. Resources are split by the amount of users per split.
PS14
Priority pricing
PS14
Flat-rate
pricing
PS21, PS14,
PS07
Edge pricing
Calculation is done based on the distance between the service and the user.
PS14
Responsive
PS14
PS14
Proportional
PS10, PS14
fairness pricing
Cumulus pricing
Based on flat pricing and dynamically priced by using a credit point system.
PS14
Session-oriented
PS14
pricing
Effective
bandwidth
pricing
26
One-off charge
PS14
per service
PS07, PS09,
Usage-based
Pricing based on the general use of the service for a period of time, e.g. a moth.
PS14
Content-based
PS14
QoS-based
PS19, PS14
Location-based
PS14
Service type
PS14
Volume-based
PS19, PS14
Differentiation
PS14
Progressive
Seller and buyer try to convene on a pricing plan. The seller announces a fixed
PS07
Co-design
price pair (p1, p2), where p1 < p2. Subsequently, the buyer commits a
on time-of-day
At first, the vendor agent needs to select the competitor to compete with. Then,
Oriented (CO)
the vendor simply decreases the price just below of the rivals price. This
Pricing
Cost-based
PS10
PS10
In general way the unit price will vary until it settles at a point where the
PS21, PS22,
Demand based
quantity demanded by consumers (at current price) will equal the quantity
PS15, PS16
Is a pricing model that dynamically changes its rate reacting to the classical
Pricing (RTP)
supply and demand rule, but with the difference that there is only one supplier.
PS22
Amazon Web Services (AWS) offer a simplified form of this pricing model
called Spot Instances.
27
Derivative
Its a kind of supply and demand based model simply adjusts prices by
Follower Model
PS15, PS16
level falls, then the direction of price adjustment is reversed, thus seeking a
local maximum of profitability.
Hybrid Pricing
This model allows a third entity called Price Authority dynamically adjust
Model
prices within static limits to balance the workload on the basis of the queue wait
PS15
Services are priced in an auction and carried out by a third party, called the
PS14, PS21
market maker, which collects the bids, selects the winners and computes the
payments.
English Auction
All bidders are free to increase their bids exceeding other offers. When none of
PS21
the bidders are willing to raise the price anymore, the auction ends, and the
highest bidder wins the item at the price of his bid.
First-Price
Each bidder submits one bid without knowing the others bids. The highest
Sealed-Bid
PS21
Auction
Vickrey
Each bidder submits one bid without knowing the others bids. The highest
PS21
bidder wins the item at the price of the second highest bidder.
Dutch Auction
The auctioneer starts with a high bid/price and continuously lowers the price
PS21
until one of the bidders takes the item at the current price. It is similar to a
first-price sealed-bid auction because in both cases the bid matters only if it is
the highest, and no relevant information is revealed during the auction process.
Double Auction
In the double auction model, buy orders (bids) and sell orders (asks) may be
PS21
submitted at any time during the trading period. If at any time there are open
bids and asks that match or are compatible in terms of price and requirements
(e.g., quantity of goods or shares), a trade is executed immediately.
2.3.4
In order for cloud providers supply clients with services that meet their quality constraints,
they both need to negotiate the clients requirements and the providers infrastructure
capabilities. It is known as Service Level Agreement (SLA). However, this is not an easy
task, according to Jain et al. (1988) there are difficulties to formalize a SLA, such as lack
28
of flexibility and precision. This way, to compound a SLA it is important to know which
aspects have to be taken into account.
When performing the analysis, few studies explicitly stated the formalization of SLA
in cloud/grid computing scenario. However 4 primary studies (PS01, PS02, PS08 and
PS17) are complementary. They are summarized following.
1) SLA Description Language (PS01) This primary study introduced a framework
that enables dynamic specification and verification of SLAs in the cloud. Its main
contribution to our research is a format of SLA-Description based on XML specification
which defines the main Quality of Services (QoS) along with their threshold values agreed
upon selection of cloud services. It also defines the period of service provision, the cost
of using the service, and the possible actions that should be taken if QoS provision is
frequently violated. Below, the Code 2.1 describes an example of SLA according to this
description language.
Code 2.1 Example of SLA-Description (Falasi and Serhani, 2011)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
The provider can specify three Service Levels: Gold, Platinum and Silver which are
called classes. As aforementioned each class addresses a set of Quality of Services (QoS).
In Code 2.1 can be observed the class GOLD and its QoS owes the response times 8 and
10 milliseconds thresholds. This QoS means that when such limit is exceeded a discount
of $0.1" is assigned to the customer.
29
2) SLA Metrics x Service Types (PS02) This paper presents the main criteria which
should be considered at the stage of designing the SLA in cloud computing. In this
work its proposed a framework which the SLA parameters are specified by metrics.
These metrics define how cloud service parameters can be measured and specify values
of measurable parameters. In the cloud computing architecture, there are four types of
services which providers can present to consumers. These services are: (i) Infrastructure
as a Service (IaaS), (ii) Platform as a Service (PaaS), (iii) Software as a Service (SaaS),
and (iv) Storage as a Service.
(i) SLA metrics for IaaS: Companies like Amazon AWS provide IaaS. Most of
the consumers are confused as to which important parameter should be defined in
the hardware part of the SLA. It lists the most important parameters for consumers
who are interested in using cloud as an infrastructure service (Table 2.6).
Table 2.6 SLA metrics for IaaS (Alhamad et al., 2010)
Parameter
Description
CPU capacity
Memory size
Boot time
Storage
Scale up
Scale down
Scale up time
Auto scaling
Response time
(ii) SLA metrics for PaaS: Platform as a Service is a type of cloud computing
that provides all the requirements needed to support application developers in
developing, evaluating, and delivering applications and software for end users
(Hilley, 2009). So, developers using PaaS do not need to download tools or
configure hardware to complete the developmental tasks. For SLA metrics related
to PaaS, Table 2.7 defines the main parameters that can be used as basic criteria
when developers want to negotiate with PaaS providers.
(iii) SLA metrics for SaaS: Software as a service is a common example of cloud
services if an application is hosted on a cloud platform and infrastructure to provide
30
Description
Integration
Scalability
Environments of deployment
Servers
Browsers
Firefox, IExplorer,..
Number of developers
built-in services for end users of cloud computing (Muller et al., 2009). Good
examples of SaaS are mail, calendar, and social web sites provided by Google,
Yahoo, and Microsoft. Table 2.8 presents the common metrics parameters for SaaS
as an example of metrics for this type of cloud service.
Table 2.8 SLA metrics for SaaS (Alhamad et al., 2010)
Parameter
Description
Reliability
Usability
Scalability
Availability
Customizability
(iv) SLA metrics for Storage as a Service: Online users access their data from
different geographical locations. In the past few years, online storage providers
were unable to maintain large size of data because of the lack of huge space in
storage disks, network performance, and data management systems. Now, data
storage service providers such as S3 by Amazon AWS configure large numbers of
storage hardware and they are able to manage and serve millions of users efficiently
with their method of data transference and ensuring these data are compatible with
various types of applications. The parameters for data storage service metrics are
basic requirements for negotiation with storage providers. Such parameters are
presented in Table 2.9.
31
Table 2.9 SLA metrics for Storage as a service (Alhamad et al., 2010)
Parameter
Description
Geographic Location
Scalability
Storage space
Storage billing
Security
Privacy
Backup
Recovery
System throughput
Amount of data that can be retrieved from system in specific unit of time
Transferring bandwidth
32
33
Monitoring Functions
The SLA Satisfaction Function (SSF(S)) specifies if a SLA Si is fulfilled or
it is violated
The Minimum Violating Response Time (MV RT(S)) determines the minimum response time from which a SLA S is violated.
The Outsourced Virtual Machines (OV M(S)) is the number of virtual machines that we have externalized for running the servers whose contain the
web application with the associated SLA S.
Revenue (Rvn(S)) is the economic benefit that a provider obtains with the
execution of a web application whose SLA is S. It is defined as:
Rvn(S) = Prci (CoE + Peni)
Punctual Revenue (Rvn(t;M)) is the total (t) gain (or loss) obtained by hosting a set of web applications with the corresponding set M of SLAs.
2.4
Results Analysis
By analysing the results, it can enable us to present the number of studies tabulated
in each category defined in this study. Thus, it is possible to identify what have been
emphasized in past research and determine gaps and opportunities for future research
(Petersen et al., 2008).
2.4.1
Research Type
Studies
Quantity
7 (30,4%)
6 (26%)
PS01, PS02, PS13, PS06, PS09, PS10, PS05, PS04, PS15, PS17, PS19, PS20
12 (52,1%)
PS07
1 (4,3%)
0 (0%)
0 (0%)
Validation
Research
Evaluation
Research
Solution
Proposal
Philosophical
Papers
Opinion Papers
Experience
Papers
34
First, let us analyze the distribution of the type of research performed in the studies
(Table 2.10). The concepts for the research types were presented in Table 2.3 in Section
2.2.4 (Keywording).
Opinion and Experience papers are notoriously nonexistent in this field, while a
number of Validation, Evaluation, and, primarily Solution Proposal papers were found.
There is also a need for Philosophical papers, because they lead the creation of
new ideas. However, another more important point was observed related to Evaluation
Research papers, which concerns techniques implemented in practice mainly in industry;
the small quantity of such studies compared to Solution Proposal papers indicates the low
level of experimentation in industry.
Certainly, progress has been made in this area, but the accelerated growth in the
number of cloud providers, as reported by Jeremy (2010), influences the degree of competitiveness, causing their proposals not be released into the scientific community. This
situation encourages us to perform research analyzing and comparing cloud providers
accounting models in practice.
2.4.2
Table 2.11 shows the contribution type classification scheme. Most of the studies propose
concrete Models or Frameworks, rather than addressing activities related to accounting
functions. Few Processes, and Techniques and no Methods were registered. One possible
explanation may be the observation made earlier about the lack of practical results
disclosed by industry. In this case, we can conclude that even small companies publish
what they did (models and frameworks) but hide the how they did it (processes, techniques,
and methods).
Table 2.11 Contribution Type Classification
Contribution Type
Studies
Method
0 (0%)
Process
5 (21,7%)
Quantity
Technique
PS08
1 (4,3%)
Model
PS13, PS07, PS06, PS09, PS10, PS15, PS16, PS14, PS17, PS18, PS19,
14 (60,8%)
Framework
35
2.4.3
We analyzed the relationship between the research questions and the research types, using
a bubble plot to represent the interconnected frequencies (Figure 2.9). This figure is
basically an x-y scatterplot with bubbles at the intersections of categories. The size of
a bubble represents the number of papers in the pair of categories at that intersection
(Petersen et al., 2008).
The chart shows that only one paper (PS20) fulfilled the RQ1 (accounting taxonomy),
and it was classified as a Solution Proposal. However, it is important to highlight that
PS20 evolved into the study PS14, classified as Evaluation Research. PS14 proposed a
flexible accounting model validated in a real-life scenario, which ensured the taxonomy
validity.
No question was answered by papers that addressed personal Opinions or Experience,
on the other hand one paper (PS02) made a significant contribution, answering RQ2
(accounting models) and RQ3 (pricing schemes); it was classified as a Philosophical
paper and discussed a general pricing scheme that can define pricing variations for any
computational element.
Most of the information related to RQ2 (accounting models) comes from papers
classified as Solution papers. Although four papers were classified as Solution proposals,
five studies were conducted in an academic or industrial environment (validation and
evaluation research), indicating some maturity of accounting models.
Although the majority of studies addressing RQ3 (pricing Schemes) was classified
as Solution Proposal and Validation Research, the papers did not discuss in detail how
36
the pricing schemes could be applied but, rather, presented simple, short concepts. Thus,
as our research aims to give a general mapping of pricing schemes, future research can
focus on explaining how the pricing schemes can work in practice.
Similar to RQ1 (accounting taxonomy), few studies relevant to RQ4 (SLA composition) were found. No studies were conducted in an industrial environment, perhaps
because cloud providers do not publish the specifics of their research and results, as
discussed in Section 2.4.1.
2.4.4
The accounting models collected during this research were categorized according to their
features (see Table 2.12). In the left side are stated the five accounting models and the
right side the features. If the model attends the feature, then a X is positioned.
PS14
Pricing
Metering
Mediation
Accounting
Roaming
Billing
Charging
Financial Clearing
SLA Support
Multiple Payment Models
Multiple Charging Policy Specification
Resource as a Service
Studies
Features
X X X X X X X X X
PS06
X X
PS05
PS04
PS23
X X
37
deserve attention:
In PS14, the authors disambiguated the expressions accounting process" and
accounting function." Accounting process" refers to a meta-concept that includes
all taxonomy functions, while accounting function" is related to recording and
summarizing technical data in terms of money, transactions, and events.
In PS23, the accounting and billing functions are grouped as integrated subprocesses forming a macro-process.
Finally, it is important to highlight that all primary studies cited the term billing."
We attribute this result to the influence of other fields, such as telephony, that commonly
used this term before cloud computing became a research trend.
Interactive systems increase the usability of applications by providing a convenient
access and allowing the user to spend less time learning how to use the application
and more quickly produce results. The graphical user-interface achieves this usability
(Bencomo et al., 1997). In this context, the Graphical User Interface Support was
analyzed in order to investigate whether the accounting models offered some type of
graphical user interface which could bring usability to access the accounting system. We
noted that some proposed models possess a user interface that gives access control to
managing accounting mechanisms, but not all did so; only 40% had a final graphical user
or admin interface support, which seems to be a research opportunity.
We analyzed the SLA Support feature, which was relevant to one research question,
but the relationships between research type and research questions depicted in Figure
2.9 did not indicate which accounting models provided such support. Thus, we verified
features such as SLA monitoring or whether the customer could choose their desired
service quality, and found that 80% offered such features. Therefore, SLA support has
been shown to be a relevant topic of interest in cloud accounting.
We initially planned to include the term monitoring;" however, the term SLA
support" was preferred because it is a less ambiguous concept. According to Lindner
et al. (2011), SLA and monitoring are strictly related, because the concept of metrics,
considered for the purposes of monitoring, is extremely semantically close to the concept
of key performance indicators, from a SLA point of view.
The accounting model proposed by Ruiz-Agundez et al. (2011) explored the requirement of flexibility in usage records and exchanges between heterogeneous network
components. In other research, (Henzinger et al., 2010) examine flexibility in the pricing
model for the user and cloud provider. Accordingly, the users must be presented with a
38
pricing model that offers flexibility as a requirement, such as a choice between different
execution speeds. For the cloud provider, it must present a programming model that offers
flexibility in execution, such as a choice between different scheduling policies. Finally,
Elmroth et al. (2009) claim that an accounting model must allow changing metrics, for
example, to easily record the metric database transactions per second".
Considering these aspects related to flexibility in cloud accounting models, we identified more two features which could be used to analyze the five accounting models:
Multiple Payment Model and a Multiple Charging Policy Specification. First, we
investigated whether the models were prepared to support different payment models, such
as the pre-paid, post-paid, and hybrid models. These models are in no way unique to
cloud computing but, to the contrary, are well known to consumers after being used for
years in other utility markets, most notably the mobile phone industry (Lindner et al.,
2011). Therefore, some accounting models (40%) are ready to work, for example, with
resource consumption based on previous purchased credits (pre-paid) (PS06 and PS23).
We included the flexible charging policy specification and aimed to learn whether the
proposed solutions utilized a mechanism that could enable the provider to easily specify
charging policies through, for example, a language. As presented in Table 2.12, none of
the models include this feature.
According to Ben-Yehuda et al. (2012), over the next few years, a new model of
buying and selling cloud computing resources will evolve. Instead of providers exclusively
selling server equivalent virtual machines for relatively long periods of time (as done
in todays IaaS Clouds), providers will increasingly sell individual resources (such as
CPU, memory, and I/O resources) for a few seconds at a time. Ben-Yehuda et al. (2012)
named this nascent economic model the Resource as a Service (RaaS). Thus, finally,
we analyzed the use of this economic model, and as with the flexible charging policy
specification feature, none of the models applied this model.
In summary, among the analyzed features, only the SLA Support and Billing Function were offered by more than 50% of the accounting models.
2.5
Threats to Validity
39
2.6. DISCUSSION
cover payment models (pre- and post-paid), but we had several discussions with
project members (me and the advisor) to validate the questions.
Publication Bias: We cannot guarantee that all relevant studies were selected. It is
possible that some relevant studies were not chosen during the search process. We
mitigated this threat as much as possible by following references in the relevant
studies.
Data Extraction: The studies were classified based on our judgement; however,
some studies could have been classified incorrectly. To mitigate this threat, more
than one researcher performed the classification.
Grid Computing Inclusion: Although this studys main focus is cloud computing,
we also included grid computing. We included it in two questions (RQ03 and
RQ04), aiming to increase the possibility of finding relevant results for cloud
computing. However, it is possible that some findings related to grid computing
are not well applicable in cloud scenarios, because we did conduct experiments to
assess the applicability but, instead, held several discussions with project members
to mitigate this problem.
2.6
Discussion
This systematic mapping study enabled us to analyze the cloud accounting field from
several perspectives. The chosen points of investigation yielded a variety of information
relevant to different types of cloud accounting solutions. We believe that this mapping
study generated state-of-the-art information about the main issues, because the studied
subject can be understood through the answers returned for the four research questions.
The relevant knowledge was obtained, because these questions were based on previous
research into both cloud and grid computing, increasing the reliability of the scope of
research. This section discusses these four research questions, the classification applied
in the primary studies, and what we can draw from it.
The first question was necessary, because we noticed a wide divergence in nomenclatures even in the early stages of research. Although we found only one taxonomy and one
respective accounting process, it was highly robust, based on 36 other studies. Despite
being suitable for use in cloud computing, it was designed to be applied to the Future
Internet," a generic and broad concept. We recommend that everyone who desires to use
this accounting process should consider adapting it before use it by adding or removing
40
2.6. DISCUSSION
functions; for example, the roaming function makes no sense if there is only one service
provider.
In the second question, when we searched for accounting models we hoped to find
a significant number of solutions, but identified only five. We tried to extract the main
features of these account models and ultimately found a couple of limitations which
motivated us to analyze more closely the models peculiarities in order to identify research
opportunities.
The third question considered a broad picture of the 31 types of compiled pricing
schemes. However, it is important to note that they include schemes for both cloud and
grid computing, and no distinction was made between these types because our primary
goal was to map all of the pricing schemes. Although we have condensed several schemes
with different names but the same meanings, the final result includes highly similar types;
it could give rise to doubts, although the references column may clarify these cases.
Future work could apply a series of categorizations to these pricing schemes in order to
answer the following questions:
Which pricing schemes can be used by PaaS, SaaS and IaaS?
Which pricing schemes are used in industry and how are they applied?
Which pricing schemes can be combined, and which combinations could result in
fairer charges?
Which pricing schemes can be used in the context of federated clouds?
Which pricing schemes better suit the pre-paid or post-paid models?
Finally, for the fourth question, we saw the need to study SLAs in cloud computing.
Again, we expected to find many studies, but the four papers we found presented distinct
yet complementary information that could guide new proposal. For example, assume that
a cloud provider wants to add SLA Support to its services. First, the provider needs to
define what high-level information must be included in the contract, such as a validity
period or specific penalties. The study PS17 addressed this possibility. Next, the provider
needs to choose which metrics are appropriate for its provided service type (IaaS, PaaS, or
SaaS). The study PS02 could help with that decision, addressing SLA metrics by service
types. To monitor these metrics, the provider needs to define them. The study PS01
shows how to do so with an XML-based language. Finally, the cloud provider wants to
offer its customers a system to manage their costs for SLA penalties. The study PS08 can
recommend economic models to guide the implementation of such a functionality.
41
2.6. DISCUSSION
The analysis performed on the selected studies focused on four topics: research type
classification, contribution type classification, the relationship between research type
and research questions, and finally accounting models analysis. We next discuss each
classification.
The classification of research type revealed a disparity between the number of studies
we considered more scientific, offering some sort of validation, and the less scientific
studies based, for example, on arguments and experience reports. We suggest focusing
on the 12 studies classified as Solution Proposals and investigating whether these studies
have evolved or whether advances along their lines of inquiry would be possible.
Utilization of the classification of contribution type depends on what the researchers
aims, because he can take advantage whatever contribution. When dealing the types of
contributions which yielded the fewest results (method and technique), any new proposal
is likely to be unique. Working with the types of contributions which yielded more results
(model and framework), the researcher can use these proposals as inputs to build new
ones.
The relationship between research types and research questions can also be used to
identify research opportunities. First, it must be emphasized that RQ1 (accounting taxonomy) and RQ2 (accounting models) restricted the search for papers to cloud computing,
while RQ3 (pricing schemes) and RQ4 (SLAs) also included grid computing. Certainly,
this difference influenced the questions results but also provided more satisfactory outputs.
In the future, we could expand the scope of RQ1 and RQ2 to include grid computing and
see what could be relevant for cloud computing. We can also conclude that the research
types Validation Research and Evaluation Research proved be immature for application
to RQ1 (accounting taxonomy) and RQ4 (SLAs). In RQ1, only one paper was found,
and it focused solely on introducing and not validating the taxonomy. For the same
reason, RQ4 treats a specific aspect of SLA composition, and we searched for proposals
of configurations, not merely how they could be used.
Classification of the accounting models was based on seven features: standard accounting process, federated clouds, graphical user interface, SLA support, multiple
payment model, flexible charging policy specifications, and RaaS. We found that none of
the models offered all of the investigated features, and again research gaps were evident
such as the RaaS model. Considering all these results, we could start to design our
accounting framework, because the mapping study provided all the necessary information
to be filtered for what we judged necessary. From this process was born the Monext
framework.
42
2.6. DISCUSSION
First, an accounting solution needs a process, and RQ1 introduced a robust taxonomy
for this purpose. Previously, we discussed the possibility of not using all the accounting
features when constructing an accounting solution, but we decided to use all of them in
order to build a comprehensive, generic framework.
Regarding the architecture, the framework must encompass complex environments
like federated clouds, so it must also facilitate simpler structures. Given that requirement, among the five accounting models, the studies PS06 and PS23 are related to the
RESERVOIR project and addresses federated clouds. Therefore, at first, we will base our
decisions on RESERVOIR characteristics, aiming to find ideas to design the architecture
of our tool along with as the guidelines and requirements for its construction.
The study PS06 introduces eight principles (introduced in the Section 2.3.2) which
serve as a guide for what requirements an accounting system must fulfill. The study
analyzed usage scenarios presenting typical challenges for federated clouds to derive these
principles. In our solution, we will treat these principles as requirements; however, to
construct a more complete proposal, we will add and implement all the features analyzed
in Section 2.4.4, resulting in 13 requirements:
REQ-01 Location Unawareness: Account for the VMs as a service, running
locally or remotely no matter where it is running.
REQ-02 Flexible Data Format: It should be possible to include additional usage
information metrics.
REQ-03 Service Elasticity: The number of VMs underlying and fulfilling a
service can be scaled due to service elasticity. The accounting system must be
designed to handle such a scenario.
REQ-04 Service Accounting: The accounting system must be suitable for long
running services, and not limited to tasks with a limited execution time.
REQ-05 Compensations: Both usage and compensations (due to breaking SLAs)
must be accounted for.
REQ-06 Service Billing: Billing must be managed on a per service basis and not
just for each VM.
REQ-07 Adaptable Design: The accounting system must be open for modifications to cope with future changes and enhancements.
REQ-08 Complex Pricing: The function that calculates prices from the accounting
information must be able to incorporate complex pricing rules.
43
2.7
Chapter Summary
This chapter presented the results of a systematic mapping study of accounting models for
cloud computing. This study was motivated by the lack of an accounting system in some
federated cloud platforms. Therefore, the main goal of this review was to determine what
issues have been studied so far to support the development of a new accounting framework
for this scenario. A secondary objective was to yield guidelines to aid researchers in
planning future research.
Therefore, following a set of strict steps, we searched 580 papers, selecting 23 studies
to answer four research questions. As its major contribution, this chapter provides an
overview of accounting in cloud computing and the specific findings as follows:
The terms pricing, accounting and billing are the most used terms in these studies.
Of these terms, billing is the most commonly used due to the influence of other
fields, such as telephony, that used the term widely before cloud computing became
a research trend.
In general, there are few studies on accounting models for cloud computing, and
the existing ones were conducted mainly in industry environment and report on
real-life experiments. Additionally, there is a need for new proposals related to
federated cloud infrastructure. Topics related to SLA and security, on the other
hand, have gained considerable attention in recent years.
Despite the many existing pricing scheme types, detailed, rather than brief, exploration of their application is needed.
44
For the composition of SLAs, some studies propose general items for the contract
(e.g., scope, penalties, restrictions), and others propose specific metrics. Studying
these results can aid in developing new solutions that combine proposals.
Finally, we filtered much data yielded by the mapping study and generated the generic
accounting framework Monext, which is presented in the next chapter.
45
3
Monext: An Accounting Framework for
Federated Clouds
Take risks: If you win, you will be happy; if you lose, you will be wise.
ANONYMOUS
Accounting has been applied to many areas, such as Wi-Fi connections (Detal et al.,
2009), VoIP services (Ruiz-Agundez et al., 2010a), grid services (Morariu et al., 2006),
micro-payments (Rob, 2005), packet-switched networks (Karsten et al., 2000), and more
recently cloud computing.
The systematic mapping study presented in last chapter allowed us to observe a set of
limitations among the existing accounting models. These findings in addition to eight
accounting principles generated thirteen requirements. We followed them to build a
flexible accounting framework focused on IaaS, called Monext (illustrated in Figure
3.1). In this context we consider a framework a set of processes and techniques used to
solve a problem. With Monext, private clouds or even simple IT companies may control
their computing resources under a financial aspect enabling to sell these resources to
end customers (Figure 3.2). This chapter presents such an accounting framework which
aims to manage the accounting process as a whole, from usage information recording to
payment.
46
The remainder of this chapter is structured as follows: Section 3.1 presents the Monext
architecture under five points of view (Use Case, Logical, Development, Process, and
Physical) justifying how each requirement was fulfilled; Section 3.2 shows the details
about a DSL proposal; and Section 3.3 summarizes the chapter.
3.1
Architecture Description
Software architecture deals with the design and implementation of the high-level structure
of the software. It is the result of assembling a certain number of architectural elements
in some well-chosen forms. Usually, aiming to present a software architecture it is used
some View Model through the use of architecture views. This mechanism enables to
introduce a software to different stakeholders from distinct perspectives. Aiming to
accurately describe the Monext architecture we chose the 4+1" View Model (Kruchten,
1995), since it is widely accepted by the software industry to represent application
47
architecture blueprints and explores the biggest number of architecture views, facilitating
its understanding (Systems, 2007).
Philippe Kruchten originally presented the 4+1 View Model to describe softwareintensive systems. However this approach is today an architecture style" to organize any
application architecture into five views, depicted in Figure 3.3 and listed following:
Use Case View: also called Scenarios, it describes the functionality of the system
from the perspective from the outside world.
Logical View: supports the functional requirements which the system should
provide in terms of services to its users, decomposed into a set of key abstractions.
Development View: focuses on software modules and subsystems.
Process View: captures the concurrency and synchronization aspects of the design.
Physical View: describes the mapping(s) of the software onto the hardware and
reflects its distributed aspect.
The next sub-sections present the Monext architecture based on 4+1" View Model,
but before that, the main concepts are provided in the form of a Glossary.
3.1.1
Glossary
48
Account: Represents the proper customer which can pay for the use of VMs.
Anomaly: It happens when something unexpected occurs, something different
from the specified in the SLA.
Charging Policy: A charging policy is a mechanism that establishes rules to
convert technical resource usage records into monetary information. In our context
means a rule which specifies how the customers will be charged.
Credentials: As the name suggests, means a set of mechanisms of identification
(passwords) used to access the VMs.
Key Performance Indicator: Means a special type of Service Level Indicator in
which focus on the performance requirement.
Payment Method: Payment employed by a customer, such as cash, check, money
order, or credit card with order or upon invoicing; also called payment type.
Payment Model: Represents how the customer desires to pay for its consumed
resources, classified in two types: pre-paid model in which he has to pay for the
consumption in advance buying credits; and post-paid model in which he pays only
after the consumption.
Service Level Agreement (SLA): A SLA is a negotiated agreement between two
parties, where one is the customer and the other is the service provider. The SLA
records are common understanding about services, priorities, responsibilities, and
warranties.
Service Level Indicator: Represents the possible metrics included by a SLA to be
monitored, for example, availability of 99%.
Usage Records: Means how much resource the customer have been used. A
unique usage record is a kind of snapshot with the amount of resource used that
time.
Virtual Machine Type: Represents a possible configuration of a Virtual Machine
(VM), including its potential of Memory, CPU and in our context, involving the
corresponding price.
3.1.2
As aforementioned, this view describes the system functionalities from the outside world
perspective. It contains diagrams describing what the system is supposed to do from a
black box perspective. All other views use this view to guide them. The Monext use
49
cases are presented in Figure 3.4 and its descriptions in Table 3.2. Due the limited scope
of a dissertation and our goal to focus on the core aspects of the framework we omitted
the use case flows descriptions.
Description
Requirements
Customer
REQ-11
Inform Bill
A generated Bill may be in one of three states (OPENED, EXPIRED, PAID); when
REQ-09
Paid
created, its state is OPENED, when the bills due date is exceeded it becomes EXPIRED;
Reports
finally when the cloud provider (Admin) receives some customer payment he must
inform the corresponding Bill to change its status to PAID.
Specify
Before the system starts the resources monitoring, the Admin must specify what prices
REQ-08 REQ-14
Prices
REQ-15
Configure
The framework must collect how much resource the customer have been used (usage
REQ-08
Collector
records) to next, charge him. The Admim must specify in what frequency the usage
Agent
Admin
REQ-11
Reports
50
Generate
The system automatically generates bills for all active Accounts in the last day of each
REQ-08 REQ-05
Bills
month.
REQ-06
Collect
REQ-03
Monitor
A prePaid model is applied in case of the Customer desires to pay a limited amount of
REQ-05 REQ-12
Pre-Paid
usage credits before use it. When the Customer uses a pre-paid model the system may
REQ-13
Accounts
Manage
The Customer can include, exclude and update his profile. This use case is expanded in
Customer
Figure 3.5
Usage
Records
REQ-11
Information
Manage
The Admin can include, exclude and update information about Domain Entities as for
Information
example define what are the types of VMs available. This use case is expanded in Figure
of Domain
3.5
REQ-11
Entities
Figure 3.5 Use Cases: Manage Information of Domain Entities and Manage Customer Information in an expanded way.
Description
Requirements
Customer
REQ-11 REQ-09
Reports
51
Manage
The Admim can include, exclude and update instance types (Virtual Machines
Virtual
configurations). At this moment the Admin may specify the price for each configuration,
Machine
REQ-11 REQ-09
Type
Manage
The Admim can include, exclude and update information about data centers which make
REQ-09 REQ-10
Data Centers
part of the federated cloud. Similar to Virtual Machine Type" here the Admin may
REQ-11
specify a tariff for each data center representing its computing potential.
Manage
The Admim can include, exclude and update charging policies. Such charging policies
REQ-08 REQ-11
Charging
REQ-05 REQ-12
Policies
REQ-13
Manage
The Customer can include, exclude and update its desired Service Level Indicators for its
REQ-11 REQ-12
SLA
Service Level Agreement. The used metrics are BANDWIDTH (the amount of data that
REQ-05
can be transmitted along the channel during a specified period and measured in bits per
second (bps)), JITTER (measures the variability over time of the packet latency across
the network) and DELAY (time undesired to obtain a response for a requisition)
Manage
The Customer can include, exclude and update its payment information. It involves its
Payment
Payment Method (credit card, cash etc.), and its Payment Model (pre-paid/post-paid).
REQ-11 REQ-13
Information
Manage
The Customer can include, exclude and update its personal identification.
REQ-11
Personal
Information
3.1.3
Logical View
The logical view primarily supports the functional requirements in which the system
should provide in terms of services to its users. The system is decomposed into a set of
key abstractions, taken (mostly) from the problem domain, in the form of object classes.
They exploit the principles of association, abstraction, encapsulation, and inheritance.
This decomposition is not only for the sake of functional analysis, but also serves to
identify common mechanisms and design elements across the various parts of the system
in a more detailed level (Kruchten, 1995).
Monext includes two main modules depicted in Figure 3.6. The first module is called
JiTCollectorAgent. It reads periodically the VMs consumed resources into the cloud and
1 http://aws.amazon.com/pt/ec2/pricing/
52
JiTProcessingService is responsible for the central processing component that performs tasks regarding collected data treatments and generation of bills. This collected data
is called usage record and is stored appropriately after being treated; the charging policies
are also stored, to be used by charging and billing functions later. The JiTAnomalyDetector is responsible for collecting and sending network anomalies to JiTProcessingService.
An anomaly means non-compliance with a SLA. To collect network information, the
JiTAnomalyDetector is hosted in a central server but identifies in which data center the
anomaly occurred. JiTProcessingService receives and stores the anomalies for further
bill compensations so that Monext provides SLA support.
It is important to note that the solution is independent from the complexity of an IaaS
architecture, including federated clouds platforms, since the collecting points are located
inside the virtual machines and the processing points are outside the clouds.
We also used the UML 2.0 to design this view. Figure 3.7 presents the framework
architecture under a package structure. Monext architecture was based on the Accounting Process Taxonomy (Ruiz-Agundez et al., 2011) and it was divided between two
macro modules: jit_collector_agent and jit_processing_service. The jit_collector_agent
is responsible for collecting the usage records from the Virtual Machines whereas
jit_processing_service receives these usage records and charge for them. In addition,
53
jit_processing_service separates the function accounting from others due its frequent
database access characteristic. Others two packages are deployed similar to JiTCollectorAgent: jit_anomaly_detector_agent (responsible for report anomaly occurrences) and
jit_provisioner (terminates instances in case of pre-paid payment models). The next
sub-sections detail this logical view evidencing the main respective classes.
jit_collector_agent
Figure 3.8 shows the classes of jit_collector_agent package. The accounting process
starts with collecting information. This function is performed by the class CentralMeter
and it collects information when the VM starts. CentralMeter implements the project
pattern Facade (El Maghawry and Dawood, 2010) and specific classes (CPUMeter
and MemoryMeter) treat specific resource types. In addition, the class CentralMeter
through the getUsageRecord() method provides formatted usage information and the
corresponding VM and Data Center (JiTDC). These identifiers are important because
different data centers may apply different charging policies. Finally, the usage record
will be sent by the method sendCollectedData() in Mediator class which in turn has an
instance of CentralMeter.
54
accounting_manager
The module jit_processing_service includes six sub-packages. The first package, accounting_manager is responsible for treats and persists usage records for subsequent charging
(Figure 3.9). The UsageRecord class keeps information regarding the resource usage, the
Account, VM and data center. A SummaryUsageRecord instance is created for each VM
at each month and grouping usage records is constantly updated until the month ends.
The SchedulerFinishInstances class in turn, monitors pre-paid Accounts and notifies the
external jit_provisioner package when the limit is exceeded. This function fulfill the
REQ-11 Multiple Payment Models requirement, since pre-paid and post-paid models
can be applied with Monext. Finally, the CommunicationServicePool works as a buffer to
effectively receive the usage records from the VMs.
55
pricing_manager
The pricing_manager package focuses on classes where the cloud administrator must
specify details about the infrastructure and its prices (Figure 3.10). The VM class
represents a virtual machine which is associated with a specific customer (Account). The
VM also keeps its resource consumption through the entity SummaryUsageRecord. It
informs its VMState (e.g. Running), the corresponding data center (JiTDC) with its price
(JiTDCRate) and a VMType. The VMType class keeps the possible VM configurations
(images). It includes individual resource type capacities with a collection of monetary
rates, in the same way as JiTDC.
charging_manager
The charging_manager package supports the domain between accounting and billing
(Figure 3.11). Here, the debit calculation is individually performed and all the necessary
information is kept in the ChargingRecord class, including: the period (month); which
considered VM/data center; the consumed resources (SummaryUsageRecord); and a
charging policy. The charging policy can be of FlexibleChargingPolicy type (specified
with VeloZ) or of DefaultChargingPolicyEnum type (hard coded charging policies). Using
the CurrentChargingPolicy class, the administrator specifies what policy is the current
one (flexible or default). The ChargingService class calculates the totalPrice field in the
ChargingRecord.
56
billing_manager
The billing_manager package includes only three classes (Figure 3.12). The first, Bill,
aggregates: the calculated ChargingRecords (monetary value per VM); the Account
(customer); the period of consumption (startDate and endDate); when it was generated
(generationDate); a state (BillStateEnum); and the calculated final value (totalValue)
resulted from the charging policy execution. The second class, BillingService performs
two functions: the generation of bills for all or individual Accounts; and the payment of
a specific debit. The third class, SchedulerBillsGeneration, triggers automatically the
generation of bills at the end of each month.
57
financial_clearing_manager
The financial_clearing_manager package joins simple classes related to the payment and
information detail task (Figure 3.13). When the customer is registered in the system it
must specify the PaymentInformation, considering the PaymentMethod (credit card data)
and the PaymentModel (pre-paid or post-paid). Another class, AccountingReport, is a
generic class used to format detailed financial and resource consumption information
presented to the system user.
user_manager
In the user_manager package (Figure 3.14), the Account class represents the customer
which consumes the cloud resources. It encompasses: the PaymentInformation, declared
in financial_clearing_manager package; a profile with personal information (name,
contact); the corresponding Bills, VMs, SLAs (including metrics to be monitored); a state
(e.g. Active); and a VMs access credential (Credentials class).
58
3.1.4
Development View
The Development View focuses on the actual software module organization on the
software development environment. The subsystems are organized in a hierarchy of
layers. Each layer provides a narrow and well-defined interface to the layers above it.
It minimizes dependencies between modules and allow simple release strategies layer
by layer. The Development View takes into account internal requirements related to the
ease of development, software management, reuse or commonality, and to the constraints
imposed by the programming language. The development view serves as the basis for
requirement allocation (Kruchten, 1995).
Arguably, layering is a common best-practice pattern used by software architects
to break apart complex systems. In a layered architecture, the principal elements or
components are arranged in the form of a layered cake where each layer rests on a lower
layer. Generally, a layer represents a grouping of elements that provides related services.
A higher layer might either use services only defined by the immediate lower layer (closed
architecture) or services by all the lower layers (open architecture) (Gerber et al., 2007).
RESERVOIRs architecture is organized in three layers (presented in Section 2.3.2).
The Business Layer, forms the link between the technical system and a possible service
provider (a third entity that resells the service). The Billing Layer is responsible for
payment models management (pre/post paid), and the Accounting Layer focuses on
collecting and managing the usage data.
Although the RESERVOIR layered architecture includes some accounting functions
like Billing, it does not implement other important functions formalized by Ruiz-Agundez
et al. (2010c), like Metering, evidencing the possibility of improvement in adopting a
59
Standard Accounting Process. Thus, Monext combined the RESERVOIR layered architecture idea with such accounting process due the clear separation of responsibilities. So
it was necessary to allocate each function to its appropriate layer, taking into account their
relationships. Table 3.3 presents the functions of the standard accounting process; Figure
3.15 (a) shows the accounting process flow; Figure 3.15 (b) shows the RESERVOIR
layered architecture; and Figure 3.15 (c) represents our new proposed composition.
Table 3.3 Taxonomy of Accounting Process Ruiz-Agundez et al. (2010c)
Concept
Pricing
Function
Function of giving a price to a certain resource usage.
Metering
Collects raw information regarding the resource usage of a certain service by a consumer and its usage.
Mediation
Is intended to do a first treatment of raw technical data by transforming these metering records into a data
format that can be used for storing and further processing.
Accounting
Has the function of filtering and treat more accurately the records passed by mediation function.
Roaming
Allows using more than one provider while maintaining a formal, customer-vendor relationship just with one.
Billing
Also called of invoicing, is the process of transforming charge records into the final bill, summarizing the
charge records of a certain time period and indicating the amount of monetary units to be paid by the customer.
Charging
Is the process of calculating the cost of a resource usage, the function that translates technical values into
monetary units by applying a pricing function to the session records.
Financial
Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,
Clearing
60
Figure 3.15 (a) Accounting Process (Ruiz-Agundez et al., 2010b); (b) RESERVOIR layered
architecture (presented in Section 2.3.2); (c) Monext in Layers, combining the Ruiz Agundezs
accounting process and the RESERVOIR layered architecture idea.
As can be seen in Figure 3.15 (c), we kept the Business Layer term but renamed
Billing Layer as the Processing Layer and the Accounting Layer as the Collector Layer.
It made more sense to group those functions with processing characteristics separately
from those functions with low level aspects related to collector actions. In addition,
we named the functions as Managers, emphasizing that they transformed into system
components. Lastly, we split the Business Layer based on two actors: Admin can specify
new charging policies and other system configurations; the Customer can register his
desires related to SLAs as well as access detailed reports. Therefore the Monext was
designed based on this layered architecture style and implementing the Ruiz Agundezs
accounting process, fulfilling the REQ-09 Standard Accounting Process requirement.
Such a strategy enabled us to build an uncoupling solution.
61
3.1.5
Process View
The process view, or process architecture, describes the view of the architecture that
includes running processes and instantiated objects that exist in the system. It describes
important concurrency and synchronization issues. Describes how the run-time system is
structured as a set of elements that have run-time behaviour and interactions. Run-time
structure often bears little resemblance to the code structure. Such view is useful for
thinking about run-time system quality attributes, such as performance and reliability
(Kruchten, 1995). This section complements the previous ones, since it presents the
main framework components JiTCollectorAgent and JiTProcessingService, focusing on
a run-time perspective.
JiTCollectorAgent
VM migration is an inherent characteristic of virtualization and cloud computing. Looking
into this aspect, Monext encompassed such characteristics as collecting usage information
from inside the VM through an agent.
This agent enables the proper machine to inform its consumption. Using percentage
as a unit of measure the agent capture the usage information called usage records. So, it
is stored and processed by the JiTProcessingService, outside the infrastructure or even the
cloud. We called this approach a Remote Collecting Strategy. Since it does not require
complex deployment, this strategy enables charging from both, virtual and physical
machines even in small companies.
Such an option was adopted because it was previously used by Narayan et al. (2012) in
a similar way and attends to the VMs migration, running locally or remotely. Thus, a VM
could migrate even between data centers, making the Remote Collecting Strategy more
appropriate. Using this approach, the REQ-01 Location Unawareness requirement was
attended which says that Accounting must be for the VMs as a service, running locally
or remotely no matter where it is running".
The JiTCollectorAgent was built using Java 6 and the Hyperic SIGAR API 2 to collect
the usage information. The Hyperics System Information Gatherer (SIGAR) provides
a couple of possible metrics like system memory, swap, CPU, load average, uptime,
and network information. However, we focused on collecting only two traditional and
main hardware metrics (memory and CPU) for this Master research, but it is included
as a future work to include other metrics. Next, we provide this information as total
2 http://www.hyperic.com/products/sigar/
62
3 http://www.amqp.org/
4 http://www.rabbitmq.com
63
The use of RabbitMQ allowed the JiTCollectorAgent to send messages from the VM
to specific consumers implemented by a CommunicationService class. To mitigate the
overload of receiving messages on the server side, there is a CommunicationService
running as a Java Thread for each Account, representing a customer in the system that
only receives messages from VMs it owns. It is important to mention that this strategy is
used to receive both, usage records and network anomalies (for SLA compensations), as
depicted in Figure 3.17.
JiTProcessingService
As previously mentioned, the JiTProcessingService module treats all the accounting
process functions related to formatting and filtering the collected raw data and generate
bills. To keep the architecture consistent, this module was designed following such a
process. Figure 3.18 shows the main entities and their acronyms. It illustrates generally
how we implemented the core functionalities. Monext is a system wherein service
providers can sell computational resources to final customers, which in turn creates a
register with a specific access policy called an Account.
The first task performed by the administrator before turning on" the accounting
system is to specify the possible Virtual Machine Types (VMT) with their capacity and
corresponding monetary rates. This is similar to the Amazon AWS EC25 , which offers
5 http://aws.amazon.com
64
different instance configurations. After this pricing configuration, one Account can create
as many VMs as necessary, composing an elastic service.
This idea addresses the REQ-03 Service Elasticity requirement which says that The
number of VMs underlying and fulfilling a service can scale due to service elasticity.
The accounting system must be designed to handle such scenario", because with Monext
the number of VMs underlying a service can change dynamically, and the accounting
system does not care about where the VM is running. Only if the VM is active, its
JiTCollectorAgent can send usage records. As the system performs constant collecting,
the accounting task is also constant and not time frame dependent enabling long running
services. It fulfills the REQ-04 Service Accounting requirement which advocates that
The accounting system must be suitable for long running services, and not limited to tasks
with a limited execution time".
These usage records (UR) are accounted from anywhere (i.e., any data center). However, as mentioned in Section 3.1.5, there is a Java Thread acting as a subscriber that
receives only the UR owned by its specific Account. This way, when an UR is received,
it is immediately added to an entity called Summary Usage Record (SUR). A SUR is
created for each VM at each month and is constantly updated until the month ends. SUR
allows the use of not only PostPaid but also a PrePaid payment model, since SUR always
keeps the current amount of consumed resources.
When the current month ends, and the functions pricing, metering, mediator, and
65
accounting have been executed, then it is time to calculate the customers debits and
generate the bills automatically. Accordingly, in the charging phase, a Charging Record
(CR) is created. The CR represents the calculated monetary data about one specific VMs
consumption for the current month, considering four items as input.
The first item is the SUR, which provides how much data or load were consumed.
The second, the Current Charging Policy (CCP), previously written in VeloZ, represents
the current policy. The third, VMT, contains the price of that VM configuration. Finally, some compensation is included in case of SLA violations, fulfilling the REQ-05
Compensations and requirement which says: Both usage and compensations (due to
breaking SLAs) must be accounted for". The SLAs are previously specified to each
customer when they are registered, fulfilling the REQ-10 SLA Support requirement
which says: Must be offered for the customer a mechanism to specify a Quality of
Service (QoS)".
With the obtained CR, the next step is to effectively generate the bills in the billing
phase. The REQ-06 Service Billing requirement notes that billing must be managed
on a per service basis and not just for each VM. So one bill encompasses all consumed
services in the month; all CR has to be added to the Bill. A bill has three states (opened,
expired, and paid), and any issue related to payment is resolved in the financial clearing
phase. Roaming is next to billing, meaning that the customer can consume resources
from multiple providers, but it is billed transparently through one provider.
In terms of technology used to implement this module, three aspects were observed.
The first one was robustness. We developed a solution to deal with financial information. It was important to be fault tolerant and provide an advanced suite test tool. The
second aspect was also appointed by the Mapping Study as one limitation in the existing
accounting systems related to the REQ-11 Graphical User Interface requirement. The
third one was related to the REQ-07 Adaptable Design requirement which says: an
accounting system must be open for modifications to cope with future changes and enhancements". The Grails6 framework was chosen to mitigate these respectively problems
as Grails provides such functionalities through an advanced suite test tool, a web-based
interface and a Model-View-Controller (MVC) organization. The MVC architecture style
separates software into models representing core functionality, views which display the
models to the user, and controllers which let the user change the models (Mahemoff and
Johnston, 1999). Figures 3.19 and 3.20 present two web page screenshots.
6 http://grails.org/
66
3.1.6
Physical View
The physical view is concerned with the topology of software components of the physical
layer, as well as the physical connections between these components. This view is also
known as the deployment view. It encompasses the nodes that form the systems hardware
topology on which the system executes; it focuses on distribution, communication and
67
The Appendix A present how to deploy the JiTProcessingService and JiTCollectorAgent respectively, and all artifacts can be downloaded through the URL: http:
//cin.ufpe.br/~faps/monext/.
Next section introduces the details about the DSL VeloZ and what functionalities it
offers illustrated with examples.
68
3.2. VELOZ
3.2
VeloZ
The principle R8 - Complex Pricing of RESERVOIR project says that the function that
calculate prices from the accounting information must be able to incorporate complex
pricing rules". However, for the best of our knowledge there is not a cloud accounting
solution which offers a programming language to leverage this functionality. For this
reason we stated the requirement REQ-12 Multiple Charging Policy Specification and
proposed the VeloZ (Monext-Charging Policy Language), a programming language for
charging policies specifications.
Charging policies are mechanisms that establish rules to convert technical resource
usage records into monetary information. It is a formula or algorithm used every time
when generating a bill. VeloZ allows IaaS providers to specify its own charging policies
and control its consumption in a financial aspect. However, whether the company does
not want to configure it, the Monext framework provides two default hard coded charging
policies:
VOLUME_TIME: The price is calculated using the amount of data in terms of
average resource usage and time consumption;
VOLUME_TIME_LOCATION: The price is calculated using the amount of data
in terms of average resource usage, time consumption, and virtual machine location.
The administrator by default may choose these two charging policies. However,
these two possibilities are not enough when the provider requires more adaptability or
ad hoc" policies. Therefore, in order to offer more flexibility for a cloud provider, the
Monext framework introduces the VeloZ, which is a Domain Specific Language (DSL)
that enables cloud administrators to write charging policies.
According to Backus (1978), DSLs are programming languages or executable specification languages that offer through appropriate notations and abstractions expressive
power focused on, and usually restricted to, a particular problem domain. VeloZ is an
executable language that provides default and pre-calculated variables, proper to the
IaaS accounting domain. VeloZ is based on the expression paradigm. An expression
in a programming language is a combination of explicit values, constants, variables,
operators, and functions. These elements are interpreted according to the particular rules
of precedence and in association with a particular programming language that computes
and then produces another value.
Such a process, as mathematical expressions, is called evaluation. The value can be
of several types, such as numerical, string, and logical. For example, 2+3 is an arithmetic
69
3.2. VELOZ
70
3.2. VELOZ
1. dec {ListId} in: Firstly, dec" and in" are reserved words that limit the declaration
scope of pre calculated variables. The administrator specifies a list of identifications
(ListId) chosen between default variables calculated by the system and previously
defined separated by comma, e.g., dec {cpu_rate, mem_rate} in. Only variables
correctly written will be accepted by the compiler, and values cannot be assigned
to these variables. A list of some default variables is shown in Table 3.4.
The default variables declared inside the dec" block are divided into three types.
The first one is called the Average Type, and these variables indicate the total
average related to a specific resource for a period of time (e.g., a month). The
second group is named Volume Type and reflects the amount of data in terms of
consumed resources, indicating the total sum of usage data logged. Finally, the
Monetary Type, in this case, each Virtual Machine Type has a configuration to
which is assigned a monetary rate related to the potential for each resource type.
2. calc {VariableDeclaration} in: It is responsible for the computing procedures, using the variables defined in the dec" block and new temporary variables. It enables
expression assignments separated by comma, e.g., calc {myVar = location_rate +
mem_rate} in.
3. total {Expression}: Whereas the previous blocks had temporary declarations and
calculations, the total" block receives the variables used to compound the final rule
of charging. For example, if the administrator desires only to charge for memory
consumption, it can be specified as follows: total {mem_sum * mem_rate}.
According to the economic model Resource as a Service (Ben-Yehuda et al., 2012)
renting a fixed combination of cloud resources cannot and does not reflect the interests of
clients. First, as the sizes of servers are likely to continue increasing hundreds of cores
71
3.2. VELOZ
Description
cpu_avg
mem_avg
cpu_sum
mem_sum
used_time
cpu_rate
mem_rate
location_rate
time_rate
compensation
and hundreds of gigabytes of memory per server in a few years an entire server equivalent
may be too large for some customer needs. Second, selling a fixed combination of
resources is only efficient when the load customers need is known in advance and remains
strictly constant. As neither condition is likely, the ability to dynamically mix-and-match
different amounts of compute, memory, and I/O resources would probably be highly
valued by clients. By extrapolation, compute, memory, and I/O resources will be rented
and charged for in dynamically changing amounts and not in fixed bundles. The resources
available for rent include CPU, memory, and I/O resources. CPU capacity is sold on a
hardware-thread basis, or even as the number of cycles per unit of time; Memory is sold
on the basis of memory frames; and I/O is sold on the basis of bandwidth.
Using VeloZ, the cloud provider may choose to charge for one or a combination of
resource types. It is possible to specify a different price for each resource type trying
to fulfill the REQ-13 Resource as a Service requirement, because if a customer asks
for more Memory, VeloZ enable the provider to charge for this increased capacity in
an individual way. However, instead of heterogeneous measure types (cycles, memory
frames or bandwidth) JiTCollectorAgent captures and VeloZ uses the relative percentage
of total consumed resources. With such functionality, our solution follows the economic
model Resource as a Service. It provides a different price for each resource type, and
to the best of our knowledge has not been implemented by accounting models thus far.
Table 3.5 presents some valid examples of charging policies.
72
3.2. VELOZ
Charging Policy
dec { cpu_avg, used_time, cpu_rate} in
calc {fixed_time = 1, fixed_cpu_avg = 100} in
total { cpu_rate/((fixed_time/used_time)*(fixed_cpu_avg/cpu_avg)) }
cpu_rate
(pre-defined in $)
One second using
100% of Memory
capacity costs
mem_rate
(pre-defined in $)
One hour (3600
seconds) of use
costs time_rate
(pre-defined in $)
The first policy considers only CPU, the second only memory, and the third only Time
consumption. In each charging policy the resource has its pre-defined individual price
(cpu_rate, mem_rate, time_rate) and not charged with fixed bundles as, for example, the
Amazon AWS EC27 does by default. However, it is possible, since the third policy in
Table 3.5 considers only the total time of consumption using as basis one hour. So, the
cloud administrator just has to set a price (time_rate variable) for each VM Type as same
as Amazon AWS EC2 uses different instance types (Small, Medium, Large, Extra Large
etc.) (Figure 3.23).
Figure 3.23 Amazon AWS - On Demand Instance Types Pricing (Amazon-AWS, 2012)
7 http://aws.amazon.com/pt/ec2/pricing/
73
3.3
Chapter Conclusion
74
4
A Preliminary Case Study
4.1
Definition
The first activity is called Definition. The foundations of the case study are determined,
presenting why the case study will be conducted. Furthermore, the objective and goals of
the case study must be defined.
4.1.1
Goal
A goal is suggested by the problem to be solved. The goal of this evaluation is summarized
following:
75
4.2. PLANNING
4.1.2
Questions
Flexibility:
Q1. Can the Monext framework charge for different resource types at the
same time?
Efficiency:
Q2. Can the Monext framework handle the scalability of VMs?
Q3. Can the Monext framework charge for long-running services?
Reliability:
Q4. Can the Monext framework calculate bills considering all the customer
usage?
Q5. Can the Monext framework handle anomalies in calculating bills and
considering compensation?
4.2
Planning
After the definition of the case study, the planning phase should prepare how the case
study will be conducted.
4.2.1
As aforementioned we have chosen as a case study the JiTCloud platform. The JiTCloud
is a result from the research of a group which involved eighteen Brazilian universities,
sponsored by the Centro de Pesquisa e Desenvolvimento em Tecnologias Digitais para
Informao e Comunicao (CTIC)1 . It is a federated cloud platform which proposal
addresses an alternative to build computational infrastructure to support cloud computing
which is not based on traditional capacity planning. Inspired by the Toyotas Just in Time
1 http://www.ctic.rnp.br/web/ctic/
76
4.2. PLANNING
Philosophy (JiT) (Toyota, 2012), it introduces the concept of Just in Time Clouds for
representing a new service category in which the provider (here named JiTProvider")
allocates resources only when demanded and until there is use for them. Built upon
amortized resources from a supply chain.
Amortized resource refers to the resource installed and not used to support for example
the operation of peak demand. A JiTProvider is a public cloud computing provider that
instead of assembling and maintaining a structure of data centers for supporting its own
service makes use of a federation of low scale amortized resources already existing
into private contexts. Unlike proxies of conventional providers of cloud computing (e.g.
rightscale.com), a JiTProvider does not represent any public cloud provider, but acts as a
legitimate and fully autonomous provider that takes advantage of resources that would be
irretrievably wasted without its intervention.
Each resource pool amortized over a given environment represents an abstraction
called Just in Time Data Center (JiT DC). Each JiT DC brings some amount of resources
with certain characteristics and capabilities. The JiT DC resources must be raised and
finely graded by the JiT Provider. Depending on the type, it can be specialized as a JiT VM
to represent a specific VM within a specific JiT DC. Among the general characteristics of
a JiT DC, there is the level of service supported by its resources and conditions negotiated
or arbitrated by the owner for its use. A Just in Time Cloud is illustrated in Figure 4.1).
The JiT Resources that are integrating in JiT Data Centers can be classified into
dedicated and non-dedicated types. Dedicated is when they are fully allocated for use by
the JiT Provider for a certain period of time. Non-dedicated is when their assignment is
partial, being shared in an opportunistic fashion. It has the possibility of being reclaimed
by their corresponding owners without any prior warning. In the first case, there are
reservation and levels of availability traded. In the second case, the resources are volatile
and can suffer from failures or relocation at any time. In both cases, the provider needs to
77
4.2. PLANNING
deal with migration issues and take into account the necessary time to commission and
decommission the resources.
In a deployment view, depicted in Figure 4.2, the JiTCloud solution is divided into
three modules, or artifacts: CloudClient, CloudMiddleware, and JiTDC. All the three
components were developed using Java, and deploying them requires uncompressing
the jar files and configuring some properties related to credentials. The CloudClient
gives the customer access to the cloud access. Through it, the customer can start and
terminate VM instances and monitor details of his usage through a set of commands. The
CloudMiddleware performs all the control, processing, and load balancing which directs
the requisitions to the JiTDCs. The JiTDC component is deployed in a data center which
must have installed an Eucalyptus2 Instance, a software platform for public and private
IaaS clouds. Finally, the JiTCloud project aims to use its solution to integrate data centers
of Brazilian universities.
78
4.2. PLANNING
necessary, because the sub-modules are not web applications but merely components.
The client access (View) is provided by the proper JiTCloud.
The CloudMiddeware uses the design pattern Dependency Injection, which allows
removing hard-coded dependencies and changing them at either run-time or compile-time.
Therefore, after we generated a .jar file, we deployed it inside the CloudMiddleware.
Another necessary task was to create a separate database for the component Monext due its
peculiarities of the wide range of saved objects (e.g., usage records). This task motivated
us to externalize some variables into a properties file in order to easily change databases
and specify other configurations. The properties are loaded when the CloudMiddleware
starts. Figure 4.1 shows such properties.
Table 4.1 Monext Configuration Properties
Properties
Description
amqp.host
amqp.port
amqp.ssl_port amqp.username
amqp.password
amqp.exchange.name
amqp.anomaly.exchange.name
These properties refer to the access credentials to the RabbitMQ broker (host,
port, username, passoword). The amqp.exchange.name refers to a specific name
for the exchange of messages containing usage records (discussed in Section
3.1.5). The property amqp.anomaly.exchange.name similarly, refers to the
exchange specific to receive the anomalies.
schedule.billing.time.day
schedule.billing.time.hour
schedule.billing.time.minute
This group defines the day, hour and minute that the bills are generated
automatically every month.
schedule.terminate.vm.hour
schedule.terminate.vm.minute
This group defines the hour and minute that the boundaries of pre-paid
Accounts will be checked to possibly terminate the VMs when credits are
exceeded.
hibernate.connection.driver_class
hibernate.dialect
hibernate.connection.url
hibernate.connection.username
hibernate.connection.password
sla.support
pre.paid.model.support
The variable sla.support refers to whether the Administrator desires or not the
charging considering compensations whereas the variable
pre.paid.model.support refers to whether the Administrator desires or not to
enable the schedule which terminate instances automatically in case of pre-paid
payment models.
4.2.2
Evaluation Design
In this phase, the experiments to be executed are detailed, including how many objects
and factors they include. More specifically, we determine the details of the environment
configuration and what charging policies will be addressed.
79
4.2. PLANNING
The case study used a JiTCloud instance composed of two data centers at Brazilian
universities, UFCG and IFPB. These data centers are distributed geographically and
configured with the Eucalyptus solution. To create a more distributed configuration, we
hosted the CloudMiddleware component in the Amazon EC2 service, with a medium"
VM (3.75 GiB mem., 2 EC2 computer, and 410 GB of storage). Finally, the CloudClient
was configured in a personal computer, because it provides a simple access interface and
does not require much computing capacity. Figure 4.3 presents this environment.
80
4.3. OPERATION
Charging Policy
CP1
CP2
CP3
At this stage, we did not specify how many bills would be generated or how many VMs
initialized, because we did not know the level of autonomy offered by the universities
data centers.
4.3
Operation
When a case study has been designed and planned it must be carried out in order to collect
the data that should be analyzed. This is what we mean with the operation of a case study.
In the operational phase of a case study, the treatments, depicted in Section 4.2.2 are
applied.
The operational phase of this case study consists of three steps: preparation where
81
4.3. OPERATION
the environment and specific details are prepared, execution, where the treatments are
effectively executed and the data is collected, and data validation where the collected
data is validated.
4.3.1
Preparation
Database: We used the database MySQL to retain the Monext data. A cleaned
database scheme was created on the CloudMiddlewares server.
JiTCollectorAgent: We prepared an Ubuntu Image3 to generate VMs Instances
with the following properties: 1GHz of CPU, 2GB of Memory and 100GB of Disk.
Then, we installed the JiTCollectorAgent inside this VM image. However, to simulate the resources usage, we also prepared a mechanism to vary the consumption.
We used Stress4 , a deliberately simple workload generator for POSIX systems. It
imposes a configurable amount of CPU, memory, I/O, and disk stress on the system.
It is written in C, and is free software licensed. Stress runs for a specified amount
of time, so we developed a script to execute the Stress during random periods in
loop.
AMQP Broker: We configured a RabbitMQ server on UFCG Universitys infrastructure to require some level of network quality in order to exchange the messages
between the JiTCollectorAgent and the JiTProcessingService.
Pricing: We specify the prices using properties files. The arbitrary prices used by
the configured Image were:
Treatment T1: cpu_rate = $0.5
Treatments T2 and T3: cpu_rate = $0.05, mem_rate = $0.07, disk_rate =
$0.06
SLA Specification: To control the result variability, we manually generated fake
anomalies and sent them to the JiTProcessingService throughout the AMQP communication. However, we illustrate an SLA specification which we could use in
the case study (Figure 4.5).
3 http://uec-images.ubuntu.com/
4 http://weather.ou.edu/
apw/projects/stress/
82
4.4. INTERPRETATION
4.3.2
Execution
The case study was conducted in January 2013. The first action we performed was to
configure the CloudMiddleware to distribute the VMs equally among the data centers.
Next, we performed the three treatments described in Section 4.2.2. The additional
information about them are described following.
Treatment 1 (T1): This treatment was performed for only one VM. We captured
usage records over eight hours while generating 16 bills at half-hour intervals,
simulating a monthly generation. The charging policy used for this treatment was
described in Figure 4.4.
Treatment 2 (T2): One bill for a group of 30 VMs was generated after eight hours.
The charging policy used for this treatment was introduced in Table 4.2 (charging
policy CP2).
Treatment 3 (T3): One bill for a group of 30 VMs was generated after eight hours.
The charging policy used for this treatment was introduced by Table 4.2 (charging
policy CP3).
4.3.3
Data Validation
In this phase, all data are checked in order to verify whether the data are reasonable and
it has been collected correctly. All data was collected correctly and none VM presented
malfunctioning.
4.4
Interpretation
After collecting experimental data in the operation phase, we aim to draw valid conclusions from it, and to do so, we must interpret the experimental data (Wohlin et al., 2000).
In this phase, the quantitative and qualitative data were analyzed.
83
4.4. INTERPRETATION
4.4.1
Question 1
Question 1 asked whether the Monext framework could charge for different resource
types at the same time. Thus, we verified whether two considered resource types by a
charging policy effectively corroborated for the bill value. T1 supported this analysis. We
captured usage records for one VM over eight hours while generating 16 bills in half-hour
intervals, simulating a monthly generation. This charging policy which considers CPU
and time was introduced by Table 4.2 (charging policy CP1) in Section 4.2.2.
Therefore, we compiled the results, remaining three groups of data: the sum of CPU
usage (variable cpu_sum of VeloZ); time consumed (variable used_time of VeloZ); and
total monetary value, which we called price. We plotted these results on two charts
depicted in Figures 4.6(a) and 4.6(b).
60
50
30000
50
40
15000
30
10000
20
5000
10
0
1
10 11 12 13 14 15 16
bills
25000
40
20000
30
15000
20
10000
35000
20000
price
used_time
60
Time (seconds)
25000
CPU (Sum of %)
.......
price
cpu_sum
.......
30000
10
5000
0
0
1
10 11 12 13 14 15 16
bills
Figures 4.6(a) and 4.6(b) both provide evidence of a correlation between CPU and
price and between time and price. This result indicates that both, CPU and Time were
considered by the Bills, since there is a correlation among them in the same direction.
Question 2
Question 2 asked whether the framework could handle the scalability of VMs. We
captured usage records for a group of 30 VMs over eight hours, generating only one
bill after that. The charging policy used for this treatment was introduced by Table
4.2 (charging policy CP2) in Section 4.2.2 and considers CPU, memory, disk, and time
resources. Therefore, focusing on the covariance of usage time (usage_time) and the
number of usage records (ur_number) for each VM, we obtained the chart depicted in
Figure 4.6.
84
4.4. INTERPRETATION
usage_time
ur_collected
28680
21890
28660
Usage Time (seconds)
21900
21880
28640
28620
21870
28600
21860
28580
21850
28560
21840
28540
21830
28520
28500
.......
28700
21820
1
9 11 13 15 17 19 21 23 25 27 29
virtual machines
As can be seen on the chart, the usage records number are almost equal to the used
time. This result suggests that the framework can handle the VMs scalability, but since
usage records are collected for all VMs, this case study presented a problem: There is a
high delay in receiving the usage records by JiTProcessingService. An average of 24%
of usage records were not accounted on time. We speculate this happened due to two
decisions: the geographical distribution of the components and the high frequency of
sending messages.
With components, we mean the JiTProcessingService (inside the CloudMiddleware),
the JiTCollectorAgent and the server RabbitMQ. To mitigate the delay, such components
could be reorganized. In a large scale scenario, would be hosted a CloudMiddleware in
conjunction with a server RabbitMQ for each group of close data centers, as depicted in
Figure 4.7. However such decentralization could bring other problems.
85
4.4. INTERPRETATION
how Amazon EC2 records customer usage records and found that, in some services,
Amazon collects usage records only twice by day, causing inaccurate billing. Unlike
Amazon, we aimed to provide fair, consistent billing, but a frequency of once a second
was impracticable. Therefore, we re-ran T2 with a sending frequency of ten seconds, and
the results were satisfactory, with all usage records accounted for on time.
Question 3 and Question 4
This subsection interprets the results for both Questions 3 and 4, because they use the
same output of T2.
Question 3 asked whether the Monext framework could charge for long-running
services. Table 4.3 shows details from the charging records for each VM, including VM
identification (vm_id); amount of used resources (disk_sum, mem_sum, and cpu_sum);
the (used_time_a and used_time_b); and the monetary value of each VM (cr_value). The
bill was based on the sum of all cr_values and totaled $295.01.
The time used and recorded of all the VMs were equal. Interpreting this result, we can
see that, although the VM may have a problem with network and become unable to send
the usage records, the time consumption will be accounted properly without interruption.
Thus, in the worst-case scenario, the Monext framework can charge the same way as
Amazon EC2, considering only time consumption.
The conclusion for Question 4 is very simple. This question asked whether the
Monext framework could calculate bills considering all the customers usage or, in other
words, whether all the charging records could be properly totaled in the final bill. We
manually added the column cr_value from Table 4.3, and the result was exactly equal to
$295.01.
Question 5
Question 5 asked whether the Monext framework could handle anomalies in calculating
bills and considering compensations. T3 supported this analysis. It generated only one bill
for a group of 30 VMs after eight hours using the charging policy presented in Table Table
4.2 (charging policy CP3) in Section 4.2.2 that considers time and SLA compensation.
The anomalies were generated manually, because we wanted to control the anomalies
attributes in order to better simulate a real-life utilization. Thus, we generated eight
types of anomalies: bandwidth, latency, and jitter. Each anomaly generates a specific
compensation, which is calculated by multiplying three characteristics of the anomaly: its
86
4.4. INTERPRETATION
gravity (how much it exceeds the SLA threshold), duration, and price. Table 4.4 presents
the eight generated anomalies which totaled $20.64.
Table 4.4 Generated Fake" Anomalies
anomaly_id
type
AN1
bandwidth
AN2
bandwidth
AN3
bandwidth
AN4
latency
AN5
latency
AN6
latency
AN7
jitter
AN8
jitter
gravity
364
319
329
51
67
28
15
49
measurement_unit
bits per second
bits per second
bits per second
bits per second
bits per second
bits per second
miliseconds
miliseconds
anomaly_compensation ($)
2.18
2.87
3.49
4.54
2.77
2.09
0.39
2.29
20.64
Table 4.5 presents the results from T3 and the charging records for each VM, including:
VM identification (vm_id); the time used, the compensation considered by the bill, the
manually calculated sum from the anomalies (anomalies_sum) and the monetary value
for each charging record (cr_value). All the VMs considered the anomalies properly,
because as can be seen in the Table 4.5 the column anomalies_sum is the equal to the
column compensation (which correspond the sum of anomalies values).
87
4.4. INTERPRETATION
4.4.2
used_time (s)
28668
28669
28687
28650
28628
28569
28650
28651
28599
28636
28611
28620
28603
28643
28592
28665
28585
28688
28639
28635
28594
28637
28632
28607
28658
28602
28641
28584
28673
28597
compensation ($)
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
anomalies_sum ($)
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
20.64
bill_value:
cr_value ($)
7.23
7.23
7.25
7.22
7.19
7.14
7.22
7.22
7.17
7.20
7.18
7.19
7.17
7.21
7.16
7.23
7.15
7.25
7.20
7.20
7.16
7.20
7.20
7.17
7.22
7.17
7.21
7.15
7.24
7.16
215.89
Discussion
This subsection presents a discussion of the case study results. We observed whether and
why the 13 Monext requirements were fulfilled.
REQ-01 Location Unawareness: For this requirement, accounting must be performed as a service for VMs running locally or remotely. Therefore, the case
study was organized to create a distributed configuration of resources (JiTDCs) and
other components (CloudMiddleware and CloudClient). The results showed that
all remotely hosted VMs were accounted for using the sending frequency of ten
seconds.
REQ-02 Flexible Data Format: For this requirement, it should be possible to
include additional usage information metrics. Therefore, a new metric related to
disk usage (disk_sum, disk_avg, and disk_rate) was added. It yielded evidence that
additional metrics can be included, due to the technology used and architectural
design.
88
4.4. INTERPRETATION
REQ-03 Service Elasticity: For this requirement, the number of VMs underlying
and fulfilling a service can be scaled due to service elasticity. The accounting
system must be designed to handle such scenario. Q2 focused on this issue and
statistically concluded that the framework can handle the VMs scalability. However,
we recognize that the number of VMs was limited, and we aim to expand the case
study in future work.
REQ-04 Service Accounting: For this requirement, the accounting system must be
suitable for long-running services and not limited to tasks with a limited execution
time. Therefore, the framework must account for as long as the customer desires to
use the services. The case study was limited to eight hours due to the constraints of
the data centers, but the satisfactory outputs showed that the framework is scalable
and prepared to account without interruption.
REQ-05 Compensations: For this requirement, both usage and compensations
(due to breaking SLAs) must be accounted for. T3 used a charging policy considering usage and compensation and aimed to answer Q5 by analyzing whether the
generated anomalies reduced the bill value, which occurred.
REQ-06 Service Billing: For this requirement, billing must be managed on a perservice basis and not just for each VM. The answer to Q4 showed that consumption
by all individual VMs were totaled as charging records in a unique, final bill.
REQ-07 Adaptable Design: For this requirement, the accounting system must be
open for modifications to cope with future changes and enhancements. The case
study fulfilled this requirement, because the constraints of the JiTCloud constraints
the separation of the MVC architecture of Monext so that only the Model part was
used.
REQ-08 Complex Pricing: For this requirement, the function which calculates
prices from the accounting information must be able to incorporate complex pricing
rules. The case study performed three treatments using different charging policies.
In particular, T2 included four metrics and 11 variables in the same rule.
REQ-09 Standard Accounting Process: For this requirement, a unified, formal
accounting process must be followed. The case study utilized almost all accounting
functions, even the roaming function (which makes it clear that more than one
provider is being used). The financial clearing function was not used, since it just
change the bill status and we focused on more complex functionalities.
REQ-10 SLA Support: For this requirement, the customer must be offered a
89
4.4. INTERPRETATION
4.4.3
Threats to Validity
When repeating the case study, some factors should be considered, because the first
execution had a few limitations.
Size Scalability. According to Tanenbaum and Van Steen (2006), the size of a
distributed system must be scalable; that is, it must be easy to add more users and
resources. Due to the restrictions imposed by the available resources, the case
study used a limited number of data centers and VMs. The framework should be
evaluated with more resources to provide greater assurance of scalability.
Geographical Scalability. Also according to Tanenbaum and Van Steen (2006),
a distributed system must be geographically scalable; that is, system components
can be located far from each other. Due to the small number of resources, the
geographical distribution of components (JiTDCs, CloudMiddleware, and CloudClient) was limited, and they were all hosted in the same country. The distribution
of this framework should be expanded..
90
Time Constraint. The JiTCloud project could include the sub-modules of Monexts JiTProcessingService component only in the final period of my Masters, for
this reason the case study was performed over just few hours. The case study
should be conducted over a month to increase its reliability.
Simulated Context. The JiTCloud project is unfinished and does not have real
customers, so we performed an case study instead of a case study. The case study
should be evaluated in a real-life scenario in future.
4.5
Chapter Summary
This chapter discussed a case study that evaluated the feasibility of Monext framework.
The methodology used by the case study was adapted from the method established by
(Wohlin et al., 2000), which consisted of four phases: definition, planning, operation, and
interpretation. In the definition phase, the foundation of the case study is determined,
including why the case study should be conducted. During the definition phase, we stated
the goal of the case study and then elaborated five questions to guide the process.
During the planning phase, we discussed where the case study should be performed
and undertaken The operation phase determined the specifics of the case studys preconditions and execution. Finally, to draw conclusions from the case studys output, we
analyzed and interpreted the results.
This case study offered evidence that Monext framework fulfilled its purpose works
correctly installed inside he JiTCloud Platform. However, some improvements can be
done so that the system better handles large, complex environments. The next chapter
presents the conclusions of this research, its main contributions, and possible directions
for future work.
91
5
Conclusion
Can you imagine what I would do if I could do all I can?
SUN TZU (544 - 496 .BC)
Federated clouds are a promising cloud computing field. However, few recent studies
have addressed the issue of accounting federated clouds (Buyya et al., 2010; RESERVOIR,
2012), and four federated cloud platforms (Kertesz et al., 2012; Celesti et al., 2010;
Distefano et al., 2011) do not address the accounting requirement, and thus a proper
accounting system to charge for consumed resources. Therefore, the Monext framework
was built (Chapter 3) to support charging IaaS in federated cloud. All design decisions
were based on the results of a systematic mapping study (Chapter 2) and evaluated in a
real federated cloud platform (Chapter 4).
In this chapter, the conclusion of this work is presented. The Chapter remainder is
organized as follows. The research contributions are highlighted in Section 5.1. Future
work concerning to the research are listed in Section 5.2. Section 5.3 presents the
academic contributions. Lastly, the concluding remarks of this dissertation are described
in Section 5.4.
5.1
Research Contributions
The main contributions of this work are (a) a state-of-the-art of cloud accounting system
based on a systematic mapping study, (b) a proposed framework called Monext to support
federated cloud platforms, and (c) an experimental study applied within the JiTCloud
project.
Mapping Study on Cloud Accounting: We presented a study and identified the
main purposes of cloud accounting, emphasizing the key challenges. This study
92
was conducted based on the good practices of systematic mapping studies proposed
by Petersen et al. (2008), and several important, related works were selected.
Monext Framework: A solution to charge federated clouds was developed. The
requirements, design, and implementation of the proposed solution were presented,
along with its main benefits: a domain specific language called VeloZ for charging
policy specifications; an adaptable design that cloud providers can manipulate to
make the solution fit their intent; It is designed to support large customers demands
independently where the resources are hosted; and support for SLAs and pre- and
post-paid models.
The VeloZ DSL: VeloZ allows IaaS providers to specify its own charging policies
and control its consumption in a financial aspect.
Experimental Study: An experiment evaluating the Monext solution was based on
the process proposed by Wohlin et al. (2000), which is composed of the following
main activities: definition, planning, operation, and interpretation. As a result, five
null hypotheses were rejected, providing evidence of the frameworks quality.
5.2
Future Work
93
5.3
Academic Contribution
The conducted mapping study was published in a scientific conference: SILVA, F. A. P.;
SILVEIRA N., PAULO. A. M.; GARCIA, V. C.; ASSAD, R. E.; TRINTA, F. M. "Accounting
Models for Cloud Computing: A Systematic Mapping Study". In: International Conference on Grid Computing & Applications (GCA), 2012, Las Vegas. Proceedings of the
2012 International Conference on Grid Computing & Applications, 2012. p. 3-9.
5.4
Concluding Remarks
Since Amazon started to sell cloud computing services in 2006 and many others IT
companies quickly followed suit, accounting in cloud computing has slowly gained the
attention of the scientific community, and many gaps still remain to be explored. The
systematic mapping study introduced many of these research opportunities, while Monext
focused on specific points. However, we are confident that Monext is a comprehensive
solution, and we believe that the use of a standard accounting process (Ruiz-Agundez
et al., 2010c) and Monexts layered architectures enables it to be better understood and
extended by other solutions. Applying the 13 guiding requirements and the remote
collecting strategy made it possible to serve both complex federated cloud platforms and
single data centers. In addition, using VeloZ, cloud administrators can specify charging
policies themselves, instead of depending on programmers to do it. Moreover, we judge
Monext to be an interesting solution, because it explored the union of existing accounting
models and feature to mitigate their limitations. This framework offers different reports
through a web-based interface, provides SLA support, and applies the emergent economic
model RaaS, among others benefits. Finally, this dissertation provides one more step in
the maturation of cloud accounting and suggests directions for further work in this field.
94
Bibliography
95
BIBLIOGRAPHY
Buthelezi, M., Adigun, M. O., Ekabua, O. O., and Iyilade, J. (2008). Accounting, pricing
and charging service models for a guiset grid-based service provisioning environment.
In H. R. Arabnia and A. Bahrami, editors, CSREA EEE, pages 350355. CSREA Press.
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009a). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing
as the 5th utility. Future Gener. Comput. Syst., 25(6), 599616.
Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009b). Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing
as the 5th utility. Future Gener. Comput. Syst., 25(6), 599616.
Buyya, R., Ranjan, R., and Calheiros, R. N. (2010). Intercloud: utility-oriented federation
of cloud computing environments for scaling of application services. In Proceedings
of the 10th international conference on Algorithms and Architectures for Parallel
Processing - Volume Part I, ICA3PP10, pages 1331, Berlin, Heidelberg. SpringerVerlag.
Cai, H., Zhang, K., Wang, M., Li, J., Sun, L., and Mao, X. (2009). Customer centric
cloud service model and a case study on commerce as a service. In Proceedings of the
2009 IEEE International Conference on Cloud Computing, CLOUD 09, pages 5764,
Washington, DC, USA. IEEE Computer Society.
Caracas, A. and Altmann, J. (2007). A pricing information service for grid computing.
In Proceedings of the 5th international workshop on Middleware for grid computing:
held at the ACM/IFIP/USENIX 8th International Middleware Conference, MGC 07,
pages 4:14:6, New York, NY, USA. ACM.
Celesti, A., Tusa, F., Villari, M., and Puliafito, A. (2010). How to enhance cloud
architectures to enable cross-federation. In Cloud Computing (CLOUD), 2010 IEEE
3rd International Conference on, pages 337 345.
Cohen, J. (1988). Statistical power analysis for the behavioral sciences, volume 2nd.
Lawrence Erlbaum Associates.
Comellas, J. O. F., Presa, I. G., and Fernndez, J. G. (2010). Sla-driven elastic cloud
hosting provider. In Proceedings of the 2010 18th Euromicro Conference on Parallel,
Distributed and Network-based Processing, PDP 10, pages 111118, Washington,
DC, USA. IEEE Computer Society.
96
BIBLIOGRAPHY
Condori-Fernandez, N., Daneva, M., Sikkel, K., Wieringa, R., Dieste, O., and Pastor, O.
(2009). A systematic mapping study on empirical evaluation of software requirements
specifications techniques. In L. Williams, J. Miller, and R. Selby, editors, Third
International Symposium on Empirical Software Engineering and Measurement, pages
503505, Los Alamitos. IEEE Computer Society Press.
Costa, R., Brasileiro, F., de Souza Filho, G. L., and Sousa, D. M. (2010). Just in time
clouds: Enabling highly-elastic public clouds over low scale amortized resources.
Technical Reports-Laboratrio de Sistemas Distribudos http://tinyurl.com/
8c3paal.
Denne, M. (2007). Pricing utility computing services. In International Journal of Web
Services Research (IJWSR).
Detal, G., Leroy, D., and Bonaventure, O. (2009). An adaptive three-party accounting
protocol. In Proceedings of the 5th international student workshop on Emerging
networking experiments and technologies, Co-Next Student Workshop 09, pages 34,
New York, NY, USA. ACM.
Distefano, S., Fazio, M., and Puliafito, A. (2011). The cloud@home resource management
system. In Utility and Cloud Computing (UCC), 2011 Fourth IEEE International
Conference on, pages 122 129.
El Maghawry, N. and Dawood, A. (2010). Aspect oriented gof design patterns. In
Informatics and Systems (INFOS), 2010 The 7th International Conference on, pages 1
7.
Elmroth, E., Marquez, F. G., Henriksson, D., and Ferrera, D. P. (2009). Accounting
and billing for federated cloud infrastructures. In Proceedings of the 2009 Eighth
International Conference on Grid and Cooperative Computing, GCC 09, pages 268
275, Washington, DC, USA. IEEE Computer Society.
Ernemann, C., Hamscher, V., and Yahyapour, R. (2002). Economic scheduling in grid
computing. In Revised Papers from the 8th International Workshop on Job Scheduling
Strategies for Parallel Processing, JSSPP 02, pages 128152, London, UK, UK.
Springer-Verlag.
Falasi, A. A. and Serhani, M. A. (2011). A framework for sla-based cloud services
verification and composition. In Proc. Int. Conference on Innovations in Information
Technology (IIT), pages 287292.
97
BIBLIOGRAPHY
98
BIBLIOGRAPHY
Karsten, M., Schmitt, J., Stiller, B., and Wolf, L. (2000). Charging for packet-switched
network communication-motivation and overview. Comput. Commun., 23(3), 290302.
Kertesz, A., Kecskemeti, G., Marosi, A., Oriol, M., Franch, X., and Marco, J. (2012).
Integrated monitoring approach for seamless service provisioning in federated clouds.
In Parallel, Distributed and Network-Based Processing (PDP), 2012 20th Euromicro
International Conference on, pages 567 574.
Kitchenham, B. (2010). Whats up with software metrics? - a preliminary mapping study.
J. Syst. Softw., 83(1), 3751.
Kitchenham, B. and Charters, S. (2007). Guidelines for performing systematic literature
reviews in software engineering. Software Engineering Group School of , 2(EBSE
2007-001), 1051.
Kitchenham, B., Mendes, E., and Travassos, G. (2007). Cross versus within-company
cost estimation studies: A systematic review. Software Engineering, IEEE Transactions
on, 33(5), 316 329.
Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., and Linkman, S.
(2009). Systematic literature reviews in software engineering - a systematic literature
review. Inf. Softw. Technol., 51(1), 715.
Kitchenham, B. A., Dyba, T., and Jorgensen, M. (2004). Evidence-based software engineering. In Proceedings of the 26th International Conference on Software Engineering,
ICSE 04, pages 273281, Washington, DC, USA. IEEE Computer Society.
Kleinrock, L. (2005). A vision for the Internet. ST Journal for Research, 2(1), 45.
Kruchten, P. (1995). The 4+1 view model of architecture. IEEE Softw., 12(6), 4250.
Lehmann, S. and Buxmann, P. (2009). Pricing strategies of software vendors. Business
and Information Systems Engineering, 1, 452462.
Lindner, M., Galan, F., Chapman, C., Clayman, S., Henriksson, D., and Elmroth, E.
(2011). The cloud supply chain : A framework for information, monitoring, accounting
and billing. In 2nd International ICST Conference on Cloud Computing (CloudComp
2010).
Liu, F., Tong, J., Mao, J., Bohn, R., Messina, J., Badger, L., and Leaf, D. (2012). NIST
Cloud Computing Reference Architecture: Recommendations of the National Institute
99
BIBLIOGRAPHY
100
BIBLIOGRAPHY
Park, K.-W., Han, J., Chung, J., and Park, K. H. (2012). Themis: A mutually verifiable
billing system for the cloud computing environment. IEEE Transactions on Services
Computing, 99(PrePrints).
Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M. (2008). Systematic mapping
studies in software engineering. In Proceedings of the 12th international conference on
Evaluation and Assessment in Software Engineering, EASE08, pages 6877, Swinton,
UK, UK. British Computer Society.
Piro, R. M., Guarise, A., and Werbrouck, A. (2003). An economy-based accounting
infrastructure for the datagrid. In Proceedings of the 4th International Workshop on
Grid Computing, GRID 03, pages 202, Washington, DC, USA. IEEE Computer
Society.
Pretorius, R. and Budgen, D. (2008). A mapping study on empirical evidence related
to the models and forms used in the uml. In Proceedings of the Second ACM-IEEE
international symposium on Empirical software engineering and measurement, ESEM
08, pages 342344, New York, NY, USA. ACM.
Prodan, R. and Ostermann, S. (2009). A survey and taxonomy of infrastructure as a
service and web hosting cloud providers. In Grid Computing, 2009 10th IEEE/ACM
International Conference on, pages 17 25.
RabbitMQ (2007). Open source enterprise messaging. http://www.rabbitmq.
Accessed:
com/resources/RabbitMQ_PressRelease_080207.pdf.
30/11/2012.
RabbitMQ (2012). Open source enterprise messaging. http://www.rabbitmq.
com/tutorials/amqp-concepts.html. Accessed: 30/11/2012.
Reijns, G. L. and van Gemund, A. J. C. (2005). Predicting the execution times of
parallel-independent programs using pearson distributions. Parallel Comput., pages
877899.
RESERVOIR (2012). Resources and services virtualization without barriers. http:
//62.149.240.97/. Accessed: 30/11/2012.
Rochwerger, B., Breitgand, D., Levy, E., Galis, A., Nagin, K., Llorente, I. M., Montero,
R., Wolfsthal, Y., Elmroth, E., Cceres, J., Ben-Yehuda, M., Emmerich, W., and Galn,
101
BIBLIOGRAPHY
F. (2009). The reservoir model and architecture for open federated cloud computing.
IBM J. Res. Dev., 53(4), 535545.
Rohitratana, J. and Altmann, J. (2010). Agent-based simulations of the software market
under different pricing schemes for software-as-a-service and perpetual software. In
J. Altmann and O. Rana, editors, Economics of Grids, Clouds, Systems, and Services,
volume 6296 of Lecture Notes in Computer Science, pages 6277. Springer Berlin
Heidelberg.
Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2010a). Tarificacion flexible de
servicios en internet. Proceedings of the XX Jornadas de Telecom I+D, Telefonica,
Valladolid, Spain.
Ruiz-Agundez, I., K. Penya, Y., and G. Bringas, P. (2010b). A taxonomy of the future
internet accounting process. In Int. Conference on Advanced Engineering Computing
and Applications in Sciences (ADVCOMP 10), pages 111117.
Ruiz-Agundez, I., Penya, Y., and Bringas, P. (2010c). A taxonomy of the future internet
accounting process. In Advanced Engineering Computing and Applications in Sciences
(ADVCOMP 10), Int. Conference on, pages 111117.
Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2011). A flexible accounting model
for cloud computing. In Proceedings of the 2011 Annual SRII Global Conference, SRII
11, pages 277284, Washington, DC, USA. IEEE Computer Society.
Sahai, A., Sahai, A., Durante, A., Durante, A., Machiraju, V., and Machiraju, V. (2001).
Towards automated sla management for web services. Technical report.
Sahai, A., Graupner, S., Machiraju, V., and Moorsel, A. v. (2003). Specifying and
monitoring guarantees in commercial grids through sla. In Proceedings of the 3st
International Symposium on Cluster Computing and the Grid, CCGRID 03, pages
292, Washington, DC, USA. IEEE Computer Society.
Samimi, P. and Patel, A. (2011). Review of pricing models for grid and cloud computing.
In Proc. IEEE Symposium on Computers and Informatics (ISCI 11), pages 634639.
Song, J., Liu, W., and Wang, Y. (2007). Competitive pricing model for resource scheduling in grid computing. In Proceedings of the Third International Conference on
Semantics, Knowledge and Grid, SKG 07, pages 406409, Washington, DC, USA.
IEEE Computer Society.
102
BIBLIOGRAPHY
103
BIBLIOGRAPHY
104
Appendices
105
A
Deploy Instructions
A.1
JiTProcessingService Deploy
This section describes how to deploy the web application using the Apache Tomcat 6.0
and the MySQL Server 5.1. We omitted the installation of this environment for simplicity.
Therefore, considering these execution environments installed, as the JiTProcessingService is a Grails application its deployable product has an .WAR" extension (the war file
can be found inside the jit_processing_service_web_dist_0.4.zip file). There is a couple
of ways to deploy this product but the easiest is to follow five steps:
1. Create the database scheme on the MySQL Server.
2. Configure the credentials of a database scheme (connection.user, connection.password,
connection.url etc.) in a properties file.
3. Stop Tomcat.
4. Delete an existing deployment. If you have previously deployed jitprocessingservice.war" in TOMCAT_HOME/webapps, then it has been unpacked into webapps/jitprocessingservice/... You must delete this directory and all its contents. On
Unix, this can be done with rm -r $TOMCAT_HOME/webapps/jitprocessingservice.
5. Copy WAR file to TOMCA_HOME/webapps/.
6. Start Tomcat.
7. Access http://localhost:8080/jitprocessingservice.
106
It is important to highlight that the autoDeploy" attribute in the <app>/METAINF/context.xml file must be true", so that, the Host will attempt to deploy and update
web applications dynamically, as needed.
A.2
JiTCollectorAgent Deploy
The most of our experiments were using Linux environment but the JiTCollectorAgent
was also tested with Windows SO. This tutorial uses Ubuntu Linux distribution. Aiming
to deploy JiTCollectorAgent it must uncompress the jit_collector_agent_dist_0.4.zip file
in an appropriate directory of the VM image (in our case we used the /opt directory).
When uncompressed, the jit_collector_agent_dist_0.4.zip artifact shows the following
files:
jit_collector_agent.jar: Executable file in which when started publishes the collected information
jba.properties: Properties file that keeps the message broker credentials
libsigar-amd64-linux.so: Adapter library for the Linux Operational System
libsigar-x86-linux.so: Adapter library for the Linux Operational System
sigar-amd64-winnt.dll: Adapter library for the Windows Operational System
sigar-x86-winnt.dll: Adapter library for the Windows Operational System
To execute jit_collector_agent.jar, it is necessary the Java Runtime Environment installed (1.6 version). Next, just execute the following command: java -jar jit_collector_
agent.jar <interval>. For which <interval> identifies the frequency of sending messages
in seconds. The jba.properties file owns the following configuration information:
virtual.machine: VM identification (it must be related to a specific Account)
amqp.host: Message broker endpoint
amqp.port: Message broker standard port
amqp.ssl_port: Message broker ssl port
Finally, to automatize the agent initialization, the /etc/rc.local file must be updated
with the following command:
java -jar "bash /opt/jit_collector_agent/jit_collector_agent.jar <interval> > /dev/null " -s /bin/bash
107