125
“Monext: An Accounting Framework for Federated Clouds” By Francisco Airton Pereira da Silva M.Sc. Dissertation www.cin.ufpe.br/~posgraduacao RECIFE, FEB/2013

Monext: An Accounting Framework for Federated Clouds

Embed Size (px)

DESCRIPTION

Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.Resumo: A Computação na Nuvem se tornou um paradigma consumado para executar serviços em infraestruturas externas, onde de uma forma virtual a capacidade praticamente ilimitada pode ser alocada dinamicamente. Este paradigma estabelece um novo cenário para a implantação de aplicações e serviços de TI. Neste modelo, desde aplicações completas até infraestrutura de máquinas são ofertadas a usuários, que são cobrados apenas pelo uso dos recursos consumidos. Desta forma, os bens de consumo da nuvem são ofertados através de abstrações de serviços, onde atualmente são citadas três principais categorias: Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura como Serviço (IaaS).No caso do IaaS são oferecidos recursos computacionais na forma de Máquinas Virtuais para o cliente final. Para atingir o aspecto ilimitado de recursos é necessário distribuir estas Máquinas Virtuais por vários Data Centers. Esta distribuição dificulta atender uma série de requisitos como Segurança, Confiabilidade, Disponibilidade e a Tarifação pelos recursos consumidos. A Tarifação refere-se a como os recursos são registrados, contabilizados e cobrados. Mesmo no caso de um único provedor esta tarefa não é nada fácil e existe um contexto que esta dificuldade se torna ainda maior, conhecida como Federação de Computação na Nuvem ou também chamadas de Nuvens Federadas.Nuvens Federadas ocorrem quando um provedor de Computação na Nuvem terceiriza recursos dinamicamente para outros provedores em resposta à variação da demanda. Desta forma ocorre um aglomerado de nuvens, porém seus recursos são heterogêneos, acarretando num maior esforço para gerenciar os recursos distribuídos e por consequên- cia para a Tarifação. Neste contexto foram identificadas pesquisas nesta área sobre plataformas para Nuvens Federadas, que não abordam o requisito de Tarifação.Esta dissertação apresenta um framework voltado à tarifação de Infraestrutura como Serviço com foco em Nuvens Federadas. Objetivando colher informações sobre esta área e consequentemente gerar insumos para fundamentar as decisões na construção do framework, foi aplicado um Estudo de Mapeamento Sistemático.Esta dissertação também apresenta uma validação inicial da ferramenta, através de um estudo experimental, mostrando indícios de que os requisitos gerados pelo Mapeamento Sistemático foram atendidos, bem como será viável a aplicação da solução por provedores de serviços de nuvem em um cenário real.

Citation preview

Page 1: Monext: An Accounting Framework for Federated Clouds

“Monext: An Accounting Framework forFederated Clouds”

By

Francisco Airton Pereira da Silva

M.Sc. Dissertation

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, FEB/2013

Page 2: Monext: An Accounting Framework for Federated Clouds

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Francisco Airton Pereira da Silva

“Monext: An Accounting Framework forFederated Clouds”

A M.Sc. Dissertation presented to the Centro de Informática

of Universidade Federal de Pernambuco in partial fulfillment

of the requirements for the degree of Master of Science in

Computer Science.

Advisor: Vinicius Cardoso Garcia

RECIFE, FEB/2013

Page 3: Monext: An Accounting Framework for Federated Clouds

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

Silva, Francisco Airton Pereira da Monext: an accounting framework for federated clouds. / Francisco Airton Pereira da Silva. - Recife: O Autor, 2013. xvi, 107 folhas: fig., tab. Orientador: Vinicius Cardoso Garcia.

Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.

Inclui bibliografia, glossário e apêndice. 1. Ciência da computação. 2. Sistemas distribuídos. 3. Computação em nuvem. I. Garcia, Vinicius Cardoso (orientador). II. Título. 004 CDD (23. ed.) MEI2013 – 051

Page 4: Monext: An Accounting Framework for Federated Clouds

Dissertação de Mestrado apresentada por Francisco Airton Pereira da Silva à Pós-

Graduação em Ciência da Computação do Centro de Informática da Universidade Federal

de Pernambuco, sob o título “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 Informática / UFPE

______________________________________________

Prof. Francisco Vilar Brasileiro

Departamento de Sistemas e Computação / UFCG

_______________________________________________

Prof. Vinicius Cardoso Garcia

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 27 de fevereiro de 2013

___________________________________________________

Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Page 5: Monext: An Accounting Framework for Federated Clouds

I specially dedicate this dissertation with love and affection

to my mother Maria José who suffered for our distance

during all this time.

Page 6: Monext: An Accounting Framework for Federated Clouds

Acknowledgements

Firstly to God for every blessing, protection, love and strength throughout my life.To my father Antônio, 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 thedistance we will always be together.

To my sweet girlfriend Patrícia, for all love, affection, support and friendship duringall these years of partnership, in special the two last ones, as well as by welcome andfriendly words in the most adverse moments.

To my friends from the "OsCinFuturo" group for all support and friendship: LeninAbadie, Marco André, Thiago Vieira, Paulo Fernando, Dhiego Abrantes, Rodolfo Arruda,Adriano Tito, Hélio 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

Page 7: Monext: An Accounting Framework for Federated Clouds

When you walk through a storm,

Hold your head up high,

And don’t be afraid of the dark.

At the end of a storm,

There’s a golden sky,

And a sweet silver song of a lark

Walk On! Walk On! With hope in your heart,

And you’ll never walk alone....

—RICHARD RODGERS (You’ll Never Walk Alone)

Page 8: Monext: An Accounting Framework for Federated Clouds

Resumo

A Computação na Nuvem se tornou um paradigma consumado para executar serviços eminfraestruturas externas, onde de uma forma virtual a capacidade praticamente ilimitadapode ser alocada dinamicamente. Este paradigma estabelece um novo cenário para aimplantação de aplicações e serviços de TI. Neste modelo, desde aplicações completasaté infraestrutura de máquinas são ofertadas a usuários, que são cobrados apenas pelouso dos recursos consumidos. Desta forma, os bens de consumo da nuvem são ofertadosatravés de abstrações de serviços, onde atualmente são citadas três principais categorias:Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura comoServiço (IaaS).

No caso do IaaS são oferecidos recursos computacionais na forma de MáquinasVirtuais para o cliente final. Para atingir o aspecto ilimitado de recursos é necessáriodistribuir estas Máquinas Virtuais por vários Data Centers. Esta distribuição dificultaatender uma série de requisitos como Segurança, Confiabilidade, Disponibilidade e aTarifação pelos recursos consumidos. A Tarifação refere-se a como os recursos sãoregistrados, contabilizados e cobrados. Mesmo no caso de um único provedor esta tarefanão é fácil e existe um contexto em que esta dificuldade se torna ainda maior, conhecidacomo Federação de Computação na Nuvem ou também chamadas de Nuvens Federadas.

Nuvens Federadas ocorrem quando um provedor de Computação na Nuvem terceirizarecursos dinamicamente para outros provedores em resposta à variação da demanda.Desta forma ocorre um aglomerado de nuvens, porém seus recursos são heterogêneos,acarretando num maior esforço para gerenciar os recursos distribuídos e por consequên-cia para a Tarifação. Neste contexto foram identificadas pesquisas nesta área sobreplataformas para Nuvens Federadas, que não abordam o requisito de Tarifação.

Esta dissertação apresenta um framework voltado à tarifação de Infraestrutura comoServiço com foco em Nuvens Federadas. Objetivando colher informações sobre estaárea e consequentemente gerar insumos para fundamentar as decisões na construção doframework, foi aplicado um Estudo de Mapeamento Sistemático.

Esta dissertação também apresenta uma validação inicial da ferramenta, através de umestudo experimental, mostrando indícios de que os requisitos gerados pelo MapeamentoSistemático foram atendidos, bem como será viável a aplicação da solução por provedoresde serviços de nuvem em um cenário real.

Palavras-chave: Computação na Nuvem, Infraestrutura como Serviço, Tarifação, Con-tabilidade, Nuvens Federadas, Linguagem Específica de Domínio

vi

Page 9: Monext: An Accounting Framework for Federated Clouds

Abstract

Cloud computing has become an established paradigm for running services on externalinfrastructure that dynamically allocates virtually unlimited capacity. This paradigmcreates a new scenario for the deployment of applications and information technology(IT) services. In this model, complete applications and machine infrastructure are offeredto users, who are charged only for the resources they consume. Thus, cloud resources areoffered through service abstractions classified into three main categories: Software as aService (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 aimto offer such unlimited resources necessitates distributing these virtual machines throughmultiple data centers. This distribution makes harder to fulfill a number of requirementsincluding security, reliability, availability, and accounting. Accounting refers to howresources are recorded, accounted for, and charged. Even for a single cloud providerthis task is hard, and it becomes more difficult for a federation of cloud computing, orfederated cloud, in which a cloud provider dynamically outsources resources to otherproviders in response to demand variation. Thus, a cluster of clouds shares heterogeneousresources, requiring greater effort to manage and accurately account for the distributedresources.

Some earlier research has addressed the development of platforms for federatedclouds but without considering the accounting requirement. This dissertation presentsa framework for charging IaaS with a focus on federated cloud. In order to gatherinformation about this topic area and to generate guidelines for building the framework,we applied a systematic mapping study. This dissertation also presents an initial validationof the tool through a case study, showing evidence that the requirements generatedthrough the mapping study were fulfilled by the framework and presenting indications ofits feasibility in a real cloud service scenario.

Keywords: Cloud Computing, Infrastructure as a Service, Accounting, Billing, Feder-ated Clouds, Domain Specific Language

vii

Page 10: Monext: An Accounting Framework for Federated Clouds

Contents

List of Figures ix

List of Tables x

List of Acronyms xi

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Statements of the Contributions . . . . . . . . . . . . . . . . . . . . . . 51.5 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Systematic Mapping Study on Cloud Accounting 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Literature Review Method . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Definition of Research Questions . . . . . . . . . . . . . . . . 102.2.2 Conduct Search . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 Screening of Papers . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Keywording . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.5 Data Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Mapping Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 RQ1 - Is there any taxonomy for concepts related to accounting

process in cloud computing? . . . . . . . . . . . . . . . . . . . 172.3.2 RQ2 - What are the existing accounting models for cloud com-

puting? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.3 RQ3 - What are the existing pricing schemes for cloud or grid

computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.4 RQ4 - What are the aspects taken into account to compose a SLA

in cloud/grid computing scenario? . . . . . . . . . . . . . . . . 282.4 Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.1 Research Type Classification . . . . . . . . . . . . . . . . . . . 342.4.2 Contribution Type Classification . . . . . . . . . . . . . . . . . 352.4.3 Research Types vs. Research Questions . . . . . . . . . . . . . 36

viii

Page 11: Monext: An Accounting Framework for Federated Clouds

2.4.4 Accounting Models Classification . . . . . . . . . . . . . . . . 372.5 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Monext: An Accounting Framework for Federated Clouds 463.1 Architecture Description . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1.1 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.1.2 Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . . 493.1.3 Logical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

jit_collector_agent . . . . . . . . . . . . . . . . . . . . . . . . 54accounting_manager . . . . . . . . . . . . . . . . . . . . . . . 55pricing_manager . . . . . . . . . . . . . . . . . . . . . . . . . 56charging_manager . . . . . . . . . . . . . . . . . . . . . . . . 56billing_manager . . . . . . . . . . . . . . . . . . . . . . . . . 57financial_clearing_manager . . . . . . . . . . . . . . . . . . . 58user_manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.1.4 Development View . . . . . . . . . . . . . . . . . . . . . . . . 593.1.5 Process View . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

JiTCollectorAgent . . . . . . . . . . . . . . . . . . . . . . . . 62JiTProcessingService . . . . . . . . . . . . . . . . . . . . . . . 64

3.1.6 Physical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.2 VeloZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.3 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4 A Preliminary Case Study 754.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.1.2 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.2.1 Context Selection: JiTCloud Project . . . . . . . . . . . . . . . 76

JiTCloud and Monext Integration . . . . . . . . . . . . . . . . 784.2.2 Evaluation Design . . . . . . . . . . . . . . . . . . . . . . . . 79

4.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.3.1 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.3.2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

ix

Page 12: Monext: An Accounting Framework for Federated Clouds

4.3.3 Data Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4.1 Analysis for Each Question . . . . . . . . . . . . . . . . . . . 84Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Question 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Question 3 and Question 4 . . . . . . . . . . . . . . . . . . . . 86Question 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.4.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . 90

4.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5 Conclusion 925.1 Research Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 925.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3 Academic Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 945.4 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Bibliography 95

Appendices 105

A Deploy Instructions 106A.1 JiTProcessingService Deploy . . . . . . . . . . . . . . . . . . . . . . . 106A.2 JiTCollectorAgent Deploy . . . . . . . . . . . . . . . . . . . . . . . . 107

x

Page 13: Monext: An Accounting Framework for Federated Clouds

List of Figures

2.1 Systematic Mapping Process Petersen et al. (2008) . . . . . . . . . . . 102.2 N. of Papers X Search Engines. . . . . . . . . . . . . . . . . . . . . . . 122.3 Filters of the screening process. . . . . . . . . . . . . . . . . . . . . . . 132.4 Accounting Process (Ruiz-Agundez et al., 2010b) . . . . . . . . . . . . 182.5 IPDR reference model (Ruiz-Agundez et al., 2011) . . . . . . . . . . . 192.6 Architecture in Layers for Accounting and Billing within the RESER-

VOIR Service Manager. (Elmroth et al., 2009) . . . . . . . . . . . . . . 202.7 Overall architecture and process flow of THEMIS . . . . . . . . . . . . 232.8 Monitoring data flow (Lindner et al., 2011) . . . . . . . . . . . . . . . 242.9 Research type vs. Research questions . . . . . . . . . . . . . . . . . . 36

3.1 Monext Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Monext General View . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3 The “4+1" view model . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4 Monext Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . . 503.5 Use Cases: Manage Information of Domain Entities and Manage Cus-

tomer Information in an expanded way. . . . . . . . . . . . . . . . . . 513.6 Monext General Architecture . . . . . . . . . . . . . . . . . . . . . . . 533.7 Monext Package Structure . . . . . . . . . . . . . . . . . . . . . . . . 543.8 jit_collector_agent package . . . . . . . . . . . . . . . . . . . . . . . . 553.9 accounting_manager package . . . . . . . . . . . . . . . . . . . . . . . 553.10 pricing_manager package . . . . . . . . . . . . . . . . . . . . . . . . . 563.11 charging_manager package . . . . . . . . . . . . . . . . . . . . . . . . 573.12 billing_manager package . . . . . . . . . . . . . . . . . . . . . . . . . 573.13 financial_clearing_manager package . . . . . . . . . . . . . . . . . . . 583.14 user_manager package . . . . . . . . . . . . . . . . . . . . . . . . . . 593.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 Agundez’s accounting process and the RESERVOIRlayered architecture idea. . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.16 RabbitMQ Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.17 Monext and RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . 643.18 Monext Accounting Process . . . . . . . . . . . . . . . . . . . . . . . 653.19 Monext - Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xi

Page 14: Monext: An Accounting Framework for Federated Clouds

3.20 Monext - Charging Policy Specification Page . . . . . . . . . . . . . . 673.21 Monext Deployment View . . . . . . . . . . . . . . . . . . . . . . . . 683.22 VeloZ Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.23 Amazon AWS - On Demand Instance Types Pricing (Amazon-AWS, 2012) 73

4.1 Composition of a JiT Cloud (Costa et al., 2010) . . . . . . . . . . . . . 774.2 JiTCloud Deployment View . . . . . . . . . . . . . . . . . . . . . . . 784.3 Experimental Environment . . . . . . . . . . . . . . . . . . . . . . . . 804.4 Charging Policy A Explanation . . . . . . . . . . . . . . . . . . . . . . 814.5 SLA Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.6 Usage Time vs. Number of Collected Usage Records . . . . . . . . . . 854.7 Monext Possible Configuration . . . . . . . . . . . . . . . . . . . . . . 85

xii

Page 15: Monext: An Accounting Framework for Federated Clouds

List of Tables

2.1 Search String . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Primary Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Research Type Facet (Wieringa et al., 2005) . . . . . . . . . . . . . . . 162.4 Taxonomy of Accounting Process (Ruiz-Agundez et al., 2010b) . . . . 172.5 Pricing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.6 SLA metrics for IaaS (Alhamad et al., 2010) . . . . . . . . . . . . . . . 302.7 SLA metrics for PasS (Alhamad et al., 2010) . . . . . . . . . . . . . . 312.8 SLA metrics for SaaS (Alhamad et al., 2010) . . . . . . . . . . . . . . 312.9 SLA metrics for Storage as a service (Alhamad et al., 2010) . . . . . . 322.10 Research Type Classification . . . . . . . . . . . . . . . . . . . . . . . 342.11 Contribution Type Classification . . . . . . . . . . . . . . . . . . . . . 352.12 Accounting Models Classification . . . . . . . . . . . . . . . . . . . . 37

3.1 General Use Cases Description . . . . . . . . . . . . . . . . . . . . . . 503.2 Specific Use Cases Description . . . . . . . . . . . . . . . . . . . . . . 513.3 Taxonomy of Accounting Process Ruiz-Agundez et al. (2010c) . . . . . 603.4 Default Charging Variables . . . . . . . . . . . . . . . . . . . . . . . . 723.5 Charging Policy Examples . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1 Monext Configuration Properties . . . . . . . . . . . . . . . . . . . . . 794.2 Evaluated Charging Policies . . . . . . . . . . . . . . . . . . . . . . . 814.3 Results from Treatment 2 (T2) . . . . . . . . . . . . . . . . . . . . . . 874.4 Generated “Fake" Anomalies . . . . . . . . . . . . . . . . . . . . . . . 874.5 Results from Treatment 3 (T3) . . . . . . . . . . . . . . . . . . . . . . 88

xiii

Page 16: Monext: An Accounting Framework for Federated Clouds

List of Acronyms

ABC Accounting, Billing, and Compensation

ADB Accounting Database

AMQP Advanced Message Queuing Protocol

API Application Programming Interface

ARPANET Advanced Research Projects Agency Network

AWS Amazon Web Services

BNF Backus-Naur Form

bps bits per second

CCP Current Charging Policy

CNA Cloud Notary Authority

CoE Cost of Execution

CoH Cost of Hosting

CoO Cost of Outsourcing

CR Charging Record

CSP Cloud Service Provider

DSL Domain Specific Language

EC2 Amazon Elastic Compute Cloud

EQ Equality Level

GQM Goal Question Metric

HTTP Hypertext Transfer Protocol

IaaS Infrastructure as a Service

IPDR Internet Protocol Detail Record

xiv

Page 17: Monext: An Accounting Framework for Federated Clouds

JiT DC Just in Time Data Center

JiT Just in Time

JiTCA Just in Time Cloud Accounting

JiTCA-CPL Just in Time Cloud Accounting - Charging Policy Language

KPI Key Performance Indicator

MV RT Minimum Violating Response Time

MS Mapping Study

NIST National Institute of Standards and Technology

PaaS Platform as a Service

Pen Penalty

Prc Price

POSIX Portable Operating System Interface

PS Primary Study

QoS Quality of Service

REQ Requirement

Revenue Rvn

RQ Research Question

RTP Real-Time Pricing

S3 Amazon Simple Storage Service

SaaS Software as a Service

SC Scenarios

SCA Service Configuration Analyzer

SSF SLA Satisfaction Function

xv

Page 18: Monext: An Accounting Framework for Federated Clouds

SLA Service Level Agreement

SLM Service Life-cycle Manager

SMAM SM Accounting Manager

SOA Service Oriented Architecture

SUR Summary Usage Record

UFPE Federal University of Pernambuco

VAM VEEM Accounting Manager

VEEM Virtual Execution Environment Manager

VMT Virtual Machine Type

VoIP Voice over Internet Protocol

Wi-Fi Wireless Fidelity

XML eXtensible Markup Language

xvi

Page 19: Monext: An Accounting Framework for Federated Clouds

1Introduction

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 theoriginal Advanced Research Projects Agency Network (ARPANET) project which seededthe 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 provisioningmodel anticipated the massive transformation of the entire computing industry in the21st century whereby computing services will be readily available on demand, like otherutility services available in today’s society.

Similarly, computing service users (consumers) need to pay providers only when theyaccess computing services. In addition, consumers no longer need to invest heavily orencounter difficulties in building and maintaining complex IT infrastructure. In such amodel, users access services based on their requirements without regard to where theservices are hosted. This model has been referred to as utility computing, or recently asCloud Computing (Buyya et al., 2009a; Weiss, 2007).

The Information Technology Laboratory at the National Institute of Standards andTechnology (NIST) has posted a working definition of cloud computing: “Cloud Com-

puting 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

1

Page 20: Monext: An Accounting Framework for Federated Clouds

the goals of saving hardware cost and energy by reducing idle cycles in the computinghardware, which is in turn achieved by packing computing tasks to fill up the capacity ofthe underlying hardware. In this context, the NIST also defines three types of deliverymodels 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 notcontrol the operating system, hardware or network infrastructure on which it’s running.With SaaS, clients subscribe to applications offered by providers rather than building orbuying them. Developers can also enrich their applications by integrating SaaS servicesinto them. Examples of SaaS solutions include Google Apps1 and Salesforce2.

When the consumer uses a hosting environment for their applications it is calledPlatform as a Service (PaaS). The consumer controls the applications that run in theenvironment (and possibly has some control over the hosting environment), but doesnot control the operating system, hardware or network infrastructure on which they arerunning. The platform is typically an application framework which supplies users withdevelopment and administration platforms. Examples of PaaS platforms include GoogleApp Engine3 and Windows Azure4.

With Infrastructure as a Service (IaaS) the consumer uses "fundamental computingresources" such as processing power, storage, networking components or middleware.The consumer can control the operating system, storage, deployed applications andpossibly networking components such as firewalls and load balancers, but not the cloudinfrastructure beneath them. It represents the base of the pyramid without which the wholearchitecture cannot exist. Examples of IaaS providers include Amazon5, Rackspace6, andGoGrid7.

The cloud computing paradigm is gaining a lot of popularity throughout the researchcommunity and all these three delivery models. It is influencing the development ofInformation Technology and changing the way that vendors, providers and end-usersview computation. As a matter of fact, cloud computing makes software available as aservice over the Internet and has changed the way in which hardware is designed andpurchased.

1http://www.google.com/intl/en/enterprise/apps2http://www.salesforce.com3http://appengine.google.com/4http://www.windowsazure.com5http://aws.amazon.com6http://www.rackspace.com/7http://www.gogrid.com/

2

Page 21: Monext: An Accounting Framework for Federated Clouds

1.1. MOTIVATION

Amazon started to sell cloud computing services in 2006, giving birth to the AmazonWeb Services (AWS). AWS allowed individuals and enterprises to utilize Amazon’s net-work architecture and software expertise to quickly and easily host their own applicationsand services on Amazon’s hardware. Quickly, many prominent information technology(IT) companies followed suit. Some immediately differentiated themselves as high-levelniche 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 generalactivity is important for business and commercial purposes, and in recent years, it hasbeen applied to cloud computing scenario. A cloud provider charges a customer a fee forthe usage of a certain service. The fee can be based on hardware, storage, or network, forinstance, 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 disserta-tion. 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.4gives an overview of the contributions of this research, and finally, Section 1.5 describeshow this dissertation is organized.

1.1 Motivation

Cloud services are usually sold on demand through a pay-as-you-go model: The customeronly pays for what is used and no more (Narayan et al., 2012). However, behind thisgeneral structure, various other factors influence the final price. The cloud accounting fieldencompasses 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 (Buyyaet al., 2010; RESERVOIR, 2012). A federated cloud allows a provider to dynamicallyoutsource resources to other providers in response to demand variations. This complexmechanism increases the capacity of a group of data centers. They partner with eachother because no single cloud provider has the necessary infrastructure. They may preferto construct a federated cloud infrastructure mixing multiple public and private clouds toprovide better support. This requirement often arises in enterprises with global operations

3

Page 22: Monext: An Accounting Framework for Federated Clouds

1.2. PROBLEM STATEMENT

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. Suchevolution aims at provisioning services across different cloud providers, considering inparticular, among others, the accounting requirement.

According to Celesti et al. (2010), the federated cloud area is considered a trend forthe 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 Celesti’s forecast and real-life commercialsolutions such as ComputeNext8, ScaleUp9 and RightScale10 which aggregate differentproviders. This development encouraged us to study this subject more in depth, andwe 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 require-ment; that is, they do not have a proper accounting system to charge for their provisionedresources.

1.2 Problem Statement

The problem statement of this dissertation is formulated as:There are some federated cloud platforms that does not provide

accounting services. This work proposes an accounting framework tocharge computing resources from federated cloud platforms.

In order to achieve this goal, a systematic mapping study (Chapter 2) was conductedto collect information needed to guide the framework construction. A systematic mappingstudy provides an overview of a research area and identifies the quantity and type ofresearch and results available within it (Petersen et al., 2008). In Chapter 4, we validated

8http://www.computenext.com/9http://www.scaleupCloud.com/scaleup-solutions/federated-Cloud/

10http://www.rightscale.com/

4

Page 23: Monext: An Accounting Framework for Federated Clouds

1.3. OUT OF SCOPE

the framework with a real federated cloud platform developed by a consortium of BrazilianUniversities.

1.3 Out of Scope

Some subjects were excluded from the scope of this project.

• SaaS and PaaS - SaaS and PaaS are not covered in this dissertation, althoughthe mapping study provides evidence for charging metrics for any type of cloudservice. We identified and focused on the need for an accounting solution for cloudcomputing in federated cloud platforms which address only IaaS.

• Resource Cost Management - Samimi and Patel (2011) state that advanced strate-gies regarding pricing and cost tariff specification optimizes return on investment.Cloud computing faces several major challenges in this area, including electricalpower and human resources mensuration. However, the framework proposed bythis work does not calculate or recommend a price to be applied for purchasedresources, because the entire infrastructure must be well known first.

• Security - Some factors related to security were not covered by the framework,such as cryptography and secure data transfer of usage records (consumptionof information by the customer) due to the high level of access and processing.Similarly, we needed real-time monitoring of consumption and bureaucracy in datatransfer, which would require lowering the speed of that activity.

• Anomaly Detector Mechanism - An anomaly is the occurrence of somethingunexpected, different than specified in the SLA. The research does include thefunctionality of compensations due to SLA violations, such as problems or delaysto access to resources. However, the mechanism which captures such anomalieswas developed by a group of researchers from the JiTCloud project (Costa et al.,2010).

1.4 Statements of the Contributions

The research presented in this dissertation makes the following contributions:

• A mapping study of state-of-the-art on cloud accounting that provides better under-standing of the main trends, gaps, and challenges in this area;

5

Page 24: Monext: An Accounting Framework for Federated Clouds

1.5. DISSERTATION STRUCTURE

• An accounting framework for federated cloud; and

• The definition, planning, operation and interpretation of an experimental study inorder to evaluate the proposed solution.

1.5 Dissertation Structure

The remainder of this dissertation is organized as follows: Chapter 2 presents a mappingstudy in order to investigate the state-of-the-art of accounting models for cloud comput-ing, synthesize available evidence to suggest important implications for practice, as wellas identifying research trends, open issues, and areas for improvement; Chapter 3 de-scribes the proposed framework, including its architecture details and a Domain SpecificLanguage for charging policy specification; Chapter 4 presents the Experimental Studyperformed under the JiTCloud platform; and Chapter 5 provides a set of conclusionsdiscussing our contributions and outline directions for future work.

6

Page 25: Monext: An Accounting Framework for Federated Clouds

2Systematic Mapping Study on Cloud

Accounting

Would you like me to give you a formula for success? It’s 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 onlyfor the capacity that they actually use. In this context, cloud providers have their ownaccounting models including their specific billing mechanisms. Thus, it is important tostudy this heterogeneity aiming to map out the existing cloud accounting solutions tobecome possible new proposals.

This Chapter presents a systematic mapping study. It conducted four research ques-tions, evidencing 580 studies. It applied a formal investigation analysis which highlighted23 papers. Such research focused on three inherent issues to cloud accounting: accountingmodels, pricing schemes and SLA structure. The mapping results can help to under-stand the cloud accounting constraints by identifying points that still require additionalinvestigation, since important aspects regarding particular issues have not been addressedyet.

2.1 Introduction

Cloud computing has become an established paradigm for running services on externalinfrastructure, where virtually unlimited capacity can be dynamically allocated. Howeverthis unlimited aspect may become expensive, and research projects have tried to mitigate

7

Page 26: Monext: An Accounting Framework for Federated Clouds

2.1. INTRODUCTION

it through the development of new architectures, exploring different accounting models(Ruiz-Agundez et al., 2011; Elmroth et al., 2009; Pandey et al., 2009; Park et al., 2012).

Accounting in cloud computing is a recent discipline, hence there have been a fewattempts to find a model which considers all the accounting requirements, and no workhas tried to address a mapping of the existing accounting models to identify research gapsand encourage future proposals presenting, for example, a standardized taxonomy.

In this context, this chapter presents a systematic mapping study (Petersen et al.,2008) conducted from August to December in 2011. It studied the cloud accounting field,synthesizing evidence to suggest important implications for practice, as well as identifyingresearch trends, open issues, and areas for improvement. It addressed accounting modelsfor cloud computing and other aspects related also to grid computing.

A Mapping Study, according to Petersen et al. (2008) is an evidence-based approachto provide an overview of a research area, and identify research details available within it.The results are gained from a defined approach to find, assess and aggregate the outcomesfrom relevant studies. Thus, it provides a balanced and objective summary of the relevantevidence. Hence, the goal of this investigation is to identify, evaluate, and synthesizestate-of-the-art on the cloud accounting area to present what has been achieved so far.

We considered in our studies the grid computing research field, mainly due to threeconsiderations. The first point is the correlated aspects between cloud and grid computing.The second point is the older grid origin with probable relevant contributions. As finalreason, the existing mature accounting models under this research area.

In Gohner (2006), the authors perform a comparison between the six most knownaccounting systems in grid computing. They evidenced advantages and disadvantageswhereas allowing to realise what aspects the grid accounting systems have in common.First, they use a proper taxonomy to describe their functions which make part of anaccounting process (a set of operations that manages the data regarding the use ofthe resources (Ruiz-Agundez et al., 2010b)). Next, they present a measurement unitmechanism to apply under the resource consumption and accordingly charge for it,called pricing scheme (Caracas and Altmann, 2007). Finally, all of them worry aboutQoS Requirements and explore how to monitor this Quality of Service. In some casesestablishing SLA.

Based on Gohner (2006) considerations and a previous literature investigation, fourresearch questions were derived to guide this Mapping Study, as follows:

• RQ1: Is there any taxonomy for concepts related to accounting process in cloudcomputing?

8

Page 27: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

• 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/gridcomputing scenario?

The remainder of this chapter is structured as follows: Section 2.2 presents thesystematic 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; Section2.5 introduces some threats to validity; Section 2.6 discusses the results; Finally, Section2.7 presents a summary of the chapter.

2.2 Literature Review Method

While a Systematic Review is a mean of identifying, evaluating and interpreting allavailable research relevant to a particular question (Kitchenham and Charters, 2007), aMS intends to ‘map out’ the research undertaken (Budgen et al., 2008; Petersen et al.,2008). A well organized set of good practices and procedures for undertaking MS isdefined in Budgen et al. (2008); Petersen et al. (2008). It establishes the base for this MS.The importance and use of MS in the computer science area is observed in several studies(Afzal et al., 2008; Bailey et al., 2007; Budgen et al., 2008; Condori-Fernandez et al.,2009; Kitchenham, 2010; Petersen et al., 2008; Pretorius and Budgen, 2008), showingthe relevance and potential of the method.

A MS comprises the analysis of primary studies that investigate aspects related topredefined research questions. It aims at integrating and synthesizing evidence to supportor refute particular research hypotheses. The main reasons to perform a MS can be statedas follows, as defined by (Budgen et al., 2008):

• To make an unbiased assessment of as many studies as possible, identifying existinggaps in current research and contributing to the research community with thereliable synthesis of the data;

• To provide a systematic procedure for identifying the nature and extent of theempirical study data that is available to answer research questions;

• To map out the research that has been undertaken;

9

Page 28: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

• 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 Figure2.1 is composed of five steps with specific outcomes and each phase is discussed in thenext sections (Definition of Research Questions, Conducting Search, Screening of Papers,Keywording and Data Extraction).

Figure 2.1 Systematic Mapping Process Petersen et al. (2008)

2.2.1 Definition of Research Questions

As previously stated, the objective of this study is to understand, characterize and summa-rize evidences, identifying issues regarding cloud accounting field aiming to substantiateour project decisions. Thus, four research questions were derived from the objective ofthe study. The research questions, and the rationale for their inclusion, are detailed below.

• RQ1: Is there any taxonomy for concepts related to accounting process incloud 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 specificusage of a service. The accounting process have to be disambiguated, employing aprecise terminology and splitting all the functions involved. The objective of thisquestion 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 whichconsider both, engineering and economic aspects. It is essential to dimension

10

Page 29: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

the provider infrastructure, make statistical analysis of the usages, among otheractivities (Ernemann et al., 2002). The aim of this research question is to elucidatethe existing accounting models on cloud computing, and this way looking fordifferent 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 acommon form of currency (Mihailescu and Teo, 2010a). Pricing schemes representthe business interface between the provider and the customer. They are used toachieve different objectives such as maximizing profit, maximizing social welfare,or defining certain schemes of fairness. A pricing scheme presents the unit oftrade 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 whichpricing schemes exist since every accounting model must implement it somehow.

• RQ4: What are the aspects taken into account to compose a SLA in cloud/gridcomputing scenario?

Cloud providers supply clients with services and must meet their constraints.They both need to negotiate the client’s request and the provider’s infrastructurecapabilities agreeing to certain conditions. This agreement is known as ServiceLevel Agreement (SLA), and it is what the provider conforms to deliver the clientwith what he needs (Lindner et al., 2011). According to Sahai et al. (2001), SLAformalization is a challenged task mainly in terms of precision. In addition it wasobserved a wide adoption of SLA in grid computing area. Therefore, this questionaims 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 orbrowsing manually through relevant conference proceedings or journal publications. Thestrategy used to construct the search terms follows the same approach used in Kitchenhamet al. (2007), since it is systematized in essence and defines steps to derive the searchstrings 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

Page 30: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

• Identify, by inquiries with experts in the field and/or subject librarians, alternativespellings 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 StringSLA OR “Service Level Agreement” OR billing ORpricing OR payment OR accounting AND “cloudcomputing” OR “grid computing” OR “Infrastruc-ture as a Service” OR “Platform as a Service” OR“Software as a Service”

Firstly, an automatic search was conducted in different search engines (IEEEXplore,ACM Digital Library, Scopus and ScienceDirect digital databases). It is important to bementioned that all search strings were calibrated regarding to each search engine. Next, amanual search was performed by visiting two high classified periodic journals accordingto the Brazilian institution CAPES1 (Coordination for the Improvement of Higher LevelPersonnel): Journal Concurrency and Computation; and Journal of Supercomputing. Asa result from the application of both search strategies 580 studies were collected. Theresult is shown in Figure 2.2.

Figure 2.2 N. of Papers X Search Engines.

2.2.3 Screening of Papers

As the first conducted search includes repeated and low relevant work, filters are necessarysince only unique and relevant primary studies must be included. At this point, the studieswere considered according to Inclusion and Exclusion Criteria.

1http://www.capes.gov.br/avaliacao/qualis

12

Page 31: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

The former, includes:

• Research that explores a taxonomy for accounting process in cloud computingcontext;

• Research that proposes accounting models directed to cloud computing;

• Research that provides concepts about pricing schemes in cloud/grid computing;and

• Research related to SLA’s composition in cloud/grid computing.

The latter, excludes the studies which:

• Studies did not address or just mentioned accounting models/processes, pricingschemes, SLA composition on cloud/grid computing;

• Studies only available as abstracts or presentations; and

• Duplicate studies. When a study has been published in more than one publication,the most complete version will be considered.

Figure 2.3 illustrates such screening process. The exclusion criteria were appliedto the title and abstract of the identified studies, resulting in 98 studies being selected.The large amount of duplicated studies contributed to this significant difference. Next, asecond filter was applied, analysing the introduction and conclusion remaining 23 primarystudies. Table 2.2 presents a list with the 23 papers.

Figure 2.3 Filters of the screening process.

Kitchenham et al. (2004) advocates the use of study quality assessment to removethe effect of low-quality studies on results. However, given the small number of primary

13

Page 32: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

studies we did not wish to exclude papers based on their quality. This phenomenon wasalso acknowledged by Staples and Niazi (2007), who found the strict guidelines to be toorestrictive in the study quality assessment.

Table 2.2: Primary Studies

Code Primary Study Reference

PS01 A Framework for SLA-based Cloud services verification and composition Falasi and Serhani (2011)

PS02 Conceptual SLA framework for Cloud Computing Alhamad et al. (2010)

PS03 A Service-oriented accounting architecture on the Grid Yu et al. (2004)

PS04 THEMIS: Towards Mutually Verifiable Billing Transactions in the Cloud

Computing Environment

Park et al. (2012)

PS05 Authentication and Billing Framework for Service Oriented Architecture Pandey et al. (2009)

PS06 Accounting and Billing for Federated Cloud Infrastructures Elmroth et al. (2009)

PS07 A pricing information service for Grid computing Caracas and Altmann

(2007)

PS08 SLA-driven Elastic Cloud Hosting Provider Comellas et al. (2010)

PS09 The economy of parallel and distributed computing in the Cloud Jai (2011)

PS10 Pricing strategies of software vendors Lehmann and Buxmann

(2009)

PS11 On Economic and Computational-Efficient Resource Pricing in Large

Distributed Systems

Mihailescu and Teo

(2010b)

PS12 Dynamic Resource Pricing on Federated Clouds Mihailescu and Teo

(2010a)

PS13 Accounting, pricing and charging service models for a GUISET Grid-based

service provisioning environment

Buthelezi et al. (2008)

PS14 A Flexible Accounting Model for Cloud Computing Ruiz-Agundez et al.

(2011)

PS15 An economy-based accounting infrastructure for the dataGrid Piro et al. (2003)

PS16 Agent-based simulations of the software market under different pricing schemes

for software-as-a-service and perpetual software

Rohitratana and Altmann

(2010)

PS17 Specifying and monitoring guarantees in commercial Grids through SLA Sahai et al. (2003)

PS18 Review of pricing models for Grid and Cloud Computing Samimi and Patel (2011)

PS19 Competitive Pricing Model for Resource Scheduling in Grid Computing Song et al. (2007)

14

Page 33: Monext: An Accounting Framework for Federated Clouds

2.2. LITERATURE REVIEW METHOD

PS20 A Taxonomy of the Future Internet Accounting Process Ruiz-Agundez et al.

(2010b)

PS21 Economic models for resource management and scheduling in Grid computing Ernemann et al. (2002)

PS22 Debunking Real-Time Pricing in Cloud Computing Wee (2011)

PS23 The Cloud Supply Chain: A Framework for Information, Monitoring,

Accounting and Billing

Lindner et al. (2011)

2.2.4 Keywording

A classification scheme is a mechanism composed by a set of categories used to classifythe primary studies such a way it extract detailed information and identify research gaps.Aiming to build our classification scheme we based on the systematic process proposedby Petersen et al. (2008) called keywording.

Keywording is a way to reduce the time needed in developing the classificationscheme and ensuring that the scheme takes the existing studies into account. Keywordingis done in two steps. First, the reviewers read abstracts and look for keywords andconcepts that reflects the contribution of the paper. While doing so the reviewer alsoidentifies the context of the research. When this is done, the set of keywords fromdifferent papers are combined together to develop a high level understanding about thenature and contribution of the research. This helps the reviewers come up with a set ofcategories which is representative of the underlying population. When abstracts are toopoor in quality, reviewers can choose to study also the introduction or conclusion sectionsof the paper. When a final set of keywords has been chosen, they can be clustered andused to form the categories for the map (Petersen et al., 2008). This way, three differentfacets were used, namely following:

• Contribution Type: Method, Process, Technique, Model and Framework (Freitaset al., 2011);

• Accounting Model Features: Pricing, Metering, Mediation, Accounting, Roam-ing, Billing, Charging, Financial Clearing, Just in Time Clouds, SLA Support,Multiple Payment Models, Charging Policy Language and Resource as a Service;

• Research Type: Validation Research, Evaluation Research, Solution Proposal,Philosophical Papers, Opinion Papers, and Experience Papers (Wieringa et al.,2005) (see definitions in Table 2.3).

15

Page 34: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Table 2.3 Research Type Facet (Wieringa et al., 2005)Class Description

Validation

Research

Techniques investigated are novel and have not yet been implemented in practice. Techniques used are for

example experiments, i.e., work done in the lab.

Evaluation

Research

Techniques are implemented in practice and an evaluation of the technique is conducted. That means, it is

shown how the technique is implemented in practice (solution implementation) and what are the

consequences of the implementation in terms of benefits and drawbacks (implementation evaluation). This

also includes identification of problems in industry.

Solution

Proposal

A solution for a problem is proposed, the solution can be either novel or a significant extension of an

existing technique. The potential benefits and the applicability of the solution is shown by a small example

or a good line of argumentation.

Philosophical

Papers

These papers sketch a new way of looking at existing things by structuring the field inform of a taxonomy

or conceptual framework.

Opinion PapersThese papers express the opinion of somebody whether a certain technique is good or bad, or how things

should been done. They do not rely on related work and research methodologies.

Experience

Papers

Experience papers explain what and how something has been done in practice. It has to be the personal

experience of the author.

2.2.5 Data Extraction

A data extraction form was designed to gather the required information and address theobjectives of this study. In this step we read the primary studies carefully and extractedtwo information: the (i) research categorization (Contribution Type, Accounting ModelFeatures 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 positioninside the paper which answered some of the four research questions.

The analysis of the results focused on presenting the frequencies of publications foreach category. This makes it possible to see which categories have been emphasized inpast 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 thesake 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

Page 35: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

their respective codes can be seen in Table 2.2.

2.3.1 RQ1 - Is there any taxonomy for concepts related to account-ing process in cloud computing?

In our research only one primary study effectively answered this question. The studyPS20 presents a taxonomy of full accounting process and its functions from the resourceusage to the financial clearing. It is not applied only to cloud computing, but other areasrelated to services on the internet. The accounting functions are presented in Table 2.4.

Table 2.4: Taxonomy of Accounting Process (Ruiz-Agundezet al., 2010b)

Concept Function

Pricing 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

Clearing

Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,

this function implies the payment of a bill.

The process flow is expressed by Figure 2.4. First, resource usages (also calledmetering records) are registered by the Metering function. Afterwards, the Mediation

function intercedes by treating the raw data and sending accounting records for theAccounting function (it is important to highlight that accounting process means the wholeprocess and the accounting function refers to one step of accounting process). TheAccounting creates session records, which are an appropriate format to be used by thefunctions Charging, Pricing and Roaming. The Pricing function generates a formuladefining how to price the session records. The Charging function generates monetaryinformation called charging records to be aggregated later by the Billing function. There,

17

Page 36: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

the final bill is generated and sent to the Financial Clearing function (Ruiz-Agundezet al., 2010b).

Figure 2.4 Accounting Process (Ruiz-Agundez et al., 2010b)

Although it was found only this taxonomy formally defined, other terms are used withsimilar meanings. For example, monitoring has the same sense of metering. Accordingto Lindner et al. (2011) the metrics generated by the monitoring function can be usedboth 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 usageinformation as raw data.

2.3.2 RQ2 - What are the existing accounting models for cloud com-puting?

When performing the analysis, five primary studies were found (PS14, PS06, PS05, PS04and PS23) that proposed some kind of accounting model, summarized following:

1) Flexible Accounting Model (PS14) - This paper proposes a flexible accountingmodel suitable for any service of cloud computing. This model is based on the accountingprocess of the Internet identified by RQ1 (Ruiz-Agundez et al., 2010b) and uses basicallytwo 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. Consideringthe accounting process proposed by Ruiz-Agundez et al. (2010b) it encompasses mainlythe financial clearing function. According to this primary study, the jBilling platformenabled the operators to apply different pricing schemes (e.g. usage-based, volume-based,

18

Page 37: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

time-based, flat-rate, quality-of-service-based, etc.). However, it was not exposed how tochoose and apply these pricing schemes in a flexible way.

In other hand, the IPDR was used as a standardized format to exchange the usagerecords between IP networks, hosting elements and operations or business support sys-tems. Thus, it provides a standardised framework that enables network and serviceaccounting comprehensively. This standard is designed to enable cost-effective usagemeasurement (Ruiz-Agundez et al., 2011).

Figure 2.5 shows the IPDR reference model. The user consumes a service and themetering function collects these records in IPDR format through the IPDR Recorder.These records can be stored or transmitted to the business support system by the mediationfunction using the IPDR Transmitter. The rest of the accounting process functions areallocated in the business support system, similar to other functions such as user man-agement, report generation, fraud management, error management or network elementsconfiguration (Ruiz-Agundez et al., 2011).

Figure 2.5 IPDR reference model (Ruiz-Agundez et al., 2011)

2) A Model for Federated Clouds (PS06) - This primary study presents a solutionfor an accounting and billing architecture for use in federated cloud environments and builtby an European Cloud project called RESERVOIR (funded by the European Union). Theidea of federated cloud is that a single entity serves as a gateway to different independentsolutions, and this is one way to solve the limited interoperability, as different technologiescan be unified and abstracted towards the consumers.

The model is organized in layers (Accounting, Billing and Business Layer). TheAccounting Layer, focused on collecting and managing the data which componentsin the Billing Layer use as their input. The Business Layer forms a link between the

19

Page 38: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

technical system and the Service Provider in terms of, e.g., pricing, invoicing, and servicemanagement. An overview of the different layers and their components can be seen inFigure 2.6.

Figure 2.6 Architecture in Layers for Accounting and Billing within the RESERVOIR ServiceManager. (Elmroth et al., 2009)

The Figure 2.6 shows the main components of the suggested architecture. It includesthe connectors indicating the main interactions between components. Components with adashed border in the figure handle the communication with other parts of the RESERVOIRsystem. As this dissertation focuses on the accounting and billing aspects, only theseparts are following explained in more detail.

The accounting layer is responsible for the interaction with the surrounding infrastruc-ture. It collects usage records and SLA violations from other components. The primarycomponent is the SM Accounting Manager (SMAM) that together with the underlyingAccounting Database (ADB) offers persistent storage and management of usage recordsand violations. The SMAM is supplied with data regarding SLA violations from the SLAViolation Assessment component, and these SLA violations are taken into account bycomponents at the Billing layer. Similarly, the VEEM Accounting Manager (VAM) isresponsible 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-paidengine, supported by the Service Configuration Analyzer (SCA) and the Service Life-cycle Manager (SLM) that are part of both the business and billing layers. SCA isresponsible for validating the deployment of services and generate unique identifiers forthese particular services. This identifier is referred to as the Accounting, Billing, and

20

Page 39: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Compensation(ABC) identifier, and all usage records and SLA violation concerning thisservice will contain such identifier. Using this approach, it is possible to address allservices without knowing where they are running or how many they are. Finally, theSLM monitors the consumed services while it communicates with pre-paid engine toprobably break off the provisioning when the pre-paid credits exceeds.

Another contribution of the RESERVOIR project in the accounting field is related toa kind of guide which dictates what characteristics an accounting system must be basedin. They outlined usage scenarios with challenges that are typical for federated cloudsand derived eight principles listed following:

• Location Unawareness: Account for the VMs as a service, running locally orremotely no matter where it is running.

• Flexible Data Format: It should be possible to include additional usage informa-tion metrics.

• Service Elasticity: The number of VMs underlying and fulfilling a service canscale due to service elasticity. The accounting system must be designed to handlesuch scenario.

• Service Accounting: The accounting system must be suitable for long runningservices, and not limited to tasks with a limited execution time.

• Compensations: Both usage and compensations (due to breaking SLAs) must beaccounted for.

• Service Billing: Billing must be managed on a per service basis and not just foreach VM.

• Adaptable Design: The accounting system must be open for modifications to copewith future changes and enhancements.

• Complex Pricing: The function that calculates prices from the accounting infor-mation must be able to incorporate complex pricing rules.

3) ABS for SOA (PS05) - This primary study presents an accounting model focusedon Software as a Service (SaaS) provisioning. Mainly the functions authentication of theclients and billing of services are carried out.

Models proposed by different researchers earlier used different servers for billing andsecurity (Authentication and Authorization). This needs more running and maintenancecost. Moreover high level of synchronization is also needed so that same entries are

21

Page 40: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

processed on both servers simultaneously. Also two different databases have to be run onboth servers.

In this context, they have integrated both the server’s functionalities in a single servercalled ABS (Authentication and Billing server) which is capable of performing certainfunctions:

• Authentication and Authorization of user;

• Communicates with the Application server for generating service instances forparticular users, and provides user the direct address of the instance.(user does notneed to contact the application server);

• This instance is generated for a particular time period ordered by user. Billing isdone on the basis of this time period.

4) THEMIS (PS04) - This model proposed a mutually (provider and user) verifiablebilling system called THEMIS to cloud computing scenario. It has as main requirementsthe transparency, security and low latency in billing transactions.

The system introduces the concept of a Cloud Notary Authority to supervise billingtransactions, 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 toresolve future disputes between a user and a cloud service provider.

Figure 2.7 shows the overall architecture THEMIS billing infrastructure, highlightingthe major components of the architecture (Cloud Service Provider (CSP), Users andCloud Notary Authority (CNA)):

• Cloud Service Provider (CSP): The CSP enables users to scale their capacityupwards or downwards in accordance with their computing requirements and topay only for the capacity that they actually use.

• Users: They assume that users are thin clients who use services in the cloudcomputing environment. To use services in such an environment, each user makesa request to the CSP with a billing transaction.

• Cloud Notary Authority (CNA): The cloud notary authority provides a mutuallyverifiable integrity mechanism to combat the malicious behaviour of users or theCSP. The cloud notary authority investigates billing transactions and generatesmutually verifiable binding information

22

Page 41: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Figure 2.7 Overall architecture and process flow of THEMIS

5) Cloud Supply Chain (PS23) - This model proposes the Cloud Supply Chain

concept, which represents a network of interconnected businesses in the cloud computingarea. It involves end-to-end provision of services required by the end customers. Thedelivered product is along the way enriched and in parallel the functions supportingmonitoring, accounting and billing are performed.

Although this primary study focus on how IaaS Providers improve their services in asupply chain, it proposes a architecture directed to collect and aggregate multiple usagerecords and Key Performance Indicators (KPI).

This model distinguishes the concepts of producers and consumers. Producers collectmonitoring data from the overall environment, in the form of usage measurements. Thisis achieved typically via software probes, which provide the necessary mechanisms tointeract with the infrastructure or service, formulating for example appropriate querieson a regular basis. This measurement data can come from numerous sources; this maybe raw data gathered from probes in the underlying infrastructure, data gathered fromprobes embedded in the application, data which is the combination of the raw data intocomposed KPIs, or data derived from the analysis of historical raw data and KPI data heldin a data store. Consumers on the other hand will read the monitoring data and will enactsome form of action, depending on the rules determined by the service or infrastructureprovider. The Figure 2.8 shows the whole structure of the Monitoring data flow.

23

Page 42: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Figure 2.8 Monitoring data flow (Lindner et al., 2011)

In this illustration a single monitoring channel is used to aggregate the measurementsobtained from probes embedded at the service level, within a virtual machine, responsiblefor the allocation and placement of service components on physical resources, or atthe resource layer itself. The central part of the architecture is called Service Manage-ment Module and resides on Infrastructure Provider’s level, composed of the LifecycleManagement, the SLA Protection and the Accounting/Billing functions.

The Lifecycle Management monitors the state of deployed applications. The SLAProtection ensures a particular level of service. The state of the application service mustbe described and exposed in the form of one or more KPIs and enacting resizing actionswhen conditions related to these KPIs are met. Lastly the accounting and billing functionsrequire the collation of measurements into usage records which will summarise the overalllevel of activity of a service provider, and from which it can derive an appropriate measureof usage costs.

2.3.3 RQ3 - What are the existing pricing schemes for cloud or gridcomputing?

A pricing scheme is a measurement unit applied under a resource consumption to becharged (Caracas and Altmann, 2007). However, different terms are used with thesame meaning, as pricing models (Samimi and Patel, 2011) or pricing mechanisms

(Osterwalder, 2004).Although the current cloud computing literature almost without exception considers

pricing of cloud services, the discussion rarely covers more than a mention about usageof pay per use pricing mechanism. However, as Harmon et al. (2009) argue, pricing isone of the most critical decisions that a firm make whether planning the introduction of a

24

Page 43: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

new IT service or repositioning an existing IT service. Weinhardt et al. (2009) argue thata commercial success with cloud services can only be achieved by developing adequatepricing schemes.

Osterwalder (2004) differentiates between three main categories of pricing schemes:Fixed, Differential and Market Pricing. Fixed Pricing mechanisms produce prices thatdo not differentiate in function of customer characteristics, are not volume dependant,and are not based on real-time market conditions. Differential Pricing refers to pricingschemes 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-timemarket conditions. Market Pricing stands for pricing schemes that produce prices basedon 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 computingbrings to IT services business. With pay per use mechanism, capacity units such asnumber of transactions, gigabytes of storage or memory or units per time such gigabytesof memory per hour are associated with resources and assigned fixed price values andcustomer 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 servicesand 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 bechallenging task with cloud services. Denne (2007) discusses various advanced ways toimplement pay per use pricing mechanism.

Denne (2007), Prodan and Ostermann (2009) and Buyya et al. (2009b) discussadvance pricing. In this pricing mechanism, customers prepay for a certain amountof capacity units that have to be consumed usually in a certain period of time andovercharging is applied if the customer exceeds the quota of prepaid units.

Youseff et al. (2008) and Weinhardt et al. (2009) discuss subscription pricing incloud and Denne (2007) mentions pricing based on pre-purchase of services. Withsubscription mechanism, customer subscribes (i.e., signs a contract) for using a pre-selected combination of service units with a fixed price for a fixed time period such as amonth. In subscription model, pricing is per unit of time and not per unit of consumption.

2Also known as pay-as-you-use, pay-as-you-go, per-unit pricing, and resource-consumption-basedpricing.

25

Page 44: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Subscription pricing is most used with SaaS services and it allows prediction of customersperiodic 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 ofour investigation the Table 2.5 summarizes all the pricing schemes found with theirrespective concepts and in which study they were discussed. Despite this heterogeneousnomenclature, it was collected 31 different types of pricing schemes, distributed on10 primary studies (PS14, PS07, PS18, PS09, PS10, PS12, PS15, PS19, PS03 andPS22). 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. WhileAuction 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 Studies

Time-based Pricing based on how long a service is used.PS21, PS14,

PS07

Paris-Metro

pricing

Used for shared resources. Resources are split by the amount of users per split. PS14

Priority pricing Services are labelled and priced according to their priority. PS14

Flat-rate A fixed tariff for a specified amount of time.PS21, PS14,

PS07

Edge pricing Calculation is done based on the distance between the service and the user. PS14

Responsive

pricing

Charging is activated only on service congestion. PS14

Effective

bandwidth

pricing

Charging is based on an expected usage function. PS14

Proportional

fairness pricing

It is according to the user’s willingness to pay, in other words, It is based on the

real value of product or service.

PS10, PS14

Cumulus pricing Based on flat pricing and dynamically priced by using a credit point system. PS14

Session-oriented Based on the use given to the session. PS14

26

Page 45: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

One-off charge

per service

One charge per service session. PS14

Usage-based Pricing based on the general use of the service for a period of time, e.g. a moth.PS07, PS09,

PS14

Content-based Pricing based on the accessed content. PS14

QoS-based Pricing depends on the hired quality of service. PS19, PS14

Location-based Pricing based on the access point of the user. PS14

Service type Pricing based on the usage of the service. PS14

Volume-based Pricing based on the volume of a metric (e.g. downloaded bytes). PS19, PS14

Differentiation

on time-of-day

Pricing based on the hour when the service is used. PS14

Progressive

Co-design

Seller and buyer try to convene on a pricing plan. The seller announces a fixed

price pair (p1, p2), where p1 < p2. Subsequently, the buyer commits a

consumption level quality related to each price announced and if agreed so he

can buy additional units progressively if needed.

PS07

Competitor-

Oriented (CO)

Pricing

At first, the vendor agent needs to select the competitor to compete with. Then,

the vendor simply decreases the price just below of the rival’s price. This

algorithm requires perfect information of the rival’s price.

PS16, PS19,

PS10

Cost-based Following the approach of cost-based pricing, the price level is established

using cost accounting. According to it price determination based on costs can

make good sense for SaaS.

PS10

Supply and

Demand based

In general way the unit price will vary until it settles at a point where the

quantity demanded by consumers (at current price) will equal the quantity

supplied by providers (at current price), resulting in an economic equilibrium of

price and quantity.

PS12, PS03,

PS21, PS22,

PS15, PS16

Real-Time

Pricing (RTP)

Is a pricing model that dynamically changes its rate reacting to the classical

supply and demand rule, but with the difference that there is only one supplier.

Amazon Web Services (AWS) offer a simplified form of this pricing model

called Spot Instances.

PS22

27

Page 46: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Derivative

Follower Model

It’s a kind of supply and demand based model simply adjusts prices by

incrementally increasing or decreasing them until the observed profitability

level falls, then the direction of price adjustment is reversed, thus seeking a

local maximum of profitability.

PS15, PS16

Hybrid Pricing

Model

This model allows a third entity called Price Authority dynamically adjust

prices within static limits to balance the workload on the basis of the queue wait

times of jobs in grid environments.

PS15

Auction based Services are priced in an auction and carried out by a third party, called the

market maker, which collects the bids, selects the winners and computes the

payments.

PS11, PS12,

PS14, PS21

English Auction All bidders are free to increase their bids exceeding other offers. When none of

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.

PS21

First-Price

Sealed-Bid

Auction

Each bidder submits one bid without knowing the others’ bids. The highest

bidder wins the item at the price of his bid.

PS21

Vickrey Each bidder submits one bid without knowing the others’ bids. The highest

bidder wins the item at the price of the second highest bidder.

PS21

Dutch Auction The auctioneer starts with a high bid/price and continuously lowers the price

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.

PS21

Double Auction In the double auction model, buy orders (bids) and sell orders (asks) may be

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.

PS21

2.3.4 RQ4 - What are the aspects taken into account to compose aSLA in cloud/grid computing scenario?

In order for cloud providers supply clients with services that meet their quality constraints,they both need to negotiate the client’s requirements and the provider’s infrastructurecapabilities. It is known as Service Level Agreement (SLA). However, this is not an easytask, according to Jain et al. (1988) there are difficulties to formalize a SLA, such as lack

28

Page 47: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

of flexibility and precision. This way, to compound a SLA it is important to know whichaspects have to be taken into account.

When performing the analysis, few studies explicitly stated the formalization of SLAin cloud/grid computing scenario. However 4 primary studies (PS01, PS02, PS08 andPS17) are complementary. They are summarized following.

1) SLA Description Language (PS01) This primary study introduced a frameworkthat enables dynamic specification and verification of SLAs in the cloud. Its maincontribution to our research is a format of SLA-Description based on XML specificationwhich defines the main Quality of Services (QoS) along with their threshold values agreedupon selection of cloud services. It also defines the period of service provision, the costof using the service, and the possible actions that should be taken if QoS provision isfrequently violated. Below, the Code 2.1 describes an example of SLA according to thisdescription language.

Code 2.1 Example of SLA-Description (Falasi and Serhani, 2011)1 <Cloud WB−name : name>2 < C l a s s : GOLD>3 / / QoS p r o p e r t i e s d e s c r i p t i o n and t h e i r t h r e s h o l d4 <QoS>5 R e p u t a t i o n = 56 RTmin= 8ms / / minimum va lue of r e s p o n s e t ime7 RTmax = 10ms / / maximum va lue of r e s p o n s e t ime8 Cost = "$0.1"

9 Min A v a i l a b i l i t y = 90%10 </QoS>11 </ C l a s s GOLD>12 < C l a s s : SILVER>13 <QoS>14 R e p u t a t i o n = NULL15 RTmin = 15ms / / minimum va lue of r e s p o n s e t ime16 Cost = "$005"

17 Min A v a i l a b i l i t y = 80%18 </QoS>19 </ C l a s s : SILVER>20 . . .21 <Terms >22 The t e r m s d e s c r i b e s t h e n e c e s s a r y a c t i o n s i f t h e QoS i s v i o l a t e d .23 <Terms >24 <Cloud WS−name : name>

The provider can specify three Service Levels: Gold, Platinum and Silver which arecalled 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 and10 milliseconds thresholds. This QoS means that when such limit is exceeded a discountof “$0.1" is assigned to the customer.

29

Page 48: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

2) SLA Metrics x Service Types (PS02) This paper presents the main criteria whichshould be considered at the stage of designing the SLA in cloud computing. In thiswork it‘s proposed a framework which the SLA parameters are specified by metrics.These metrics define how cloud service parameters can be measured and specify valuesof measurable parameters. In the cloud computing architecture, there are four types ofservices 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 ofthe consumers are confused as to which important parameter should be defined inthe hardware part of the SLA. It lists the most important parameters for consumerswho 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 CPU speed for VM

Memory size Cash memory size for VM

Boot time Time for MV to be ready for use

Storage Storage size of data for short or long term of contract

Scale up Maximum of VMs for one user

Scale down Minimum number of VMs for one user

Scale up time Time to increase a specific number of VMs

Scale down time Time to decrease a specific number of VMs

Auto scaling Boolean value for auto scaling feature

Max number can be configured on

physical serverMaximum number of VMs that can be run on individual server

Availability Uptime of service in specific time

Response time Time to complete and receive the process

• (ii) SLA metrics for PaaS: Platform as a Service is a type of cloud computingthat provides all the requirements needed to support application developers indeveloping, evaluating, and delivering applications and software for end users(Hilley, 2009). So, developers using PaaS do not need to download tools orconfigure hardware to complete the developmental tasks. For SLA metrics relatedto PaaS, Table 2.7 defines the main parameters that can be used as basic criteriawhen developers want to negotiate with PaaS providers.

• (iii) SLA metrics for SaaS: Software as a service is a common example of cloudservices if an application is hosted on a cloud platform and infrastructure to provide

30

Page 49: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Table 2.7 SLA metrics for PasS (Alhamad et al., 2010)

Parameter Description

Integration Integration with e-services and other platforms

Scalability Degree of use with large number of online users

Pay as you go billing Charging based on resources or time of service

Environments of deployment Supporting offline and cloud systems

Servers How many servers are used

Browsers Firefox, IExplorer,..

Number of developers How many developers can access to the platform

built-in services for end users of cloud computing (Muller et al., 2009). Goodexamples of SaaS are mail, calendar, and social web sites provided by Google,Yahoo, and Microsoft. Table 2.8 presents the common metrics parameters for SaaSas an example of metrics for this type of cloud service.

Table 2.8 SLA metrics for SaaS (Alhamad et al., 2010)Parameter Description

Reliability Ability to keep operating in most cases

Usability Easy built-in user interfaces

Scalability Using with individual or large organisations

Availability Uptime of software for users in specific time

Customizability Flexible to use with different types of users

• (iv) SLA metrics for Storage as a Service: Online users access their data fromdifferent geographical locations. In the past few years, online storage providerswere unable to maintain large size of data because of the lack of huge space instorage disks, network performance, and data management systems. Now, datastorage service providers such as S3 by Amazon AWS configure large numbers ofstorage hardware and they are able to manage and serve millions of users efficientlywith their method of data transference and ensuring these data are compatible withvarious types of applications. The parameters for data storage service metrics arebasic requirements for negotiation with storage providers. Such parameters arepresented in Table 2.9.

31

Page 50: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

Table 2.9 SLA metrics for Storage as a service (Alhamad et al., 2010)Parameter Description

Geographic Location Availability zones in which data are stored

Scalability Ability to increase or decrease storage space

Storage space Number of units of data storage

Storage billing How the cost of storage is calculated

Security Cryptography for storage and transferring of data, authentication, andauthorization

Privacy How the data will be stored and transferred

Backup How and where images of data are stored

Recovery Ability to recover data in disasters or failures

System throughput Amount of data that can be retrieved from system in specific unit of time

Transferring bandwidth The capacity of communication channels

Data life cycle management Managing data in data centres, and use of network infrastructure

3) SLA Components (PS17) This primary study proposes an unambiguous andflexible language for formalizing SLAs and an architecture for specifying and monitoringSLAs on grid computing scenario. Finally it references a typical SLA formulated by Jainet al. (1988) that includes the following components:

• Purpose: describing the reasons behind the creation of the SLA

• Parties: describes the parties involved in the SLA and their respective roles.

• Validity Period: defines the period of time that the SLA will cover. This isdelimited by start time and end time of the term.

• Scope: defines the services covered in the agreement.

• Restrictions: defines the necessary steps to be taken in order for the requestedservice levels to be provided.

• Service-level objectives: are the levels of service that both the users and theservice providers agree on, and usually include a set of service level indicators,like availability, performance and reliability. Each aspect of the service level, suchas availability, will have a target level to achieve. Service Level objectives haveday-time constraints associated with them, which delineate their validity.

• Service-level indicators: the means by which these levels can be measured. Ser-vice Level Indicators (SLI) are the base level indicators.

• Penalties: spells out what happens in case the service provider under-performs andis unable to meet the objectives in the SLA. If the agreement is with an external

32

Page 51: Monext: An Accounting Framework for Federated Clouds

2.3. MAPPING RESULTS

service provider, the option of terminating the contract in light of unacceptableservice levels should be built in.

• Optional Services: provides for any services that are not normally required by theuser, but might be required as an exception.

• Exclusions: specifies what is not covered in the SLA.

• Administration: describes the processes created in the SLA to meet and measureits objectives

4) SLA Satisfaction Function (PS08) Here, the authors addressed an elastic webhosting provider, namely Cloud Hosting Provider (CHP). It uses outsourcing techniqueto take advantage of IaaS for web applications deployment. Furthermore, they pursuemaximizing the revenue earned by the provider through both the analysis of SLA and theemployment of an economic model.

Therefore, this primary study does not encompasses a specification language forexample, but an economic model to calculate whether a hosting provider earns or losesmoney with a cloud provider service, looking throughout SLA violations and compen-sations. In this context, it defines a set of Economic Variables and a set of Monitoring

Functions to monitor and calculate Revenues.

• Economic Variables

– Price (Prc) is the amount of money that a customer will pay if a providerbrings to completion the SLA Si. It is specified in the same SLA and usuallyhas a predetermined value.

– Penalty (Pen) is the amount of monetary units that the provider must pay tothe client if the accorded SLA Si is violated. It is also specified in the SLAand is a function of diverse parameters.

– Cost of Execution (CoE) is a cost for the web hosting provider for executinga web application with a specified SLA S. In our environment, this cost has tobe split in two prices:

* Cost of Hosting (CoH) is the price of maintaining a local server thathosts a web application with an associated SLA S. It includes its admin-istration, its cooling, the area where it is placed, etc.

* Cost of Outsourcing (CoO) is the total amount of money that we haveto pay for outsourcing the operation of a given web application to athird-party.

33

Page 52: Monext: An Accounting Framework for Federated Clouds

2.4. RESULTS ANALYSIS

• Monitoring Functions

– The SLA Satisfaction Function (SSF(S)) specifies if a SLA Si is fulfilled orit is violated

– The Minimum Violating Response Time (MV RT(S)) determines the mini-mum response time from which a SLA S is violated.

– The Outsourced Virtual Machines (OV M(S)) is the number of virtual ma-chines that we have externalized for running the servers whose contain theweb application with the associated SLA S.

– Revenue (Rvn(S)) is the economic benefit that a provider obtains with theexecution 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 host-ing 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 tabulatedin each category defined in this study. Thus, it is possible to identify what have beenemphasized in past research and determine gaps and opportunities for future research(Petersen et al., 2008).

2.4.1 Research Type Classification

Table 2.10 Research Type ClassificationResearch Type Studies Quantity

Validation

ResearchPS08, PS11, PS12, PS18, PS19,PS03, PS23 7 (30,4%)

Evaluation

ResearchPS04, PS16, PS14, PS21, PS22, PS23 6 (26%)

Solution

ProposalPS01, PS02, PS13, PS06, PS09, PS10, PS05, PS04, PS15, PS17, PS19, PS20 12 (52,1%)

Philosophical

PapersPS07 1 (4,3%)

Opinion Papers - 0 (0%)Experience

Papers- 0 (0%)

34

Page 53: Monext: An Accounting Framework for Federated Clouds

2.4. RESULTS ANALYSIS

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 Section2.2.4 (Keywording).

Opinion and Experience papers are notoriously nonexistent in this field, while anumber of Validation, Evaluation, and, primarily Solution Proposal papers were found.

There is also a need for Philosophical papers, because they lead the creation ofnew ideas. However, another more important point was observed related to EvaluationResearch papers, which concerns techniques implemented in practice mainly in industry;the small quantity of such studies compared to Solution Proposal papers indicates the lowlevel of experimentation in industry.

Certainly, progress has been made in this area, but the accelerated growth in thenumber of cloud providers, as reported by Jeremy (2010), influences the degree of com-petitiveness, causing their proposals not be released into the scientific community. Thissituation encourages us to perform research analyzing and comparing cloud providers’accounting models in practice.

2.4.2 Contribution Type Classification

Table 2.11 shows the contribution type classification scheme. Most of the studies proposeconcrete Models or Frameworks, rather than addressing activities related to accountingfunctions. Few Processes, and Techniques and no Methods were registered. One possibleexplanation may be the observation made earlier about the lack of practical resultsdisclosed by industry. In this case, we can conclude that even small companies publishwhat they did (models and frameworks) but hide the how they did it (processes, techniques,and methods).

Table 2.11 Contribution Type ClassificationContribution Type Studies Quantity

Method - 0 (0%)Process PS01, PS04, PS17, PS20, PS23 5 (21,7%)

Technique PS08 1 (4,3%)Model PS13, PS07, PS06, PS09, PS10, PS15, PS16, PS14, PS17, PS18, PS19,

PS03, PS21, PS23

14 (60,8%)

Framework PS01, PS02, PS07, PS11, PS12, PS05 6 (26%)

35

Page 54: Monext: An Accounting Framework for Federated Clouds

2.4. RESULTS ANALYSIS

2.4.3 Research Types vs. Research Questions

We analyzed the relationship between the research questions and the research types, usinga bubble plot to represent the interconnected frequencies (Figure 2.9). This figure isbasically an x-y scatterplot with bubbles at the intersections of categories. The size ofa bubble represents the number of papers in the pair of categories at that intersection(Petersen et al., 2008).

Figure 2.9 Research type vs. Research questions

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 thatPS20 evolved into the study PS14, classified as Evaluation Research. PS14 proposed aflexible accounting model validated in a real-life scenario, which ensured the taxonomyvalidity.

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 Philosophicalpaper and discussed a general pricing scheme that can define pricing variations for anycomputational element.

Most of the information related to RQ2 (accounting models) comes from papersclassified as Solution papers. Although four papers were classified as Solution proposals,five studies were conducted in an academic or industrial environment (validation andevaluation research), indicating some maturity of accounting models.

Although the majority of studies addressing RQ3 (pricing Schemes) was classifiedas Solution Proposal and Validation Research, the papers did not discuss in detail how

36

Page 55: Monext: An Accounting Framework for Federated Clouds

2.4. RESULTS ANALYSIS

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 canfocus on explaining how the pricing schemes can work in practice.

Similar to RQ1 (accounting taxonomy), few studies relevant to RQ4 (SLA compo-sition) were found. No studies were conducted in an industrial environment, perhapsbecause cloud providers do not publish the specifics of their research and results, asdiscussed in Section 2.4.1.

2.4.4 Accounting Models Classification

The accounting models collected during this research were categorized according to theirfeatures (see Table 2.12). In the left side are stated the five accounting models and theright side the features. If the model attends the feature, then a X is positioned.

Table 2.12 Accounting Models Classification

Studies Feat

ures

Pric

ing

Met

erin

gM

edia

tion

Acc

ount

ing

Roa

min

gB

illin

gC

harg

ing

Fina

ncia

lCle

arin

gSL

ASu

ppor

tM

ultip

lePa

ymen

tMod

els

Mul

tiple

Cha

rgin

gPo

licy

Spec

ifica

tion

Res

ourc

eas

aSe

rvic

e

PS14 X X X X X X X X X

PS06 X X X

PS05 X X

PS04 X

PS23 X X X X X

First, we used the taxonomy proposed by Ruiz-Agundez et al. (2010b) to determinewhat functions the proposed models served. The terms “pricing," “accounting," and“billing" appeared in more than one paper and carried the same meanings, a homogeneitywhich indicates a certain taxonomy validity. Two findings relevant to “accounting"

37

Page 56: Monext: An Accounting Framework for Federated Clouds

2.4. RESULTS ANALYSIS

deserve attention:

• In PS14, the authors disambiguated the expressions “accounting process" and“accounting function." “Accounting process" refers to a meta-concept that includesall taxonomy functions, while “accounting function" is related to recording andsummarizing technical data in terms of money, transactions, and events.

• In PS23, the accounting and billing functions are grouped as integrated sub-processes 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 commonlyused this term before cloud computing became a research trend.

Interactive systems increase the usability of applications by providing a convenientaccess and allowing the user to spend less time learning how to use the applicationand more quickly produce results. The graphical user-interface achieves this usability(Bencomo et al., 1997). In this context, the Graphical User Interface Support wasanalyzed in order to investigate whether the accounting models offered some type ofgraphical user interface which could bring usability to access the accounting system. Wenoted that some proposed models possess a user interface that gives access control tomanaging accounting mechanisms, but not all did so; only 40% had a final graphical useror 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 Figure2.9 did not indicate which accounting models provided such support. Thus, we verifiedfeatures such as SLA monitoring or whether the customer could choose their desiredservice quality, and found that 80% offered such features. Therefore, SLA support hasbeen shown to be a relevant topic of interest in cloud accounting.

We initially planned to include the term “monitoring;" however, the term “SLAsupport" was preferred because it is a less ambiguous concept. According to Lindneret 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 conceptof key performance indicators, from a SLA point of view.

The accounting model proposed by Ruiz-Agundez et al. (2011) explored the re-quirement of flexibility in usage records and exchanges between heterogeneous networkcomponents. In other research, (Henzinger et al., 2010) examine flexibility in the pricingmodel for the user and cloud provider. Accordingly, the users must be presented with a

38

Page 57: Monext: An Accounting Framework for Federated Clouds

2.5. THREATS TO VALIDITY

pricing model that offers flexibility as a requirement, such as a choice between differentexecution speeds. For the cloud provider, it must present a programming model that offersflexibility in execution, such as a choice between different scheduling policies. Finally,Elmroth et al. (2009) claim that an accounting model must allow changing metrics, forexample, to easily record the metric “database transactions per second".

Considering these aspects related to flexibility in cloud accounting models, we iden-tified more two features which could be used to analyze the five accounting models:Multiple Payment Model and a Multiple Charging Policy Specification. First, weinvestigated whether the models were prepared to support different payment models, suchas the pre-paid, post-paid, and hybrid models. These models are in no way unique tocloud computing but, to the contrary, are well known to consumers after being used foryears 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, withresource consumption based on previous purchased credits (pre-paid) (PS06 and PS23).We included the flexible charging policy specification and aimed to learn whether theproposed solutions utilized a mechanism that could enable the provider to easily specifycharging policies through, for example, a language. As presented in Table 2.12, none ofthe models include this feature.

According to Ben-Yehuda et al. (2012), over the next few years, a new model ofbuying and selling cloud computing resources will evolve. Instead of providers exclusivelyselling server equivalent virtual machines for relatively long periods of time (as donein today’s IaaS Clouds), providers will increasingly sell individual resources (such asCPU, 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 policyspecification feature, none of the models applied this model.

In summary, among the analyzed features, only the SLA Support and Billing Func-tion were offered by more than 50% of the accounting models.

2.5 Threats to Validity

There are some threats to the validity of our study.

• Research Questions: The research questions we formulated cannot cover all ofthe accounting field related to cloud and grid computing. For example, we did not

39

Page 58: Monext: An Accounting Framework for Federated Clouds

2.6. DISCUSSION

cover payment models (pre- and post-paid), but we had several discussions withproject members (me and the advisor) to validate the questions.

• Publication Bias: We cannot guarantee that all relevant studies were selected. It ispossible that some relevant studies were not chosen during the search process. Wemitigated this threat as much as possible by following references in the relevantstudies.

• Data Extraction: The studies were classified based on our judgement; however,some studies could have been classified incorrectly. To mitigate this threat, morethan one researcher performed the classification.

• Grid Computing Inclusion: Although this study’s main focus is cloud computing,we also included grid computing. We included it in two questions (RQ03 andRQ04), aiming to increase the possibility of finding relevant results for cloudcomputing. However, it is possible that some findings related to grid computingare not well applicable in cloud scenarios, because we did conduct experiments toassess the applicability but, instead, held several discussions with project membersto mitigate this problem.

2.6 Discussion

This systematic mapping study enabled us to analyze the cloud accounting field fromseveral perspectives. The chosen points of investigation yielded a variety of informationrelevant to different types of cloud accounting solutions. We believe that this mappingstudy generated state-of-the-art information about the main issues, because the studiedsubject can be understood through the answers returned for the four research questions.The relevant knowledge was obtained, because these questions were based on previousresearch into both cloud and grid computing, increasing the reliability of the scope ofresearch. This section discusses these four research questions, the classification appliedin the primary studies, and what we can draw from it.

The first question was necessary, because we noticed a wide divergence in nomencla-tures even in the early stages of research. Although we found only one taxonomy and onerespective accounting process, it was highly robust, based on 36 other studies. Despitebeing suitable for use in cloud computing, it was designed to be applied to “the FutureInternet," a generic and broad concept. We recommend that everyone who desires to usethis accounting process should consider adapting it before use it by adding or removing

40

Page 59: Monext: An Accounting Framework for Federated Clouds

2.6. DISCUSSION

functions; for example, the roaming function makes no sense if there is only one serviceprovider.

In the second question, when we searched for accounting models we hoped to finda significant number of solutions, but identified only five. We tried to extract the mainfeatures of these account models and ultimately found a couple of limitations whichmotivated us to analyze more closely the models’ peculiarities in order to identify researchopportunities.

The third question considered a broad picture of the 31 types of compiled pricingschemes. However, it is important to note that they include schemes for both cloud andgrid computing, and no distinction was made between these types because our primarygoal was to map all of the pricing schemes. Although we have condensed several schemeswith 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 toanswer 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 infairer 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 distinctyet complementary information that could guide new proposal. For example, assume thata cloud provider wants to add SLA Support to its services. First, the provider needs todefine what high-level information must be included in the contract, such as a validityperiod or specific penalties. The study PS17 addressed this possibility. Next, the providerneeds to choose which metrics are appropriate for its provided service type (IaaS, PaaS, orSaaS). The study PS02 could help with that decision, addressing SLA metrics by servicetypes. To monitor these metrics, the provider needs to define them. The study PS01shows how to do so with an XML-based language. Finally, the cloud provider wants tooffer its customers a system to manage their costs for SLA penalties. The study PS08 canrecommend economic models to guide the implementation of such a functionality.

41

Page 60: Monext: An Accounting Framework for Federated Clouds

2.6. DISCUSSION

The analysis performed on the selected studies focused on four topics: research typeclassification, contribution type classification, the relationship between research typeand research questions, and finally accounting models analysis. We next discuss eachclassification.

The classification of research type revealed a disparity between the number of studieswe considered more scientific, offering some sort of validation, and the less scientificstudies based, for example, on arguments and experience reports. We suggest focusingon the 12 studies classified as Solution Proposals and investigating whether these studieshave evolved or whether advances along their lines of inquiry would be possible.

Utilization of the classification of contribution type depends on what the researcher’saims, because he can take advantage whatever contribution. When dealing the types ofcontributions which yielded the fewest results (method and technique), any new proposalis 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 newones.

The relationship between research types and research questions can also be used toidentify research opportunities. First, it must be emphasized that RQ1 (accounting taxon-omy) 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 andsee what could be relevant for cloud computing. We can also conclude that the researchtypes Validation Research and Evaluation Research proved be immature for applicationto 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 samereason, RQ4 treats a specific aspect of SLA composition, and we searched for proposalsof configurations, not merely how they could be used.

Classification of the accounting models was based on seven features: standard ac-counting process, federated clouds, graphical user interface, SLA support, multiplepayment model, flexible charging policy specifications, and RaaS. We found that none ofthe models offered all of the investigated features, and again research gaps were evidentsuch as the RaaS model. Considering all these results, we could start to design ouraccounting framework, because the mapping study provided all the necessary informationto be filtered for what we judged necessary. From this process was born the Monextframework.

42

Page 61: Monext: An Accounting Framework for Federated Clouds

2.6. DISCUSSION

First, an accounting solution needs a process, and RQ1 introduced a robust taxonomyfor this purpose. Previously, we discussed the possibility of not using all the accountingfeatures when constructing an accounting solution, but we decided to use all of them inorder to build a comprehensive, generic framework.

Regarding the architecture, the framework must encompass complex environmentslike federated clouds, so it must also facilitate simpler structures. Given that require-ment, among the five accounting models, the studies PS06 and PS23 are related to theRESERVOIR project and addresses federated clouds. Therefore, at first, we will base ourdecisions on RESERVOIR characteristics, aiming to find ideas to design the architectureof 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) whichserve as a guide for what requirements an accounting system must fulfill. The studyanalyzed usage scenarios presenting typical challenges for federated clouds to derive theseprinciples. In our solution, we will treat these principles as requirements; however, toconstruct a more complete proposal, we will add and implement all the features analyzedin Section 2.4.4, resulting in 13 requirements:

• REQ-01 Location Unawareness: Account for the VMs as a service, runninglocally or remotely no matter where it is running.

• REQ-02 Flexible Data Format: It should be possible to include additional usageinformation metrics.

• REQ-03 Service Elasticity: The number of VMs underlying and fulfilling aservice can be scaled due to service elasticity. The accounting system must bedesigned to handle such a scenario.

• REQ-04 Service Accounting: The accounting system must be suitable for longrunning 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 notjust for each VM.

• REQ-07 Adaptable Design: The accounting system must be open for modifica-tions to cope with future changes and enhancements.

• REQ-08 Complex Pricing: The function that calculates prices from the accountinginformation must be able to incorporate complex pricing rules.

43

Page 62: Monext: An Accounting Framework for Federated Clouds

2.7. CHAPTER SUMMARY

• REQ-09 Standard Accounting Process: A unified, formal accounting processmust be used.

• REQ-10 SLA Support: It must be offered for the customer a mechanism to specifya Quality of Service (QoS).

• REQ-11 Multiple Payment Models: pre-paid and post-paid models must beoffered.

• REQ-12 Multiple Charging Policy Specification: The accounting system admin-istrator must be able to specify charging policies without stopping the system.

• REQ-13 Resource as a Service: The economic paradigm RaaS must be supported.

2.7 Chapter Summary

This chapter presented the results of a systematic mapping study of accounting models forcloud computing. This study was motivated by the lack of an accounting system in somefederated cloud platforms. Therefore, the main goal of this review was to determine whatissues have been studied so far to support the development of a new accounting frameworkfor this scenario. A secondary objective was to yield guidelines to aid researchers inplanning future research.

Therefore, following a set of strict steps, we searched 580 papers, selecting 23 studiesto answer four research questions. As its major contribution, this chapter provides anoverview 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 otherfields, such as telephony, that used the term widely before cloud computing becamea research trend.

• In general, there are few studies on accounting models for cloud computing, andthe existing ones were conducted mainly in industry environment and report onreal-life experiments. Additionally, there is a need for new proposals related tofederated cloud infrastructure. Topics related to SLA and security, on the otherhand, have gained considerable attention in recent years.

• Despite the many existing pricing scheme types, detailed, rather than brief, explo-ration of their application is needed.

44

Page 63: Monext: An Accounting Framework for Federated Clouds

2.7. CHAPTER SUMMARY

• For the composition of SLAs, some studies propose general items for the contract(e.g., scope, penalties, restrictions), and others propose specific metrics. Studyingthese results can aid in developing new solutions that combine proposals.

Finally, we filtered much data yielded by the mapping study and generated the genericaccounting framework Monext, which is presented in the next chapter.

45

Page 64: Monext: An Accounting Framework for Federated Clouds

3Monext: 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 morerecently cloud computing.

The systematic mapping study presented in last chapter allowed us to observe a set oflimitations among the existing accounting models. These findings in addition to eightaccounting principles generated thirteen requirements. We followed them to build aflexible accounting framework focused on IaaS, called Monext (illustrated in Figure3.1). In this context we consider a framework a set of processes and techniques used tosolve a problem. With Monext, private clouds or even simple IT companies may controltheir computing resources under a financial aspect enabling to sell these resources toend customers (Figure 3.2). This chapter presents such an accounting framework whichaims to manage the accounting process as a whole, from usage information recording topayment.

46

Page 65: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.1 Monext Requirements

Figure 3.2 Monext General View

The remainder of this chapter is structured as follows: Section 3.1 presents the Monextarchitecture under five points of view (Use Case, Logical, Development, Process, andPhysical) justifying how each requirement was fulfilled; Section 3.2 shows the detailsabout 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 structureof the software. It is the result of assembling a certain number of architectural elementsin some well-chosen forms. Usually, aiming to present a software architecture it is usedsome View Model through the use of architecture views. This mechanism enables tointroduce a software to different stakeholders from distinct perspectives. Aiming toaccurately 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

Page 66: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

architecture blueprints and explores the biggest number of architecture views, facilitatingits understanding (Systems, 2007).

Philippe Kruchten originally presented the 4+1 View Model to describe software-intensive systems. However this approach is today an “architecture style" to organize anyapplication architecture into five views, depicted in Figure 3.3 and listed following:

• Use Case View: also called Scenarios, it describes the functionality of the systemfrom the perspective from the outside world.

• Logical View: supports the functional requirements which the system shouldprovide 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 andreflects its distributed aspect.

Figure 3.3 The “4+1" view model

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

A glossary, also known as an vocabulary, or clavis, is an alphabetical list of terms in aparticular domain of knowledge with the definitions for those terms. The following listexplain some important terms of our scope.

48

Page 67: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

• Account: Represents the proper customer which can pay for the use of VMs.

• Anomaly: It happens when something unexpected occurs, something differentfrom the specified in the SLA.

• Charging Policy: A charging policy is a mechanism that establishes rules toconvert technical resource usage records into monetary information. In our contextmeans 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 inwhich focus on the performance requirement.

• Payment Method: Payment employed by a customer, such as cash, check, moneyorder, or credit card with order or upon invoicing; also called payment type.

• Payment Model: Represents how the customer desires to pay for its consumedresources, classified in two types: pre-paid model in which he has to pay for theconsumption in advance buying credits; and post-paid model in which he pays onlyafter the consumption.

• Service Level Agreement (SLA): A SLA is a negotiated agreement between twoparties, where one is the customer and the other is the service provider. The SLArecords are common understanding about services, priorities, responsibilities, andwarranties.

• Service Level Indicator: Represents the possible metrics included by a SLA to bemonitored, for example, availability of 99%.

• Usage Records: Means how much resource the customer have been used. Aunique usage record is a kind of snapshot with the amount of resource used thattime.

• Virtual Machine Type: Represents a possible configuration of a Virtual Machine(VM), including its potential of Memory, CPU and in our context, involving thecorresponding price.

3.1.2 Use Case View

As aforementioned, this view describes the system functionalities from the outside worldperspective. It contains diagrams describing what the system is supposed to do from ablack box perspective. All other views use this view to guide them. The Monext use

49

Page 68: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

cases are presented in Figure 3.4 and its descriptions in Table 3.2. Due the limited scopeof a dissertation and our goal to focus on the core aspects of the framework we omittedthe use case flows descriptions.

Figure 3.4 Monext Use Case View

Table 3.1: General Use Cases Description

Use Case Description Requirements

Customer

Reports

The Customer can visualize reports including financial or usage information. REQ-11

Inform Bill

Paid

A generated Bill may be in one of three states (OPENED, EXPIRED, PAID); when

created, its state is OPENED, when the bill’s due date is exceeded it becomes EXPIRED;

finally when the cloud provider (Admin) receives some customer payment he must

inform the corresponding Bill to change its status to PAID.

REQ-09

Specify

Prices

Before the system starts the resources monitoring, the Admin must specify what prices

he desires to charge for.

REQ-08 REQ-14

REQ-15

Configure

Collector

Agent

The framework must collect how much resource the customer have been used (usage

records) to next, charge him. The Admim must specify in what frequency the usage

records are collected.

REQ-08

Admin

Reports

The Admim can visualize reports related to administrative issues. REQ-11

50

Page 69: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Generate

Bills

The system automatically generates bills for all active Accounts in the last day of each

month.

REQ-08 REQ-05

REQ-06

Collect

Usage

Records

When the instances (VMs) start, usage records are collected. REQ-03

Monitor

Pre-Paid

Accounts

A prePaid model is applied in case of the Customer desires to pay a limited amount of

usage credits before use it. When the Customer uses a pre-paid model the system may

terminate instances in case of credits completion.

REQ-05 REQ-12

REQ-13

Manage

Customer

Information

The Customer can include, exclude and update his profile. This use case is expanded in

Figure 3.5

REQ-11

Manage

Information

of Domain

Entities

The Admin can include, exclude and update information about Domain Entities as for

example define what are the types of VMs available. This use case is expanded in Figure

3.5

REQ-11

Figure 3.5 Use Cases: Manage Information of Domain Entities and Manage Customer Informa-tion in an expanded way.

Table 3.2: Specific Use Cases Description

Use Case Description Requirements

Customer

Reports

The Customer can visualize reports including financial or usage information. REQ-11 REQ-09

51

Page 70: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Manage

Virtual

Machine

Type

The Admim can include, exclude and update instance types (Virtual Machines’

configurations). At this moment the Admin may specify the price for each configuration,

similar to the Amazon AWS EC21 does by default.

REQ-11 REQ-09

Manage

Data Centers

The Admim can include, exclude and update information about data centers which make

part of the federated cloud. Similar to “Virtual Machine Type" here the Admin may

specify a tariff for each data center representing its computing potential.

REQ-09 REQ-10

REQ-11

Manage

Charging

Policies

The Admim can include, exclude and update charging policies. Such charging policies

are specified using a DSL presented in section 3.2

REQ-08 REQ-11

REQ-05 REQ-12

REQ-13

Manage

SLA

The Customer can include, exclude and update its desired Service Level Indicators for its

Service Level Agreement. The used metrics are BANDWIDTH (the amount of data that

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)

REQ-11 REQ-12

REQ-05

Manage

Payment

Information

The Customer can include, exclude and update its payment information. It involves its

Payment Method (credit card, cash etc.), and its Payment Model (pre-paid/post-paid).

REQ-11 REQ-13

Manage

Personal

Information

The Customer can include, exclude and update its personal identification. REQ-11

3.1.3 Logical View

The logical view primarily supports the functional requirements in which the systemshould provide in terms of services to its users. The system is decomposed into a set ofkey 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 toidentify common mechanisms and design elements across the various parts of the systemin a more detailed level (Kruchten, 1995).

Monext includes two main modules depicted in Figure 3.6. The first module is calledJiTCollectorAgent. It reads periodically the VMs consumed resources into the cloud and

1http://aws.amazon.com/pt/ec2/pricing/

52

Page 71: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

sends this data to the second module, JiTProcessingService.

Figure 3.6 Monext General Architecture

JiTProcessingService is responsible for the central processing component that per-forms tasks regarding collected data treatments and generation of bills. This collected datais 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 JiTAnomalyDetec-

tor is responsible for collecting and sending network anomalies to JiTProcessingService.An anomaly means non-compliance with a SLA. To collect network information, theJiTAnomalyDetector is hosted in a central server but identifies in which data center theanomaly occurred. JiTProcessingService receives and stores the anomalies for furtherbill compensations so that Monext provides SLA support.

It is important to note that the solution is independent from the complexity of an IaaSarchitecture, including federated clouds platforms, since the collecting points are locatedinside 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 frameworkarchitecture under a package structure. Monext architecture was based on the Account-

ing Process Taxonomy (Ruiz-Agundez et al., 2011) and it was divided between twomacro modules: jit_collector_agent and jit_processing_service. The jit_collector_agent

is responsible for collecting the usage records from the Virtual Machines whereasjit_processing_service receives these usage records and charge for them. In addition,

53

Page 72: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

jit_processing_service separates the function accounting from others due its frequentdatabase access characteristic. Others two packages are deployed similar to JiTCollector-Agent: jit_anomaly_detector_agent (responsible for report anomaly occurrences) andjit_provisioner (terminates instances in case of pre-paid payment models). The nextsub-sections detail this logical view evidencing the main respective classes.

Figure 3.7 Monext Package Structure

jit_collector_agent

Figure 3.8 shows the classes of jit_collector_agent package. The accounting processstarts with collecting information. This function is performed by the class CentralMeter

and it collects information when the VM starts. CentralMeter implements the projectpattern 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 thecorresponding VM and Data Center (JiTDC). These identifiers are important becausedifferent data centers may apply different charging policies. Finally, the usage recordwill be sent by the method sendCollectedData() in Mediator class which in turn has aninstance of CentralMeter.

54

Page 73: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.8 jit_collector_agent package

accounting_manager

The module jit_processing_service includes six sub-packages. The first package, account-

ing_manager is responsible for treats and persists usage records for subsequent charging(Figure 3.9). The UsageRecord class keeps information regarding the resource usage, theAccount, VM and data center. A SummaryUsageRecord instance is created for each VMat each month and grouping usage records is constantly updated until the month ends.The SchedulerFinishInstances class in turn, monitors pre-paid Accounts and notifies theexternal jit_provisioner package when the limit is exceeded. This function fulfill theREQ-11 Multiple Payment Models requirement, since pre-paid and post-paid modelscan be applied with Monext. Finally, the CommunicationServicePool works as a buffer toeffectively receive the usage records from the VMs.

Figure 3.9 accounting_manager package

55

Page 74: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

pricing_manager

The pricing_manager package focuses on classes where the cloud administrator mustspecify details about the infrastructure and its prices (Figure 3.10). The VM classrepresents a virtual machine which is associated with a specific customer (Account). TheVM also keeps its resource consumption through the entity SummaryUsageRecord. Itinforms 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 monetaryrates, in the same way as JiTDC.

Figure 3.10 pricing_manager package

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 necessaryinformation is kept in the ChargingRecord class, including: the period (month); whichconsidered VM/data center; the consumed resources (SummaryUsageRecord); and acharging policy. The charging policy can be of FlexibleChargingPolicy type (specifiedwith VeloZ) or of DefaultChargingPolicyEnum type (hard coded charging policies). Usingthe CurrentChargingPolicy class, the administrator specifies what policy is the currentone (flexible or default). The ChargingService class calculates the totalPrice field in theChargingRecord.

56

Page 75: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.11 charging_manager package

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 performstwo functions: the generation of bills for all or individual Accounts; and the payment ofa specific debit. The third class, SchedulerBillsGeneration, triggers automatically thegeneration of bills at the end of each month.

Figure 3.12 billing_manager package

57

Page 76: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

financial_clearing_manager

The financial_clearing_manager package joins simple classes related to the payment andinformation detail task (Figure 3.13). When the customer is registered in the system itmust specify the PaymentInformation, considering the PaymentMethod (credit card data)and the PaymentModel (pre-paid or post-paid). Another class, AccountingReport, is ageneric class used to format detailed financial and resource consumption informationpresented to the system user.

Figure 3.13 financial_clearing_manager package

user_manager

In the user_manager package (Figure 3.14), the Account class represents the customerwhich consumes the cloud resources. It encompasses: the PaymentInformation, declaredin 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 VM’s access credential (Credentials class).

58

Page 77: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.14 user_manager package

3.1.4 Development View

The Development View focuses on the actual software module organization on thesoftware development environment. The subsystems are organized in a hierarchy oflayers. Each layer provides a narrow and well-defined interface to the layers above it.It minimizes dependencies between modules and allow simple release strategies layerby layer. The Development View takes into account internal requirements related to theease of development, software management, reuse or commonality, and to the constraintsimposed by the programming language. The development view serves as the basis forrequirement allocation (Kruchten, 1995).

Arguably, layering is a common best-practice pattern used by software architectsto break apart complex systems. In a layered architecture, the principal elements orcomponents are arranged in the form of a layered cake where each layer rests on a lowerlayer. 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 (closedarchitecture) or services by all the lower layers (open architecture) (Gerber et al., 2007).

RESERVOIR’s 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 serviceprovider (a third entity that resells the service). The Billing Layer is responsible forpayment models management (pre/post paid), and the Accounting Layer focuses oncollecting and managing the usage data.

Although the RESERVOIR layered architecture includes some accounting functionslike Billing, it does not implement other important functions formalized by Ruiz-Agundezet al. (2010c), like Metering, evidencing the possibility of improvement in adopting a

59

Page 78: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Standard Accounting Process. Thus, Monext combined the RESERVOIR layered archi-tecture idea with such accounting process due the clear separation of responsibilities. Soit was necessary to allocate each function to its appropriate layer, taking into account theirrelationships. Table 3.3 presents the functions of the standard accounting process; Figure3.15 (a) shows the accounting process flow; Figure 3.15 (b) shows the RESERVOIRlayered architecture; and Figure 3.15 (c) represents our new proposed composition.

Table 3.3 Taxonomy of Accounting Process Ruiz-Agundez et al. (2010c)

Concept Function

Pricing 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

Clearing

Includes activities from a commitment for a transaction to its settlement. In the case of resource accounting,

this function implies the payment of a bill.

60

Page 79: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.15 (a) Accounting Process (Ruiz-Agundez et al., 2010b); (b) RESERVOIR layeredarchitecture (presented in Section 2.3.2); (c) Monext in Layers, combining the Ruiz Agundez’saccounting process and the RESERVOIR layered architecture idea.

As can be seen in Figure 3.15 (c), we kept the Business Layer term but renamedBilling Layer as the Processing Layer and the Accounting Layer as the Collector Layer.It made more sense to group those functions with processing characteristics separatelyfrom those functions with low level aspects related to collector actions. In addition,we named the functions as Managers, emphasizing that they transformed into systemcomponents. Lastly, we split the Business Layer based on two actors: Admin can specifynew charging policies and other system configurations; the Customer can register hisdesires related to SLAs as well as access detailed reports. Therefore the Monext wasdesigned based on this layered architecture style and implementing the Ruiz Agundez’saccounting process, fulfilling the REQ-09 Standard Accounting Process requirement.Such a strategy enabled us to build an uncoupling solution.

61

Page 80: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

3.1.5 Process View

The process view, or process architecture, describes the view of the architecture thatincludes running processes and instantiated objects that exist in the system. It describesimportant concurrency and synchronization issues. Describes how the run-time system isstructured as a set of elements that have run-time behaviour and interactions. Run-timestructure often bears little resemblance to the code structure. Such view is useful forthinking about run-time system quality attributes, such as performance and reliability(Kruchten, 1995). This section complements the previous ones, since it presents themain framework components JiTCollectorAgent and JiTProcessingService, focusing ona run-time perspective.

JiTCollectorAgent

VM migration is an inherent characteristic of virtualization and cloud computing. Lookinginto this aspect, Monext encompassed such characteristics as collecting usage informationfrom inside the VM through an agent.

This agent enables the proper machine to inform its consumption. Using percentageas a unit of measure the agent capture the usage information called usage records. So, itis stored and processed by the JiTProcessingService, outside the infrastructure or even thecloud. We called this approach a Remote Collecting Strategy. Since it does not requirecomplex deployment, this strategy enables charging from both, virtual and physicalmachines even in small companies.

Such an option was adopted because it was previously used by Narayan et al. (2012) ina similar way and attends to the VMs migration, running locally or remotely. Thus, a VMcould migrate even between data centers, making the Remote Collecting Strategy moreappropriate. Using this approach, the REQ-01 Location Unawareness requirement wasattended 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 API2 to collect

the usage information. The Hyperic’s System Information Gatherer (SIGAR) providesa couple of possible metrics like system memory, swap, CPU, load average, uptime,and network information. However, we focused on collecting only two traditional andmain hardware metrics (memory and CPU) for this Master research, but it is includedas a future work to include other metrics. Next, we provide this information as total

2http://www.hyperic.com/products/sigar/

62

Page 81: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

percentage captured in each second or in a configurable frequency. In this way, mergingthe remote collector feature with this API it was possible to solve the REQ-02 FlexibleData Format requirement which notes that “It should be possible to include additional

usage information metrics". Thus the agent can be evolved to also monitor applicationsand catch other metrics.

The communication between JiTCollectorAgent and JiTProcessingService utilizesthe Advanced Message Queuing Protocol (AMQP)3. The organizations JP Morgan,

iMatix, Cisco, IONA, Novell, Redhat jointly developed such protocol, which is an openstandard on application layer protocol. The goal is to provide real-time, low-cost, reliablemiddleware communication. It defines the network communication rules and servicesbuilt on top of it. AMQP protocol is widely used in the financial industry to publishand subscribe information. AMQP implementations include OpenAMQP, Apache Qpid,RabbitMQ and other related products (Xiong and Fu, 2011).

We chose the message broker RabbitMQ4, since it is a robust messaging for appli-cations; runs on all major operating systems; and is open source. RabbitMQ enablesdevelopers of messaging solutions to benefit not only from AMQP, but also from one ofthe most proven systems in use, the Open Telecommunication Platform (OTP). OTP isused by telecommunications companies to manage switching exchanges for voice calls,VoIP, and now video. These systems are designed never to go down even when handlingvast user loads. As such systems cannot be taken offline, they have to be extremely flexi-ble; for instance, it must be possible to ’hot deploy’ features and fixes whilst managingconsistent user SLAs (RabbitMQ, 2007).

The main idea of RabbitMQ is simple: it accepts and forwards messages. A programthat sends messages is a Producer. A Queue is the name for a mailbox and it livesinside RabbitMQ. Although messages flow through RabbitMQ and applications, theycan be stored only inside a queue. Besides it can be used an entity called Exchange

which distributes message copies to specific queues using rules named bindings. Finallya Consumer is a program that waits to receive messages (RabbitMQ, 2012) (Figure 3.16).

3http://www.amqp.org/4http://www.rabbitmq.com

63

Page 82: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.16 RabbitMQ Overview

The use of RabbitMQ allowed the JiTCollectorAgent to send messages from the VMto specific consumers implemented by a CommunicationService class. To mitigate theoverload 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 thatonly receives messages from VMs it owns. It is important to mention that this strategy isused to receive both, usage records and network anomalies (for SLA compensations), asdepicted in Figure 3.17.

Figure 3.17 Monext and RabbitMQ

JiTProcessingService

As previously mentioned, the JiTProcessingService module treats all the accountingprocess functions related to formatting and filtering the collected raw data and generatebills. To keep the architecture consistent, this module was designed following such aprocess. Figure 3.18 shows the main entities and their acronyms. It illustrates generallyhow we implemented the core functionalities. Monext is a system wherein serviceproviders can sell computational resources to final customers, which in turn creates aregister with a specific access policy called an Account.

The first task performed by the administrator before “turning on" the accountingsystem is to specify the possible Virtual Machine Types (VMT) with their capacity andcorresponding monetary rates. This is similar to the Amazon AWS EC25, which offers

5http://aws.amazon.com

64

Page 83: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.18 Monext Accounting Process

different instance configurations. After this pricing configuration, one Account can createas 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 Monextthe number of VMs underlying a service can change dynamically, and the accountingsystem does not care about where the VM is running. Only if the VM is active, itsJiTCollectorAgent can send usage records. As the system performs constant collecting,the accounting task is also constant and not time frame dependent enabling long runningservices. 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). How-

ever, as mentioned in Section 3.1.5, there is a Java Thread acting as a subscriber thatreceives 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 iscreated for each VM at each month and is constantly updated until the month ends. SURallows the use of not only PostPaid but also a PrePaid payment model, since SUR alwayskeeps the current amount of consumed resources.

When the current month ends, and the functions pricing, metering, mediator, and

65

Page 84: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

accounting have been executed, then it is time to calculate the customer’s debits andgenerate the bills automatically. Accordingly, in the charging phase, a Charging Record(CR) is created. The CR represents the calculated monetary data about one specific VM’sconsumption 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, representsthe current policy. The third, VMT, contains the price of that VM configuration. Fi-nally, some compensation is included in case of SLA violations, fulfilling the REQ-05Compensations and requirement which says: “Both usage and compensations (due to

breaking SLAs) must be accounted for". The SLAs are previously specified to eachcustomer when they are registered, fulfilling the REQ-10 SLA Support requirementwhich 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 managedon a per service basis and not just for each VM. So one bill encompasses all consumedservices 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 clearingphase. Roaming is next to billing, meaning that the customer can consume resourcesfrom 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 informa-tion. It was important to be fault tolerant and provide an advanced suite test tool. Thesecond aspect was also appointed by the Mapping Study as one limitation in the existingaccounting systems related to the REQ-11 Graphical User Interface requirement. Thethird 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 en-

hancements". The Grails6 framework was chosen to mitigate these respectively problemsas Grails provides such functionalities through an advanced suite test tool, a web-basedinterface and a Model-View-Controller (MVC) organization. The MVC architecture styleseparates software into models representing core functionality, views which display themodels to the user, and controllers which let the user change the models (Mahemoff andJohnston, 1999). Figures 3.19 and 3.20 present two web page screenshots.

6http://grails.org/

66

Page 85: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

Figure 3.19 Monext - Homepage

Figure 3.20 Monext - Charging Policy Specification Page

3.1.6 Physical View

The physical view is concerned with the topology of software components of the physicallayer, as well as the physical connections between these components. This view is alsoknown as the deployment view. It encompasses the nodes that form the system’s hardwaretopology on which the system executes; it focuses on distribution, communication and

67

Page 86: Monext: An Accounting Framework for Federated Clouds

3.1. ARCHITECTURE DESCRIPTION

provisioning. The software executes on a network of computers, or processing nodes.The various elements such as processes, tasks and objects need to be mapped to the nodeson which they execute (Systems, 2007).

Figure 3.21 presents such perspective of Monext. There are three types of elementson this diagram: The first represents the nodes, called here as Devices which representsthe proper machines where the software components execute; The second, the Artifacts

represent these software components; and the third is responsible for running the applica-tions called ExecutionEnvironment in which must be a Java container to manage the webapplication. From left to right, the users Customer and the framework Administrator canaccess the web application (JiTProcessingService) through the HTTP protocol, whereasa Load Balancer may be configured to distribute these accesses between a cluster ofApp Servers. The application needs a database, and the MySQL Server was used as anexample. Finally, the component JiTCollectorAgent must be installed in a VM Imagebefore to be started, configuring to whom it belongs (which Account) and the frequencyto send usage records.

Figure 3.21 Monext Deployment View

The Appendix A present how to deploy the JiTProcessingService and JiTCollec-

torAgent 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 itoffers illustrated with examples.

68

Page 87: Monext: An Accounting Framework for Federated Clouds

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 accountingsolution which offers a programming language to leverage this functionality. For thisreason we stated the requirement REQ-12 Multiple Charging Policy Specification andproposed the VeloZ (Monext-Charging Policy Language), a programming language forcharging policies specifications.

Charging policies are mechanisms that establish rules to convert technical resourceusage records into monetary information. It is a formula or algorithm used every timewhen generating a bill. VeloZ allows IaaS providers to specify its own charging policiesand control its consumption in a financial aspect. However, whether the company doesnot want to configure it, the Monext framework provides two default hard coded chargingpolicies:

• VOLUME_TIME: The price is calculated using the amount of data in terms ofaverage resource usage and time consumption;

• VOLUME_TIME_LOCATION: The price is calculated using the amount of datain 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, theMonext 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 speci-fication languages that offer through appropriate notations and abstractions expressivepower focused on, and usually restricted to, a particular problem domain. VeloZ is anexecutable language that provides default and pre-calculated variables, proper to theIaaS accounting domain. VeloZ is based on the expression paradigm. An expressionin a programming language is a combination of explicit values, constants, variables,operators, and functions. These elements are interpreted according to the particular rulesof precedence and in association with a particular programming language that computesand then produces another value.

Such a process, as mathematical expressions, is called evaluation. The value can beof several types, such as numerical, string, and logical. For example, 2+3 is an arithmetic

69

Page 88: Monext: An Accounting Framework for Federated Clouds

3.2. VELOZ

and a programming expression which results in 5. A variable is an expression becauseit denotes a value in memory, so y+6 is also an expression. In general, an expression iscomposed of a single entity (constant, variable, etc.) or even of an operator (such as +,cons, etc.), applied to a number of arguments (or operands) which are also expressions(Gabbrielli and Martini, 2010).

Aiming to clarify how VeloZ works, Code 3.1 expresses its specification by thestandard BNF (Backus Naur form) grammar notation (Backus, 1978). The grammar of alanguage is usually presented with rules that define a precise syntax.

Code 3.1 VeloZ by Backus Naur Form1 C h a g i n g P o l i c y : : = E x p r e s s i o n2 E x p r e s s i o n : : = Value | UnaryExp | BinaryExp | Id3 Value : : = C o n c r e t e V a l u e4 C o n c r e t e V a l u e : : = I n t e g e r V a l u e | F l o a t V a l u e | BooleanValue5 UnaryExp : : = "not" E x p r e s s i o n6 BinaryExp : : =7 E x p r e s s i o n "+" E x p r e s s i o n8 | E x p r e s s i o n "-" E x p r e s s i o n9 | E x p r e s s i o n "*" E x p r e s s i o n

10 | E x p r e s s i o n "/" E x p r e s s i o n11 | E x p r e s s i o n "and" E x p r e s s i o n12 | E x p r e s s i o n "or" E x p r e s s i o n13 | E x p r e s s i o n "==" E x p r e s s i o n14 | E x p r e s s i o n "++" E x p r e s s i o n15 D e c l a r a t i o n E x p : : =16 "dec" "{"L i s t I d"}" "in" "calc" "{"V a r i a b l e D e c l a r a t i o n"}" "in" "total"

17 "{"E x p r e s s i o n"}"18 V a r i a b l e D e c l a r a t i o n : : = Id "=" E x p r e s s i o n |19 V a r i a b l e D e c l a r a t i o n "," V a r i a b l e D e c l a r a t i o n20 L i s t I d : : = Id | Id , Id

A charging policy is an expression that can be a value, an expression (unary/binary),or a variable. In this language, we consider only concrete values such as integers,floats, or Booleans. As examples of unary expressions, we consider exchange signsof integers or the negation of a Boolean. The binary expressions include arithmeticoperations, conjunction, and logical disjunction, as all types of expressions. Finally themost significant part of this BNF is “DeclarationExp" which establishes the programstructure expressed by three blocks of code, as follows:

70

Page 89: Monext: An Accounting Framework for Federated Clouds

3.2. VELOZ

Figure 3.22 VeloZ Structure

1. dec {ListId} in: Firstly, “dec" and “in" are reserved words that limit the declarationscope of pre calculated variables. The administrator specifies a list of identifications(ListId) chosen between default variables calculated by the system and previouslydefined separated by comma, e.g., dec {cpu_rate, mem_rate} in. Only variablescorrectly written will be accepted by the compiler, and values cannot be assignedto 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 totalaverage related to a specific resource for a period of time (e.g., a month). Thesecond group is named Volume Type and reflects the amount of data in terms ofconsumed resources, indicating the total sum of usage data logged. Finally, theMonetary Type, in this case, each Virtual Machine Type has a configuration towhich is assigned a monetary rate related to the potential for each resource type.

2. calc {VariableDeclaration} in: It is responsible for the computing procedures, us-ing the variables defined in the “dec" block and new temporary variables. It enablesexpression assignments separated by comma, e.g., calc {myVar = location_rate +

mem_rate} in.

3. total {Expression}: Whereas the previous blocks had temporary declarations andcalculations, the “total" block receives the variables used to compound the final ruleof charging. For example, if the administrator desires only to charge for memoryconsumption, 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 ofclients. First, as the sizes of servers are likely to continue increasing hundreds of cores

71

Page 90: Monext: An Accounting Framework for Federated Clouds

3.2. VELOZ

Table 3.4 Default Charging VariablesVariable Description

cpu_avg CPU average consumption

mem_avg Memory average consumption

cpu_sum CPU consumption volume

mem_sum Memory consumption volume

used_time Total used time since the VM started

cpu_rate Address the CPU price

mem_rate Address the Memory price

location_rate Rate assigned to where the VM is running

time_rate Rate assigned to used time

compensation Compensation due to SLA violations

and hundreds of gigabytes of memory per server in a few years an entire server equivalentmay be too large for some customer needs. Second, selling a fixed combination ofresources is only efficient when the load customers need is known in advance and remainsstrictly constant. As neither condition is likely, the ability to dynamically mix-and-matchdifferent amounts of compute, memory, and I/O resources would probably be highlyvalued by clients. By extrapolation, compute, memory, and I/O resources will be rentedand charged for in dynamically changing amounts and not in fixed bundles. The resourcesavailable for rent include CPU, memory, and I/O resources. CPU capacity is sold on ahardware-thread basis, or even as the number of cycles per unit of time; Memory is soldon 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 ofresource types. It is possible to specify a different price for each resource type tryingto fulfill the REQ-13 Resource as a Service requirement, because if a customer asksfor more Memory, VeloZ enable the provider to charge for this increased capacity inan individual way. However, instead of heterogeneous measure types (cycles, memoryframes or bandwidth) JiTCollectorAgent captures and VeloZ uses the relative percentageof total consumed resources. With such functionality, our solution follows the economicmodel Resource as a Service. It provides a different price for each resource type, andto 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

Page 91: Monext: An Accounting Framework for Federated Clouds

3.2. VELOZ

Table 3.5 Charging Policy ExamplesDescription Charging Policy

One second using

100% of CPU

capacity costs

cpu_rate

(pre-defined in $)

dec { cpu_avg, used_time, cpu_rate} incalc {fixed_time = 1, fixed_cpu_avg = 100} in

total { cpu_rate/((fixed_time/used_time)*(fixed_cpu_avg/cpu_avg)) }

One second using

100% of Memory

capacity costs

mem_rate

(pre-defined in $)

dec { mem_avg, used_time, mem_rate} incalc {fixed_time = 1, fixed_mem_avg = 100} in

total {

mem_rate/((fixed_time/used_time)*(fixed_mem_avg/mem_avg)) }

One hour (3600

seconds) of use

costs time_rate

(pre-defined in $)

dec { time_rate, used_time} incalc {fixed_time = 3600} in

total { (used_time * time_rate)/fixed_time }

The first policy considers only CPU, the second only memory, and the third only Timeconsumption. 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, theAmazon AWS EC27 does by default. However, it is possible, since the third policy inTable 3.5 considers only the total time of consumption using as basis one hour. So, thecloud administrator just has to set a price (time_rate variable) for each VM Type as sameas Amazon AWS EC2 uses different instance types (Small, Medium, Large, Extra Largeetc.) (Figure 3.23).

Figure 3.23 Amazon AWS - On Demand Instance Types Pricing (Amazon-AWS, 2012)

7http://aws.amazon.com/pt/ec2/pricing/

73

Page 92: Monext: An Accounting Framework for Federated Clouds

3.3. CHAPTER CONCLUSION

3.3 Chapter Conclusion

This chapter introduced Monext, an accounting framework which supports charging ofIaaS. It was based on the results of a systematic mapping study focused on accountingmodels. Using these results, VeloZ, a domain specific language for charging policy speci-fication, was developed. This chapter presented the architectural framework followingthe 4+1 approach (Kruchten, 1995). In addition, how VeloZ works was detailed andillustrated with examples.

Using VeloZ, cloud administrators can specify charging policies, instead of dependingon programmers to do it for them. In addition, it is possible to apply one differentcharging policy for each data center in a federated cloud. Thus, the prices could varyaccording to the resource location.

We believe that the use of a standard accounting process (Ruiz-Agundez et al., 2010c)enables Monext be better understood and extended by other solutions. Applying the 13requirements and remote collecting strategy made it possible to perform both complexfederated cloud platforms and small data center management.

We judge Monext to be an interesting solution because it explored the union ofexisting accounting model and features to mitigate their limitations. The framework offersdifferent reports through a web-based interface and provides SLA support, among othersbenefits. The next chapter presents the results of an experiment performed jointly withMonext and a new federated cloud platform, JiTCloud, to see whether the requirementscould be applied effectively in a real-life environment.

74

Page 93: Monext: An Accounting Framework for Federated Clouds

4A Preliminary Case Study

Nothing is particularly hard if you divide it into small jobs.

—HENRY FORD (1863-1947)

As described in the previous chapters, Monext framework was developed to attend aspecific area of cloud computing, known as federated clouds. Thus, Monext followed aset of requirements to fulfil such objective, but a validation is needed to provide evidencesthat the solution works. In this context, an experimental study was undertaken to evaluatethe feasibility of the tool. We used as case study one of the four federated cloud platformsevidenced by the motivation of this work, called JiTCloud.

The remainder of this chapter is organized as follows: Section 4.1 presents thedefinition of the experiment; Section 4.2 describes the planning of the experiment;Section 4.3 presents how the case studywas performed; the interpretation of the resultsare presented in Section 4.4; and finally, Section 4.5 concludes this chapter.

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 ofthe 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 summarizedfollowing:

75

Page 94: Monext: An Accounting Framework for Federated Clouds

4.2. PLANNING

The objective of this experimental study is to analyze the Monext frameworkin order to evaluate its feasibility for the JiTCloud platform from the

researcher’s point of view.

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 casestudy will be conducted.

4.2.1 Context Selection: JiTCloud Project

As aforementioned we have chosen as a case study the JiTCloud platform. The JiTCloudis 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

Informação e Comunicação (CTIC)1. It is a federated cloud platform which proposaladdresses an alternative to build computational infrastructure to support cloud computingwhich is not based on traditional capacity planning. Inspired by the Toyota’s Just in Time

1http://www.ctic.rnp.br/web/ctic/

76

Page 95: Monext: An Accounting Framework for Federated Clouds

4.2. PLANNING

Philosophy (JiT) (Toyota, 2012), it introduces the concept of Just in Time Clouds forrepresenting a new service category in which the provider (here named “JiTProvider")allocates resources only when demanded and until there is use for them. Built uponamortized resources from a supply chain.

Amortized resource refers to the resource installed and not used to support for examplethe operation of peak demand. A JiTProvider is a public cloud computing provider thatinstead of assembling and maintaining a structure of data centers for supporting its ownservice makes use of a federation of low scale amortized resources already existinginto 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 alegitimate and fully autonomous provider that takes advantage of resources that would beirretrievably wasted without its intervention.

Each resource pool amortized over a given environment represents an abstractioncalled Just in Time Data Center (JiT DC). Each JiT DC brings some amount of resourceswith certain characteristics and capabilities. The JiT DC resources must be raised andfinely graded by the JiT Provider. Depending on the type, it can be specialized as a JiT VMto represent a specific VM within a specific JiT DC. Among the general characteristics ofa JiT DC, there is the level of service supported by its resources and conditions negotiatedor arbitrated by the owner for its use. A Just in Time Cloud is illustrated in Figure 4.1).

Figure 4.1 Composition of a JiT Cloud (Costa et al., 2010)

The JiT Resources that are integrating in JiT Data Centers can be classified intodedicated and non-dedicated types. Dedicated is when they are fully allocated for use bythe JiT Provider for a certain period of time. Non-dedicated is when their assignment ispartial, being shared in an opportunistic fashion. It has the possibility of being reclaimedby their corresponding owners without any prior warning. In the first case, there arereservation and levels of availability traded. In the second case, the resources are volatileand can suffer from failures or relocation at any time. In both cases, the provider needs to

77

Page 96: Monext: An Accounting Framework for Federated Clouds

4.2. PLANNING

deal with migration issues and take into account the necessary time to commission anddecommission the resources.

In a deployment view, depicted in Figure 4.2, the JiTCloud solution is divided intothree modules, or artifacts: CloudClient, CloudMiddleware, and JiTDC. All the threecomponents were developed using Java, and deploying them requires uncompressingthe jar files and configuring some properties related to credentials. The CloudClientgives the customer access to the cloud access. Through it, the customer can start andterminate VM instances and monitor details of his usage through a set of commands. TheCloudMiddleware performs all the control, processing, and load balancing which directsthe requisitions to the JiTDCs. The JiTDC component is deployed in a data center whichmust have installed an Eucalyptus2 Instance, a software platform for public and privateIaaS clouds. Finally, the JiTCloud project aims to use its solution to integrate data centersof Brazilian universities.

Figure 4.2 JiTCloud Deployment View

JiTCloud and Monext Integration

This subsection details the integration of the Monext framework with the JiTCloudplatform. As mentioned, the CloudMiddleware of the JiTCloud works as a centralprocessor. This component contains the sub-modules responsible for security, monitoring,and provisioning, while Monext provides the accounting system. The CloudMiddlewareis a completely decoupled module and offers a robust API which enables changing itssub-modules and their respective functionalities. Thus, Monext was adapted to followsuch an API but had to be separated from its previous structure organized with the Model-View-Controller architecture style, retaining only the Model part. This separation was

2http://www.eucalyptus.com/

78

Page 97: Monext: An Accounting Framework for Federated Clouds

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 allowsremoving 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 itspeculiarities of the wide range of saved objects (e.g., usage records). This task motivatedus to externalize some variables into a properties file in order to easily change databasesand specify other configurations. The properties are loaded when the CloudMiddlewarestarts. Figure 4.1 shows such properties.

Table 4.1 Monext Configuration PropertiesProperties Description

amqp.hostamqp.portamqp.ssl_port amqp.usernameamqp.passwordamqp.exchange.nameamqp.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 namefor the exchange of messages containing usage records (discussed in Section3.1.5). The property amqp.anomaly.exchange.name similarly, refers to theexchange specific to receive the anomalies.

schedule.billing.time.dayschedule.billing.time.hourschedule.billing.time.minute

This group defines the day, hour and minute that the bills are generatedautomatically every month.

schedule.terminate.vm.hourschedule.terminate.vm.minute

This group defines the hour and minute that the boundaries of pre-paidAccounts will be checked to possibly terminate the VMs when credits areexceeded.

hibernate.connection.driver_classhibernate.dialecthibernate.connection.urlhibernate.connection.usernamehibernate.connection.password

The third set of properties specifies credentials to access a relational database.This brings great flexibility for choosing it.

sla.supportpre.paid.model.support

The variable sla.support refers to whether the Administrator desires or not thecharging considering compensations whereas the variablepre.paid.model.support refers to whether the Administrator desires or not toenable the schedule which terminate instances automatically in case of pre-paidpayment models.

4.2.2 Evaluation Design

In this phase, the experiments to be executed are detailed, including how many objectsand factors they include. More specifically, we determine the details of the environmentconfiguration and what charging policies will be addressed.

79

Page 98: Monext: An Accounting Framework for Federated Clouds

4.2. PLANNING

The case study used a JiTCloud instance composed of two data centers at Brazilianuniversities, UFCG and IFPB. These data centers are distributed geographically andconfigured with the Eucalyptus solution. To create a more distributed configuration, wehosted 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 CloudClientwas configured in a personal computer, because it provides a simple access interface anddoes not require much computing capacity. Figure 4.3 presents this environment.

Figure 4.3 Experimental Environment

We executed three scenarios, as follows.

• Treatment 1 (T1): Successive generations of bills for only one VM using thecharging policy depicted in Table 4.2 that considers two aspects: total CPU volume(cpu_sum variable) and total time used (used_time variable). For the price ofresources, the “dec" block shows the cpu_rate variable. The “calc" block sets theauxiliary variables’ fixed_time (in seconds) and fixed_cpu_sum (in percentage);the calculation base was one hour (3,600 seconds) and 2,000 total CPU usage (inpercentage sum). The “total" block reports the price for both CPU usage and time.

• Treatment 2 (T2): Generation of only one bill after some time of consumption fora group of VMs using the charging policy depicted in Table 4.2(charging policyCP2) that considers the CPU, memory, disk, and time resources.

• Treatment 3 (T3): Generation of only one bill after some time of consumption fora group of VMs using the charging policy depicted in Table 4.2 (charging policyCP3) that considers the time resource and SLA compensation.

To better explain how the charging policy CP1 presented in Table 4.2 works, Figure4.4 displays a simplified explanation of the total calculation. Such explanation is sufficientto understand the others CP2 and CP3 charging policies.

80

Page 99: Monext: An Accounting Framework for Federated Clouds

4.3. OPERATION

Table 4.2 Evaluated Charging PoliciesId Charging Policy

CP1

dec { cpu_sum, used_time, cpu_rate } incalc { fixed_time = 3600, fixed_cpu_sum = 2000 } intotal {

cpu_rate/((fixed_cpu_sum/cpu_sum)*(fixed_time/used_time))}

CP2

dec { cpu_sum, cpu_rate, mem_sum, mem_rate, disk_sum, disk_rate, used_time } incalc { fixed_cpu_sum = 400000, fixed_mem_sum = 400000, fixed_disk_sum = 400000, fixed_time = 3600} intotal {

cpu_rate/((fixed_cpu_sum/cpu_sum)*(fixed_time/used_time)) +mem_rate/((fixed_mem_sum/mem_sum)*(fixed_time/used_time)) +disk_rate/((fixed_disk_sum/disk_sum)*(fixed_time/used_time))

}

CP3

dec { time_rate, used_time } incalc { fixed_time = 3600 } intotal {

((used_time * time_rate)/ fixed_time) - compensation}

Figure 4.4 Charging Policy A Explanation

At this stage, we did not specify how many bills would be generated or how many VMsinitialized, 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 collectthe 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 areapplied.

The operational phase of this case study consists of three steps: preparation where

81

Page 100: Monext: An Accounting Framework for Federated Clouds

4.3. OPERATION

the environment and specific details are prepared, execution, where the treatments areeffectively executed and the data is collected, and data validation where the collecteddata is validated.

4.3.1 Preparation

• Database: We used the database MySQL to retain the Monext data. A cleaneddatabase scheme was created on the CloudMiddleware’s server.

• JiTCollectorAgent: We prepared an Ubuntu Image3 to generate VMs Instanceswith the following properties: 1GHz of CPU, 2GB of Memory and 100GB of Disk.Then, we installed the JiTCollectorAgent inside this VM image. However, to simu-late the resources usage, we also prepared a mechanism to vary the consumption.We used Stress4, a deliberately simple workload generator for POSIX systems. Itimposes 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 amountof time, so we developed a script to execute the Stress during random periods inloop.

• AMQP Broker: We configured a RabbitMQ server on UFCG University’s infras-tructure to require some level of network quality in order to exchange the messagesbetween the JiTCollectorAgent and the JiTProcessingService.

• Pricing: We specify the prices using properties files. The arbitrary prices used bythe 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 fakeanomalies and sent them to the JiTProcessingService throughout the AMQP com-munication. However, we illustrate an SLA specification which we could use inthe case study (Figure 4.5).

3http://uec-images.ubuntu.com/4http://weather.ou.edu/ apw/projects/stress/

82

Page 101: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

Figure 4.5 SLA Example

4.3.2 Execution

The case study was conducted in January 2013. The first action we performed was toconfigure the CloudMiddleware to distribute the VMs equally among the data centers.Next, we performed the three treatments described in Section 4.2.2. The additionalinformation about them are described following.

• Treatment 1 (T1): This treatment was performed for only one VM. We capturedusage records over eight hours while generating 16 bills at half-hour intervals,simulating a monthly generation. The charging policy used for this treatment wasdescribed 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 (chargingpolicy 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 (chargingpolicy CP3).

4.3.3 Data Validation

In this phase, all data are checked in order to verify whether the data are reasonable andit has been collected correctly. All data was collected correctly and none VM presentedmalfunctioning.

4.4 Interpretation

After collecting experimental data in the operation phase, we aim to draw valid conclu-sions 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

Page 102: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

4.4.1 Analysis for Each Question

Question 1

Question 1 asked whether the Monext framework could charge for different resourcetypes at the same time. Thus, we verified whether two considered resource types by acharging policy effectively corroborated for the bill value. T1 supported this analysis. Wecaptured usage records for one VM over eight hours while generating 16 bills in half-hourintervals, simulating a monthly generation. This charging policy which considers CPUand 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 CPUusage (variable cpu_sum of VeloZ); time consumed (variable used_time of VeloZ); andtotal monetary value, which we called price. We plotted these results on two chartsdepicted in Figures 4.6(a) and 4.6(b).

0

10

20

30

40

50

60

0

5000

10000

15000

20000

25000

30000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Ch

arge

d P

rice

($

)

CP

U (

Sum

of

%)

cpu_sum price .......

bills

(a) Variation of CPU vs. Price

0

10

20

30

40

50

60

0

5000

10000

15000

20000

25000

30000

35000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Ch

arge

d P

rice

($

)

Tim

e (

seco

nd

s)

used_time price .......

bills

(b) Variation of Time vs. Price

Figures 4.6(a) and 4.6(b) both provide evidence of a correlation between CPU andprice and between time and price. This result indicates that both, CPU and Time wereconsidered 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. Wecaptured usage records for a group of 30 VMs over eight hours, generating only onebill after that. The charging policy used for this treatment was introduced by Table4.2 (charging policy CP2) in Section 4.2.2 and considers CPU, memory, disk, and timeresources. Therefore, focusing on the covariance of usage time (usage_time) and thenumber of usage records (ur_number) for each VM, we obtained the chart depicted inFigure 4.6.

84

Page 103: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

21820

21830

21840

21850

21860

21870

21880

21890

21900

28500

28520

28540

28560

28580

28600

28620

28640

28660

28680

28700

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Nu

mb

er

of

Usa

ge R

eco

rds

Co

llect

ed

Usa

ge T

ime

(se

con

ds)

usage_time ur_collected .......

virtual machines

Figure 4.6 Usage Time vs. Number of Collected Usage Records

As can be seen on the chart, the usage records number are almost equal to the usedtime. This result suggests that the framework can handle the VMs scalability, but sinceusage records are collected for all VMs, this case study presented a problem: There is ahigh 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 twodecisions: 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 componentscould be reorganized. In a large scale scenario, would be hosted a CloudMiddleware inconjunction with a server RabbitMQ for each group of close data centers, as depicted inFigure 4.7. However such decentralization could bring other problems.

Figure 4.7 Monext Possible Configuration

We configured the JiTCollectorAgent to send usage records at a frequency of onesecond. Due to the geographical distribution, it was impossible to use this frequencyin the Remote Collecting Strategy. Mihoob et al. (2010) studied this subject, analyzing

85

Page 104: Monext: An Accounting Framework for Federated Clouds

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. UnlikeAmazon, we aimed to provide fair, consistent billing, but a frequency of once a secondwas impracticable. Therefore, we re-ran T2 with a sending frequency of ten seconds, andthe 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 thesame output of T2.

Question 3 asked whether the Monext framework could charge for long-runningservices. Table 4.3 shows details from the charging records for each VM, including VMidentification (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). Thebill 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 cansee that, although the VM may have a problem with network and become unable to sendthe 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 asAmazon EC2, considering only time consumption.

The conclusion for Question 4 is very simple. This question asked whether theMonext framework could calculate bills considering all the customers’ usage or, in otherwords, whether all the charging records could be properly totaled in the final bill. Wemanually 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 calculatingbills and considering compensations. T3 supported this analysis. It generated only one billfor a group of 30 VMs after eight hours using the charging policy presented in Table Table4.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 eighttypes of anomalies: bandwidth, latency, and jitter. Each anomaly generates a specificcompensation, which is calculated by multiplying three characteristics of the anomaly: its

86

Page 105: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

Table 4.3 Results from Treatment 2 (T2)

vm_id disk_sum (%+) mem_sum (%+) cpu_sum (%+) used_time_a (s) used_time_b (s) cr_value ($)VM1 51831 36289 25220 28668 28668 10.08VM2 45821 39682 24682 28669 28669 10.45VM3 46829 35895 26481 28687 28687 10.29VM4 54827 32967 26485 28650 28650 9.87VM5 42576 32918 25619 28628 28628 9.68VM6 42358 35684 25487 28569 28569 10.02VM7 53968 31972 23581 28650 28650 9.15VM8 54386 39542 26581 28651 28651 10.80VM9 57918 31957 25358 28599 28599 9.48

VM10 53895 38945 25694 28636 28636 10.54VM11 42587 36791 25896 28611 28611 10.27VM12 52043 34826 23849 28620 28620 9.59VM13 42189 39857 23516 28603 28603 10.22VM14 57824 36827 21537 28643 28643 9.42VM15 43819 31548 25689 28592 28592 9.49VM16 53827 32549 25638 28665 28665 9.64VM17 51287 32457 23516 28585 28585 9.18VM18 48529 32648 23516 28688 28688 9.24VM19 41728 32584 25893 28639 28639 9.69VM20 49681 39962 22658 28635 28635 10.07VM21 52681 31254 29823 28594 28594 10.27VM22 45896 36984 28569 28637 28637 10.83VM23 57823 32654 21358 28632 28632 8.80VM24 48523 39758 24153 28607 28607 10.33VM25 45287 32548 28165 28658 28658 10.14VM26 41938 36258 24715 28602 28602 9.95VM27 52689 34585 25631 28641 28641 9.92VM28 42869 35689 29165 28584 28584 10.75VM29 55862 32694 25413 28673 28673 9.62VM30 59137 35846 21358 28597 28597 9.23

bill_value: 295.01

gravity (how much it exceeds the SLA threshold), duration, and price. Table 4.4 presentsthe eight generated anomalies which totaled $20.64.

Table 4.4 Generated “Fake" Anomalies

anomaly_id type gravity measurement_unit duration (s) price ($) anomaly_compensation ($)AN1 bandwidth 364 bits per second 300 0.00002 2.18AN2 bandwidth 319 bits per second 450 0.00002 2.87AN3 bandwidth 329 bits per second 531 0.00002 3.49AN4 latency 51 bits per second 297 0.0003 4.54AN5 latency 67 bits per second 138 0.0003 2.77AN6 latency 28 bits per second 249 0.0003 2.09AN7 jitter 15 miliseconds 258 0.0001 0.39AN8 jitter 49 miliseconds 468 0.0001 2.29

total_compensation: 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, themanually calculated sum from the anomalies (anomalies_sum) and the monetary valuefor 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 thecolumn compensation (which correspond the sum of anomalies values).

87

Page 106: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

Table 4.5 Results from Treatment 3 (T3)

vm_id used_time (s) compensation ($) anomalies_sum ($) cr_value ($)VM1 28668 20.64 20.64 7.23VM2 28669 20.64 20.64 7.23VM3 28687 20.64 20.64 7.25VM4 28650 20.64 20.64 7.22VM5 28628 20.64 20.64 7.19VM6 28569 20.64 20.64 7.14VM7 28650 20.64 20.64 7.22VM8 28651 20.64 20.64 7.22VM9 28599 20.64 20.64 7.17VM10 28636 20.64 20.64 7.20VM11 28611 20.64 20.64 7.18VM12 28620 20.64 20.64 7.19VM13 28603 20.64 20.64 7.17VM14 28643 20.64 20.64 7.21VM15 28592 20.64 20.64 7.16VM16 28665 20.64 20.64 7.23VM17 28585 20.64 20.64 7.15VM18 28688 20.64 20.64 7.25VM19 28639 20.64 20.64 7.20VM20 28635 20.64 20.64 7.20VM21 28594 20.64 20.64 7.16VM22 28637 20.64 20.64 7.20VM23 28632 20.64 20.64 7.20VM24 28607 20.64 20.64 7.17VM25 28658 20.64 20.64 7.22VM26 28602 20.64 20.64 7.17VM27 28641 20.64 20.64 7.21VM28 28584 20.64 20.64 7.15VM29 28673 20.64 20.64 7.24VM30 28597 20.64 20.64 7.16

bill_value: 215.89

4.4.2 Discussion

This subsection presents a discussion of the case study results. We observed whether andwhy the 13 Monext requirements were fulfilled.

• REQ-01 Location Unawareness: For this requirement, accounting must be per-formed as a service for VMs running locally or remotely. Therefore, the casestudy was organized to create a distributed configuration of resources (JiTDCs) andother components (CloudMiddleware and CloudClient). The results showed thatall remotely hosted VMs were accounted for using the sending frequency of tenseconds.

• REQ-02 Flexible Data Format: For this requirement, it should be possible toinclude additional usage information metrics. Therefore, a new metric related todisk usage (disk_sum, disk_avg, and disk_rate) was added. It yielded evidence thatadditional metrics can be included, due to the technology used and architecturaldesign.

88

Page 107: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

• REQ-03 Service Elasticity: For this requirement, the number of VMs underlyingand fulfilling a service can be scaled due to service elasticity. The accountingsystem must be designed to handle such scenario. Q2 focused on this issue andstatistically 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 casestudy in future work.

• REQ-04 Service Accounting: For this requirement, the accounting system must besuitable for long-running services and not limited to tasks with a limited executiontime. Therefore, the framework must account for as long as the customer desires touse the services. The case study was limited to eight hours due to the constraints ofthe data centers, but the satisfactory outputs showed that the framework is scalableand 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 consid-ering usage and compensation and aimed to answer Q5 by analyzing whether thegenerated anomalies reduced the bill value, which occurred.

• REQ-06 Service Billing: For this requirement, billing must be managed on a per-service basis and not just for each VM. The answer to Q4 showed that consumptionby all individual VMs were totaled as charging records in a unique, final bill.

• REQ-07 Adaptable Design: For this requirement, the accounting system must beopen for modifications to cope with future changes and enhancements. The casestudy fulfilled this requirement, because the constraints of the JiTCloud constraintsthe separation of the MVC architecture of Monext so that only the Model part wasused.

• REQ-08 Complex Pricing: For this requirement, the function which calculatesprices from the accounting information must be able to incorporate complex pricingrules. 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, formalaccounting process must be followed. The case study utilized almost all accountingfunctions, even the roaming function (which makes it clear that more than oneprovider is being used). The financial clearing function was not used, since it justchange the bill status and we focused on more complex functionalities.

• REQ-10 SLA Support: For this requirement, the customer must be offered a

89

Page 108: Monext: An Accounting Framework for Federated Clouds

4.4. INTERPRETATION

mechanism by which to specify a QoS desired to generate compensation later. T3considered compensation, and Figure 4.5 in Section 4.3.1 presented how SLAs arespecified using a XML-based language.

• REQ-11 Multiple Payment Models: For this requirement, pre-paid and post-paidmodels must be offered. Which model is implemented depends on when thecustomer pays and what services are used before (post-paid) or after (pre-paid)the payment. Therefore, it was more difficult to evaluate the pre-paid model,because the credits purchased must be controlled. We developed a schedule whichautomatically terminates in the case of exceeded credit limits; however, the casestudy did not implement this functionality, because we focused on in other centralfeatures.

• REQ-12 Multiple Charging Policy Specification: For this requirement, the ac-counting system administrator must have a way to specify charging policies withoutstopping the system. The charging policies written in VeloZ were specified insideconfiguration files so that the charging policy could be changed without interruptingthe system.

• REQ-13 Resource as a Service: For this requirement, the accounting system mustsupport the economic paradigm RaaS. Since we based charging policies separateon resource types, the RaaS philosophy was followed.

4.4.3 Threats to Validity

When repeating the case study, some factors should be considered, because the firstexecution had a few limitations.

• Size Scalability. According to Tanenbaum and Van Steen (2006), the size of adistributed system must be scalable; that is, it must be easy to add more users andresources. Due to the restrictions imposed by the available resources, the casestudy used a limited number of data centers and VMs. The framework should beevaluated 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 componentscan be located far from each other. Due to the small number of resources, thegeographical distribution of components (JiTDCs, CloudMiddleware, and Cloud-Client) was limited, and they were all hosted in the same country. The distributionof this framework should be expanded..

90

Page 109: Monext: An Accounting Framework for Federated Clouds

4.5. CHAPTER SUMMARY

• Time Constraint. The JiTCloud project could include the sub-modules of Mon-ext’s JiTProcessingService component only in the final period of my Masters, forthis reason the case study was performed over just few hours. The case studyshould be conducted over a month to increase its reliability.

• Simulated Context. The JiTCloud project is unfinished and does not have realcustomers, so we performed an case study instead of a case study. The case studyshould 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, andinterpretation. 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 statedthe 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 performedand undertaken The operation phase determined the specifics of the case study’s pre-conditions and execution. Finally, to draw conclusions from the case study’s output, weanalyzed and interpreted the results.

This case study offered evidence that Monext framework fulfilled its purpose workscorrectly installed inside he JiTCloud Platform. However, some improvements can bedone so that the system better handles large, complex environments. The next chapterpresents the conclusions of this research, its main contributions, and possible directionsfor future work.

91

Page 110: Monext: An Accounting Framework for Federated Clouds

5Conclusion

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 studieshave 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 properaccounting system to charge for consumed resources. Therefore, the Monext frameworkwas built (Chapter 3) to support charging IaaS in federated cloud. All design decisionswere based on the results of a systematic mapping study (Chapter 2) and evaluated in areal federated cloud platform (Chapter 4).

In this chapter, the conclusion of this work is presented. The Chapter remainder isorganized as follows. The research contributions are highlighted in Section 5.1. Futurework concerning to the research are listed in Section 5.2. Section 5.3 presents theacademic contributions. Lastly, the concluding remarks of this dissertation are describedin Section 5.4.

5.1 Research Contributions

The main contributions of this work are (a) a state-of-the-art of cloud accounting systembased on a systematic mapping study, (b) a proposed framework called Monext to supportfederated cloud platforms, and (c) an experimental study applied within the JiTCloudproject.

• Mapping Study on Cloud Accounting: We presented a study and identified themain purposes of cloud accounting, emphasizing the key challenges. This study

92

Page 111: Monext: An Accounting Framework for Federated Clouds

5.2. FUTURE WORK

was conducted based on the good practices of systematic mapping studies proposedby Petersen et al. (2008), and several important, related works were selected.

• Monext Framework: A solution to charge federated clouds was developed. Therequirements, design, and implementation of the proposed solution were presented,along with its main benefits: a domain specific language called VeloZ for chargingpolicy specifications; an adaptable design that cloud providers can manipulate tomake the solution fit their intent; It is designed to support large customers demandsindependently where the resources are hosted; and support for SLAs and pre- andpost-paid models.

• The VeloZ DSL: VeloZ allows IaaS providers to specify its own charging policiesand control its consumption in a financial aspect.

• Experimental Study: An experiment evaluating the Monext solution was based onthe process proposed by Wohlin et al. (2000), which is composed of the followingmain activities: definition, planning, operation, and interpretation. As a result, fivenull hypotheses were rejected, providing evidence of the framework’s quality.

5.2 Future Work

• Systematic Mapping Study: The mapping study discussed in this dissertationwas conducted from September to December 2011 and cloud computing areaevolves rapidly, so it is important to repeat the search to identify new scientificcontributions.

• Improvements of Monext: To optimize the Monext, enhancements and new fea-tures must be implemented: (i) new consumption metrics; (ii) investments insecurity of billing transaction and communication between VMs and the JiTPro-cessingService; (iii) isolation of the JiTCollectorAgent inside the VM, perhapschanging the Operational System Kernel; and (iv) since all consumption infor-mation is recorded, the use of advanced databases may be necessary and NoSQLsolutions probably are a good option. These four features were not implementeddue to the Masters time constraint.

• Extension of the Experiment: Since the experiment performed in this dissertationwas applied in the context of the JiTCloud Platform, it is necessary to perform moreexperiments with other scenarios with more complex data centers to improve the

93

Page 112: Monext: An Accounting Framework for Federated Clouds

5.3. ACADEMIC CONTRIBUTION

framework’s reliability. Increasing the number of used VMs is strong recommendedto provide more conclusive results.

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 Confer-

ence 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 ITcompanies quickly followed suit, accounting in cloud computing has slowly gained theattention of the scientific community, and many gaps still remain to be explored. Thesystematic mapping study introduced many of these research opportunities, while Monextfocused on specific points. However, we are confident that Monext is a comprehensivesolution, and we believe that the use of a standard accounting process (Ruiz-Agundezet al., 2010c) and Monext’s layered architectures enables it to be better understood andextended by other solutions. Applying the 13 guiding requirements and the remotecollecting strategy made it possible to serve both complex federated cloud platforms andsingle data centers. In addition, using VeloZ, cloud administrators can specify chargingpolicies themselves, instead of depending on programmers to do it. Moreover, we judgeMonext to be an interesting solution, because it explored the union of existing accountingmodels and feature to mitigate their limitations. This framework offers different reportsthrough a web-based interface, provides SLA support, and applies the emergent economicmodel RaaS, among others benefits. Finally, this dissertation provides one more step inthe maturation of cloud accounting and suggests directions for further work in this field.

94

Page 113: Monext: An Accounting Framework for Federated Clouds

Bibliography

(2005). Micro payment gateways. Enschede.

Afzal, W., Torkar, R., and Feldt, R. (2008). A systematic mapping study on non-functionalsearch-based software testing. In SEKE’08, pages 488–493.

Alhamad, M., Dillon, T., and Chang, E. (2010). Conceptual sla framework for cloud com-puting. In Digital Ecosystems and Technologies (DEST), 2010 4th IEEE International

Conference on, pages 606 –610.

Amazon-AWS (2012). Amazon elastic compute cloud (amazon ec2). http://aws.amazon.com/ec2/. Acessed: 20/12/2012.

Backus, J. (1978). Can programming be liberated from the von neumann style?: afunctional style and its algebra of programs. Commun. ACM, 21(8), 613–641.

Bailey, J., Budgen, D., Turner, M., Kitchenham, B., Brereton, P., and Linkman, S. (2007).Evidence relating to object-oriented software design: A survey. In Proceedings of the

First International Symposium on Empirical Software Engineering and Measurement,ESEM ’07, pages 482–484, Washington, DC, USA. IEEE Computer Society.

Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The goal question metricapproach. In Encyclopedia of Software Engineering. Wiley.

Ben-Yehuda, O. A., Ben-Yehuda, M., Schuster, A., and Tsafrir, D. (2012). The resource-as-a-service (raas) cloud. In Proceedings of the 4th USENIX conference on Hot Topics

in Cloud Ccomputing, HotCloud’12, pages 12–12, Berkeley, CA, USA. USENIXAssociation.

Bencomo, N., Losavio, F., Marchena, F., and Matteo, A. (1997). Java implementations ofuser-interface frameworks. In Technology of Object-Oriented Languages and Systems,

1997. TOOLS 23. Proceedings, pages 232–246.

Brynjolfsson, E., Hofmann, P., and Jordan, J. (2010). Cloud computing and electricity:beyond the utility model. Commun. ACM, 53(5), 32–34.

Budgen, D., Turner, M., Brereton, P., and Kitchenham, B. (2008). Using Mapping Studiesin Software Engineering. In Proceedings of PPIG 2008, pages 195–204. LancasterUniversity.

95

Page 114: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

Buthelezi, M., Adigun, M. O., Ekabua, O. O., and Iyilade, J. (2008). Accounting, pricingand charging service models for a guiset grid-based service provisioning environment.In H. R. Arabnia and A. Bahrami, editors, CSREA EEE, pages 350–355. CSREA Press.

Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009a). Cloud com-puting and emerging it platforms: Vision, hype, and reality for delivering computingas the 5th utility. Future Gener. Comput. Syst., 25(6), 599–616.

Buyya, R., Yeo, C. S., Venugopal, S., Broberg, J., and Brandic, I. (2009b). Cloud com-puting and emerging it platforms: Vision, hype, and reality for delivering computingas the 5th utility. Future Gener. Comput. Syst., 25(6), 599–616.

Buyya, R., Ranjan, R., and Calheiros, R. N. (2010). Intercloud: utility-oriented federationof 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, ICA3PP’10, pages 13–31, Berlin, Heidelberg. Springer-Verlag.

Cai, H., Zhang, K., Wang, M., Li, J., Sun, L., and Mao, X. (2009). Customer centriccloud 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 57–64,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:1–4:6, New York, NY, USA. ACM.

Celesti, A., Tusa, F., Villari, M., and Puliafito, A. (2010). How to enhance cloudarchitectures 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 Fernández, J. G. (2010). Sla-driven elastic cloudhosting provider. In Proceedings of the 2010 18th Euromicro Conference on Parallel,

Distributed and Network-based Processing, PDP ’10, pages 111–118, Washington,DC, USA. IEEE Computer Society.

96

Page 115: Monext: An Accounting Framework for Federated Clouds

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 requirementsspecifications techniques. In L. Williams, J. Miller, and R. Selby, editors, Third

International Symposium on Empirical Software Engineering and Measurement, pages503–505, Los Alamitos. IEEE Computer Society Press.

Costa, R., Brasileiro, F., de Souza Filho, G. L., and Sousa, D. M. (2010). Just in timeclouds: Enabling highly-elastic public clouds over low scale amortized resources.Technical Reports-Laboratório de Sistemas Distribuídos 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 accountingprotocol. In Proceedings of the 5th international student workshop on Emerging

networking experiments and technologies, Co-Next Student Workshop ’09, pages 3–4,New York, NY, USA. ACM.

Distefano, S., Fazio, M., and Puliafito, A. (2011). The cloud@home resource managementsystem. 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. InInformatics and Systems (INFOS), 2010 The 7th International Conference on, pages 1–7.

Elmroth, E., Marquez, F. G., Henriksson, D., and Ferrera, D. P. (2009). Accountingand 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 gridcomputing. In Revised Papers from the 8th International Workshop on Job Scheduling

Strategies for Parallel Processing, JSSPP ’02, pages 128–152, London, UK, UK.Springer-Verlag.

Falasi, A. A. and Serhani, M. A. (2011). A framework for sla-based cloud servicesverification and composition. In Proc. Int. Conference on Innovations in Information

Technology (IIT), pages 287–292.

97

Page 116: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

Fowler, M. (2012). Inversion of control. http://martinfowler.com/bliki/InversionOfControl.html. Acessed: 20/12/2012.

Freitas, I., da Mota Silveira Neto, P. A., O’Leary, P., de Almeida, E. S., andde Lemos Meira, S. R. (2011). Agile software product lines: a systematic mappingstudy. Softw. Pract. Exper., 41(8), 899–920.

Gabbrielli, M. and Martini, S. (2010). Programming Languages: Principles and

Paradigms. Springer Publishing Company, Incorporated, 1st edition.

Gerber, A. J., Barnard, A., and van der Merwe, A. J. (2007). Towards a semantic weblayered architecture. In Proceedings of the 25th conference on IASTED International

Multi-Conference: Software Engineering, SE’07, pages 353–362, Anaheim, CA, USA.ACTA Press.

Gohner, M. (2006). Accounting-ansatze im bereich des grid-computing. http://

tinyurl.com/87goucy. Accessed: 30/11/2012.

Goiri, Guitart, J., and Torres, J. (2010). Characterizing cloud federation for enhancingproviders’ profit. 2012 IEEE Fifth International Conference on Cloud Computing, 0,123–130.

Harmon, R., Demirkan, H., Hefley, B., and Auseklis, N. (2009). Pricing strategies forinformation technology services: A value-based approach. In System Sciences, 2009.

HICSS ’09. 42nd Hawaii International Conference on, pages 1 –10.

Henzinger, T., Singh, A., Singh, V., Wies, T., and Zufferey, D. (2010). Flexprice: Flexibleprovisioning of resources in a cloud environment. In Cloud Computing (CLOUD),

2010 IEEE 3rd International Conference on, pages 83 –90.

Hilley, D. (2009). Cloud computing: A taxonomy of platform and infrastructure-levelofferings. Georgia Institute of Technology, Tech. Rep. GIT-CERCS-09-13.

Jai, B. (2011). The economy of parallel and distributed computing in the cloud. In Proc.

Int. Symposium on VLSI Design, Automation and Test (VLSI-DAT 2011), pages 25–28.

Jain, R., Ramakrishnan, K. K., and Chiu, D.-M. (1988). Innovations in internetworking.chapter Congestion avoidance in computer networks with a connectionless networklayer, pages 140–156. Artech House, Inc., Norwood, MA, USA.

Jeremy, G. (2010). The top 250 players in the cloud computing ecosystem.

98

Page 117: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

Karsten, M., Schmitt, J., Stiller, B., and Wolf, L. (2000). Charging for packet-switchednetwork communication-motivation and overview. Comput. Commun., 23(3), 290–302.

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). What’s up with software metrics? - a preliminary mapping study.J. Syst. Softw., 83(1), 37–51.

Kitchenham, B. and Charters, S. (2007). Guidelines for performing systematic literaturereviews in software engineering. Software Engineering Group School of , 2(EBSE2007-001), 1051.

Kitchenham, B., Mendes, E., and Travassos, G. (2007). Cross versus within-companycost 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 literaturereview. Inf. Softw. Technol., 51(1), 7–15.

Kitchenham, B. A., Dyba, T., and Jorgensen, M. (2004). Evidence-based software engi-neering. In Proceedings of the 26th International Conference on Software Engineering,ICSE ’04, pages 273–281, Washington, DC, USA. IEEE Computer Society.

Kleinrock, L. (2005). A vision for the Internet. ST Journal for Research, 2(1), 4–5.

Kruchten, P. (1995). The 4+1 view model of architecture. IEEE Softw., 12(6), 42–50.

Lehmann, S. and Buxmann, P. (2009). Pricing strategies of software vendors. Business

and Information Systems Engineering, 1, 452–462.

Lindner, M., Galan, F., Chapman, C., Clayman, S., Henriksson, D., and Elmroth, E.(2011). The cloud supply chain : A framework for information, monitoring, accountingand 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

Page 118: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

of Standards and Technology (Special Publication 500-292). CreateSpace IndependentPublishing Platform, USA.

Mahemoff, M. and Johnston, L. (1999). Handling multiple domain objects with model-view-controller. In Technology of Object-Oriented Languages and Systems, 1999.

TOOLS 32. Proceedings, pages 28 –39.

Mihailescu, M. and Teo, Y. (2010a). Dynamic resource pricing on federated clouds. InInt. Conference on Cluster, Cloud and Grid Computing (CCGrid), pages 513–517.

Mihailescu, M. and Teo, Y. M. (2010b). On economic and computational-efficientresource pricing in large distributed systems. In Proc. Int. Conference on Cluster,

Cloud and Grid Computing (CCGRID 10), pages 838–843, Washington, DC, USA.

Mihoob, A., Molina-Jimenez, C., and Shrivastava, S. (2010). A case for consumer150;centric resource accounting models. In Cloud Computing (CLOUD), 2010 IEEE

3rd International Conference on, pages 506 –512.

Morariu, C., Waldburger, M., and Stiller, B. (2006). An integrated accounting andcharging architecture for mobile grids. In Broadband Communications, Networks and

Systems, 2006. BROADNETS 2006. 3rd International Conference on, pages 1 –10.

Muller, J., Krugger, J., Enderlein, S., Helmich, M., and Zeier, A. (2009). Customizingenterprise software as a service applications: Back-end extension in a multi-tenancyenvironment. In Enterprise Information Systems, volume 24 of Lecture Notes in

Business Information Processing, pages 66–77. Springer Berlin Heidelberg.

Narayan, A., Rao, S., Ranjan, G., and Dheenadayalan, K. (2012). Smart metering ofcloud services. In Systems Conference (SysCon), 2012 IEEE International, pages 1 –7.

Osterwalder, A. (2004). The Business Model Ontology a proposition in a design science

approach.

Ouyang, J., Sahai, A., and Prnyne, J. (2007). A mechanism of specifying and determiningpricing in utility computing environments. In Business-Driven IT Management, 2007.

BDIM ’07. 2nd IEEE/IFIP International Workshop on, pages 39 –44.

Pandey, T., Singh, B., Kushwaha, D., and Misra, A. (2009). Authentication and billingframework for service oriented architecture. In Systems, 2009. ICONS ’09. Fourth

International Conference on, pages 91 –95.

100

Page 119: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

Park, K.-W., Han, J., Chung, J., and Park, K. H. (2012). Themis: A mutually verifiablebilling system for the cloud computing environment. IEEE Transactions on Services

Computing, 99(PrePrints).

Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M. (2008). Systematic mappingstudies in software engineering. In Proceedings of the 12th international conference on

Evaluation and Assessment in Software Engineering, EASE’08, pages 68–77, Swinton,UK, UK. British Computer Society.

Piro, R. M., Guarise, A., and Werbrouck, A. (2003). An economy-based accountinginfrastructure for the datagrid. In Proceedings of the 4th International Workshop on

Grid Computing, GRID ’03, pages 202–, Washington, DC, USA. IEEE ComputerSociety.

Pretorius, R. and Budgen, D. (2008). A mapping study on empirical evidence relatedto 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 342–344, New York, NY, USA. ACM.

Prodan, R. and Ostermann, S. (2009). A survey and taxonomy of infrastructure as aservice 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.

com/resources/RabbitMQ_PressRelease_080207.pdf. Accessed: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 ofparallel-independent programs using pearson distributions. Parallel Comput., pages877–899.

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., Cáceres, J., Ben-Yehuda, M., Emmerich, W., and Galán,

101

Page 120: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

F. (2009). The reservoir model and architecture for open federated cloud computing.IBM J. Res. Dev., 53(4), 535–545.

Rohitratana, J. and Altmann, J. (2010). Agent-based simulations of the software marketunder different pricing schemes for software-as-a-service and perpetual software. InJ. Altmann and O. Rana, editors, Economics of Grids, Clouds, Systems, and Services,volume 6296 of Lecture Notes in Computer Science, pages 62–77. Springer BerlinHeidelberg.

Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2010a). Tarificacion flexible deservicios 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 futureinternet accounting process. In Int. Conference on Advanced Engineering Computing

and Applications in Sciences (ADVCOMP 10), pages 111–117.

Ruiz-Agundez, I., Penya, Y., and Bringas, P. (2010c). A taxonomy of the future internetaccounting process. In Advanced Engineering Computing and Applications in Sciences

(ADVCOMP 10), Int. Conference on, pages 111–117.

Ruiz-Agundez, I., Penya, Y. K., and Bringas, P. G. (2011). A flexible accounting modelfor cloud computing. In Proceedings of the 2011 Annual SRII Global Conference, SRII’11, pages 277–284, 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 andmonitoring guarantees in commercial grids through sla. In Proceedings of the 3st

International Symposium on Cluster Computing and the Grid, CCGRID ’03, pages292–, 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 634–639.

Song, J., Liu, W., and Wang, Y. (2007). Competitive pricing model for resource schedul-ing in grid computing. In Proceedings of the Third International Conference on

Semantics, Knowledge and Grid, SKG ’07, pages 406–409, Washington, DC, USA.IEEE Computer Society.

102

Page 121: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

Staples, M. and Niazi, M. (2007). Experiences using systematic review guidelines. J.

Syst. Softw., 80(9), 1425–1437.

Systems, S. (2007). Applying 4+1 view architecture with uml 2. http://tinyurl.com/cn34ssr. Accessed: 30/11/2012.

Tanenbaum, A. and Van Steen, M. (2006). Distributed systems. Principles and Paradigms.

Toyota (2012). Toyota production system (tps). http://tinyurl.com/c9wqmh3.Acessed: 30/11/2012.

Wahla, R. S. (1941). Aicpa committee on terminology. Accounting Terminology Bulletin

Review and Rsum.

Wee, S. (2011). Debunking real-time pricing in cloud computing. In Cluster, Cloud and

Grid Computing (CCGrid), 2011 11th IEEE/ACM International Symposium on, pages585 –590.

Weinhardt, C., Anandasivam, A., Blau, B., Borissov, N., Meinl, T., and Michalk, W.(2009). Cloud computing a classification, business models, and research directions.Business and Information Systems Engineering, 1, 391–399.

Weiss, A. (2007). Computing in the clouds. netWorker, 11(4), 16–25.

Wieringa, R., Maiden, N., Mead, N., and Rolland, C. (2005). Requirements engineeringpaper classification and evaluation criteria: a proposal and a discussion. Requir. Eng.,11(1), 102–107.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2000).Experimentation in software engineering: an introduction. Kluwer Academic Publish-ers, Norwell, MA, USA.

Xiong, X. and Fu, J. (2011). Active status certificate publish and subscribe based on amqp.In Computational and Information Sciences (ICCIS), 2011 International Conference

on, pages 725 –728.

Youseff, L., Butrico, M., and Da Silva, D. (2008). Toward a unified ontology of cloudcomputing. In Grid Computing Environments Workshop, 2008. GCE ’08, pages 1 –10.

Yu, J., Li, M., Li, Y., Hong, F., and Du, Y. (2004). A service-oriented accountingarchitecture on the grid. In Proceedings of the 5th international conference on Parallel

103

Page 122: Monext: An Accounting Framework for Federated Clouds

BIBLIOGRAPHY

and Distributed Computing: applications and Technologies, PDCAT’04, pages 310–313, Berlin, Heidelberg. Springer-Verlag.

104

Page 123: Monext: An Accounting Framework for Federated Clouds

Appendices

105

Page 124: Monext: An Accounting Framework for Federated Clouds

ADeploy Instructions

A.1 JiTProcessingService Deploy

This section describes how to deploy the web application using the Apache Tomcat 6.0and the MySQL Server 5.1. We omitted the installation of this environment for simplicity.Therefore, considering these execution environments installed, as the JiTProcessingSer-

vice is a Grails application its deployable product has an “.WAR" extension (the war filecan be found inside the jit_processing_service_web_dist_0.4.zip file). There is a coupleof 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 “jitprocessingser-vice.war" in TOMCAT_HOME/webapps, then it has been unpacked into webapp-s/jitprocessingservice/... You must delete this directory and all its contents. OnUnix, 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

Page 125: Monext: An Accounting Framework for Federated Clouds

A.2. JITCOLLECTORAGENT DEPLOY

It is important to highlight that the “autoDeploy" attribute in the <app>/META-INF/context.xml file must be “true", so that, the Host will attempt to deploy and updateweb 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. Aimingto deploy JiTCollectorAgent it must uncompress the jit_collector_agent_dist_0.4.zip filein 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 followingfiles:

• jit_collector_agent.jar: Executable file in which when started publishes the col-lected 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 in-stalled (1.6 version). Next, just execute the following command: java -jar jit_collector_agent.jar <interval>. For which <interval> identifies the frequency of sending messagesin 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 updatedwith the following command:

java -jar "bash /opt/jit_collector_agent/jit_collector_agent.jar <interval> > /de-v/null " -s /bin/bash

107